A software architecture review examines a design against measurable quality scenarios, such as availability, recovery, security and cost, before it is built. It records the decision, the options rejected and the risks accepted, each with an owner, and its depth should match how hard the decision is to reverse.
Most costly architecture mistakes were visible on a whiteboard. Nobody asked the right question while changing the answer cost an afternoon, not a quarter.
A structural engineer who checks plans before the foundations are poured costs a day's fee. Moving a load-bearing wall after the family has moved in costs the house. A software architecture review is that check for systems. This guide explains what a review covers, which decisions deserve one, how to run one in a week and how to apply it to the platforms you buy.
What a software architecture review is, and why reviews fail
A software architecture review examines a design against the qualities the business needs, such as availability, security, cost and ease of change. It records the resulting decisions, risks and trade-offs. It is neither a code review nor an approval committee. Its purpose is to surface risk while change is still cheap.
Carnegie Mellon's Software Engineering Institute (SEI) sets a useful target in its Architecture Tradeoff Analysis Method. Its outputs include risks, non-risks, trade-off points and quality scenarios. ISO/IEC/IEEE 42010:2022 sets out how to describe an architecture through views. Few teams need the full formality, but those outputs are the right aim.
Reviews usually fail by arriving too late, being too heavy, testing opinions rather than requirements, or leaving findings untracked. The stakes are rising. Verizon's 2025 Data Breach Investigations Report found third parties involved in 30% of breaches, double the previous year. Every external dependency is an architectural decision that deserves examination.
Match the depth of review to the decision
Two tests set the tier: how hard the decision is to reverse, and how many teams, customers or data sets it affects. A new internal endpoint needs no ceremony. A new customer data model or a multi-year platform commitment deserves real scrutiny.
| Tier | Typical triggers | Format | Output |
|---|---|---|---|
| 0. None | Reversible, local changes within agreed patterns | Team judgement | Decision record if non-obvious |
| 1. Light | New service using existing patterns | Short design document, two reviewers | Decision record; risks logged |
| 2. Full | Customer data flows, new external dependency, cross-team platform | Design document plus a 60 to 90 minute session | Decision record; risks with owners and dates |
| 3. Deep | Core re-architecture, major migration, multi-year platform purchase | Scenario-based evaluation over three to four days | Trade-off analysis and a go or no-go |
Set re-review triggers as well, because architecture decays as assumptions change. Typical triggers are traffic far beyond the design assumption, a new region or regulation, a new class of sensitive data, and AI components that act on customer data.
Replace adjectives with measurable scenarios
Start from quality attributes, not diagrams. ISO/IEC 25010:2023 defines nine product quality characteristics, including reliability, security and maintainability, which make a sound checklist. Turn each relevant one into a scenario with a measurable response.
For example: 'When the payment provider times out at peak, checkout queues the order within two seconds and no order is lost.' A scenario of this kind turns an argument about taste into a test the design passes or fails. Cover five areas:
- Load and scale: what saturates first at ten times current peak, and the cost per transaction then.
- Failure and recovery: recovery time and recovery point objectives, and the date of the last full restore test.
- Security and data: where personal data is stored and copied, and how tenants are isolated.
- Operability: whether an on-call engineer who did not build it can diagnose and fix it at 3 a.m.
- Dependencies and exit: which suppliers sit on the critical path, and how you would leave each one.
Consider a hypothetical checkout path that calls four services in sequence, each at 99.9% availability. Availability in series multiplies, so the path achieves about 99.6%. That allows roughly 173 minutes of downtime in a 30-day month, against the 43 the business expects. The fix is architectural: make non-essential calls asynchronous and let checkout queue orders when a service is down.
Run a proportionate review in one week
A tier 2 review rarely needs more than a week of elapsed time, provided the work is written down first. A practical rhythm:
- Day 1, write: the author drafts the context, quality scenarios, at least two options and known risks.
- Days 2 to 4, comment: two or three reviewers, one from operations or security, mark their top three concerns.
- Day 5, decide: a 60 to 90 minute session covers only those concerns, and a named decider makes the call.
- Same day, record: a short decision record is stored with the code, and each accepted risk gains an owner and a date.
Measure outcomes rather than the number of reviews held. Track incidents traced to risks that were never identified. Watch change fail rate and deployment rework rate, two instability metrics from the DORA research programme, for reviewed systems. A process that takes a month will simply be bypassed.
Apply the same review to suppliers
A platform on your critical path brings its architecture with it. Run a tier 2 or tier 3 review using the same scenarios, but ask for evidence rather than assurances.
| Area | What to ask | Evidence that answers it |
|---|---|---|
| Availability | Committed availability and dependency design | Service level commitment and incident history |
| Recovery | Recovery objectives and last full restore test | Test record or independent assurance report |
| Tenancy and data | Isolation, storage location and sub-processors | Data flow description and sub-processor list |
| Change | Release testing, rollback and customer notice | Change management policy and notice commitments |
| Exit | Data export and deletion at contract end | Documented export formats and deletion confirmation |
The bottom line
Conclusion
The structural engineer earns the fee by asking awkward questions while the walls are still lines on paper. A good architecture review does the same. It is tiered to the decision, driven by measurable scenarios, recorded briefly and followed through until every accepted risk has an owner.
This week, list the three decisions your teams are about to make that would be hardest to reverse. Write one measurable quality scenario for each before anyone starts building.
Frequently asked questions
When should I require a software architecture review?
Require one for decisions that are hard to reverse or affect many teams, customers or data sets, such as customer data flows, new critical dependencies and multi-year platform purchases.
What is an architecture decision record?
It is a short document stored with the code. It records the context, the decision, the options rejected, the consequences accepted and a date to revisit it.
What is a quality attribute scenario?
It is a testable statement of how a system should respond to a specific event under specific conditions, with a measurable result such as a recovery time.
How long should an architecture review take?
A proportionate written review can be completed within a week of elapsed time. A deep scenario-based evaluation of a major system typically runs over several days.
How does availability change when services are chained?
Availability multiplies across services called in sequence. Four services at 99.9% each give about 99.6% overall, or roughly 173 minutes of downtime in a 30-day month.
References
- Carnegie Mellon University Software Engineering Institute, Architecture Tradeoff Analysis Method collection (14 February 2018)
- ISO, ISO/IEC/IEEE 42010:2022 Software, systems and enterprise: Architecture description (November 2022)
- ISO, ISO/IEC 25010:2023 Systems and software Quality Requirements and Evaluation (SQuaRE): Product quality model (November 2023)
- Verizon, 2025 Data Breach Investigations Report (press release)
- DORA, Software delivery metrics: the four keys
Disclaimer: General information only, not legal, security, compliance or financial advice. Check the cited sources and seek professional advice. Names belong to their owners; no endorsement implied.