Architecture Reviews That Do Not Become Theater

The worst architecture reviews sound impressive and change nothing. Senior people say correct things. Diagrams are admired. Someone asks about scalability. Someone else asks about observability. A principal engineer says "it depends" with excellent posture. The meeting ends. The system proceeds exactly as before.

That is architecture theater. The ceremony is real. The decision is not.

What A Review Is For

An architecture review should improve a decision before the cost of being wrong gets large. That is it. It is not a stage for seniority. It is not a compliance ritual. It is not a place to collect every concern anyone can imagine.

The AWS Well-Architected review guidance is useful here because it frames review as a lightweight, blame-free conversation that identifies critical issues and actions. That spirit travels well beyond AWS. A good review should leave behind a clearer decision, named risks, an owner, and a follow-up path.

Review Fewer Things

Not every technical choice deserves a formal review. Reviewing everything teaches teams to hide decisions or perform them. I prefer to review choices that are expensive, hard to reverse, cross-team, security-sensitive, reliability-sensitive, data-sensitive, or likely to constrain hiring and operations.

If a decision is cheap and reversible, document it lightly and move. If a decision is expensive and irreversible, slow down enough to think.

Ask For Evidence, Not Confidence

Review meetings often reward confident speech. That is dangerous. The better question is not "are you confident?" It is "what evidence would make us more or less confident?"

Evidence can be a prototype, load test, incident history, customer workflow, cost model, threat model, ADR, migration rehearsal, SLO, or operational runbook. The evidence does not have to be perfect. It just has to move the conversation away from taste.

Record The Decision And The Consequence

Michael Nygard's architecture decision record practice remains useful because it is small. Capture the context, decision, and consequences. That is enough to preserve why the team chose a path. Future engineers do not need a museum. They need a map of the tradeoffs that mattered at the time.

An ADR is especially useful when a decision looks strange six months later. Often it was not strange. It was constrained. A good record protects teams from rediscovering old debates without the old context.

Make Reliability And Cost First-Class

Reviews become abstract when they ignore user-facing reliability and operating cost. Google SRE's SLO and error-budget language is helpful because it connects engineering decisions to user experience and release tradeoffs. You do not need to copy the vocabulary perfectly, but you do need to ask: what reliability promise does this architecture support, and what work becomes impossible if we break it?

Cost deserves the same treatment. The question is not "is this cheaper?" It is "what cost curve are we accepting, and who will notice first when it bends?"

The Review I Want

The review I want is calm, specific, and short. It starts with the decision trigger. It names constraints. It brings evidence. It makes tradeoffs explicit. It records the decision. It assigns the owner. It schedules follow-up. It does not try to make everyone feel equally heard on every topic. It tries to make the next wrong move less likely.

Architecture is executive leverage when it changes decisions. Everything else is theater with better diagrams.