Architecture Is About the Important Stuff
Architecture is the set of decisions that are hard to change, whatever those turn out to be.
“Architecture is about the important stuff. Whatever that is.”
To an executive
The decisions that matter most are those expensive to reverse. Leadership attention should go there, and we should look for ways to make more choices cheap to undo.
To an engineer
Spend review effort on what is hardest to change, such as data models and public interfaces. Look for ways to make those choices easier to reverse.
The idea
In "Who Needs an Architect?", Fowler, drawing on Ralph Johnson, argued that architecture is not a particular layer or diagram but the expert developers' shared understanding of a system's important parts. What counts as important depends on the system: persistence may be central to an enterprise application and a minor detail in a medical imaging one. In his words, architecture is about the important stuff. Whatever that is.
He also challenged the definition of architecture as the decisions made early. They are the decisions you wish you could get right early, but you are not more likely to get them right than any other. What makes them important is that they are hard to change.
This reframes the architect's job: find what is important and hard to change, focus energy there, and, as Fowler put it, try to remove architecture by finding ways to eliminate irreversibility in software designs.
Why it works
Attention is limited. Reviews that cover everything evenly spend most of their time on decisions that are cheap to fix later.
The cost of a mistake scales with the cost of change. A wrong logging library is an afternoon's work. A wrong data model or public contract can take years to unwind.
Reducing irreversibility reduces risk. Every decision made cheaper to change is one less decision that must be right first time.
Where it applies
- Design reviews, to decide where to spend the time.
- Architecture documentation, which should describe the important parts, not every component.
- Platform and vendor choices, contracts and shared schemas, which are typically costly to change.
- Defining the architect's role, as the person who worries about the important stuff.
How to apply
- List the decisions in play and rate each by how expensive it would be to change later.
- Spend review time on the expensive ones: data models, public contracts, event schemas, security boundaries, platform choices.
- Leave cheap decisions to the team, and say so.
- Look for ways to make expensive decisions cheaper: versioned contracts, abstraction at the right seam, migration tooling.
Example scenario
An architecture review spent its time on UI frameworks, logging formats and folder structures, but never discussed the event schema shared by 20 consuming services. A field rename in that schema later took a year to roll out.
For the next system, the team began each review by listing decisions by cost of change. The shared schema went to the top, gained explicit versioning and a compatibility check in the pipeline, and the framework and folder choices were left to the team.
Questions to ask
- What in this system will be hardest to change in two years' time?
- Is our review time going to the costly-to-change decisions or the easy ones?
- What could we do now to make this decision cheaper to reverse later?
When not to use it
- Very small or short-lived systems, where almost everything is cheap to change and a heavy focus on architecture is wasted.
How it misleads you
Declaring everything important. If everything is architecture, nothing is. The opposite trap is assuming the important stuff is the same on every system; it depends on where the real complexity lies.
Further reading
Last reviewed · Suggest an improvement