Most architecture governance is theatre. Not because the people running it are cynical, but because the design optimises for the appearance of control rather than the quality of decisions. A monthly review board, a slide deck, a sign-off, a record that someone with a senior title nodded. It feels like rigour. It rarely is.
This is a Delivery Architecture: The Translation Layer problem, not a process problem. Architecture is the discipline of making decisions that let an organisation change safely and deliver consistently. Governance is meant to raise the quality of those decisions. The test is therefore simple, and uncomfortable: does the governance you run measurably improve decision quality by more than the flow it costs? Most organisations have never asked, and if they did, the answer would be no.
The empirical case against the gate
The most useful finding here is also the most ignored. DORA's research into change approval found that approval by an external body — a change advisory board or a senior manager outside the team — was negatively correlated with software delivery performance, and produced no evidence that it reduced change-fail rates. The recommended mechanism for segregation of duties was peer review plus automation, not a committee. In other words, the safety case for the gate is empirically weak. The thing we tell ourselves the board is for, it does not do.
Sit with that, because it reframes the whole conversation. If a slow, centralised approval gate neither speeds delivery nor lowers failure, then its primary output is assurance theatre: a paper trail that exists to make risk and compliance feel comfortable. The governance is real; the value is imagined. And the cost — larger batches, delayed decisions, architects pulled into rooms to rubber-stamp work they did not do — is paid every single sprint.
The governance-to-value ratio
We find it clarifying to make this explicit and treat it as a first-class delivery metric: the The Governance-to-Value Ratio ratio. Governance is justified only by the decision quality it adds minus the flow cost it imposes. Run that calculation honestly across a typical enterprise and the ratio is structurally upside-down — a great deal of ceremony producing very little improvement in the decisions that actually matter. The instinct when something goes wrong is to add another checkpoint. The instinct is almost always counter-productive: you have raised the cost side of the ratio without touching the quality side.
Governance that cannot point to a decision it made better is not governance. It is the cost of pretending.
Records, advice, and the lightweight stack
The good news is that the lightweight alternatives are now mature, not experimental. The base primitive is the Architecture Decision Record, coined by Michael Nygard in 2011 as a deliberately small document focused on the decision itself — context, the options considered, and the consequences accepted. ADRs are now thoroughly mainstream: MADR reached 4.0.0 in September 2024, Azure's Well-Architected guidance adopted them in November 2024, and in December 2025 the UK Government Digital Service published a cross-government ADR framework explicitly to cut duplication, retain context when staff leave, and enable more joined-up delivery.
The decision-making model that pairs with records is Andrew Harmel-Law's Architecture Advice Process, set out in his O'Reilly book 'Facilitating Software Architecture' (2024). The rule is elegant: anyone may take an architectural decision, provided they seek advice from everyone meaningfully affected and from those with relevant expertise. Advice is not permission. Consensus is not required. Advice-givers cannot veto. Accountability stays with the person taking the decision, and the decision is recorded in an ADR. Around this sit three supports — a weekly, roughly hour-long Architecture Advisory Forum that gives advice rather than approval, a small set of team-sourced principles, and a technology radar. To be clear, this is Harmel-Law's named model, and the credit is his; what we add is how to decide when it is not enough.
An escalation model based on consequence, not hierarchy
Most writing frames the choice as binary — heavyweight boards or fully decentralised advice. That is a false dichotomy. The missing piece is an escalation model that asks when a decision legitimately earns more weight. We tier governance by consequence, borrowing two dimensions. The first is reversibility, in Bezos's framing of one-way and two-way doors. The second is blast radius: how many teams and systems a decision constrains.
Two-way-door decisions — reversible, locally contained — take the advice process and nothing more. The cost of being wrong is the cost of changing your mind later, which is low. One-way-door decisions, or anything that is irreversible across team boundaries, earn synchronous review: a real conversation with the affected and the expert before the door closes. This makes governance proportional to consequence. It is the precise opposite of a uniform monthly board that treats a library choice and a data-residency commitment as the same risk class. The board insults the small decisions and under-serves the large ones.
Harmel-Law is candid about how this degrades, and the failure modes are worth naming because they are the ones we see most: senior people quietly blocking decisions, the same architects continuing to decide everything, off-the-radar 'shadow architecture', and a simple absence of organisational trust. His stated hardest problem — 'to be in all the right places at all the right times' — is the real constraint, not the model itself. None of this works if the records and forums become bolt-on compliance artefacts. Both GDS and Harmel-Law make the same caveat: process delivers value only as part of the team's normal rhythm. The moment ADRs become box-ticking, you have rebuilt the theatre with cheaper props.
ADRs as the audit trail, not the documentation
Here is the reframe that lets decentralisation survive contact with risk and compliance. Most people treat ADRs as documentation. They are better understood as the audit trail that makes a decentralised system legible to assurance. Much governance theatre exists to satisfy a genuine need — someone has to be able to reconstruct why a decision was taken and confirm it is being honoured. A good ADR corpus answers the first. Automated fitness functions answer the second. As the saying goes, a decision record documents the decision; a fitness function assures it. Between them they satisfy the assurance need more cheaply, and continuously, than a committee that meets once a month and forgets by Thursday.
Why this becomes urgent under AI
There is a forcing function arriving. As an agentic SDLC accelerates the rate at which architectural decisions are proposed, human approval gates become the binding constraint — the bottleneck simply moves to the slowest human in the loop. A monthly board cannot govern decisions arriving at machine speed; it can only ignore most of them, which is shadow architecture by another name. The advice-process, ADR, and fitness-function stack is the only model we have seen that scales to that volume while preserving accountability, because it distributes the decision and automates the assurance rather than centralising both.
This is the same translation-layer problem we keep returning to. Governance, done well, is the layer that lets an organisation accept AI-generated decisions safely — recorded, advised, and continuously checked — rather than either rubber-stamping them or freezing. Lightweight governance is not the soft option. It is the only version that survives the volume.
If you want to start, do not start with a new board. Start by measuring your The Governance-to-Value Ratio ratio: which gates have actually improved a decision, and what flow they cost to do it. Then move two-way-door decisions to the advice process and reserve synchronous review for the doors that do not reopen. For more on how this connects to outcomes, see our companion notes on Architecture Decision Records: The Missing Link Between Architecture and Delivery and Why Most Architecture Functions Fail to Create Business Value.