Is this Architecture?
Look for decisions!
Part of my job as Chief Architect is to review and approve system architectures. When I ask teams to show me “their architecture”, I frequently don’t consider what I receive an architecture document. The counter-question “what do you expect?” isn’t so easy for me to answer: despite many formal definitions, it isn’t immediately clear what architecture is or whether a document really depicts an architecture. Too often we have to fall back to the “I know it when I see it” test famously applied to obscene material by the Supreme Court. We’d hope that identifying architecture is a more noble task than identifying obscene material, so let’s try a little harder. I am not a big believer in all-encompassing definitions but prefer to use lists of defining characteristics or tests that can be applied. One of my favorite tests for architecture documentation is whether it contains any non-trivial decisions and the rationale behind them.
Defining Software Architecture
Enough attempts at defining software architecture have been made that the Software Engineering Institute (SEI) maintains a reference page of software architecture definitions.
The most widely used definitions include the one from Garlan and Perry from 1995:
The structure of the components of a system, their interrelationships, and principles and guidelines governing their design and evolution over time
In 2000 the ANSI/IEEE Std 1471 chose the following definition: (adopted as ISO/IEC 42010 in 2007):
The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution
The Open Group adopted a variation thereof for TOGAF:
The structure of the components, their interrelationships, and principles and guidelines governing their design and evolution over time
One of my personal favorites is from Desmond D’Souza’s and Alan Cameron Wills’ book1:
Design decisions about any system that keep implementors and maintainers from exercising needless creativity
The key point here isn’t that architecture should dampen all creativity, but needless creativity, of which I witness ample amounts. It also highlights the importance of making decisions .
Architectural Decisions
These well-thought-out definitions aren’t easy to apply, though, when someone walks up with a PowerPoint slide showing boxes and lines, claiming “this is my system architecture”. The first test I tend to apply is whether the documentation contains meaningful decisions. After all, if no decisions needed to be made, why employ an architect and prepare architectural documentation?
Martin Fowler’s knack for explaining the essence of things using extremely simple examples motivated me to illustrate the “architectural decision test” with the simplest example I could think of, drawing from the (admittedly limping) analogy to building architecture. I even took it upon myself to supply the artwork to make sure things end up about as basic as one could wish for and to pay homage to Christopher Alexander’s Pattern Sketches2.
Consider the drawing of a house on the left. It has many of the elements required by the popular definitions of systems architecture: we see the main components of the system (door, windows, roof) and their interrelationships (door and windows in the wall, roof on the top). We might be a tad thin, though, on principles governing its design, but we do notice that we have a single door that reaches the ground and multiple windows, which follows common building principles.
Yet, to build such a house I wouldn’t want to pay an architect. This house is “cookie-cutter”, meaning I don’t see any non-obvious decisions that an architect would have made. Consequently, I wouldn’t consider this architecture.
Let’s compare this to the sketch on the right-hand side. The sketch is equally simple and poorly drawn and the house is almost the same, except for the roof. This house has a steep roof and for a good reason: the house is designed for a cold climate where winters bring extensive snowfall. Snow is quite heavy and can easily overload the roof of the house. A steep roof allows the snow to slide off or be easily removed thanks to gravity, a pretty cheap and widely available resource. Additionally, an overhang prevents the sliding snow from piling up right in front of the windows.
To me, this is architecture: non-trivial decisions have been made and documented. The decisions are driven by the system context, in this case, the climate: it’s unlikely that the customer explicitly stated a requirement that the roof not be crushed. Additionally, the documentation highlights relevant decisions and omits unnecessary noise.
If you believe these architectural decisions were pretty obvious, let’s look at a very different house:
This house was designed for a different climate, a hot and sunny one, which allows the walls to be made out of glass as insulation against low temperatures is less of a concern. However, walls of glass have the problem that the sun heats up the building, making it feel more like a greenhouse than a residence. The solution? Extending the roof well beyond the glass walls keeps the interior in the shade, especially in summer when the sun is high in the sky. In the winter, when the sun is low on the horizon, the sun reaches through the windows and helps warm the building interior. Also, a flat roof with an overhang isn’t a problem in this climate. Again, the architecture is defined by a fairly simple, but fundamental decision documented in an easy-to-understand format that highlights the essence of the decision and the rationale behind it.
Fundamental Decisions Don’t Need to be Complicated
If you think the idea of building an overhanging roof isn’t all that original or significant, try buying one of the first homes to feature such a design, e.g. the Case Study House No 22 in Los Angeles by architect Pierre Koenig. It’s easily in the league of most recognized residential building in Los Angeles or beyond (aided by Julius Shulman’s iconic photograph) and surely isn’t for sale. You can tour it, though, if you sign up far in advance. Significant architecture decisions may look obvious in hindsight but that doesn’t diminish their value. No one is perfect, though: UCLA PhD students have measured that the overhang works better on the south-facing facade than west or east3.
Fit for Purpose
The simple house example also highlights another important property of architecture: rarely is an architecture simply “good” or “bad”. Rather, architecture is fit or unfit for purpose. A house with glass walls and a flat roof may be regarded as great architecture, but probably not in the Swiss Alps where it will collapse after a few winters or suffer from a leaking roof. It also doesn’t do much good near the equator where the sun’s path on the sky remains fairly constant throughout the year. In those regions, you are better off with thick walls, small windows, and lots of air conditioning.
Assessing the context and identifying implicit constraints or assumptions in proposed designs is an architect’s key responsibility. Sometimes, architects are described as the people dealing with non-functional requirements. I find that more often than not architects have to deal with non-requirements, implicit needs or assumptions that weren’t communicated at all.
Even the dreaded Big Ball of Mud can be “fit for purpose”, e.g. when you need to make a deadline at all cost and can’t care much about what happens afterwards. This may not be the context you wish for, but just like houses in some regions have to be earthquake proof, some architectures have to be management-proof.
Passing the Test
Having stretched the overused building architecture analogy one more time, how do we translate it back to software systems architecture? Systems architecture doesn’t have to be something terribly complicated. It must include, however, significant decisions that are well documented and are based on a clear rationale. The word “significant” may be open to some interpretation and depend on the level of sophistication of the organization, but “we separate front-end from back-end code” or “we use monitoring” surely have the ring of “my door reaches the ground so people can walk in” or “I put windows in the walls so light can enter”. Instead, when discussing architectures let’s talk about what isn’t obvious or something that involved heavy trade-offs. For example, “do you use a service layer and why?” (some people may find even this obvious) or “why do you use a session-oriented conversation protocol?”
It’s quite amazing how many “architecture documents” don’t pass this relatively simple test. I hope using the building analogy provides a simple and non-threatening way to provide feedback and to motivate architects to better document their designs and decisions.