The architecture review checklist.
What a useful architecture review examines, in the order that keeps it about the decision rather than the diagram. Use it to review your own system or to judge whether a review you commissioned earned its fee.
This page prints cleanly, without the navigation. No signup, no download gate.
Anchor the review to a decision.
- Name the decision the review serves
- A review without a decision produces observations; a review with one produces a recommendation.
- List the constraints that are actually fixed
- Budget, team, lifetime, and the ones that only feel fixed. Designs fail on imagined constraints as often as real ones.
- Agree what evidence would settle it
- Decide up front what would change your mind; that is what the review must go and measure.
Boundaries, and what crosses them.
- Compare intended boundaries with real dependencies
- Import graphs and deployment units tell the truth; slides do not.
- Find the coupling that transmits change
- If touching one module reliably breaks another, that seam is the review.
- Check ownership per boundary
- A boundary nobody owns decays into a corridor everybody uses.
- Locate the seams for future extraction
- Good structure is measured by what could be pulled out later without a rewrite.
Where information lives and moves.
- Establish where each kind of data is owned
- Two writers to one truth is an incident schedule.
- Make integration contracts explicit
- Every implicit contract is discovered during an outage.
- Walk the failure path of each integration
- What happens when the other side is slow, wrong, or gone decides real availability.
- Hunt for the shared database
- The most common hidden coupling in systems old enough to earn a review.
What the system must guarantee.
- Name the quality attributes the business actually needs
- Availability, latency, integrity, changeability: named, bounded, and traceable to money.
- Find where the design depends on hope
- Every unmonitored assumption is a quality attribute waiting to fail.
- Walk the load and failure paths
- On paper first, then against production behaviour; the divergence is the finding.
The path to production and back.
- Trace how a change reaches production
- Steps, waits, and people; delivery friction is architecture, not process trivia.
- Test the rollback story
- A deploy you cannot undo is a bet, not a release.
- Measure the operational load the design creates
- Systems that need constant attendance were designed to need it.
The lifecycle you inherit.
- List every dependency with an owner and an exit
- Each one is maintenance, security exposure, and a future migration.
- Assess framework churn exposure
- A framework on a fast deprecation cycle sets your maintenance calendar for you.
- Check the supply-chain surface
- What arrives at build time, from where, verified how.
What the architecture makes expensive.
- Attribute run cost to design decisions
- Compute, licences, and people time follow structure; the bill is evidence.
- Ask what simplification would buy
- The cheapest component is the one removed; count those candidates honestly.
Make the outcome survive the meeting.
- Write the decision record
- Constraint, decision, avoided alternative, and why: the format outlives attendees.
- Assign each follow-up an owner and a date
- Findings without owners are trivia.
- Set the re-review trigger
- Growth, team change, or a missed quality bound; reviews age like the systems they describe.
Want independent eyes on the answers?
Tell us the decision in front of you. The review runs this list against your system and returns a recommendation with its reasoning.