As a software architect, I should know what a software architecture actually is. Unfortunately, there is no consens about the definition. This pages serves as a collection with comments.
Software architecture refers to the fundamental structures of a software system and the discipline of creating such structures and systems. Each structure comprises software elements, relations among them, and properties of both elements and relations.
This is from Wikipedia and apparently comes from the book "Documenting Software Architectures: Views and Beyond". Two of the authors also wrote the primary textbook "Software Architecture in Practice". In there the definition is similar:
The software architecture of a system is the set of structure needed to reason about the system, which comprises software elements, relations among them, and properties of both.
This book is from the Software Engineering Institute (SEI) from CMU. They also published a collection of definitions which starts roughly like this article but only seems to contain slight variations of the above definition.
Architecture is the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution. –IEEE 1471
The definition of IEEE is similar to the above but extends it by considering change (design and evolution). Should change be considered in the architecture or is that rather a question of process and organization? Here is a definition which places more weight on the process.
An architecture is the set of significant decisions about the organization of a software system, the selection of structural elements and their interfaces by which the system is composed, together with their behavior as specified in the collaborations among those elements, the composition of these elements into progressively larger subsystems, and the architectural style that guides this organization -- these elements and their interfaces, their collaborations, and their composition. –Kruchten (2003) The Rational Unified Process: An Introduction
A central aspect of architecture is to split things up. Surprisingly, architecture is often not concerned with functionality. Instead architectural drivers are the ilities (useability, reusability, maintainability, testability, scalability, availability, reliability, extensibility, portability, etc). Without the ilities where is no reason to split things up. The architecture would be one blob containing all the functionality. Here is another quote about the ilites aka "common quality attributes."
Software Architecture helps to shape the design, which is used to communicate and collaborate on the implementation of the functional and non-functional requirements when producing an application while optimizing common quality attributes. –Bodje and Nasira (2013) Software Architecture at the Glance–––To Make a Long Story Short
Going to the extreme of process, some definitions focus on decision making.
We do not view a software architecture as a set of components and connectors, but rather as the composition of a set of architectural design decisions. –Jan Bosch and Anton Jansen (IEEE 2005)
Software architecture is, fundamentally, a composition of architectural design decisions. These design decisions should be represented as first-class entities in the software architecture and it should, at least before system deployment, be possible to add, remove and change architectural design decisions against limited effort. –Jan Bosch (2004) "Software architecture: The next step."
All architecture is design but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change. –Grady Booch (2006) "On design"
Software architecture is the set of design decisions which, if made incorrectly, may cause your project to be cancelled. –Eoin Woods (2010)
This is great for my ego as architect. I'm making the important decisions while these lowly developers are left with small insignificant decisions. Look how important I am!
A software craftsman has a natural rejection reflex to such aloof architects. Here is a supporting quote.
Truth can only be found in one place: the code. –Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship
In the Free Software world, I completely agree. However, in the commercial world the truth might also be found in the requirements. The requirements are what was sold to the customer and what has to be delivered in the end. Anyways, the truth is not in the architecture. The implication for me as an architect is that I have to actively tie architecture closely to the truth. At work we use the architecture model to generate some of the code. The upside is that the architecture is in sync with the code aka the truth. The downside is that the architecture must be kept in sync with the code which requires additional effort.
Martin Fowler wrote Who needs an architect?. He quotes Ralph Johnson a lot:
Architecture is the decisions that you wish you could get right early in a project, but that you are not necessarily more likely to get them right than any other. —Ralph Johnson
While it is funny and there is some truth in it, it is not good definition. There are plenty of decisions which are not architecture but still fit this definition (e.g. organizational ones). To get to the heart of the matter we must figure out why we have this wish.
Architecture is about the important stuff. Whatever that is. –Ralph Johnson
Likewise: funny but not a good definition. Plenty of non-architecture is also important.
What is important about a large software project? One possibility would be "whatever concerns many people". Here is a quote for this mindset:
In most successful software projects, the expert developers working on that project have a shared understanding of the system design. This shared understanding is called ‘architecture.’ This understanding includes how the system is divided into components and how the components interact through interfaces. These components are usually composed of smaller components, but the architecture only includes the components and interfaces that are understood by all the developers. –Ralph Johnson
I like this idea of "shared understanding" because it provides a good definition which technical aspects should not be included in architecture: The aspects where a shared understanding is not necessary because it only concerns a single component/team. It also hints at the duty of an architect to communicate with all stakeholders; to share the understanding.
My last quote tries to combine all the aspect already mentioned.
The research process produces four general metaphors for architecture, “architecture as blueprint”, “architecture as literature”, “architecture as language”, and “architecture as decision”. –Kari Smolander (2002) Four Metaphors of Architecture in Software Organizations: Finding out The Meaning of Architecture in Practice
The blueprint is about working implementation and structure. The literature is about past solutions and learning from past mistakes. The language is about common or shared understanding. The decision is about rationality or how to make good decisions.
So what is my personal view? I believe the "shared understanding" is the actual goal. That the shared understanding is used for decision making follows naturally. For the truthiness of this shared understanding we need to keep it close to the implementation. Structure and documentation is required due the cognitive limitations of us humans. Here is my definition:
Thanks to John Carter in the lobste.rs discussion I found this 2007 SEI collection of definitions.