Enterprise Architecture Governance

Enterprise Architecture Governance is the set of structures, principles, standards, and processes that turn architecture from a set of recommendations into a set of binding decisions. Without governance, EA is advisory — admired, then ignored. With governance, EA is authoritative — and the enterprise's architecture evolves coherently by design rather than by drift.

Effective governance is a balance. Too little, and the architecture fragments as every team optimises locally. Too much, and governance becomes a bottleneck that teams route around, producing the same fragmentation through shadow IT. The art is governance that enables as much as it constrains — that provides well-paved roads teams want to use.

This page covers the Architecture Board, architecture principles, standards management, the review process, waivers and exceptions, governance maturity, and the metrics that prove governance is working.

The Architecture Board is the body that holds architectural authority. Its composition matters: it must include senior architects (enterprise, domain), business representation (to weigh business value), and delivery leadership (to weigh feasibility). Without business and delivery voices, the board becomes a technical club whose decisions do not survive contact with commercial reality.

The board's authority must be real. It should be able to approve, defer, or reject initiatives on architectural grounds — ideally as a gate in the investment process. A board that can only 'advise' is a forum, not a governance body, and its decisions will be overridden whenever they are inconvenient.

Cadence matters as much as authority. A board that meets too rarely forces teams to wait; one that meets too often becomes a rubber stamp. The healthy pattern is a regular cadence (fortnightly or monthly) with a fast-track path for low-risk decisions, so the board's time is spent on genuinely significant architecture questions.

Architecture principles are the constitution of the EA — a small set of memorable, decision-shaping statements that guide choices when standards are silent. Examples: 'Buy before build before rent, unless the capability is a differentiator', 'Data is a shared asset, not an application property', 'Design for failure'. Good principles are few, general, and genuinely shape decisions; bad ones are many, vague, and ignored.

The test of a principle is whether it changes a decision. A principle that every reasonable person would already follow adds governance overhead without value. A principle that creates real tension — and resolves it consistently — is doing its job. Principles should be revisited annually and retired when they no longer shape decisions.

Principles must be communicated until they are internalised. The goal is not that teams consult a document, but that a senior engineer instinctively applies 'we prefer managed services' because the principle has become part of how the organisation thinks. Principles embedded in culture govern far more than principles enforced at review.

Standards are the mandated and preferred technologies, patterns, and approaches the enterprise uses. The distinction between mandated (must use) and preferred (should use, with justification to deviate) is important — it focuses strictness where it matters and leaves room to innovate where it does not.

Standards must be maintained. A standard that is not reviewed becomes a fossil that teams work around, and the workarounds become the de facto (ungoverned) standard. The healthy pattern is a standards catalogue with named owners, review cadence, and a clear lifecycle: proposed, adopted, deprecated, retired.

The standards catalogue is also a communication tool. A team starting a new solution should be able to look up 'what database, what message broker, what identity provider are approved' and get an answer in minutes. When that lookup is fast and reliable, teams use the paved road; when it is slow or ambiguous, they build their own.

Architecture reviews are where governance meets delivery. A review evaluates a solution against principles, standards, and the target state, and produces one of three outcomes: approve, approve with conditions, or reject with reasons. The review must be timely — a review that arrives after implementation is a postmortem, not governance.

The best reviews are proportionate. A low-risk, standards-conformant solution gets a lightweight fast-track review; a high-risk, novel solution gets a deep review with the right experts. Applying the same heavy review to everything creates a bottleneck that encourages teams to avoid the process; applying no review to anything is the opposite failure.

Reviews should produce learning, not just verdicts. Patterns observed in reviews — repeated exceptions to a standard, a common architectural question — should feed back into the EA as updated standards, principles, or reference patterns. A review process that only gates but never learns is a one-way valve that misses its main compounding benefit.

No standards catalogue covers every situation, and rigid enforcement of an inappropriate standard produces worse outcomes than a managed exception. A healthy governance process has a clear waiver mechanism: a documented exception with a rationale, an expiry, and an owner, approved at the appropriate level.

Waivers are not failures of governance; they are governance working. A waiver records that a decision deliberately deviated from a standard, why, and for how long — which is far better than an undocumented deviation that becomes a silent precedent. The discipline is to review expiring waivers and either renew them (rare) or retire the deviation by bringing the solution into conformance.

The signal to watch is waiver volume and pattern. A few waivers are healthy; a rising volume of waivers against the same standard signals the standard is wrong and should be revised, not enforced harder. Governance that treats waivers as problems to suppress misses the feedback they provide.

Governance maturity progresses in stages — from ad-hoc reviews, to a defined process, to measured governance, to governance that demonstrably enables delivery. Most organisations have a defined process; fewer measure whether it works; fewest can show it enables rather than obstructs.

The metrics that matter are enabling ones: lead time through architecture review, percentage of solutions using approved standards without exception, time-to-decision on waivers, and — most importantly — whether governed solutions deliver faster or slower than ungoverned ones. A governance process that slows delivery without improving outcomes is failing, regardless of how thorough it appears.

The ultimate metric is trust: do delivery teams bring designs to governance early because it helps, or avoid it until forced because it obstructs? A governance process teams choose to use is succeeding; one they are forced to use is not, however rigorous it looks.