ATAM, the Architecture Tradeoff Analysis Method by Rick Kazman, Mark Klein and Paul Clements of the SEI at Carnegie Mellon University, evaluates a software architecture against its quality goals. A utility tree breaks those goals into prioritized quality attribute scenarios, and a nine-step process analyzes the architectural approaches against them. The result names sensitivity points, tradeoff points where one decision affects several quality attributes in conflicting ways, and risks and non-risks.

ATAM

Details
Full Name

Architecture Tradeoff Analysis Method

Also known as

Architecture Evaluation, ATAM Review

Core Concepts:

Utility Tree

Hierarchical decomposition of system quality goals into concrete, prioritized quality attribute scenarios (e.g., Performance → Response Time → "Search results returned in < 1s under peak load")

Quality Attribute Scenarios

Testable, concrete expressions of quality requirements consisting of stimulus, source, environment, artifact, response, and response measure

Architectural Approaches

Design decisions and patterns (e.g., caching, replication, layering) used to achieve quality attributes

Sensitivity Points

Architectural decisions that significantly affect one specific quality attribute

Tradeoff Points

Architectural decisions that affect two or more quality attributes in conflicting ways — the core insight of ATAM

Risks and Non-risks

Identified architectural decisions that may (risks) or demonstrably will not (non-risks) lead to future problems

Nine-step process

Presentation of ATAM → presentation of business drivers → presentation of architecture → identification of architectural approaches → generation of utility tree → analysis of architectural approaches → brainstorming scenarios → analysis of scenarios → presentation of results

Key Proponents

Rick Kazman, Mark Klein, Paul Clements (SEI / Carnegie Mellon University)

When to Use:

  • Evaluating a software architecture before major investment in implementation

  • When multiple stakeholders have conflicting quality requirements (e.g., performance vs. security)

  • During architecture reviews of safety-critical or high-availability systems

  • When making buy-vs.-build decisions or selecting between competing architectural styles