Architecture evaluation, ATAM, risk, and fitness functions
Evaluation tests whether architecture claims satisfy prioritized scenarios and exposes sensitivity points, trade-offs, risks, and non-risks. Review quality depends on concrete scenarios and evidence.
Core ideas and patterns
| Idea | What it solves | Cost, limit, or warning |
|---|---|---|
| ATAM | Evaluates trade-offs through business drivers, scenarios, approaches, and analysis | A workshop is not a substitute for experiments |
| Quality-attribute workshop | Elicits and prioritizes measurable scenarios | Needs broad stakeholder representation |
| Risk storming | Uses views and scenarios to find architectural risk collaboratively | Risk severity needs follow-up ownership |
| Sensitivity point | Finds a decision where small change strongly affects quality | Unknown sensitivities create surprise |
| Trade-off point | Finds one decision affecting multiple qualities | Optimization requires business priority |
| Fitness function | Continuously checks an architectural property | Only automatable properties are covered |
| Threat model | Evaluates adversarial failure paths | Must be updated as boundaries and assets change |
| Load/fault prototype | Tests uncertain quality claims | Prototype environment must represent the force being tested |
How to apply it
Present mission, scope, drivers, constraints, views, and approaches. Collect scenario candidates from diverse stakeholders, prioritize them, and walk each through the design. Record risk, sensitivity, trade-off, and evidence gaps. Assign experiments or changes. Re-evaluate major deltas, not every line of code.
Evidence, not opinion
Turn recurring claims into architecture tests: dependency rules, API compatibility, latency/capacity budgets, availability exercises, recovery, data residency, security controls, cost ceilings, and ownership metadata.
Small example
A cache TTL is a sensitivity point for latency and freshness. The evaluation measures both under failure and defines a bounded stale mode instead of arguing that caching is generally good or bad.
Feynman check
Explain the design to a new engineer without using the pattern names. State the problem, the forces that conflict, the chosen boundary or mechanism, what can fail, and the evidence that would prove the choice still works.