Guide · Architecture review

The architecture review checklist: what “good” looks like

Creating a design is the easy part. Reviewing it well — consistently, across every domain, with evidence behind each judgement — is what separates a strong architecture practice from the rest.

Why a checklist beats memory

Experienced architects believe they will remember to ask about disaster recovery. Under time pressure, at the end of a long session, with a delivery lead insisting the date is fixed, they frequently do not.

A checklist does two things a good memory cannot. It makes reviews comparable, so two solutions assessed by different architects are held to the same bar. And it makes omissions visible — an unanswered item is evidence in itself, and often the most useful output of the review.

The ten domains

A workable checklist covers ten areas. Fewer and you will miss something structural; many more and reviews stop finishing.

1. Business fit — which capabilities does this serve, which business outcome does it enable, and who owns that outcome?
2. Solution design — components, responsibilities, and why this shape rather than the alternatives that were considered.
3. Data — what is mastered where, what is copied, how quality is assured, and what the retention position is.
4. Integration — interfaces, patterns, synchronous versus asynchronous, failure behaviour and coupling.
5. Security — identity, access control, data classification, encryption in transit and at rest, threat modelling.
6. Compliance and privacy — regulatory obligations, data residency, lawful basis, auditability.
7. Non-functional requirements — performance, availability, scalability, recovery. Covered in depth in the NFR checklist.
8. Operability — monitoring, alerting, support model, runbooks, who gets paged at 3am.
9. Cost — build, run and exit costs, licensing model, and what happens to cost as volume grows.
10. Risk and dependencies — what this relies on, what relies on it, and what has no mitigation.

What good evidence looks like

The difference between a review that improves outcomes and one that generates paperwork is the standard of evidence accepted.

"We've thought about security" is not evidence. A threat model, a named data classification and a documented access control approach are. "It'll scale" is not evidence. A stated concurrency target with a test result, or a costed scaling approach, is. The question to keep asking is: what would I need to see to believe this?

Where evidence does not exist, that is a legitimate and useful finding. Record it as an open item with an owner and a date rather than either waving it through or blocking the whole solution over it.

Tailoring by review type

One checklist applied identically to every review wastes everyone's time. The domains stay constant; the depth changes.

Review type	Emphasis	Typically light on
Concept / early	Business fit, options considered, rough cost, major risks	Detailed design, operability
High-level design	Solution shape, integration, data, NFR targets	Implementation detail
Detailed design	Everything, at depth	Nothing
Security-focused	Security, compliance, data	Cost, business fit
Pre-go-live	Operability, recovery, support model, open risks	Options analysis — too late

From checklist to decision

A completed checklist is an input, not an outcome. The review has to produce a decision the organisation can act on, and there are only four useful ones: approve, approve with conditions, rework, or reject.

Most reviews land on approve with conditions, and conditions are where reviews succeed or fail. A condition needs an owner, a date and a definition of done. "Address security concerns" is not a condition. "Produce a threat model reviewed by the security architect before build starts, owned by the solution architect, due 14 March" is. Conditions without owners are suggestions, and everyone knows it.

The full process around this sits in the solution architecture review.

Anti-patterns

• The unfailable review. If no solution has ever been sent back, the review is theatre and the organisation has worked that out.
• The ambush. Material circulated the night before produces uninformed challenge and defensive architects. Demand documents 48 hours ahead or move the review.
• Reviewing too late. A review after contracts are signed can only rubber-stamp. The earliest useful gate is before commercial commitment.
• Style over substance. Time spent on diagram notation is time not spent on whether the failure modes have been thought through.
• No record. If the reasoning is not written down, the same debate recurs in six months. Capture decisions as ADRs.