An organisation of 120 teams ships several hundred changes a day. Architecture standards exist as a wiki, adherence is inconsistent, and the review board has a six-week queue. One governance investment can be funded this year. Which comes first?
Show the full answer Hide the answer
The deciding property
Several hundred changes a day against any human review process gives a queue, not governance. Even a generous board reviewing 20 designs a week covers a fraction of a percent of changes, and the fraction it covers is selected by whoever chose to submit. The constraint is arithmetic, and no amount of staffing changes its shape.
Automated conformance is the only mechanism whose capacity scales with change volume. It also changes the feedback timing from weeks to minutes, which is what determines whether a rule is obeyed: a rule enforced at merge time is a design input, and the same rule enforced six weeks later is rework.
What to encode, and what not to
The value is in choosing few rules. Good candidates are machine-checkable, unambiguous and consequential: every service declares an owner and an on-call rotation; no public load balancer without TLS and authentication; container images from approved bases only; no database credential outside the secret store; every service emits the standard request-id header; infrastructure templates carry cost-attribution tags.
Bad candidates are anything requiring judgement: whether a service boundary is right, whether this is the correct data store, whether the design is over-built. Those need the humans, which is what frees the board to do them.
Start with five rules, not fifty. Each one needs a documented reason, a fix message that says what to do rather than what is wrong, and an exemption path that is logged and time-boxed. A rule without an exemption path gets routed around, and then you lose the signal too.
Why the other options fail
- More architects to clear the queue. Doubles throughput on something that needs a hundredfold increase. It also makes the board more central, which deepens the dependency it should be reducing, and it is the most expensive option on the list.
- A mandatory standards document with executive approval. A wiki page already exists and is inconsistently followed; the failure was never a lack of authority, it was that nothing checks. Executive endorsement of an unenforceable rule mainly creates a compliance theatre where teams assert adherence on a form.
- An ADR for every change. Excellent practice at the wrong altitude. Requiring records for hundreds of daily changes produces hundreds of empty records, devalues the ones that matter, and adds latency to every change. Trigger ADRs on significance, not on every commit.
What would flip the decision
| If this changes | Choose | Because |
|---|---|---|
| Change volume is 5 a week, not 300 a day | Human review, with a triage rule | At that volume a board is genuinely capable of reviewing the changes that matter |
| The problems are design-shaped, not rule-shaped | Advisory review and reference implementations | No check can decide whether a boundary is in the right place |
| Teams cannot deploy without a central pipeline | Enforce in the paved road instead | If everyone goes through one path, make the path do the work and skip the check entirely |
When this is the wrong answer
If the estate has no shared pipeline, automated checks have nowhere to run, and building that platform is a far larger programme than the governance problem justifies. The cheaper intervention there is a reference implementation that teams copy, which gets the same defaults into new services without any enforcement mechanism at all.