An architecture review board has become a bottleneck that teams route around. What should replace it?

Why it became a bottleneck

Fixed capacity against unbounded demand. Every significant change queues for the same small group, the queue grows, and teams find routes around it — producing worse assurance than none, because the control exists on paper and not in the system.

It is also frequently reviewing the wrong things: choices with no cross-cutting consequence, at a level of detail the board cannot usefully assess, long after the decision was effectively made.

What should replace it

• Automated checks for anything mechanical. Dependency direction, forbidden libraries, mandatory observability, tenant columns, authorisation on every endpoint. A control in the pipeline is faster, more consistent, and produces evidence as a by-product — and it removes most of the volume from the human process.
• Paved roads. A team that gets a compliant, observable, audited service from one command does not need to be reviewed into compliance; the standard is in the template.
• A narrow design authority for the small class of decisions where inconsistency is genuinely a security, regulatory or interoperability problem — identity, data classification, the shape of the audit record, cross-cutting API conventions — with everything else explicitly delegated.
• Advisory review with a hard time budget, available on request, with a commitment to respond within days. A review that cannot be scheduled inside a week will be skipped, and a skipped review provides less assurance than no review because it manufactures false confidence.
• Written proposals reviewed asynchronously, which scales better than a meeting and produces a record.

The cultural condition

Reviews must be useful to the team being reviewed, or they are experienced as a tax. The test is whether teams request reviews voluntarily for decisions they find hard. If the only reviews happening are the mandatory ones, the function is compliance rather than architecture.

The narrow set worth centralising

Anything where inconsistency between teams is the problem: identity and authorisation model, data classification, event schema conventions, the audit record, tenancy model, and public API conventions. These are cheap to standardise early and extremely expensive to reconcile later.

Everything else should be a team decision, because a design authority that reviews everything reviews nothing well.