The Ghost of the Thirteenth Floor
In most large organizations, there's a peculiar character. He shows up to meetings fifteen minutes late, opens a Visio file of Byzantine complexity, utters the words "TOGAF," "capability map," and "target state architecture" in the same sentence, then retreats to his office, usually located on a floor nobody visits.
That character is the Enterprise Architect.
His salary ranges between 90,000 and 160,000 euros per year in Western Europe. His actual impact on the company's P&L? In most cases, nobody could quantify it. And that's precisely the problem.
When your impact is lower than your paycheck, it's not the organization you should blame. It's your operating model that needs to be broken.
The Diagnosis: Why EAs Get Bypassed
Before proposing a remedy, let's make an honest diagnosis. I've been an Enterprise Architect. I've seen the trap from the inside. And I've watched dozens of colleagues fall into it.
The Diagram-Without-a-Recipient Syndrome
The average EA spends 60-70% of their time producing artifacts: ArchiMate models, application maps, capability matrices, technology roadmaps. These deliverables are often of remarkable technical quality. But they have a fatal flaw: nobody asked for them, and nobody uses them.
The executive committee wants to know how much a project costs, what risk it carries, and when it will deliver value. They don't want a 47-layer diagram with "Serving" and "Realization" arrows whose semantics have been debated among three architects for six months.
The Systematically Late Arrival
In many organizations, the EA is summoned after the decision has already been made. The business has chosen the solution. The vendor has been selected. The budget is approved. And the architect is asked to "validate alignment with the target." It's a charade. The EA becomes a rubber stamp, not a strategic player.
Speaking the Wrong Language to the Wrong Audience
EAs speak tech to business decision-makers. They speak frameworks to delivery teams. They speak theory to people who need solutions. This linguistic mismatch is devastating: it creates the impression, often justified, that the architect lives in an ivory tower disconnected from operational reality.
My 5-Point Operating Model
When I was an EA, I refused the invisible-architect model. I insisted on upstream involvement, I spoke P&L, and I measured value in euros and timelines, not in artifacts. Here's the operating model that emerged.
1. Demand a "Ticket to Play" Before Any Decision
No architectural decision should be made without four elements on the table:
- Business objectives: what business problem are we solving? What gain are we targeting?
- Constraints: budget, timelines, regulation, existing technical debt.
- Acceptable trade-offs: what compromises is the business willing to make?
- Success metrics: how will we know it worked?
This ticket to play isn't a formality. It's an act of intellectual discipline that forces all stakeholders to clarify their intentions before committing. And most importantly, it positions the EA upstream of the decision, not downstream.
In practice: I've seen entire projects get redefined simply because the ticket-to-play exercise revealed that the real problem wasn't the one people thought they were solving.
2. Speak the Executive Committee's Language in Five Lines
A member of the executive committee reads between 200 and 400 pages of documents per week. They have roughly 90 seconds of attention per topic during a steering committee. In this context, the EA who shows up with a 35-slide deck has already lost.
The rule I impose on myself: every architecture topic fits in five lines:
- The problem (one sentence)
- The cost of inaction (one number)
- The options (two or three, not fifteen)
- The recommendation (one sentence)
- The residual risk (one number)
It's brutal. It's reductive. And it's exactly what a decision-maker needs to make an informed choice. The technical details exist; they're in the appendix, for those who want to dig deeper.
The underlying principle: the EA must speak cost/value, timeline, risk. Not containers, VLANs, and API gateways. Translating from technical to business language is the core of the job. Not a side activity.
3. Spend 20% of Your Time on the Ground
This is the most unpopular rule among senior EAs. And it's the most important.
An architect who doesn't read code, who doesn't participate in implementation reviews, who has never opened a terminal or a Kubernetes console in production, loses credibility with delivery teams. And an architect without credibility is an architect who gets bypassed.
20% of your time, one day per week, should be dedicated to hands-on activities:
- Code reviews on critical components
- Pair-programming sessions with teams
- Production incident analysis
- Technical evaluation of candidate solutions
This isn't micro-management. It's calibration. The architect who knows the reality on the ground makes better strategic decisions, because their mental models are aligned with reality, not with an abstraction.
4. Get Involved in Run Problems
Here's a simple test: when a major production incident occurs at 11 PM, is the EA in the loop? In most organizations, the answer is no. The architect is a "Build" player, not a "Run" player.
That's a strategic mistake. Production incidents are the richest source of information about the actual quality of the architecture. An architect who doesn't participate in the structural resolution of production problems, whether they stem from "their" architecture or not, is depriving themselves of this operational intelligence.
The goal isn't for the EA to become a night-shift operator. The goal is for them to participate in post-mortem analysis, identify structural root causes, and translate those findings into architectural actions. This is the feedback loop that transforms a theoretical architect into an effective one.
5. Tell the Value Story in Euros, Not in Artifacts
This is the hardest point, and the most transformative. The EA must be able to quantify their own contribution:
- OPEX/CAPEX reduction: "Rationalizing the middleware layer saved 340,000 euros per year in licensing."
- Time-to-market: "Implementing the microservices architecture reduced the delivery cycle from 12 weeks to 3 weeks."
- Business risks avoided: "The dependency analysis identified a single point of failure whose materialization would have cost 2 million euros in lost revenue."
- Reuse rate: "Shared components are used by 14 teams, avoiding an estimated 800,000 euros in development costs."
If you can't tell your value story in euros, someone else will tell it for you. And their version will probably be: "We're not sure what the architect does, but they're expensive."
The True Role of the Enterprise Architect
The EA is not a diagram drawer. Not a standards guardian. Not an internal auditor in disguise.
The EA is a strategic translator: they connect the business vision to technological capabilities, and they do it with enough rigor and pragmatism to ensure that connection produces measurable value.
When I secured executive buy-in on digital transformation, cloud, and data roadmaps, it wasn't because my diagrams were beautiful. It's because I spoke their language, measured value in terms they understand, and delivered quick wins that proved the approach's credibility before scaling up.
The question every EA should ask themselves every quarter: "If my position were eliminated tomorrow, what measurable impact would it have on the company's P&L over the next six months?"
If the answer is "none" or "I don't know," it's time to change your operating model.