Enterprise Architecture Governance: The System That Survives the Consultant's Departure

Architecture governance is what separates a living repository from a diagram graveyard. I've seen too many EA deployments succeed technically — clean metamodel, complete map, brand-new tool — then collapse within six months for lack of governance. My goal on every engagement, then, isn't to produce beautiful deliverables, but to build a system that works after I leave.

Good governance is neither a 50-page document nor one more committee in already saturated calendars. It's a lightweight, measurable, and largely automated mechanism that keeps architecture data fresh, used, and tied to decisions. Here's the model I deploy.

Why EA efforts collapse within six months

The collapse always follows the same script. The setup project mobilizes energy and budget, produces a complete snapshot of the IT landscape, then ends. The consultant leaves. Nobody has explicit responsibility for keeping the data current. Six months later, the repository describes a reality that no longer exists, and the organization wrongly concludes that 'EA doesn't work'.

The culprit is never the tool or the method: it's the absence of a governance system designed for the long run, not for the project. Governance isn't the final step of a deployment — it's its survival condition.

Pillar 1 — Clear roles

First pillar: explicit roles. Who creates architecture objects? Who validates them? Who consumes them? Until these responsibilities are named, nobody owns them. I write them into job descriptions and annual objectives, not into a governance document nobody re-reads.

The crucial point is the business owner. Without a sponsor on the executive committee who carries the repository's value, EA stays an IT artifact with no strategic reach, abandoned the moment the consultant leaves. The business capability offers a natural frame here: you name an owner per capability domain, accountable for the freshness and quality of their zone.

Pillar 2 — Lightweight rituals

Second pillar: lightweight rituals. The temptation is to set up heavy, frequent committees; that's the surest way to kill buy-in. In most contexts, a one-hour bi-weekly architecture review is enough, supplemented by asynchronous reviews for routine decisions.

The purpose of a ritual isn't to control, but to synchronize and unblock. A review that merely ticks boxes is one meeting too many. A review that settles three trade-offs and unblocks two projects justifies its existence.

Pillar 3 — Measurement: 4 KPIs

Third pillar: measurement. Without indicators, governance drifts into the declarative. I systematically define four simple and sufficient KPIs:

• Coverage: how many applications and capabilities are documented against the target scope.
• Freshness: how old the last update of objects is.
• Usage: who consults the repository, how often, for which views.
• Compliance: how many projects actually go through architectural review.

These four numbers, displayed on a dashboard and tracked over time, turn governance into a steering loop. Degrading freshness is a far more useful alarm than an annual audit.

The Architecture Review Board, right-sized to context

The Architecture Review Board (ARB) is the key body, but it must be sized to context. In a large regulated bank, it's a formal committee with a clear mandate and veto power. In a scale-up, it's a discussion channel with asynchronous reviews and a lead architect.

The format matters little; what matters is that every significant architecture decision is traced and arbitrated. I always keep a decision log — Architecture Decision Records (ADRs): context, options, choice, consequences. It's this log, not the diagrams, that keeps the organization's architectural memory alive.

Automate quality controls

The lever I advocate most consistently: automating quality controls. Rather than relying on individual discipline — which never survives the test of time — I configure rules in the EA tool that automatically verify object completeness, relationship consistency, and duplicate detection.

Concretely: an application with no linked capability is flagged; a capability with no owner surfaces in a report; an object not updated in six months triggers an alert. It's far less glamorous than a twelve-page governance framework, but it's exactly what separates a repository that lives from one that dies.

Govern by capabilities, not by projects

One last conviction from the field: the most durable governance anchors on business capabilities, not on projects. Projects are born and die; capabilities endure. By assigning repository responsibility per capability domain, you create stable governance that doesn't collapse with every reorganization.

This anchoring also lets you connect architecture governance to investment governance: every project declares the capability it serves, and the repository becomes the factual arbiter of portfolio decisions.

What I take from the field

EA governance that works comes down to four words: roles, rituals, measurement, automation. The rest — thick frameworks, bloated committees — is bureaucracy that reassures but serves no one.

The real success test is simple: come back to the repository a year after you left. If it's still fresh, used, and tied to decisions, governance held. If not, you delivered a project, not a system.