Notes from a conversation with Gregor Hohpe — author of The Software Architect Elevator and Enterprise Integration Patterns, former principal at AWS and Google.

The bad architects are easy to spot. The great ones are invisible — everything just works, and nobody can say exactly why. Gregor Hohpe on what separates the two, and how to become the latter.

Table of Contents

• The Amplifier, Not the Oracle
• Architecture as Risk Management
• Simplicity Is a Feature
• Mapping the Solution Space
• The Case for Visual Thinking
• The Phantom Sketch Artist
• Hard Skills That Go Stale
• Political Capital
• Architecture Isn’t Good or Bad
• Two Traps at the Finish Line
• Three Paths Forward

The Amplifier, Not the Oracle

Bad architects are easy to spot: they drop buzzwords (“cloud-native,” “loosely coupled”), hoard decisions, and treat developers as recipients of instructions. You don’t need an architect for that — a sticky note does the same job.

The mantra worth following: architects shouldn’t try to be the smartest people in the room — they should make everyone else smarter.

That means absorbing context, uncovering blind spots, surfacing trade-offs people are making without realizing it. Not solving problems for people, but helping them solve problems better. An oracle hands out answers. An amplifier raises the quality of everyone’s thinking.

The test: do people come to you as a sounding board? Do they leave with a better mental model than when they arrived? If yes, you’re doing it right.

Architecture as Risk Management

An architect’s core function is risk management. You might ship without one — and it might even work. But the odds of hitting scalability, security, or maintainability problems go up significantly.

The mistake most traditional organizations make is narrowing “risk” to execution risk: did we build what we planned? That misses the risks that actually kill products — will users adopt it? Does it move the needle? Is it generating revenue?

Good architects anticipate the full spectrum of risks and mitigate them before they’re expensive. Lower risk is lower cost. That’s the value proposition.

Simplicity Is a Feature

Simplicity is a design strength, not a sign that something wasn’t thought through hard enough. But there’s an important distinction: some complexity is inherent, and some is self-inflicted.

Distributed systems have inherent complexity — retries, timeouts, idempotency, back pressure. You can’t design your way out of the physics. What you can do is make that complexity intuitive to work with rather than pretending it doesn’t exist.

Self-inflicted complexity is the real enemy. The heuristic: as simple as possible, but no simpler. Every layer of unnecessary abstraction adds cognitive load, makes changes riskier, and accelerates the path to legacy — code nobody wants to touch because they don’t trust what it’ll break.

Mapping the Solution Space

Most technical debates fail because the participants are arguing from different maps. One engineer looks at a cylinder from the front and sees a circle. Another looks from the side and sees a rectangle. They’ll never converge because they’re not describing the same object.

The architect’s move is to frame the solution space before picking a side. Take microservices: there’s design-time modularity and runtime modularity — two independent axes. That immediately yields four options, not two. The modular monolith — well-structured code deployed as a single unit — becomes visible as a legitimate choice instead of being erased by the binary framing.

Once everyone shares the same map, disagreements stop being personal. You’re no longer fighting about who’s right. You’re reasoning together about which quadrant fits the situation.

The Case for Visual Thinking

Words are fuzzy. You can say “these systems have some relationship” and mean ten different things. A diagram either has a line between two boxes or it doesn’t.

A sketch with two-color pens can encode roughly 20 dimensions — size, shape, shading, labels, ordering, nesting, position, arrows. That’s enough richness to expose exactly where two people’s mental models diverge.

The best reaction when drawing with someone is: “that’s wrong.” Not because the drawing failed — because now you’re in a productive dialog. They correct the sketch, you refine it, and you converge on something neither of you could have articulated alone.

Learning to sketch well is muscle memory. Pair with someone who already does it. The left brain/right brain dynamic matters: use your structured mind to get something down, then your creative mind to ask whether a dimension is missing or the framing is off. Iterate between the two.

The Phantom Sketch Artist

Before cameras, police used sketch artists after crimes. The witness knows exactly what the perpetrator looks like — they have all the information. The sketch artist knows nothing about the specific person, but has the skill to draw what the witness describes. The combination produces something useful that neither could produce alone.

Architects are often the phantom sketch artist. You don’t know more about the system than the team that built it — it’s their domain, their application. But you can help them express what they know in a format that’s visible and discussable. When someone says “yes, exactly like that” pointing at your sketch, you’ve done your job.

