Architecture Evaluation and Trade-off Analysis
What this domain tests
This domain tests whether you can run a structured, scenario-driven evaluation and name risks precisely rather than vaguely.
Core rules
- ATAM sequence: present the method and the architecture, build a utility tree from prioritised quality attribute scenarios, map scenarios to architectural approaches, then identify sensitivity points, trade-off points, risks, non-risks, and the resulting decisions.
- Sensitivity point: one aspect decisively affects one quality attribute (encryption key length affects security).
- Trade-off point: a sensitivity point affecting two or more attributes in opposite directions (the same key length also affects latency). Trade-off points are where the value lies.
- Non-risk: a decision widely suspected to be risky that analysis shows is sound; recording it has value because it stops the debate recurring.
- Evaluate early enough to change course, with the stakeholders who own the concerns. A review without them produces a document, not a decision.
Worked example
Scenarios: p95 latency under 300 ms; tax rule change within two days; audit logs immutable for seven years. The team's "write everything synchronously to one encrypted ledger" makes audit durability a sensitivity point and, against latency, a trade-off point. Evaluation output: risk (latency breach at peak), trade-off (consistency versus response time), option (asynchronous append with a signed hash chain), and a follow-up measurement plan.
Traps
- Running a "review" that is only a presentation walkthrough, with no scenarios or measures.
- Labelling every decision a risk; a risk needs a scenario, an impact, and a likelihood or trigger.
- Confusing sensitivity points with trade-off points.
- Treating evaluation as one-off; architecture debt accumulates silently between reviews.