Architecture Review: What It Covers and When You Need One

An architecture review is an independent look at an existing system: how it is structured, where the risk sits, what is making change slow or expensive, and what to fix first. It is not an audit with a pass mark. The useful output is a short, prioritised list of changes, each with the reason it matters, that the team can act on.

When a review is worth doing

• Before a big investment. A new product line, a large migration, or a funding round where someone will ask whether the system can carry the plan.
• After fast growth. The system grew around deadlines, and nobody has stepped back to look at the whole.
• When delivery keeps slowing. Every change touches more than it should, and estimates keep slipping.
• When incidents repeat. The same kind of failure keeps coming back in different places.
• When a decision needs a second opinion. A rebuild, a re-platform, or a vendor choice, where the people closest to it have a stake in the answer.

If none of these apply, you may not need one. A review is most useful when there is a real decision or a real pain behind it.

What a review looks at

Area	The question
Structure	Do the boundaries between components match how the business actually changes?
Data	Who owns each piece of data, and how many copies of the truth are there?
Integrations	What happens when an external system is slow, down, or changes its API?
Reliability	Where are the single points of failure, and how would you know something broke?
Security	How are access, secrets and sensitive data handled in practice, not on paper?
Delivery	How long does a small change take to reach production, and what slows it down?
Cost	Which parts cost more to run or change than they’re worth?
Team fit	Can the current team understand, operate and change what exists?

Not every review needs every row. The question you start with decides which ones get the most time.

What you should get at the end

• A current-state picture: the systems, how they connect, and where data lives, as it really is.
• The main risks and constraints, ranked by likelihood and impact.
• Observations about the architecture: what is working and should be protected, as well as what isn’t.
• Options for the important problems, with trade-offs.
• A recommended direction and a prioritised list of changes, so the team knows what to do on Monday.

A review that ends with forty equally weighted findings hasn’t finished its job. The prioritising is the valuable part.

How to prepare

1. State the question. “Can this system support ten times the customers?” leads to a very different review than “Why does every release break something?”
2. Gather what exists. Diagrams, decision records, incident reports, deployment setup. Out of date is fine; it shows where reality drifted.
3. Book time with the people who know. The engineers who built it, the people who operate it, and someone who knows what the business needs next.
4. Agree what happens after. Who receives the findings, and who decides what to act on.

Internal or external reviewer?

An internal reviewer knows the history. An external one has no stake in past decisions, which makes it easier to say that a choice no longer fits, and easier for the team to hear it. For a system behind a big decision, an outside view is usually worth it. For regular health checks, an internal review against a shared checklist works well, and the Well-Architected pillars are a reasonable starting structure.

If you’re facing one of the situations above, an architecture review typically takes one to three days and ends with exactly that prioritised list. For a review focused on an acquisition or investment, see the technical due diligence checklist.