The analogy goes deeper: to draw faces accurately, sketch artists study human anatomy. Not to be painters — to understand what’s underneath. Architects need the same: not just to draw clean diagrams, but to understand the structural relationships they represent.

Hard Skills That Go Stale

You need genuine technical depth — system design, trade-offs, operational concerns, observability, domain-driven design. Not just familiarity. You need to have done them.

The trap is believing that the hard skills you had five or ten years ago still apply. Your trade-offs may have been sound then. They’re often wrong now. A classic example: we were told everything must scale horizontally. But Moore’s Law outpaces most business growth. A lot of modern applications could run entirely in-memory on a single modern server. That constraint dissolved — but architects who internalized it in 2010 still design around it.

Revalidate your heuristics. When someone shows you everything pointing at a central database, your instinct says “bottleneck.” But if it’s a horizontally scaled NoSQL store with flexible schemas, that heuristic is wrong. The design may be fine.

On staying current: you can’t do it alone. Two days with a trusted colleague who’s deep in a new technology is worth months of reading newsletters. Social media is a poor signal — everyone’s selling something. Build a real network. Be the person who asks engineers what they’re actually working on, and listens.

Political Capital

Accept that not everything will be in a perfect state. If you can’t tolerate imperfection, you’ll burn out trying to fix things nobody asked you to fix.

The useful mental model is political capital: a balance you earn and spend. You earn it by delivering, keeping promises, being transparent, being supportive. You spend it when you need to challenge something — calling a project a likely failure, pushing back on a direction people are committed to.

The most common mistake: overspending early. A new architect arrives confident, immediately starts criticizing every project and every decision. Even when they’re right, it ends badly. You need credibility before your critiques land.

Earn first. Then spend wisely — on one thing at a time, where it genuinely matters. Scattered criticism exhausts capital fast and changes nothing.

The “jester” has influence precisely because they have no hidden agenda. An architect with little formal power can have enormous reach if people trust they’re not lobbying for their own interests, inflating their resume, or making systems complex to look indispensable.

Architecture Isn’t Good or Bad

Architecture isn’t a battle between good patterns and bad ones. The right framing is suitable or not suitable — does it serve the context it was built for?

When reviewing an architecture, the question isn’t “is this good?” It’s: did the team understand the trade-offs? Were those trade-offs aligned with what the business actually needed? Were the decisions conscious?

Even the “big ball of mud” has genuine strengths: fast to build, cheap, requires limited expertise. If a team had a one-month deadline, couldn’t hire more people, and needed something shipped — it may have been the right call. You can always find something wrong with any architecture. That’s not the exercise.

Third-party reviews, especially vendor-led ones, always find a problem that requires buying the vendor’s latest product. Treat them accordingly.

Two Traps at the Finish Line

Trap 1: doubting yourself when it seems simple.

You untangle something genuinely complex, apply good thinking, and suddenly it seems obvious. The temptation is to doubt the result — “Could it really be this straightforward?” We’re so accustomed to complexity that clarity feels like a sign we missed something.

It isn’t. Obvious-after-the-fact is what good sense-making looks like. If you made the hard thing clear, you did the job. Don’t stumble on the finish line.

Trap 2: letting people dismiss what you surfaced.

Unearthing a hidden assumption feels trivial once it’s stated. People say “that was obvious, we knew that.” If they knew it, why didn’t they write it down? Why did it take outside perspective to surface it?

Making the implicit explicit — helping someone articulate what they already know, sketching something they couldn’t draw themselves — is the skill. When the output looks simple, that’s the peak performance, not a failure.

Three Paths Forward

From software engineer, three paths are genuinely satisfying:

1. Stay an engineer — top-notch individual contributor, deep technical craft.
2. Become a technical manager — bring technical judgment to people and team problems.
3. Become an architect — high influence, low direct power, focused on elevating others.

All three are legitimate. The architect path specifically cannot be done in isolation. You cannot make people smarter without talking to them. You cannot stay current without a network that gives you honest feedback on your decisions. The oracle model — receive requirements, emit architectures — doesn’t work and isn’t satisfying.

Gregor Hohpe is the author of The Software Architect Elevator and Enterprise Integration Patterns.