ATAM
Also known as: ATAM framework, architecture review
The Architecture Tradeoff Analysis Method (ATAM) is a systematic technique developed by Kazman et al. at CMU/SEI for evaluating software architectures against quality attributes (performance, security, modifiability). ATAM uncovers architectural risks and tradeoffs early, helping teams assess whether designs meet quality goals before implementation.
Key highlights
- Identifies architectural risks early, before costly implementation mistakes
- Makes tradeoffs explicit and negotiable among stakeholders
- Creates shared understanding of quality goals across team
- Generates documentation artifact for future architectural decisions
Intuition
This section is available to Pro members. Upgrade to Pro
How it works
This section is available to Pro members. Upgrade to Pro
When to use it
Use ATAM early in design phase, before implementation commences. Essential for large, complex systems with conflicting quality goals (e.g., real-time + security). Impractical for simple, well-understood systems or when stakeholders are unavailable. Most effective when decision-makers participate.
Strengths & limitations
- Identifies architectural risks early, before costly implementation mistakes
- Makes tradeoffs explicit and negotiable among stakeholders
- Creates shared understanding of quality goals across team
- Generates documentation artifact for future architectural decisions
- Time-consuming: requires 2–3 days and full stakeholder attendance
- Subjective: risk identification depends on team knowledge and experience
- Limited to described scenarios: unexpected workloads not analyzed
- Doesn't guarantee success: good analysis doesn't fix bad execution
Common pitfalls
This section is available to Pro members. Upgrade to Pro
Applications
This section is available to Pro members. Upgrade to Pro
Frequently asked
What is a quality attribute scenario in ATAM?
A specific, measurable description of system behavior: 'When a user adds a product to cart, response time < 200ms under normal load.' Combines stimulus (user action), environment (load), response measure (latency), and constraint. Vague goals become testable scenarios.
How long does ATAM take?
Typically 2–3 days on-site: Phase 1 (1 day) = present architecture, elicit scenarios; Phase 2 (1.5 days) = analyze architecture, identify risks; Phase 3 (0.5 days) = consolidate findings. Large systems may need 5+ days.
Who should attend ATAM?
Essential: architect, developers, decision-maker (sponsor), product owner. Recommended: QA, operations, business analyst. Minimum team size = 5–6. Skipping key stakeholders risks missing important scenarios or failing to negotiate tradeoffs.
How do I prioritize which architectures to analyze?
Use utility trees: rank quality attributes by importance and urgency. Analyze architectures addressing high-priority attributes first. Run ATAM on top 2–3 architectural options; compare risks and tradeoffs.
Sources
- 1.Kazman, R., Klein, M., Barbacci, M., Longstaff, T., Lipson, H., & Carriere, J. (2000). The Architecture Tradeoff Analysis Method. CMU/SEI Technical Report CMU/SEI-98-TR-008.
- 2.Bass, L., Klein, M., & Kazman, R. (2003). Attribute-Driven Design (ADD), Version 2. CMU/SEI-2003-TR-002.
- 3.Kazman, R., Asundi, J., & Klein, M. (2001). Making architecture design decisions: An empirical study. Proceedings of the 23rd International Conference on Software Engineering.
You have read it. What now?
Cite this page
ScholarGate. (2026, June 3). ATAM. ScholarGate. https://scholargate.app/numerical-methods/atam