Skip to content

Comparing Architectural Alternatives with ATAM

ATAM is a method for evaluating a software architecture against quality goals (see Architecture Tradeoff Analysis Method (ATAM)). You can run it on two or more drafts and compare the outcomes.

Keep the basis identical. Build one utility tree. This is a hierarchic model of the driving architectural requirements. Reuse it for every draft. Then each draft faces the same test, and differences in results come from the drafts, not from the questions.

Tally the findings per draft. When ATAM analyzes the architectural approaches, it identifies risks, sensitivity points and trade-off points. See ATAM Findings: Risks, Non-Risks, Sensitivity Points and Trade-off Points. Record these per alternative, so you can set the lists side by side.

Judge severity, not only counts. ATAM combines risks into risk themes. Each theme shows how risks threaten a business driver. A draft with fewer findings can still be worse if its few risks hit what the business cares about most. Use the themes to judge by business impact.

Record scenarios in a table. arc42 recommends using quality scenarios to evaluate an architecture, and it names ATAM. It suggests a table with quality goal, scenario, solution approach and risk. One such table per draft makes the comparison easy to read.

A team weighs two drafts for an online ordering system. Both are checked against the same utility tree and the same scenarios.

Draft A shows two risks and one trade-off point. Draft B shows one risk and three trade-off points. The team does not just count. It checks which risk themes touch the business drivers. If Draft B’s single risk threatens the most important driver, Draft A may still be the better choice.

Counting findings is quick and easy to explain. But a raw count hides how serious each finding is. Risk themes tied to business drivers give a fairer judgment, though they take more effort to build and discuss. Running the same full analysis on every draft also costs more time than analyzing one.

  • Every candidate architecture is evaluated against the same utility tree.
  • Risks, sensitivity points and trade-off points are listed separately for each alternative.
  • Risks are summarized as themes that name the business driver they threaten.
  • Quality scenarios are documented in a table with quality goal, scenario, solution approach and risk.