By Arun Mishra, Enterprise Architect | Director, Capital One
Why Enterprise Architecture Governance Fails Before Implementation Enterprise architecture governance programs tend to fail in a predictable place that most governance frameworks do not account for. The failure is not during implementation. It is not during the rollout of new standards. It happens earlier and more quietly — in the gap between what the architecture documentation says and what the production system actually does. The governance reviews have been completed. The architecture has been approved. And then, months or years later, the system behaves in ways the approved documentation does not describe, for reasons nobody currently on the team can fully explain.
I have encountered this gap more than once across financial services and healthcare technology organizations — post-merger integrations where the acquired organization’s architecture had no surviving documentation, legacy platforms where years of staff turnover had severed the connection between architectural intent and operational reality, and production pipelines whose actual behavior had drifted so far from their documented design that the documentation was actively misleading to anyone relying on it for governance decisions.
The governance programs that produced these situations were not poorly designed. They documented intent carefully and ran reviews diligently. What they did not do was treat the ongoing alignment between documented architecture and actual system behavior as a governance responsibility in its own right — and that omission is where governance fails.
The Documented Architecture Is Not the Architecture
Enterprise architecture governance is built on the assumption that architectural documentation accurately represents the systems it describes. This assumption is most reliable at the moment of initial design and degrades continuously from that point forward. Systems evolve. Requirements shift. Patches accumulate. Shortcuts get made under deadline pressure and never revisited. Staff turn over and take with them the context that would allow someone to understand why a particular decision was made.
The result, in most organizations with systems older than a few years, is a documented architecture that describes what was intended and a production system that carries the accumulated weight of decisions, changes, and workarounds that never made it back into the governance artifacts. The documented architecture is a hypothesis about the system. The system is the truth.
This matters for governance because decisions made on the basis of the documented architecture — about what changes are safe, what integrations are compatible, what the risk profile of a system actually is — are being made on the basis of a hypothesis that may no longer accurately reflect the system. That is not a technical problem. It is a risk management problem.
Where This Creates Real Organizational Risk
The consequences of this gap are not abstract. In a post-merger integration I led, the acquired organization’s architectural documentation described a data model designed around specific entity relationships. The actual system had evolved to include a deduplication rule that was not in any document — added as a one-off fix to a data quality problem years earlier and never removed. The migration plan, built from the documented architecture, would have silently dropped data the system was designed to preserve. The governance review had approved the migration plan based on documentation that did not reflect what the system actually did.
This is not an unusual scenario. It is the inevitable outcome of governance programs that treat architecture documentation as a deliverable to be produced rather than a living artifact to be maintained and periodically validated against production reality. The deliverable was produced. The review was completed. The approval was granted. And none of that process engaged with the question of whether the documented architecture was still an accurate description of the system it purported to represent.
What Governance Programs Are Missing
The missing element in most enterprise architecture governance programs is a systematic process for validating that documented architecture aligns with actual system behavior — at intervals that reflect the rate at which systems evolve. This is different from an architecture review, which assesses whether a proposed design meets standards and requirements. It is closer to an architecture audit: a comparison of what the governance artifacts say against what the system actually does in production.
Doing this rigorously requires a different kind of work than producing governance artifacts. It requires tracing actual system behavior — real transactions, real data flows, real responses to edge cases and failure conditions — rather than reading documentation and accepting it as a description of reality. It requires treating every claim in the documented architecture as a hypothesis to validate against the system, not an established fact to build decisions on top of.
In practice, this validation work surfaces things that governance reviews consistently miss: undocumented business rules that have become load-bearing, integration dependencies that are not in any architecture diagram, behavioral assumptions embedded in downstream systems that constrain what can safely be changed in upstream ones. These are precisely the things that governance decisions need to account for, and precisely the things that frameworks built around documentation rather than validation do not surface.
A Pattern That Has Worked
The approach that has worked consistently — across the rescue engagements where I have had to reconstruct the actual architecture of systems from their production behavior — is to treat production behavior as the primary source of truth and documentation as a hypothesis to be validated against it, rather than the other way around.
This means deliberately tracing edge cases and failure modes rather than only the happy path, because that is where undocumented logic concentrates. It means instrumenting systems to make their actual behavior observable and comparing that behavior against what the governance artifacts predict. And it means treating discrepancies between documented and actual behavior not as documentation cleanup tasks but as governance findings with risk implications that need to be assessed and addressed explicitly.
The Governance Implication
For architecture governance programs, the practical implication is that validation of architectural accuracy needs to be a standing governance activity, not a one-time review at the point of initial approval. The rate at which validation needs to occur will vary by system — a system that changes frequently needs more frequent validation than one that is stable — but the absence of validation at any meaningful interval is a governance gap that accumulates risk invisibly.
This does not require abandoning existing governance frameworks. It requires adding a validation discipline to them: a systematic process for periodically confirming that what the governance artifacts say about a system is still an accurate description of what the system does, and for surfacing and addressing discrepancies before they become the constraints that define what a system can safely be changed to do.
The architecture that governance programs are governing is not the one in the documents. It is the one running in production. Governance that does not engage with that distinction is not governing the actual system — it is governing a representation of it that may no longer be accurate.
Arun Mishra is an Enterprise Architect and Senior Manager with 16 years of experience in financial services and healthcare technology. He has rebuilt broken production pipelines, recovered stalled post-merger migrations, and designed payments and AI systems at scale. His work has been published in SD Times and TDWI Upside. He writes at arunkmishra.com.