The Software Architect Elevator — Book Notes
Posted on 16 May 2022 · 3 min read
"The new world doesn't reward architects who draw diagrams while sitting in the ivory tower. It has a lot in store, though, for hands-on innovation drivers and change agents." — Gregor Hohpe
I completed Gregor Hohpe's book The Software Architect Elevator: Redefining the Architect Role. It's a great read — I would strongly advise anyone interested in system architecture to pick it up.
Here are eight lessons I took from it.
1. Is this Architecture?
Before reading this book, I thought it was only me who was confused about the definition of architecture. Turns out it wasn't. A useful definition:
"The set of design decisions about any system that keeps its implementors and maintainers from exercising needless creativity."
2. Articulating an architect's value isn't easy
An architect is not a senior developer, a project manager, or a firefighter. Architects bring value by looking between components to understand interdependencies, by reducing complexity, and by articulating strategy. They see both sides of a coin and balance trade-offs against overarching goals.
3. The Architect's Elevator
Architects fill a vital role: they communicate closely with technical teams but can also communicate with upper management without losing the essence of the message. They ride what Gregor calls the Architect's Elevator — up to the penthouse where strategy is set, down to the engine room where code is written.
4. BAU is Business as Unusual
We hear "Business as Usual" every day. In reality, nobody wants a static system that never changes. Constantly evolving systems support constantly changing business activities. The rate of change is the primary factor influencing architectural decisions — change is the norm, not the exception.
5. Questions and decision-making
A good architect knows the right question — they don't necessarily need the answer. When you make a decision, don't think in terms of good or bad; ask instead: does it fit for purpose? Even the best decision has a downside. Always think in trade-offs.
6. You can't manage what you can't understand
Architects must close the gap between technical knowledge holders and high-level decision-makers. Every interaction with senior management is a teaching opportunity. A few communication tools Gregor offers:
- Build a ramp, not a cliff — consider your audience's technical level and lead them up gradually
- The whole is more than the parts — present architecture like a LEGO model, not a box of bricks
- Write for busy people — organisations are full of unread documents; brevity and clarity matter
7. Control is an illusion
Top-down control is impossible. Three gaps make it so: the knowledge gap, the alignment gap, and the effects gap. Ironically, the best way to achieve control is through autonomy — accepting the gaps rather than pretending they don't exist. Enablement, feedback, and a clear strategy are critical for successful autonomy.
8. The black market is not efficient
Gregor was allowed to make ten million technical decisions but needed management approval to buy a $200 plane ticket. By the time approval arrived, the fare had increased. Such organisations tolerate a black market because their formal processes hinder progress.
How to know you have a black market: if the answer to "how long does it take to provision a server?" is "depends on who's asking" — you have one.
The only way to beat the black market is to build an efficient white market: transparent, self-service, and fast enough that the black market starves.