Software Architecture Series – What is Software architecture?
Well till date there is no simple, short and universally accepted definition of software architecture. The Software Engineering Institute @ Carnegie Mellon University, has compiled a list of modern, classic and bibliographic definitions of software architecture ( see here ). Most of the definitions define the architecture of a system as an organisation of its components, their behaviours, interfaces and interactions.
For the time being lets pick one by Rational Unified Process IEEE
“The highest level concept of a software system in its environment. The architecture of a system [at any given point in time] is the organisation or structure of its significant components interacting through interfaces, those components being composed of smaller components and interfaces”
This is a perfectly acceptable definition, however it’s not universally accepted, the reason being “There is no highest level concept of a system. Customers have a different concept than developers. Customers do not care at all about the structure of significant components. So, perhaps an architecture is the highest level concept that developers have of a system in its environment.” – “who needs an architect“.
In simple terms, Software architecture of a system represents the system in its environment, the core components of the system, the interactions between those components and how those components are organised.
In Martin Fowler’s words “it’s about the important stuff, whatever that stuff might be”.
Martin Fowler defines software architecture as a shared understanding of the system.
This shared understanding of the system includes
- A Shared Understanding of how the system is divided into its components and how those components interact with each other.
- A Shared Understanding of the important decisions that were made and their implications.
- A Shared Understanding of the system goals and design principles.
- A Shared understanding of how the system achieves desired functional and non-functional requirements.
Till we define and universally agree on a set definition of software architecture, I think having an understand of what it is will suffice. For me the software architecture is a process, a process of thinking, defining and documenting the properties of a system to develop a shared understanding of the system among its stakeholders.
The stakeholders of the system usually include customer/business, business analysts, developers, testers, IT and infrastructure folks and sales, well just about anybody that has a vested interest in the system. For all these stake holders, software architecture means different things and this is natural as all these people view the system from different aspects. Hence it is important that the system implements the views of all these stakeholders within the given constraints.