Skip to main content

ATAM (Architecture Tradeoff Analysis Method) Sketch

What This Concept Is​

ATAM is the SEI's structured method for evaluating a software architecture against quality attributes: availability, performance, security, modifiability, and the rest. In its full form it is a 3-4 day engagement with trained evaluators, stakeholders, and architects. For this module you need the shape of it, not the full protocol.

The core artifacts:

  • Utility tree. A tree rooted at "system utility," branching into quality attributes, then into refinements, then into concrete scenarios with priority + difficulty ratings.
  • Scenarios. Concrete stimuli with measurable responses. "Under load spike of 10x within 30 seconds, the checkout p99 latency stays under 500 ms."
  • Architectural approaches. How the system proposes to satisfy scenarios.
  • Risks, non-risks, sensitivity points, tradeoff points. The four output categories that summarize what was learned.

A sensitivity point is a property of a single architecture decision that materially affects one quality attribute. A tradeoff point is a property that affects two or more, with opposing directions.

Why It Matters Here​

Most teams will never run a full ATAM. What they need is the vocabulary: utility trees, scenarios, sensitivity vs tradeoff. Even a lightweight review benefits when participants can say "this is a tradeoff point between latency and cost" instead of circling.

ATAM is also the benchmark for "how heavy a review can get." Knowing the shape lets you calibrate: "what we are doing is about 5% of ATAM, and that is appropriate for this risk."

Concrete Example​

Sketch of a utility tree for a small e-commerce checkout service.

Utility
 |
 +-- Performance
 |    +-- Latency
 |    |    +-- (H, M) p99 checkout < 500ms at 10x peak within 30s
 |    |    +-- (M, L) p95 search < 200ms during normal load
 |    +-- Throughput
 |         +-- (H, H) sustain 5000 orders/min for 1h on Black Friday
 |
 +-- Availability
 |    +-- (H, M) 99.95% monthly availability for checkout
 |    +-- (M, M) degraded-mode search when catalog is unavailable
 |
 +-- Security
 |    +-- (H, H) PCI-DSS scope contained to payment gateway
 |
 +-- Modifiability
      +-- (L, M) add a new payment provider within one sprint

Labels (importance, difficulty) = (High|Medium|Low, High|Medium|Low).

From this tree the team prioritizes the top-right scenarios (H, H) for analysis. On that analysis, the decision "use a single shared Postgres for orders and checkout read models" turns out to be a tradeoff point: it helps latency (no network hop) and hurts availability (shared fate). Naming this explicitly changes the review: it is no longer "Alice likes it, Bob doesn't," it is "we are accepting availability cost to preserve latency."

Common Confusion / Misconception​

"ATAM is a gate we have to pass." In regulated settings it may be. For most teams it is a source of vocabulary and discipline, not a checklist.

"Scenarios are use cases." Use cases describe behavior. Scenarios describe quality-attribute behavior: the stimulus, the environment, and the measurable response. "User logs in" is a use case. "Login succeeds within 200 ms at p95 when the identity provider is healthy" is a scenario.

"Sensitivity and tradeoff are the same." Sensitivity is one attribute; tradeoff is multiple attributes pulling opposite ways. A CPU-bound hot path is a sensitivity point for latency. A shared Postgres decision that affects both latency and availability is a tradeoff point.

How To Use It​

For a given proposal, use ATAM's vocabulary lightly:

  1. Write 5-8 scenarios that matter. No more. Prioritize by importance and difficulty.
  2. For each top scenario, name the architectural approach intended to satisfy it.
  3. For each approach, ask: "is this a sensitivity or tradeoff point?"
  4. Capture risks ("this approach may not survive a doubling of load"), non-risks ("this approach is already proven at 10x our load"), sensitivity points, and tradeoff points as explicit output bullets.

That is ~1-2 hours of work and is frequently enough for a useful review.

Check Yourself​

  1. Write one scenario for each of: performance, availability, modifiability for a system you know.
  2. Give one example of a sensitivity point and one of a tradeoff point from that same system.
  3. Why are scenarios better than "high performance" as a review target?

Mini Drill or Application​

Take one system you work on. In 30 minutes:

  • draft a utility tree with two quality attributes and 3 scenarios each, with (importance, difficulty) ratings
  • pick the top (H, H) scenario and name the architectural approach behind it
  • label that approach as sensitivity or tradeoff point
  • list one risk associated with it

Read This Only If Stuck​