⚠️ MUST READ ALERT: A foundational reading for software architects, senior developers, enterprise architect, senior technologists, CTO’s, senior technical architects and IT managers in this book, the author shares real-world advice and hard-learned lessons from actual IT transformations. His anecdotes help architects, senior developers, and other IT professionals prepare for a more complex but rewarding role in the enterprise.

The Software Architect Elevator, by Gregor Hohpe is one of the best books anyone can read on the ‘IT architecture’ (regardless of what type of architect you intend to be) for both folks who are starting and for those that already had established a career as an architect.

The metaphor of the elevator is that the Enterprise Architect defined in the book as “the glue between business and IT architecture” is necessary to combine organizational and technical knowledge to effect a change in their company’s structure and processes, and to achieve that, they need to connect the IT engine room to the penthouse, where the business strategy came from.

I saw these kinds of “bridges” needed even in small/medium organizations.

When I started this post to recommend the book, I find myself again discovering new things. So I’ll re-read. For the third time. And I don’t think this will be the last time to do so.

Gregor is a highly skilled writer and storyteller,and more than that, it resonates very much how reality-based and born from the experience this book is. It is real-world advice and hard-learned lessons shared in the role.

Is not a dry collection of facts, good practices and/or cases and collections of patterns. Of course there is space for this kind of content. But the difference here is what it makes The Architecture Elevator special. And also I see as a tactical book, with every useful information to navigate and thrive in the enterprise environment. Hohpe also has its own law, named after him:

Excessive complexity is nature’s punishment for organizations that are unable to make decisions

Gregor's Law

All changes to the software (better) go through this build and deployment toolchain. Knowing that the software toolchain is the first derivative, increasing a software system’s rate of change requires a well-tuned toolchain.

It’s no surprise, then, that in recent years the industry has put much attention and effort into reducing friction in software delivery: Continuous Integration (CI), Continuous Deployment (CD), and configuration automation are all aspects of increasing the first derivative of software systems and thus speeding up software delivery. Without such innovations, daily or hourly software deployments wouldn’t be possible, and companies wouldn’t be able to compete in digital markets, which thrive on constant improvement and frequent updates.

[…] here’s my proposed definition of enterprise architecture:
Enterprise architecture is the glue between business and IT architecture.

One of my favorites passages in the book:

There Always Is an Architecture

When speaking about a system’s architecture, it’s worth pointing out that all systems have one. You can’t build anything out of several pieces that doesn’t have any structure. Even clumping everything together into a giant monolith is an architecture decision. Once we come to this realization, statements like “we don’t have time for architecture” aren’t particularly meaningful. It’s simply a matter of whether you consciously choose your architecture or whether you let it happen to you. History has shown that the latter approach invariably leads to the infamous Big Ball of Mud architecture, also referred to as shantytown. Although that architecture does allow for rapid implementation without central planning or specialized skills, it also lacks critical infrastructure and doesn’t make for a great living environment. Fatalism isn’t a great enterprise architecture strategy, so I suggest you pick your architecture.

This resonates a lot with my professional experience. No one wake up one day and say “I’ll create a Big Ball of Mud”. One day your codebase will be called “legacy”, in the pejorative sense. This reminds me of the great quote from Jeff Bezos that good intentions alone doesn’t work. We need mechanisms. Architecture is this mechanism to align business objectives and IT architecture and practices.

Without lines, it’s quite difficult to represent rich relationships. The line is so important that boxes, labels, and lines suffice to make up Kent Beck’s only half-joking Galactic Modeling Language. Without lines, there wouldn’t be much of a modeling language left. Also, as often stated, “the lines are more interesting than the boxes.”

[…] if I see an architecture diagram without any connecting lines, I am skeptical as to whether it qualifies as a meaningful depiction of an architecture. Unfortunately, many diagrams fail this basic test.”

AWS re:Invent 2021 - The architect elevator: Connecting IT and the boardroom

The Architect Elevator, Gregor Hohpe - SummerSOC 2019

Breaking Changes - “Mastering the Architecture Mindset” with Gregor Hohpe

AWS re:Invent 2021 - Building modern cloud applications? Think integration

Infrastructure as actual code | Serverless Office Hours

The Architect Elevator page for the book Gregor Hohpe’s blog, always insightful, as the tagline states, “Real life writes the best stories, so ride the architect elevator up and down Enterprise IT with me.”
The Architect Elevator — Visiting the upper floors, the author’s post on Martin Fowler’s blog