An Architecture Review Process That Actually Works

Most architecture review boards fail in one of two ways. Either they become a gate that teams route around, or they become a ceremony where slides are approved without anyone reading them. A good review process is neither. It is a cheap, repeatable way to get a second set of experienced eyes on decisions that are expensive to reverse, early enough that the feedback can still change something.

Decide What Deserves a Review

Not every change needs one. Reviewing everything guarantees the process is slow and the reviewers are shallow. Reserve reviews for decisions that are hard to undo or that cross team boundaries:

Introducing a new datastore, message broker, or major framework
Changing a public API or an event contract that other teams consume
New external dependencies with security, compliance, or cost implications
Changes to data ownership, tenancy, or the trust model
Anything that alters availability or recovery targets

A useful test is the "two-way door" heuristic. If a decision can be reversed in a sprint with little cost, let the team decide. If reversing it takes a quarter, review it.

Review the Design, Not the Slides

Ask authors to submit a short written proposal at least two business days before the review. Six pages or fewer is plenty. A solid template covers:

Context and problem: what is hurting and for whom
Constraints and quality attributes: latency, throughput, availability, cost, compliance
Options considered: at least two real alternatives, including "do nothing"
Proposed design: a diagram, data flow, and ownership boundaries
Risks and unknowns: what could make this wrong
Rollout and exit plan: how to deploy it and how to back out

Written proposals force clarity. Authors often discover holes while writing, which is the cheapest review of all. They also let reviewers prepare, so the meeting can be spent on disagreement rather than explanation.

Run the Meeting Like a Debugging Session

Keep it to 45 minutes. The author spends five minutes on the problem and recommendation; the rest is questions. Reviewers should probe specific failure scenarios rather than offering general opinions:

What happens when this dependency is down for ten minutes?
How does this behave at ten times current load?
Who owns the data when two services disagree?
What is the cost of the first wrong guess, and how would we know?

Assign a facilitator who is not the author. Their job is to keep discussion on the design, capture decisions and open questions live, and stop bike-shedding. Rank feedback in three tiers: blockers (must change), concerns (author decides, but must respond), and suggestions (take or leave).

Produce a Decision, Not Just Comments

Every review ends with one of three outcomes: approved, approved with conditions, or revisit. Record the outcome and the reasoning in an architecture decision record so future engineers can see why the system looks the way it does. If reviews leave no durable artifact, the same arguments will be repeated in a year.

Keep the Process Healthy

Reviews degrade quietly, so measure them lightly:

| Signal | Healthy | Unhealthy | |---|---|---| | Time from request to review | Under one week | Several weeks | | Share of reviews with changed designs | Meaningful minority | Almost none | | Teams asking for reviews voluntarily | Common | Rare, or avoided | | Late surprises in production | Falling | Unchanged |

If nearly every proposal is approved unchanged, either the bar is too low or authors are being reviewed too late. If teams skip the process, it is probably too heavy. Consider tiering: a quick asynchronous review in a pull request for medium decisions, and a live session only for the largest ones.

Also rotate reviewers. A standing panel of three people becomes a bottleneck and a single point of taste. Drawing reviewers from different teams spreads context and grows the next generation of architects.

Key Takeaways

Review only decisions that are costly to reverse or that cross team boundaries.
Require a short written proposal with real alternatives before the meeting.
Probe failure scenarios and quality attributes instead of debating preferences.
Always leave a recorded decision with its rationale.
Treat the review process itself as a product: measure its speed and impact, tier it, and rotate reviewers.