The Diagram Nobody Reads
A few months ago, a CFO of a Luxembourg company showed me a document. Forty-seven pages. Blue, green, and yellow boxes. Dotted arrows, solid arrows, double-line arrows. Annotations in technical English. A title block reading "ArchiMate 3.2, Target State Architecture Q3 2026."
He looked at me and said: "Pierre-Jean, the architecture team has been presenting this to me in committee for six months. I don't understand any of it. And I'm fairly certain they don't either."
He was right.
Enterprise Architecture, in its current form, has become theater. A performance of intellectual rigor that masks a fundamental failure: the inability to create a dialogue between those who create business value and those who build the technology systems.
We need to talk about this. Without sugarcoating.
The Permanent Dialogue of the Deaf
The ground-level reality in most organizations I work with can be summed up as three parallel monologues that never intersect.
Business Speaks in Value
The commercial director thinks in "Value Streams" and "Business Capabilities." They want ROI. Now. They want to know how much a project costs, when it will deliver its first euros, and what risk it carries. They couldn't care less whether the application runs on Kubernetes or on a physical server in a basement. And they're right.
IT Speaks in Infrastructure
The technical director thinks in containers, VLANs, load balancers, and API gateways. They want stability, zero technical debt, and systems that handle the load. They couldn't care less which market segment generates the most margin. And they too, within their frame of reference, are right.
Architects Speak in... ArchiMate
And then there are the enterprise architects. Stuck between these two worlds, they've made a tragic choice: creating a third language that nobody understands. They spend more time debating the semantics of a "Serving" versus "Realization" arrow than delivering value. They produce models of remarkable formal elegance, and near-zero practical utility.
I ran a survey across my professional community. The question was simple: "What's the real barrier to agile enterprise architecture?" The results are telling:
- 46% identified culture (Biz vs IT war) as the main problem.
- 31% pointed to archaic and expensive tools.
- 23% mentioned architect elitism.
- 0% thought it was impossible.
In other words: the problem is identified. It's cultural, tool-related, and human. But not unsolvable. So why does it persist?
ArchiMate: The Collective Delusion
Let's say it plainly: ArchiMate, in its current form of use, functions as a collective delusion.
The framework itself isn't bad. Its layered structure (Business, Application, Technology) is intellectually coherent. The problem is what we do with it.
The Completeness Trap
ArchiMate pushes toward completeness. Toward modeling everything. Toward capturing every relationship, every dependency, every flow. The result is a model of impressive theoretical precision, and near-instant obsolescence. By the time you finish the mapping, the system has changed. You're chasing a moving target with a static tool.
The Translation Trap
ArchiMate creates a permanent need for translation. Business must translate its needs into architecture terms. Architecture must translate its models into IT terms. IT must translate its constraints into architecture terms. Each translation introduces information loss, delays, and misunderstandings. The architect becomes a trilingual parrot who spends their career rephrasing without transforming.
The Cost Trap
The "Magic Quadrant Leaders" tools that implement ArchiMate (you know which ones) cost between 50,000 and 500,000 euros per year in licenses. For that price, organizations often get graveyards of obsolete data: repositories nobody maintains, models nobody consults, dashboards nobody uses.
The opportunity cost is staggering. That money could fund three senior developers for a year. Or a complete transformation program.
Toward Liquid Architecture
The diagnosis is in. The question becomes: what do we do about it?
I propose a paradigm shift that I call Liquid Architecture. Not a new framework: the world doesn't need yet another meta-model. But a set of principles that redefine the role and tools of enterprise architecture.
Principle 1: Zero Translation
The first principle is radical: eliminate the human intermediary between business and technology.
The goal is a model where the business traces its flows, in business language, with its own concepts, and where IT wires the technology underneath, directly. No intermediate layer where an architect plays translator. No ArchiMate diagram as a "pivot language" between two worlds.
Concretely, this means tools where business models its processes in a language it masters (not an impoverished subset of ArchiMate disguised as a "business view"), and where technology decisions are traceable directly from those processes.
Architecture as code moves in this direction. When architecture is expressed as versioned, testable, and deployable code, the distance between the model and reality shrinks to zero.
Principle 2: Low Cost, High Impact
Let's stop spending a startup's annual budget on SaaS licenses for architecture tools that four people use.
Alternatives exist. Open-source tools like Archi (a free ArchiMate editor), "architecture as code" solutions based on Structurizr or Mermaid, Git repositories for versioning architectural decisions (ADR, Architecture Decision Records). The cost: virtually zero. The impact: direct and measurable.
The guiding principle: every euro spent on architecture tooling must be justified by a measurable gain in decision speed, risk reduction, or delivery acceleration.
Principle 3: Intelligible in Ten Seconds
This is the ultimate test: if your CEO can't understand the diagram in ten seconds, it's trash.
This principle has profound consequences for how we design architecture deliverables. Gone are the exhaustive models with 47 layers. In their place: targeted, contextual views that answer a specific question for a specific audience.
An architecture diagram for the executive committee doesn't look like a diagram for the DevOps team. And that's normal. The current problem is that we try to do both with the same tool and the same formalism. It doesn't work. It has never worked.
How to Break the Silo in Practice
Liquid Architecture isn't a utopia. It's a set of practices that some organizations are beginning to adopt, with tangible results.
Embed the Architect in Product Teams
The architect can't be an outside actor who "validates" team decisions. They must be embedded in squads, participate in daily standups, understand the day-to-day constraints. That's how they earn the credibility needed to influence decisions.
Replace Reviews with Guardrails
Rather than architecture committees that validate (or block) proposals, implement automated guardrails: rules in the CI/CD pipeline that verify compliance with architectural principles. Governance becomes continuous and non-blocking.
Measure Value, Not Compliance
The KPI for an architecture function should never be "number of models produced" or "compliance rate against the reference framework." It should be: "time-to-market reduction," "costs avoided through reuse," "number of decisions informed by architecture."
The Root of the Problem
Forty-six percent of the professionals surveyed identified culture as the main barrier. Not tools. Not frameworks. Culture.
This means the solution isn't technical. It's human. It requires architects who accept stepping down from their pedestal, business leaders who accept understanding technology, and organizations that accept removing the artificial boundary between "the Business" and "IT."
Because that boundary doesn't exist in reality. It only exists on our org charts. And it's this organizational fiction that fuels the dialogue of the deaf.
Enterprise Architecture isn't an intellectual scam. But its current practice has become one. And it's time to reinvent it, not with a new framework, but with the courage to question everything we thought we knew about making strategy and technology talk to each other.