---
title: "Architecture evaluation, ATAM, risk, and fitness functions"
chapter: "25"
---

# 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.