Who Validates the Validator?
A narrative has gained momentum on LinkedIn in recent months: enterprise architecture has finally arrived. Perception of architects has improved. Agreement that architecture is essential has spread. The profession, after years of being viewed as detached from operational reality, is being celebrated for stepping out of the ivory tower and focusing on business outcomes.
The conclusion being drawn is straightforward: the market has finally caught up with what architects always knew they were worth.
The conclusion is also incomplete.
There is a long history of architectures being approved, funded, implemented, and celebrated — only to become the root cause of the very chaos they were designed to prevent. The celebratory narrative tends to skip over the gap between the perception of architectural value and the operational outcomes that architectures actually produce. It is worth pausing on that gap.
The Question Worth Asking
When professional perception of any discipline improves, two interpretations are possible. The discipline has materially improved. Or the discipline has improved at communicating about itself. Survey instruments cannot easily distinguish between the two.
The label "essential" is a particularly weak signal. Compliance is essential. Documentation is essential. Annual strategy offsites are essential. Many things are declared essential in surveys and then quietly starved of budget, authority, or attention. The word "essential" in a survey response and the word "essential" in a budget allocation are often two very different things.
The more interesting question — the one that doesn't fit neatly into an optimistic LinkedIn post — is this: if enterprise architecture is more widespread, more valued, and more essential than ever before, why do most organisations still carry chaotic architectures, growing technical debt, and systems that remain only partially understood?
That is not a rhetorical provocation. It is a diagnostic question. The answer, on closer inspection, has less to do with the competence of individual architects than with a structural problem that rarely gets discussed.
The Self-Validating Loop
The pattern, observed across decades and across industries, is the following.
An enterprise architect designs an architecture. The architecture is presented to management. Management — typically a CTO, IT director, or steering committee — evaluates the proposal. The problem: the evaluators rarely have the technical depth to meaningfully challenge the design. They can assess cost, timeline, vendor reputation, and alignment with strategic language. What they generally cannot assess is whether the technical choices are sound, whether the alternatives considered were the right alternatives, or whether the long-term operational implications have been honestly evaluated.
So the proposal gets approved. Not because it was rigorously challenged, but because there was no one in the room equipped to challenge it — a structural gap, not a personal failure.
The architect then oversees or influences the implementation of the architecture they designed. When problems emerge — and they always do — the first explanation tends to be that the implementation deviated from the design. The architecture was sound; the execution was flawed. This explanation is sometimes accurate. But it also happens to be unfalsifiable by anyone who wasn't involved in both the design and the implementation at a technical level.
The result is a closed loop. The architect designs. The architect validates. The architect evaluates the outcome. At no point does an independent technical perspective enter the process with sufficient authority to say: "This doesn't hold up. Here's why. Here's what was missed."
This isn't about incompetent architects. Many are exceptionally capable. It's about a structural absence of challenge. And structures without challenge tend to drift — slowly, invisibly, and then suddenly.
The Political Shield
The reason this structure persists is organisational, not technical.
For a CTO or IT director, having an Enterprise Architect on the team serves a function beyond technical design. It signals governance. It signals strategic thinking. It provides a credible answer to board questions about "who's managing our technology direction."
When things go well, the narrative is clean: strong architectural vision, well-executed strategy. When things go badly — a failed migration, a system that can't scale, an integration that creates more problems than it solves — the architecture typically doesn't get blamed. The implementation gets blamed. The vendor gets blamed. The timeline gets blamed. The budget gets blamed. The architecture? The architecture was sound.
This isn't a conspiracy. It's a natural consequence of asking the same person to design, advocate for, oversee, and evaluate their own work. In any other professional discipline, this would be considered a conflict of interest. In enterprise architecture, it's considered normal.
The Missing Layer
In medicine, there is the concept of the second opinion. In law, adversarial challenge. In engineering, independent review. In aviation, mandatory inspections by people who didn't build the aircraft. In accounting, external auditors who don't report to the CFO.
In enterprise architecture, there is... the architect.
The missing layer is structural separation — a function whose purpose is not to design architecture, not to implement it, and not to report to the architect. Its purpose is to challenge. To ask the questions that the design process should have answered but didn't. To stress-test assumptions. To look for the failure modes the architect either did not consider or did not want to highlight.
This is not about creating bureaucracy. It is about creating accountability. The difference between a design that was validated and a design that was merely approved is the difference between an architecture that survives contact with reality and one that looks brilliant until the first production incident at 3 AM.
The questions are simple. The discomfort they create is the point.
Why was this technology chosen over the alternatives? What's the operational cost at year five, not just the implementation cost at year zero? Who maintains this when the architect moves to the next project? What happens when this vendor is acquired, pivots, or sunsets the product? Where is the single point of failure that everyone agreed to ignore because fixing it would blow the timeline?
These questions aren't hostile. They're diagnostic. The fact that they're rarely asked by someone with the independence and authority to insist on answers is, on close inspection, the single largest structural gap in enterprise technology governance.
Why This Gap Persists
The reason is uncomfortable but straightforward: organisations rarely want to pay for the contradiction.
Independent challenge is expensive. It requires experienced people who understand architecture deeply enough to question it but who have no stake in the outcome. It slows things down — or at least it appears to. It creates friction in a process that leadership wants to be smooth. And it occasionally produces answers that are uncomfortable to hear: "This architecture has fundamental problems that will cost ten times more to fix in three years than they would to fix now."
That message doesn't play well in a quarterly review. It doesn't fit in a steering committee slide. It doesn't align with the narrative that the architecture programme is on track and delivering value.
So the gap persists. And the consequences accumulate — not as dramatic failures, but as a slow accretion of technical debt, operational complexity, and institutional knowledge loss that eventually becomes the crisis that the next architect will be hired to solve.
The Real Question
The LinkedIn narrative says enterprise architecture has earned its seat at the table. Perhaps it has. But earning a seat at the table and being accountable for what happens after you sit down are different things.
The question isn't whether organisations need architects. They clearly do. The question is whether the current structure — where architects design, advocate for, oversee, and evaluate their own work with limited independent challenge — is producing the outcomes it claims to produce.
The improving perception suggests the profession is communicating better. Whether it is delivering better is a different question — one that requires looking past the survey results and into the production environments, the incident logs, and the technical debt registries that don't make it into LinkedIn posts.
Accountability isn't a threat to good architecture. It's the thing that separates good architecture from architecture that simply hasn't been tested yet.