Software architecture review: the evidence checklist

An architecture review should explain whether the current system can support the next business decisions.

A large dark module and smaller connected modules beneath an inspection lens.

An architecture review should explain whether the current system can support the next business decisions. A clean diagram is useful context, but it cannot show whether a migration is recoverable or a dependency is already limiting delivery. Start with the decision the review must support: onboarding larger customers, adding a market, changing a provider or increasing release frequency.

Choose a representative journey

Follow a customer journey across the browser, API, database, queue and external provider. Record ownership, trust boundaries and where state becomes durable. Compare the diagram with deployed configuration and a recent trace. Include a failure journey as well as a successful one: expired credentials, a slow dependency or an interrupted worker often reveal responsibilities that are absent from the diagram.

Request evidence in useful groups

Collect deployment definitions, dependency versions, database schemas and migration history. Add recent incident reports, release timings, performance measurements and recurring support problems. Ask for a small set of important architectural decisions and the constraints behind them. Keep customer records and secrets out of the review pack; read-only access and anonymised examples are usually enough for initial investigation.

Make each claim testable

For reliability, request a restoration result rather than a backup schedule. For scale, examine a representative workload and bottleneck rather than a server specification. For maintainability, trace one recent feature through the components it changed. For security, inspect how authentication, authorisation and tenant boundaries are actually enforced. Mark unavailable evidence as unknown instead of translating an interview answer into a passed check.

Leave a decision register

Record the observation, supporting evidence, business consequence and smallest useful next step. Distinguish defects that need repair from deliberate trade-offs that remain suitable. Give each recommendation an owner and acceptance condition. A suggested extraction, for example, should name the boundary and release problem it resolves, plus the migration and rollback work. Revisit the register when product constraints change rather than treating the review as a permanent certificate.

Frequently asked questions

Do we need a complete system diagram first?

No. Start with a working map of one important journey and validate it against deployed behaviour.

Is source code access required?

It improves confidence in implementation claims. Without it, state clearly which conclusions rely on configuration, traces or interviews.

How much history should we share?

Choose incidents and releases that illustrate current risks. A large unfiltered document dump is less useful than representative evidence.

Can the review recommend keeping the monolith?

Yes. The right outcome follows the constraints; a new deployment model is not a required deliverable.

What makes a recommendation actionable?

A concrete consequence, evidence, named owner, bounded change and a check that demonstrates improvement.

Bring the scope. We will help make it buildable.

Share the user journey, integrations and launch constraints. We can clarify the scope and prepare an estimate with assumptions and exclusions.

Explore the delivery scope →