ATAM (Architecture Tradeoff Analysis Method)

ATAM, the Architecture Tradeoff Analysis Method, is a structured way to evaluate a software architecture against its quality attribute requirements. It was described by Rick Kazman, Mark Klein, and Paul Clements of the Software Engineering Institute in a 2000 technical report, which states its purpose as assessing the consequences of architectural decisions in light of quality attribute requirements. The report is explicit that ATAM is a risk identification method, not a precise prediction of any measurable attribute such as latency or mean time to failure.

The problem it addresses

Requirements such as “highly available” or “easy to change” cannot be checked, and architecture descriptions are often too vague to check them against. The report names this directly: two of ATAM’s major goals are to elicit a precise statement of the driving quality attribute requirements and a precise statement of the architectural design decisions. Only then can the third goal — judging whether the decisions satisfy the requirements — be carried out. Because it works on design artifacts rather than a running system, it can be done early, when problems are still relatively cheap to fix.

The steps

The 2000 report lays out nine steps:

1. Present the method to the participants.
2. Present the business drivers — the goals the system exists to serve.
3. Present the architecture.
4. Identify the architectural approaches used, without analyzing them yet.
5. Build a quality attribute utility tree: refine attributes such as performance, availability, security, and modifiability down to concrete scenarios with stimuli and responses, and prioritize them.
6. Analyze the approaches against the high-priority scenarios, identifying risks, sensitivity points, and tradeoff points.
7. Brainstorm a larger set of scenarios with the whole stakeholder group and prioritize them by voting.
8. Analyze the approaches again against those scenarios.
9. Present the results.

The report describes running these in two phases: a first meeting between the evaluators and part of the architecture team, concentrating on the first six steps, and a later session with a broader set of stakeholders. Scenarios come in three kinds — use cases of the system as it is expected to run, growth scenarios for expected near-term change, and exploratory scenarios that stress the architecture with extreme change.

What it produces

Every sensitivity and tradeoff point is a candidate risk, and by the end of the evaluation each is classified as a risk or a non-risk. The SEI describes the risks being gathered into risk themes that threaten the business drivers — which is what connects a technical finding to a reason management should care.

Borrowing it outside a formal evaluation

A full ATAM involves trained evaluators and days of stakeholder time, but its core moves are useful on their own. When choosing between platforms, for instance, a requirement like “must support concurrent workloads” can become a scenario: while the nightly load runs, the finance dashboard’s queries still return within ten seconds. That scenario can be demonstrated or not, and the product decisions it depends on can be named. The written list of risks and tradeoff points then doubles as a decision record that explains, later, what was knowingly accepted. How this applies to platform selection is worked through in Choosing a Data Platform: What to Compare When the Feature Lists Match.

References

• Rick Kazman, Mark Klein, and Paul Clements, ATAM: Method for Architecture Evaluation, CMU/SEI-2000-TR-004
• Software Engineering Institute, Architecture Tradeoff Analysis Method Collection