The Software Architect Elevator: The Book I Wish I’d Had in 2018

Back in 2018, I wrote a post called What Does an Enterprise Architect Do?. I wrote it because nearly everyone who interviewed me for the job asked that same question. My answer was a careful list of roles and responsibilities. It was accurate. It was also a little dry.

Gregor Hohpe answered the same question much better, with one image: an elevator.

His book, The Software Architect Elevator: Redefining the Architect’s Role in the Digital Enterprise (O’Reilly, 2020), grew out of his years as a chief architect in a large enterprise and his earlier collection, 37 Things One Architect Knows About IT Transformation. It’s written as a series of short chapters you can read in any order, which makes it easy to pick up between meetings. If you’re an architect, an IT leader, or an executive who works with architects, it belongs on your shelf.

Here are Clif’s notes.

The big idea: ride the elevator

Picture your organization as a tall building. At the top is the penthouse, where executives set strategy and make investment decisions. At the bottom is the engine room, where engineers build and run the systems that make the business work. In between are a lot of floors full of middle management, process, and translation.

The problem is that the penthouse and the engine room rarely talk to each other directly. Strategy gets watered down on the way down. Technical reality gets filtered on the way up. By the time a message has passed through enough floors, both sides are making decisions based on a version of reality that isn’t quite true.

Hohpe’s answer is that the architect’s job is to ride the elevator. A good architect is comfortable in the engine room, close enough to the technology to know what’s real. A good architect is also comfortable in the penthouse, able to explain technology decisions in terms of business outcomes. And they move between the two often, so both floors stay connected.

That’s it. That’s the job. It’s the best one-sentence description of enterprise architecture I’ve come across.

Same decision, different language

One of my favorite ideas in the book is that you describe the same decision differently on different floors. In the engine room you might say, “We’re running the database in a multi-zone configuration with standby replicas.” In the penthouse you say, “We chose to spend a bit more so that an outage won’t cost us customer data or a day of sales.”

Both statements are true. Neither one is dumbed down. They’re aimed at what each audience needs to decide. An architect who can only speak one of those languages is only doing half the job.

Architecture is selling options

Hohpe makes a case I’ve found very useful with finance-minded executives: good architecture is like buying options. A financial option gives you the right, but not the obligation, to do something later. Architecture works the same way. A clean interface, a well-placed abstraction, or a decision to avoid lock-in costs something now, and in return gives you the ability to change direction later without starting over.

The value of an option goes up as uncertainty goes up. In a stable, predictable world, you don’t need many options, so you can build things simply and directly. In a fast-changing world, options are worth a lot.

This is a very practical way to fight complexity. Every bit of flexibility you build in costs something. So don’t add flexibility “just in case.” Add it where you’re genuinely uncertain, and be able to explain what option you’re buying and why it’s worth the price.

Speed is a strategy

The book spends a lot of time on why traditional IT organizations struggle to move fast, and why that matters more than it used to. Organizations built for cost efficiency and control tend to treat change as risk to be minimized. Digital companies treat speed itself as a competitive advantage.

One theme I especially like is “if it hurts, do it more often.” Annual releases are painful because so much change piles up between them. Frequent, small releases are less painful because each one is small. The same goes for many things we avoid: deployments, upgrades, migrations. Avoiding them doesn’t remove the pain. It saves it up.

Organizations are systems too

Hohpe treats the organization the same way he’d treat a technical system: it has structure, feedback loops, and behavior that emerges from how it’s put together. That’s why reorganizations often fail to stick and why symptoms like buggy software often have causes far from the code, such as overloaded teams or bad incentives.

For anyone trying to simplify an enterprise, this is a crucial insight. A lot of technical complexity is really organizational complexity in disguise. You can’t fix it with a new framework.

Why this book matters for battling complexity

The thread that ties all of this together is alignment. When the penthouse and the engine room are disconnected, complexity grows in the gap. Executives fund initiatives without understanding their technical cost. Engineers build sophisticated solutions to problems the business doesn’t actually have. Nobody sees the whole picture, so nobody can make it simpler.

An architect who rides the elevator closes that gap. They can tell leadership, “This initiative will add three new platforms we’ll have to run forever. Here’s a simpler option.” They can tell engineers, “The business doesn’t need five-nines here. Ninety-nine and a half percent will do, and it’s a much simpler design.”

That’s how architecture becomes a tool for simplicity instead of a source of complexity.

Who should read it

Architects, especially new ones, or anyone who has been asked “so what exactly do you do?”
IT leaders and CIOs who want to get more value from their architecture teams.
Engineers thinking about the architect path, who want to know what the job looks like beyond diagrams.
Business executives who work with technology teams and want to understand how to get honest, useful answers from them.

If you enjoy it, Hohpe has continued the series with Platform Strategy and Cloud Strategy, and he writes regularly at architectelevator.com. I’ll have notes on Platform Strategy soon.