Architecture decisions in your organisation are either ignored or bottlenecked in a review board. Design something better.

Why both failure modes have the same cause

A review board is a synchronous, low-bandwidth, high-latency channel: teams wait, decisions are made by people distant from the work, and the outcome depends on who is in the room. Teams route around it — which is the "ignored" failure — or they queue, which is the bottleneck.

Distance from the work is the most common source of poor architecture decisions. The fix is to move decisions closer to teams while keeping the constraints that genuinely need to be organisation-wide.

Principles, small in number and with rationale

Five to ten, each with a statement, rationale, implications and exceptions.

The rationale is what makes a principle applicable to a case its authors did not foresee. "Prefer managed services" is a slogan; "prefer managed services because operational capacity is our scarcest resource" resolves the unforeseen case immediately.

Two tests: a principle must be directive — it excludes something — and contestable, in that another organisation could reasonably hold the opposite. "We value quality" fails both.

The exception path is what keeps them credible. A principle with no exception route is either ignored or followed into an obviously wrong outcome.

Automate what can be automated

Fitness functions in the pipeline replace most of what a review board was checking, and do it better: on every commit, in minutes, to the person who caused the drift, objectively, without depending on a reviewer noticing.

What is mechanically checkable: dependency direction and layering, forbidden libraries and versions, API compatibility (diffing OpenAPI or Protobuf for breaking changes), performance budgets, security policy (no public buckets, no unencrypted volumes), licence compliance.

Rules: start with a small set that matters — a pipeline failing for trivial reasons gets bypassed. Give each a message explaining why. Provide a recorded exception mechanism, so a legitimate deviation is documented rather than achieved by deleting the check.

Decide by reversibility

"How expensive is it to undo?" should determine the process, not the topic.

Reversible — a library, an internal API shape, a caching layer. The team decides, records it briefly, and moves. Extended analysis of something changeable next month wastes the most expensive resource in the room.

Irreversible or expensive — a data model that will hold years of records, a partitioning key, a public API contract, a vendor commitment, a regional topology. These deserve real analysis, a written record and broader review.

Publishing this distinction is itself most of the governance change, because it tells teams what they may simply decide.

Record decisions where they can be found

ADRs in the repository, versioned with the code: context, options considered, decision, consequences. The rejected options and their reasons are what future readers actually need, and they are what stops the same debate recurring every eighteen months.

Keep architects close to delivery

Architecture as a team activity with a named owner rather than a separate function that hands designs over. Architects embedded in delivery, writing code or at least reviewing it, with explicit decision rights — what a team decides, what escalates, and to whom.

Then measure whether it is working: lead time for architectural decisions, fitness function pass rates, and the number of exceptions requested — a rising exception rate means a rule is wrong, not that teams are non-compliant.