Skip to content
Software Architecture Guide

Architecture Tradeoff Analysis Method (ATAM)

Explanation

Section titled “Explanation”

The Architecture Tradeoff Analysis Method (ATAM) was developed at the Software Engineering Institute at Carnegie Mellon University. It evaluates a software architecture against its quality attribute goals. These are goals such as speed or security (see the article Quality Attribute). The method also shows how those goals interact.

The aim is to expose architectural risks. These are weaknesses that could keep an organization from reaching its business goals.

How it runs

ATAM formally has nine steps. Phase 1 covers steps 1 to 6. Phase 2 covers steps 7 to 9 and finishes the evaluation. Step 5 builds a utility tree. This is a hierarchic model of the requirements that drive the architecture.

What it produces

  • Risks, and non-risks (points judged to be safe).
  • Sensitivity points and trade-off points, found while the team analyzes the architectural approaches. See the articles Sensitivity Point and Trade-off Point.
  • Risk themes. ATAM groups individual risks into themes. Each theme shows how it threatens a business driver.
  • The utility tree itself.

For details on these findings, see ATAM Findings: Risks, Non-Risks, Sensitivity Points and Trade-off Points.

When it pays off

ATAM is most valuable early in the life cycle. Changing the architecture is cheap at that stage.

Example

Section titled “Example”

A team plans an online ticket shop. Fast checkout and strong data protection are both top goals. During the evaluation, the group finds that encrypting every request slows checkout. That is a trade-off point. The group also finds that checkout depends on one payment service with no fallback. That is a risk. The team records both and links the risk to the business goal of steady sales.

Trade-offs

Section titled “Trade-offs”

ATAM is costly. A 2022 review says comprehensive methods, ATAM in particular, need a great deal of cost and effort. The method is scenario-based, but it involves many stakeholders for up to six weeks.

Its prioritization uses cumulative voting. This can cause excessive rivalry among stakeholders. Its templates can also be confusing.

Lightweight variants cut cost by narrowing scope. One variant runs in under 6 hours and omits brainstorming and prioritizing. See Lightweight ATAM and Advantages and Drawbacks of ATAM.

Checks

Section titled “Checks”
  • The architecture documentation records an evaluation of the architecture against its quality attribute goals.
  • The documented evaluation lists the architectural risks found and states which business goals they could threaten.
  • Sensitivity points and trade-off points found during the analysis are recorded.
  • A utility tree of the driving architectural requirements is included or referenced.
Section titled “Related”

Sources

Section titled “Sources”