How to run a useful architecture review
Most architecture reviews are too late, too vague, or too focused on aesthetics. Here is a structured approach that produces decisions, not just observations.
Architecture reviews are one of those practices that every engineering organisation does at some point, but few do well. The common failure mode: a group of engineers looks at diagrams for an hour and agrees that the system is complex. Nothing changes.
A useful architecture review produces specific decisions, surfaces concrete risks, and gives the team a prioritised list of actions. Here’s how to run one.
Before the review
Define what you’re reviewing and why. “Let’s review the architecture” is not a useful scope. “We’re scaling to 10x current load in six months — let’s review whether our data layer can handle it” is.
Collect artifacts before the meeting, not during it:
- A current-state diagram (not aspirational — what’s actually running)
- Recent incident reports
- Performance metrics and error rates
- A list of planned changes for the next six months
Distribute these at least two days in advance. Review sessions where the first thirty minutes are spent drawing boxes on a whiteboard are usually not useful.
During the review
Structure the conversation around four questions:
1. What does this system actually do? Make sure everyone in the room has the same mental model. It’s common to discover disagreements here that have been silently causing misaligned decisions for months.
2. What are the failure modes? Walk the critical paths. For each one: what happens if this component is slow? What happens if it fails? Where are the single points of failure?
3. What changes in the next six months, and what breaks? Planned load growth, new features, team changes. Stress-test the current design against known future state.
4. What would you change if you were starting today? This surfaces the delta between the current design and what the team now knows. Some of those changes are worth making now. Many aren’t. The exercise helps you separate informed trade-offs from accumulated accidents.
After the review
Document decisions and their rationale, not just the outcomes. “We decided not to shard the database” is less useful than “We decided not to shard the database because current growth projections don’t require it for 18 months, and the operational complexity is not worth the insurance.”
Produce a prioritised action list with owners and timelines. Anything without an owner will not happen.
Schedule the next review. Architecture drift is slow and invisible until it isn’t. Quarterly reviews for fast-moving systems, biannual for stable ones.
The most important thing
The goal is not to produce a perfect architecture. It is to make the implicit explicit — to surface the risks and trade-offs that everyone is managing individually in their heads and get them into a shared, writable document. That shared understanding is worth more than any diagram.