Definitions of Software Architecture

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:

Tweet This
Software architecture documents the shared understanding of a software system.

Thanks to John Carter in
the discussion
I found this
2007 SEI collection of definitions.


Software architecture documents the shared understanding of a software system.

Read More