Most architects I've met don't see themselves as living in an ivory tower. But that's exactly how the rest of the organization tends to see them.
It's a perception problem, and it's a real one.
For years, Enterprise Architecture has carried this reputation: the function that produces beautiful diagrams nobody reads, demands compliance with frameworks nobody internalizes, and shows up at design reviews to tell delivery teams what they can't do. The verb most associated with EA in many enterprises is "block."
I've sat on both sides of this. I spent most of my career running IT infrastructure and cloud operations — closer to the engine room than the executive deck. When I moved into Enterprise Architecture, the goal wasn't to escape delivery. It was to influence decisions before they became my problem to operate.
That shift in mindset is what this piece is really about.
Two ideas that reframed how I think about EA
The first comes from Gregor Hohpe, who described the architect's role with a metaphor I haven't been able to shake:
"A great architect must ride the elevator, moving between floors to translate business goals into technical reality and vice versa." [1]
The elevator. Not the executive lounge. Not the data center. The elevator.
Architects who spend all their time on the top floor lose touch with what is actually being built — and end up producing strategy disconnected from constraint.
Architects who never leave the engine room can't influence the decisions that matter most. Either extreme makes you irrelevant in a different way.
The second comes from Dr. Mehmet Yildiz:
"The role of architects is to provide pragmatic, iterative progress that balances speed with architectural rigor." [2]
This one challenges a different bias — the architect's bias toward perfection. Big-bang target architectures, exhaustive standards documents, three-year transformation plans that go stale within six months. These are comfortable artifacts. They give the appearance of rigor without exposing you to the discomfort of being wrong in real time.
Pragmatic, iterative progress is harder. It means being willing to call a decision good enough, ship guardrails before they are complete, and adjust as you learn. That requires confidence — and the willingness to take responsibility when reality pushes back.
Vertical and horizontal movement
Hohpe's elevator captures vertical movement: between strategy at the top and execution at the bottom. But the modern architect's job also requires horizontal movement: across business domains, across architecture disciplines, across delivery teams.
A connected architect moves both ways.
Vertically, they translate between what the business is trying to achieve and what the technology stack will allow — without distorting either direction. That translation is the actual work. It is rarely as elegant as the diagrams suggest.
Horizontally, they work alongside security architects, data architects, infrastructure architects, AI architects, and solution architects so the enterprise doesn't fragment into a collection of well-designed silos that don't compose. A target state stitched together from independent local optima is not an architecture. It is an accident waiting to happen.
The combined architect — vertical and horizontal — is harder to develop and harder to retain. But that is the architect who avoids both traps: the ivory tower at the top, and the delivery undertow at the bottom.
Translating this into how EA actually works
I keep coming back to three principles when I think about how to operationalize this in my team. They are not original. They are the result of being repeatedly humbled by what doesn't work.
EA leads digital transformation; it does not approve it. The most expensive failure mode in any architecture function is being invited to the design review at the end. By then the constraints have hardened, the vendor is selected, and the team has already absorbed the political cost of changing direction. Real influence happens upstream — when strategy is being shaped, when capability roadmaps are being drawn, when business leaders are still asking "what should we even build?" The architect's seat at that table has to be earned by being useful, not by being entitled to it.
Architecture governance enables delivery; it does not impede it. Guardrails should be clear, enforceable, and small enough to internalize. If a standards document needs a workshop to explain, it isn't a standard — it's a research paper. The bar I hold my team to is simple: a delivery team should be able to read our principles in fifteen minutes and know what is in bounds and what isn't. Anything beyond that is a sign we haven't done our work yet.
Architects are connected, not parallel. Security, infrastructure, data, AI, and solution architects need to operate as one community, not five adjacent functions. When architects are aligned, decisions move faster because the team isn't waiting for cross-domain consensus to be brokered after the fact. When architects aren't aligned, every meaningful design becomes a negotiation.
The outcome we are aiming for is straightforward to describe and hard to achieve: EA perceived as a strategic partner and value enabler, governance experienced as automatic rather than ceremonial, and teams empowered to move fast inside boundaries they actually understand.
"One is None": a leadership principle for an EA team
The strategic posture is one half of the picture. The other half is how the team is built to deliver it.
The principle I lean on most heavily for my team is borrowed from special operations doctrine: one is none, two is one. [3]
Translated to enterprise architecture: every critical area has at least two people who own the context. Not two people listed on a Confluence page. Two people who could walk into a steering committee tomorrow and represent the architecture position with confidence.
This sounds like redundancy. It is. But it is redundancy with intent.
Enterprise Architecture, more than most functions, is exposed to key-person risk. The value of an architect compounds with context — relationships with delivery teams, history of past decisions, understanding of which constraints are real and which were rationalizations dressed up as constraints. Lose that person and you lose six to twelve months of organizational memory. One is None is what I use to harden the team against that.
For 2026, the operating model is simple. Every initiative in every portfolio has at least one architect with primary ownership and at least one with backup context. Whatever the rotation — vacation, promotion, a sudden cross-domain demand — there is an architect ready to step in without the delivery team feeling the seam.
The implications I expect to see, and am tracking deliberately:
The team makes faster decisions because no architect is the sole bottleneck for their domain. Continuity holds across leave, transitions, and reorganizations. Architects deliberately develop into adjacent domains, which strengthens horizontal movement across the whole team. And — most importantly — the function becomes credible to the business as something they can rely on, not just something they have to consult.
The honest version
I am not going to pretend any of this is solved.
Architects still get pulled into late-stage approvals. Governance still feels heavy in places where it shouldn't. The ivory tower perception is sticky, and earning the strategic seat takes more than declaring you have earned it. We are working on all of this in the open with our delivery teams, our CIO, and the broader technology organization.
What I do believe — and what I have staked my approach on — is that the pragmatic architect is the one who survives. The architect who rides the elevator and walks the floors. The architect who chooses iterative progress over theoretical perfection. The architect who builds a team where no one is the single point of failure.
That is the function I want EA to be. And that is the standard I am trying to hold myself, and my team, to.
References
- Gregor Hohpe, The Software Architect Elevator: Redefining the Architect's Role in the Digital Enterprise (O'Reilly, 2020). The elevator metaphor is developed across the opening chapters and remains the through-line of the book. ↩︎
- Dr. Mehmet Yildiz, on the role of pragmatic architecture in technology leadership. See his published essays on Medium and the ILLUMINATION publications, where he writes extensively on practical architecture practice and the architect's responsibilities in modern enterprises. ↩︎
- The principle "One is None, Two is One" is widely attributed to U.S. military and special operations doctrine, where it is applied to mission-critical equipment redundancy. It has since been adopted in leadership and resilience writing — most notably by Tim Ferriss and Jocko Willink — as a heuristic for designing systems and teams that survive single points of failure. ↩︎