Purpose
ATAM helps teams weigh architecture decisions when quality goals compete. The team considers business goals, stakeholder expectations, and technical decisions together. The evaluation shows which risks need further investigation.
Architecture Analysis method
ATAM (Architecture Tradeoff Analysis Method)
Examines how architectural decisions support important quality goals and where risks or trade-offs arise.
ATAM examines an architecture through concrete situations, such as a load spike or an outage. The evaluation team first works with the architects to understand which decisions support the most important quality goals. Other stakeholders then contribute their requirements. The result is a reasoned account of risks, trade-offs and open questions.
How does the architecture support our most important quality goals, and where do risks or trade-offs arise?
- Participants
- Evaluation team, architects, and relevant stakeholders
- Time
- Several meetings plus preparation and analysis; total effort depends on scope
The six work sections group the nine ATAM steps. Plan two evaluation rounds, analysis between them and a final report.
Scope
Clarify the assignment, business goals and architecture
Establish a shared view of the method, evaluation goal and system. Covers ATAM steps 1 to 3.
Approaches
Identify architectural approaches
Make decisions and approaches supporting quality goals explicit. Covers ATAM step 4.
Utility tree
Turn quality goals into concrete scenarios
A utility tree organizes quality goals, more specific requirements and concrete scenarios in a tree. Covers ATAM step 5.
Analysis
Analyze approaches against prioritized scenarios
Trace relevant decisions and examine their justification. Covers ATAM step 6.
Scenarios
Add further scenarios and review findings
A broader stakeholder group contributes and prioritizes scenarios. Analyze the architecture again against them. Covers ATAM steps 7 and 8.
Report
Hand over findings and follow-up work
Present traceable results and group related risks into themes. Covers ATAM step 9 and subsequent handoff.
Revisit affected scenarios when the architecture or quality goals change. Record the new baseline and evidence still needed in the report.
A good fit when
Useful for planned or existing software systems with several important quality goals, such as fast responses and high availability. The evaluation requires a concrete architecture description, clear business goals and people from the affected areas.
Ideal for
- Architecture decisions with competing quality goals
- Risks in important existing or planned systems
- Shared priorities among technical and business participants
Not good for
- Quick reviews without architecture documents or available participants
- Sole proof of measurable runtime properties
Outputs
Prioritized scenarios
A utility tree organizes quality goals and scenarios. Additional stakeholder scenarios and their order of priority have a stated rationale.
Risks and trade-offs
Reasoned findings on risks and trade-offs in the examined architecture. Measurable claims about performance, security or availability are supported by appropriate technical analyses.
Next steps with named owners
A list of the next investigations and decisions, each with a responsible person and a date.
ATAM evaluation report
Fictional worked example
Record scenarios, reasoning and next steps so others can follow the assessment.
Evaluation frame
Describe scope, architecture version, business goals, roles and dates. Also identify areas outside the assignment.
Reservation service v0.8; expansion; latency and reliable allocation.
Utility tree and scenarios
Organize quality goals, specific requirements and scenarios in the utility tree. Explain the business importance and technical difficulty of each scenario.
S1: 500 bookings/min, 95 percent confirmed within 2 s. S2: zone failure, service restored within 60 s. Both scenarios: high importance and difficulty; fictional requirements.
Scenario analysis
For each scenario, record the decision examined, reasoning, evidence and assumptions. Record risks, decisions judged acceptable with supporting reasons (non-risks), sensitivity points and trade-off points.
R1: Evidence for zone failure is pending. The required number of confirming systems affects response time and failure tolerance. Basis: fictional design.
Additional scenarios
Record new scenarios, represented perspectives, prioritization and changes to findings.
Operations adds S3: repeated requests should lead to the same booking.
Risk themes and handoff
Record risk themes, business impact, limitations and follow-up work with owners and review dates.
Reliable bookings: development and operations examine zone failure and handling of repeated requests. Evidence is pending.
All examples are invented. Target values are requirements; expected effects and open evidence needs are explicitly marked.
First step
Agree the evaluation scope, business goals, architecture version and participants. Assemble an experienced evaluation team and plan two evaluation rounds with time for analysis between them.
Good to do first
Deep dive
How it works
Clarify the evaluation scope and business goals with the evaluation team. Ask the architects to present the main architectural approaches. Organize quality goals and concrete situations in a Quality Attribute Utility Tree: a tree that breaks goals down into scenarios that can be examined. Analyze the highest-priority scenarios technically. Additional stakeholders contribute and prioritize scenarios for a second analysis. Record risks, sensitivity points, and trade-offs in the findings report.
In detail
ATAM combines several meetings with preparation and technical analysis. The team needs a clear architecture description, known business goals, and access to the people responsible and relevant specialists. Experienced architecture evaluators examine how individual decisions affect expected system behavior. Sensitivity points are places where a change strongly affects one quality. Trade-off points affect several qualities and require those effects to be weighed. The report records reasoned risks and assumptions. Add runtime measurements, security checks, or code analyses as separate investigations where needed.
Facilitation
Agree in advance which decisions and system parts will be evaluated. Form the evaluation team and involve the architects and relevant specialists. Describe each scenario’s trigger, operating conditions, and expected system response. Record the evidence supporting each judgment. One person can prepare documents and scenarios. A full evaluation requires shared priorities and several professional perspectives. Allow time to review the findings and gather feedback from participants.
The method guide walks execution through 6 phases, timing, 6 pitfalls, and clear stop criteria.
Open method guideYour perspective
Does this method help with your work?
Your feedback helps shape the next improvements to methodatlas.
Sources and topics
Sources
SEI: ATAM: Method for Architecture Evaluationsei.cmu.eduOriginal report, especially chapters 7 to 9: outputs, nine ATAM steps and two evaluation phases. The six work sections editorially group those steps; preparation and reporting belong to the overall initiative. Example and worksheet are original teaching additions.Original report PDFsei.cmu.eduFull text for deeper study of the steps and evaluation limits identified above.
Artifact templates
ATAM (Architecture Tradeoff Analysis Method): WorksheetPrepare the overall initiative or a selected analysis block with a concrete question, documents and participants.markdown
ATAM (Architecture Tradeoff Analysis Method): WorksheetPrepare the overall initiative or a selected analysis block with a concrete question, documents and participants.
markdownatam-markdown.md
Prepare the overall initiative or a selected analysis block with a concrete question, documents and participants.
ATAM (Architecture Tradeoff Analysis Method): Worksheet
Question
To be confirmed
Desired outcome
To be confirmed
Scope
Whole analysis initiative Time: Multiple meetings and interim work, to be agreed according to scope
Complete this worksheet on paper or in your own document during the work.
Preparation for this scope
Method setup
- Materials: Versioned architecture documents, business goals, scenario list, findings log and access to the sources used.
- Roles: An experienced evaluation team with a facilitator and note-taker; architecture, product and project representatives; people from affected areas. Specialists contribute expertise for the quality goals under review. One person can prepare documents and partial analyses; the full evaluation brings these roles together.
- Advance information: Agree the evaluation scope, business goals, architecture version and participants. Assemble an experienced evaluation team and plan two evaluation rounds with time for analysis between them.
- Overall time needed: Plan preparation, a first evaluation round, analysis between meetings, a second round with further participants and the report. Agree the duration based on system scope and analysis needs. The time entered for one step applies to that selected work block.
- Setup: Set up a shared document with stable scenario and finding IDs. Label facts, assumptions, technical evidence and decisions separately.
Prepare for the work steps
Scope: Clarify the assignment, business goals and architecture
- Evaluation assignment
- Business goals and architecture description
Approaches: Identify architectural approaches
- Agreed architecture baseline
- Business drivers
Utility tree: Turn quality goals into concrete scenarios
- Business drivers
- Quality requirements
- Architectural approaches
Analysis: Analyze approaches against prioritized scenarios
- Prioritized utility-tree scenarios
- Architectural approaches and available evidence
Scenarios: Add further scenarios and review findings
- Initial analysis
- Participants from other affected areas
- Utility tree
Report: Hand over findings and follow-up work
- Reviewed scenario analyses
- Risks, non-risks and tradeoffs
ATAM evaluation report
Evaluation frame
Describe scope, architecture version, business goals, roles and dates. Also identify areas outside the assignment.
...
Utility tree and scenarios
Organize quality goals, specific requirements and scenarios in the utility tree. Explain the business importance and technical difficulty of each scenario.
...
Scenario analysis
For each scenario, record the decision examined, reasoning, evidence and assumptions. Record risks, decisions judged acceptable with supporting reasons (non-risks), sensitivity points and trade-off points.
...
Additional scenarios
Record new scenarios, represented perspectives, prioritization and changes to findings.
...
Risk themes and handoff
Record risk themes, business impact, limitations and follow-up work with owners and review dates.
...
Enter your own information, sources and assumptions in the blank worksheet.
SEI: Architecture Tradeoff Analysis Method
Scope: Clarify the assignment, business goals and architecture
Expected artifact: Scope, goals and architecture version
Show which quality requirements follow from the business goals. Identify architecture views that still need to be prepared.
Entry:
...
- Is the architecture baseline unambiguous?
- Are confirmed business goals and assumptions still to be checked clearly labelled?
Approaches: Identify architectural approaches
Expected artifact: Relevant architectural approaches
For each product used, describe its purpose, how it is configured and its expected effect.
Entry:
...
- Is the intended effect of each approach described?
- Can affected structures and parameters be located?
Utility tree: Turn quality goals into concrete scenarios
Expected artifact: Prioritized quality scenarios
Keep importance and technical difficulty as separate ratings.
Entry:
...
- Can each prioritized scenario be understood in its business context?
- Are importance and difficulty justified?
Analysis: Analyze approaches against prioritized scenarios
Expected artifact: Risks, non-risks, sensitivities and trade-offs
For non-risks, record the conditions under which the assessment holds. For open claims, specify the check still required.
Entry:
...
- Does each conclusion link a decision, scenario and evidence?
- Are opposing effects and knowledge gaps visible?
Scenarios: Add further scenarios and review findings
Expected artifact: Additional scenarios and findings
Record represented perspectives and scenarios left outside the analysis.
Entry:
...
- Are important stakeholder perspectives represented?
- Were new scenarios actually analyzed?
Report: Hand over findings and follow-up work
Expected artifact: Report with risk themes and next actions
The report can support both changing and retaining a decision. Record the resulting decisions separately.
Entry:
...
- Can another reader follow the chain of evidence?
- Does each priority open question have an owner?
Open questions and next steps
...
Method guide: https://methodatlas.meierhoff-systems.de/en/methods/atam/run-sheet
Alternatives and neighbors
Fitting alternatives with decision guidance, followed by other related methods.
Architecture
SAAM (Software Architecture Analysis Method)
Choose SAAM to focus on modifiability through concrete change tasks.
Architecture
LASR (Lightweight Approach for Software Reviews)
Choose LASR for an initial risk assessment by a small team and targeted investigation of open questions.
Architecture
Risk Storming
Moves architecture context, options, and consequences toward a concrete result through "place the architecture diagram or plan in the center", "set risk categories such as technical, organizational, and external", and "assign an owner and next steps for each top risk".
Architecture
Views and Beyond
Connects several views of large systems and keeps cross-view information for the overall picture.
Architecture
Architecture Decision Record
Documents an architecture decision with context, alternatives, and consequences so later reviews remain traceable.
Architecture
Architecture Inception Canvas
Bundles problem, goals, stakeholders, and risks into a starting picture that sorts early architecture questions.
Constraints and origin
HighWorkshop + asyncSeveral meetings plus preparation and analysis; total effort depends on scope
Profile
- Method form
- Analysis method
- Participants
- Evaluation team, architects, and relevant stakeholders
- Time
- Several meetings plus preparation and analysis; total effort depends on scope
- Maturity
- Canonical
Next up: Experiment Canvas