The head of retail digital has a feature ready to ship. It is a small thing, a redesigned account-summary screen in the mobile app, and the team could deploy it this week. There is one obstacle: to pull the balances it needs, the fastest path is a direct call straight into the Northline core, bypassing the shared integration layer the architecture team has been carefully building. It would work. It would also be exactly the kind of point-to-point shortcut that created Aldermont's three-cores mess in the first place. Before the team can ship, the design has to go to the architecture review board.
Everyone involved feels the tension in the room. The retail lead sees a review board standing between a finished feature and its users, adding a week of delay to something that works. The architects see a team about to add one more untracked integration to an estate already drowning in them. Both are right, and the mechanism that has to resolve their conflict, well or badly, is architecture governance.
What governance is actually for
Strip away the connotations and governance has a simple definition. Architecture governance is the set of processes by which an organization ensures that individual technology decisions stay aligned with the agreed target architecture and standards. It is the enforcement layer. Everything the earlier posts described, the target state, the canonical customer model, the portfolio's intended shape, is just a set of good intentions until something makes day-to-day decisions actually conform to it.
The need is easiest to see by imagining its absence. Aldermont can run a flawless TOGAF program, produce a beautiful target architecture, and pick the perfect survivor core, and none of it matters if, under delivery pressure, a hundred individual teams each make the locally convenient choice that quietly violates the plan. The target architecture erodes one reasonable shortcut at a time. Governance exists to catch those shortcuts at the moment they are proposed, before they become permanent.
The core idea: Governance is what stands between a good architecture on paper and a degraded architecture in reality. Its job is to keep the sum of many local, reasonable decisions from adding up to a globally incoherent estate. Done well, it is nearly invisible. Done badly, it becomes the gatekeeping bureaucracy that gives enterprise architecture its worst reputation.
That last sentence is the whole problem in miniature. Governance is genuinely necessary and genuinely dangerous, and the difference between the two versions is not whether you have it but how it is designed. So it is worth looking at the machinery, then at how that machinery goes wrong.
The machinery of governance
Governance is usually built from three kinds of thing: the standards that define what "aligned" means, the bodies that make decisions, and the process that routes decisions to them. Each is simple on its own; the art is in how lightly or heavily they are applied.
The standards and principles are the written rules that decisions are checked against. These range from high-level principles ("every data entity has one system of record") down to specific standards ("new services authenticate through the central identity provider"; "integrations go through the shared event backbone, not point-to-point"). Aldermont's shortcut is a governance issue precisely because there is a standard it would violate. Without written standards, governance has nothing to enforce and degenerates into the personal opinion of whoever is in the room.
The decision bodies are the people or groups empowered to approve, reject, or grant exceptions. The classic one is the Architecture Review Board, often shortened to ARB: a group that reviews significant technology decisions against the standards. Larger organizations layer these, with a central board for enterprise-wide decisions and delegated authority for smaller ones. The board is where the retail lead's feature is headed.
The process is how a decision reaches a body and what happens to it there: what triggers a review, what the team must bring, how the decision is recorded, and how exceptions are handled. This is the part most responsible for whether governance feels like help or obstruction, because it determines how much friction every decision carries.
The central tension — control versus speed
Every design choice in governance is a trade-off along a single axis, and pretending otherwise is how governance goes wrong. On one end is control: catch every deviation, review everything, keep the architecture perfectly coherent. On the other is speed: let teams decide and ship without waiting on a board. You cannot maximize both. More of one is less of the other, and the honest work of designing governance is choosing where on that axis each kind of decision should sit.
Both ends fail at their extreme. Total control produces the caricature everyone dreads: every trivial decision queued for a slow committee, teams waiting weeks for sign-off on things that never needed it, and eventually the predictable rebellion where teams simply stop telling the board what they are doing. That last outcome is the worst of all, because governance that is routed around provides the illusion of control with none of the substance. Total speed produces the opposite failure, the one Aldermont is living: every team optimizing locally, no coherence, and an estate that decays into exactly the three-cores tangle the whole series has been about.
The retail lead's stuck feature is a single point on this axis. Route it through a heavyweight board and a one-week feature waits a month; wave every such decision through and the point-to-point shortcuts accumulate until the estate is ungovernable. Neither extreme is the answer. The answer is to make the axis itself the design tool.
What good governance actually does differently
The way out of the control-versus-speed bind is to stop treating it as one setting for all decisions. Good governance is risk-based: it spends its scrutiny where the stakes are high and gets out of the way where they are low. A few design choices separate the governance that helps from the governance that obstructs.
The first is proportionality. Not every decision deserves the same process. Choosing a new core banking platform warrants the full review board; picking a logging library does not. Good governance tiers its decisions, reserving heavyweight review for choices that are expensive to reverse or that affect many teams, and delegating or auto-approving the rest. The retail lead's problem is often really a proportionality failure: a genuinely significant decision (bypassing the integration layer) and a trivial one (a screen redesign) getting funneled through the same slow gate.
The second is enablement over gatekeeping. The most effective modern governance shifts from saying no at the end to making the right thing easy from the start. Instead of a board that rejects non-compliant designs, the architecture team provides paved paths: pre-approved patterns, a ready-made integration that is easier to use than the shortcut, reference implementations that are compliant by default. When the compliant path is also the path of least resistance, most decisions never need a review at all, because the easy choice is already the right one. This reframes the architect from gatekeeper to service provider, and it is the single biggest lever for defusing the tension.
The third is a real exception process. Sometimes the shortcut genuinely is the right call: a deadline that matters more than the debt it incurs, a case the standards did not anticipate. Governance that cannot say yes to exceptions will be routed around, so mature governance grants them deliberately, records them, and tracks the resulting debt so it can be paid down later. An exception is a conscious, logged decision to deviate, which is entirely different from an unnoticed violation. This is where governance connects directly to the portfolio from the previous post: each granted exception is a known entry in the technical-debt ledger rather than a silent liability discovered years later.
Resolving the retail lead's feature
With that machinery in view, the opening standoff resolves in a way that satisfies neither caricature. The design is triaged, and the screen redesign itself sails through on the paved path; it was never the issue. The one significant element, the direct call bypassing the integration layer, is what actually reaches the board.
And there, good governance does something more useful than simply saying no. The better outcome is that the architecture team already provides a paved path: a ready-made way to read a balance through the shared layer that is genuinely easy to use, so the team gets its data without the shortcut and ships close to on time. If that paved path does not yet exist, the honest move may be to grant an exception, ship now, and log the direct call as a tracked piece of debt to be migrated onto the integration layer later. What good governance does not do is leave the team stuck at a slow gate with a finished feature and no path forward. The stuck feature is itself a symptom of governance designed badly.
Where you will encounter it
Most engineers meet architecture governance long before they hear the term. The review you have to pass before provisioning infrastructure is governance. The mandate to authenticate through the central identity provider is a governance standard. The pull-request check that blocks a disallowed dependency is governance automated into the pipeline, which is proportionality done well, since the low-stakes rule is enforced with zero human friction. The design document you circulate for architectural sign-off before a big project is the review process in action.
The quality of that governance is something you can now read. When the process is proportionate, when the compliant path is the easy one, when exceptions are possible and tracked, governance feels like guardrails. When every decision hits the same slow board, when saying no is the only move available, and when the only way to move fast is to hide what you are doing, governance has been designed badly, and the estate will suffer for it either way, through gridlock or through the shortcuts that gridlock provokes.
Summary
Architecture governance is the enforcement layer that keeps a good architecture on paper from becoming a degraded architecture in reality. It is built from standards that define what alignment means, decision bodies like the review board that rule on significant choices, and the process that connects them. Without it, the target architecture erodes one locally reasonable shortcut at a time, which is precisely how Aldermont ended up running three of everything.
But governance is the part of enterprise architecture most capable of doing harm, because it sits on a genuine tension between control and speed that has no single right setting. The failure at one extreme is sprawl; at the other, it is gridlock and the quiet rebellion of teams routing around the board, which is worse than no governance at all. The way through is not to pick a point on that axis but to vary it: proportionate scrutiny that goes heavy on decisions that are expensive to reverse and gets out of the way on those that are not, paved paths that make the compliant choice the easy choice so most decisions never need a review, and a real exception process that turns unavoidable deviations into tracked debt rather than silent liabilities. The head of retail digital and the architecture team are not really enemies; they are two ends of a trade-off that well-designed governance is supposed to hold in balance. Get that design right and governance becomes nearly invisible, the guardrails that let the organization move fast without driving off the road. Get it wrong and it becomes the gatekeeping bureaucracy that gave the whole discipline its reputation. Which of those you build is a design choice, and it is the one that determines whether everything the rest of this series described survives contact with a Monday-morning deadline.
Part of the Enterprise Architecture series on this blog.
Part of the Explained series — concepts in tech, clearly.