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.