Architecture review
An architectural review checks whether a design meets its important goals under relevant conditions. Scenarios and evidence keep the evaluation traceable.
- QuestionExamine a concrete scenario.
- EvidenceProof instead of assertion.
- Subsequent stepFinding leads to action.
Context
Why this is important
A design appears plausible until the error occurs. A review examines goals in concrete processes and records what is proven and what is missing. Risks are only named; how you hold them shows risk log.
This building block structures design review and findings. Trade-off analysis compares options; risk log records uncertainty and follow-up steps.
At a glance · Review: goal to follow-up
Review findings for late payment
The team tracks the order completion in the event of a delayed payment response. It checks status model, resumption, data durability and operational indicators.
This is how you read the picture
- Question First column of the lines, such as “How to avoid double loading?”
- Evidence Column ‘Proof’: power key and provider identifier, metric for open clarifications.
- Subsequent step Column “Concrete follow-up step”: “Determine responsible and threshold”.
| Aspects | Evidence | Evaluation of the result | Specific follow-up step |
|---|---|---|---|
| What does the shop show? | Status display in case of missing response | “Payment will be clarified” seen in the test | Complete test with late response |
| How is double burden avoided? | Idempotency key and provider identifier | Repeat delivers existing payment | Check identification repetition in the integration test |
| How are operations informed? | Metric for open clarifications | Alert limit missing | Setting responsible persons and threshold values |
Benefits & limitations
Helps if:
- Architecture choices that are hard to reverse benefit from joint review of their consequences for business, development and operations.
- Changes in quality objectives or operational findings justify a targeted re-evaluation of affected assumptions.
Boundaries
- When a decision depends on runtime behaviour, measurements or tests provide stronger evidence than a diagram review.
- Opinions without a link to requirements are hard to prioritise; connect each finding to a scenario and possible consequence.
- Open findings need a home: record uncertainties in the Risk log and decisions in an ADR.
In practice
- Narrow the review objective and scenarios. State the decision or change and select a few relevant quality and failure scenarios. Record assumptions and constraints. This creates a focused review scope.
- Bring participants and evidence together. Invite the responsible stakeholders and provide diagrams, measurements and decisions. Distinguish confirmed facts from open assumptions. This allows joint assessment of the design and operational reality.
- Turn findings into next steps. Prioritise risks by impact and uncertainty, and assign owners and verification methods. Track results until the decision or design is updated. This provides traceable follow-through with an owner and next check.
Read the detailed explanation
An architecture review examines whether a design supports relevant requirements and quality goals and accounts for operational consequences. It considers selected scenarios, tracing components, data and states. A review of a consequential Architecture decision organises questions and findings; Quality attributes provides suitable assessment criteria.
The outcomes are prioritised risks, assumptions and concrete evidence or actions. Diagrams support discussion but do not replace measurement or implementation. Business, development and operations participants contribute different perspectives and experience. Depth and formality depend on uncertainty and reversal costs. Each finding needs a clear impact, owner and next verification step. Establish the purpose, scope and required decision before starting. Afterwards, track open findings through the normal workflow until the required evidence is available.
ATAM (Architecture Tradeoff Analysis Method) evaluates architecture using quality scenarios and exposes trade-offs and risks.
Check your understanding
Test yourself in three stages
ReadingCheck in the picture
What is missing from the operational statement on open clarifications?
View the solution with justification
The alarm limit is missing. The next step is to set responsible persons and threshold values.
ApplyingTransferred to a new situation
A review should check whether a repeated payment request is debited twice. How do you formulate the exam?
View the solution with justification
In the integration test, check that the same identifier provides only the existing payment. The document is the Idempotency key together with the provider identifier.
EvaluateWeighing an alternative
The team only wants to review the design based on the documentation. What does it win and what does it lose?
View the solution with justification
This is fast, but only proves intentions. Tests and operational indicators show whether the delay case actually works and cost additional effort.
Explore further
These optional deepenings complement the learning goal of this page.
LASR: Lightweight Approach for Software Reviews
LASR structures a lightweight review in four steps: Lean Mission Statement, Evaluation Criteria, Risk-based Review and Quality-focused Analysis. A concise mission statement clarifies purpose and system boundaries; the team then prioritises quality characteristics, examines risky scenarios and analyses the design against these criteria.
For the shop, the mission statement describes which orders it enables for whom. For checkout, the team prioritises reliable payment processing and clear feedback. It traces slow payment responses through the process and checks how retries are protected against duplicate charges. Where needed, code analysis or tests provide deeper evidence.
For testingReview the shop using the four LASR steps: state the mission, prioritise checkout qualities, trace the greatest payment risk and analyse the design against those criteria. Investigate an uncertain finding further through code analysis or a targeted test where needed.
Further building blocks
References
- SEI – ATAM: Method for Architecture Evaluation (opens in new tab)Describes the scenario-based assessment of quality objectives, risks and conflicts of objectives.
- arc42 – Quality scenarios for architecture evaluation (opens in new tab)Shows how quality scenarios structure architectural reviews and make risks visible.
- AWS – Well-Architected Framework Review Process (opens in new tab)Describes a repeatable review process with measures taken from identified risks.
- LASR · Lightweight Approach for Software Reviews (opens in new tab)Four steps from system mission statement to criteria and risks to quality-oriented analysis.