Architecture Governance Model
The definition of which architectural decisions require which level of scrutiny, and who holds the authority for each.
Governance fails in two opposite directions and both are common. Too heavy: every decision goes to a board, delivery slows, and teams learn to present decisions already made as though they were options. Too light: teams diverge, the estate fragments, and the cost appears years later as integration and support burden nobody can trace to a decision.
A workable model tiers by consequence and reversibility rather than by project size. Decisions that are easily reversed and locally scoped belong to the team, with no review. Decisions that are hard to reverse or cross team boundaries — a new datastore technology, a shared contract, an authentication model, a cloud region strategy — warrant collective review. Decisions that commit the organisation for years or carry regulatory weight need formal sign-off.
The mechanisms available, from lightest to heaviest: an ADR with a review period and no meeting; an advisory group that architects consult; a decision record with delegated authority, where architects in teams hold the authority and the central function sets the principles and audits; and a formal board.
The direction that consistently works better than a stronger board: move enforcement into automation — policy as code, compliance checks, paved roads — and reserve human review for genuine judgement. Governance that a machine performs is applied consistently and costs nothing per change, which is what allows the human forum to be small, rare and taken seriously.