Most architecture practices don't fail on the design work — they fail on governance. Done well, governance keeps decisions consistent and risks visible; done badly, it's bureaucracy everyone avoids.
Architecture governance is the set of mechanisms that make architectural decisions consistent, visible and accountable across an organisation. It answers three questions: who decides, on what basis, and what happens when someone wants to deviate.
It is not the same as doing architecture. Design work produces the answer; governance ensures the answer is applied, that deviations are conscious rather than accidental, and that the reasoning survives the people who were in the room.
A complete governance model has six parts. Most struggling practices have three or four and cannot work out why decisions keep unravelling.
The exception route is the piece most often missing, and its absence is more damaging than it looks. Without a sanctioned way to deviate, teams deviate anyway and simply do not tell you. You lose the deviation and the visibility.
Most governance dysfunction traces back to unclear decision rights. If nobody has written down who can approve a £50k technology choice versus a £5m platform selection, every decision escalates to the same forum, which then becomes a bottleneck and gets bypassed.
Set thresholds explicitly: what a solution architect decides alone, what needs a domain architect, what needs the design authority, what needs an executive. Push as much as possible to the lowest level that can be held accountable. Governance that reserves every decision to a central committee will be routed around within a year, and the people routing around it will be right to.
| Failure | What it looks like | Root cause |
|---|---|---|
| Bottleneck | Projects wait weeks for a slot; delivery leads escalate | Everything needs central approval; no delegated thresholds |
| Rubber stamp | Nothing has ever been rejected or reworked | Reviews scheduled after commitment; no authority to say no |
| Shadow architecture | Systems appear that governance never saw | No exception route, or the process costs more than ignoring it |
| Principle drift | Principles exist; nobody cites them | Too abstract, too many, never referenced in reviews |
| Invisible value | Leadership asks what governance is for | Nothing measured; no reporting |
The test of good governance is whether a delivery team would voluntarily bring something to it. That happens when the process is fast, when it resolves ambiguity the team could not resolve alone, and when a decision — including a difficult one — actually holds afterwards.
Practically, that means publishing the standing agenda and thresholds so nobody wonders whether they need to come. It means committing to a turnaround, so a submission gets a decision within a fixed number of working days. And it means the chair defending an unpopular decision when a sponsor pushes back, because a governance body that folds under pressure once has taught the organisation everything it needs to know.
Do not launch a full model in one go. Start with a fortnightly forum, a written list of what must come to it, and a decision log. Add principles once you have seen the recurring arguments — principles written before you know the arguments are guesswork. Add measurement last, once there is something to measure.
A lightweight model that runs every fortnight for a year beats a comprehensive one that is abandoned after three months.
The Architecture Practice Setup Kit is architecture governance in a box — operating model, Design Authority, principles, exceptions and a live KPI dashboard, with a worked example.
