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.

1. 1

   Scope

   Clarify the assignment, business goals and architecture

   

   Goal

   Establish an agreed basis for evaluation.

   Inputs for this step

   • Evaluation assignment
   • Business goals and architecture description

   Actions

   • Before the first meeting, agree which parts of the system to evaluate, who participates, who receives the report and how to handle confidential information.
   • Introduce ATAM and what its findings can establish. Ask product representatives to explain the business goals and constraints, known in ATAM as business drivers. The architecture team explains the system structure and key decisions.
   • For an existing system, mark differences between the documented and implemented architecture.

   Output

   Scope, goals and architecture version

   Show which quality requirements follow from the business goals. Identify architecture views that still need to be prepared.

   Quality check

   Is the architecture baseline unambiguous? Are confirmed business goals and assumptions still to be checked clearly labelled?

   Pitfall

   The review starts with a list of preferred technologies. Link each technology to a concrete architectural decision and explain which business goal it supports.

   Timing: Preparation and shared opening; schedule according to system scope.

2. 2

   Approaches

   Identify architectural approaches

   

   Goal

   Identify which architectural decisions to examine.

   Inputs for this step

   • Agreed architecture baseline
   • Business drivers

   Actions

   • Name important approaches such as replication, decoupling, caching or access control and their intended effects.
   • Show where each approach is used and which components or interfaces it affects. Record settings and assumptions that still need clarification.

   Output

   Relevant architectural approaches

   For each product used, describe its purpose, how it is configured and its expected effect.

   Quality check

   Is the intended effect of each approach described? Can affected structures and parameters be located?

   Pitfall

   An architecture pattern is treated as evidence that a quality goal is met. Describe how the pattern is implemented and examine its expected effect against the relevant scenario.

   Timing: First evaluation meeting; arrange separate follow-ups for missing details.

3. 3

   Utility tree

   Turn quality goals into concrete scenarios

   

   Goal

   Select important and technically difficult scenarios.

   Inputs for this step

   • Business drivers
   • Quality requirements
   • Architectural approaches

   Actions

   • Build a utility tree with architecture and project representatives. Start with quality attributes such as availability, refine them into requirements and describe concrete situations as scenarios.
   • Specify stimulus, context, affected system elements, expected response and measurable target.
   • Rate each scenario by business importance and expected implementation difficulty. Explain which scenarios you will examine first.

   Output

   Prioritized quality scenarios

   Keep importance and technical difficulty as separate ratings.

   Quality check

   Can each prioritized scenario be understood in its business context? Are importance and difficulty justified?

   Pitfall

   The tree ends with general words such as fast or secure. Replace quality adjectives with concrete stimuli, context and observable responses.

   Timing: First evaluation meeting; refine with the appropriate specialists as needed.

4. 4

   Analysis

   Analyze approaches against prioritized scenarios

   

   Goal

   Identify risks and trade-offs with clear reasoning.

   Inputs for this step

   • Prioritized utility-tree scenarios
   • Architectural approaches and available evidence

   Actions

   • Walk through how the architecture would respond to each priority scenario. Examine the relevant quality goal and involve performance, security or operations specialists as needed.
   • Record risks. Also document decisions that support the quality goal under the examined conditions. ATAM calls these non-risks. State the scenario, reasoning and assumptions for each.
   • Mark parameters that strongly influence a quality goal as sensitivity points. A parameter that affects several quality goals is a trade-off point. Describe conflicts in particular, such as faster responses at the cost of lower resilience.
   • For each finding, state whether it is based on documents, expert judgment, a calculation or a measurement. Agree suitable checks for claims that remain unresolved.

   Output

   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.

   Quality check

   Does each conclusion link a decision, scenario and evidence? Are opposing effects and knowledge gaps visible?

   Pitfall

   Agreement is treated as proof of runtime properties. State the basis of the assessment and plan suitable models or measurements for open questions about runtime behavior.

   Timing: First evaluation meeting and agreed interim work; schedule deeper technical analysis separately.

5. 5

   Scenarios

   Add further scenarios and review findings

   

   Goal

   Test the initial analysis against further relevant perspectives.

   Inputs for this step

   • Initial analysis
   • Participants from other affected areas
   • Utility tree

   Actions

   • Invite representatives of users, business, development, operations and other affected groups to the second evaluation meeting.
   • Collect additional scenarios, combine duplicates and agree a reasoned order of priority with the group.
   • Analyze the highest-priority scenarios using the same approach. Extend and correct the initial findings.

   Output

   Additional scenarios and findings

   Record represented perspectives and scenarios left outside the analysis.

   Quality check

   Are important stakeholder perspectives represented? Were new scenarios actually analyzed?

   Pitfall

   New scenarios are accepted only when they confirm the initial analysis. Examine contradictory and missing scenarios explicitly and record changes to findings.

   Timing: Second evaluation meeting after agreed interim work.

6. 6

   Report

   Hand over findings and follow-up work

   

   Goal

   Hand over findings so the responsible people can decide what to do next.

   Inputs for this step

   • Reviewed scenario analyses
   • Risks, non-risks and tradeoffs

   Actions

   • Present the evaluation scope, quality goals, examined scenarios and findings. Explain which conclusions the results support and which questions remain open.
   • Group related risks into themes and connect them to business goals. Preserve differing judgments.
   • Agree next investigations or decisions, owners and review dates with the responsible people. Keep decisions distinct from review findings.

   Output

   Report with risk themes and next actions

   The report can support both changing and retaining a decision. Record the resulting decisions separately.

   Quality check

   Can another reader follow the chain of evidence? Does each priority open question have an owner?

   Pitfall

   The report recommends replacing the architecture wholesale. Tie each recommendation to affected scenarios, expected benefit, uncertainty and required evidence.

   Timing: Schedule result presentation and report preparation separately.