Definition of software architecture

Oct 20, 2009 | George Fairbanks

I believe there is a difference between architecture and detailed
design, but it’s hard to make a clean distinction. The problem is
that some small details are architectural while others are
not. Unfortunately, this has led some authors to say that architects
get to decide what is architecture and what is not, which is
unsatisfactory. I am in the process of developing my own definition
which explains more. Here’s my best shot:

The developers of software systems design an architecture that is
intended to handle a small set of high-level qualities or features,
such as security, throughput, plugable codecs, or standards
compliance. The decisions they make are not limited to the
highest-level design units such as the top-level components or
modules. Instead, the decisions impact the detailed design inside of
components and modules.

For example, the original Java Beans spec required a naming pattern
for exposed bean properties because it would use reflection to convert
methods like getFoo into an exposed property called Foo. Similarly,
the architecture may prohibit threads, require methods to complete
within 100ms, require computation to be divided into Jobs, and other
details that are down deep in the code.

My brother builds skyscrapers. He tells me that usually a (building)
architect will specify some low-level details but leave others to be
handled by the construction company. On a recent job, the architect
insisted that the gap between windows be quite small because this
detail was important for his intention on how the building would look.
It was then that I realized that it was the intention that was the
key: there is a “chain of intentionality” from just a few high-level
intentions of the architect that reaches down into a few low-level
details. Most of the details are left open to any reasonable
implementation, but some are constrained via a chain back to the
top-level intentions of the architect.

So, here is my definition of architecture:

The architecture of a system is the design decisions made by system
developers to achieve their top-level intentions, and the designs that
follow directly from those decisions.

The main problem I have with this definition is that it excludes
unintentional architectures. I believe that all systems have an
architecture, even if it just emerged rather than being consciously
chosen by the developers. So the definition is too constrained, but
it does help explain two things. First, architecture is not just the
top-level boxes or design decisions. Second, low-level details may be
architectural and it’s not just because of the whim of the architect.


George Fairbanks is a software developer, designer, and architect living in New York city

+1-303-834-7760 (Recruiters: Please do not call)
Twitter: @GHFairbanks