Architecture evaluation catches expensive mistakes while they're still cheap to fix. ATAM is the courtroom — quality attributes are cross-examined against every architectural decision.
The earlier a design flaw is found, the cheaper it is to fix.
Architecture must be evaluated before construction begins — not after. Architecture is shaped by three drivers: functional requirements, non‑functional requirements, and business constraints.
Forces prioritization of conflicting goals.
Forces clear explanation of the architecture.
Improves quality of architecture documentation.
Uncovers opportunities for cross‑project reuse.
Results in improved architecture practices overall.
All three lean on the same two ingredients: scenarios and quality attributes. The difference is depth and focus, not the underlying idea.
Architecture Tradeoff Analysis Method. The most‑used method — full focus on quality‑attribute tradeoffs and risk discovery. This chapter's main subject.
Software Architecture Analysis Method. ATAM's predecessor — simpler, earlier scenario‑based analysis technique.
Active Reviews for Intermediate Designs. Reviews designs that aren't complete architectures yet — earlier in the process, more informal.
ATAM assesses the consequences of architectural decisions against quality‑attribute requirements and business goals — which really means: hunting for risk where one quality attribute is affected by a decision made for another.
In complex systems, quality attributes are never achieved in isolation. Chasing one quality often moves another — sometimes helping it, sometimes hurting it. So every architectural decision is really a tradeoff between quality attributes, made in service of the business goals.
Performance, Availability, Usability, Security — PAUS. What the person using the system feels.
Modifiability, Portability, Reusability, Testability, Interoperability — MPRTI. What the engineering team feels.
Time to market, cost & benefits, projected lifetime, project budget — TLCB. What the business feels.
ATAM only works if these three groups cooperate — leave one out and the evaluation is blind to part of the system's reality.
3–5 experienced architects, external to the project. They run the process.
People with authority to change the project — project manager, customer, senior manager.
Developers, testers, integrators, maintainers, performance engineers, users.
| Role | Responsibility, in one line |
|---|---|
| Team leader | Sets up the evaluation, coordinates with the client, forms the team, delivers the final report. |
| Evaluation leader | Runs the evaluation — facilitates scenario elicitation, prioritization, analysis, on‑site work. |
| Scenario scribe | Writes scenarios on the flipchart/whiteboard; locks the exact agreed wording. |
| Proceedings scribe | Types everything electronically — raw scenarios, motivating issues, resolutions; hands out the adopted list. |
| Questioner | Raises architecturally interesting issues, usually tied to their own quality‑attribute expertise. |
Notice the shape: it opens with three "Present" steps, works through Identify → Generate → Analyze, loops back for Brainstorm → Analyze again, then closes with one more Present.
Overview of steps, techniques, and expected outputs (utility tree, scenarios, risks, sensitivity points).
Goals, stakeholders, high‑level requirements, top quality scenarios, constraints — from the decision maker.
Lead architect walks through it — often using the 4+1 view model — and flags known risks.
Evaluation team names the patterns in play — client‑server, layered, pipe‑filter, etc.
Top‑down prioritization of quality goals into concrete, scored scenarios.
Trace the highest‑ranked scenarios through the architecture; capture decisions, risks, sensitivities, tradeoffs.
Now the full stakeholder community adds scenarios and votes — checking whether they agree with the utility tree.
Same analysis as step 6, now against the newly brainstormed, stakeholder‑driven scenarios.
Report + slides: business context, architecture documentation, prioritized scenarios, utility tree, risks/non‑risks/sensitivities/tradeoffs.
Present ×3 (1,2,3) → Identify, Generate, Analyze (4,5,6) → Brainstorm, Analyze (7,8) → Present (9).
| Phase | Activity | Participants | Typical duration |
|---|---|---|---|
| 0 | Partnership & preparation: logistics, planning, stakeholder recruitment, team formation. | Evaluation team leadership + key decision‑makers | Informal, over a few weeks |
| 1 | Evaluation: Steps 1–6 | Evaluation team + project decision‑makers | 1–2 days, then a 2–3 week hiatus |
| 2 | Evaluation: Steps 7–9 | Evaluation team, decision‑makers, stakeholders | 2 days |
| 3 | Follow‑up: report generation & delivery, process improvement. | Evaluation team + evaluation client | 1 week |
A top‑down structure: Utility → Quality Attributes → Refinements → concrete
Scenarios.
Every leaf scenario gets scored (Importance, Difficulty) — e.g. (H,H) means high
business
importance, high architectural difficulty. That's the pair the team prioritizes first.
High‑High leaves are triaged first in Step 6 — they're the scenarios most likely to reveal real risk.
These four labels are what the evaluation team attaches to every architectural decision while tracing a scenario. Getting these definitions exact is one of the most commonly tested parts of ATAM.
A decision that has a significant effect on one quality attribute. Tune this decision and that one attribute moves noticeably.
A decision that's a sensitivity point for more than one attribute — improving one costs another.
A potentially problematic architectural decision — something that could threaten a quality goal if left unaddressed.
A decision the team is confident is safe — reviewed and found sound.
| Scenario | Detect and recover from HW failure of the main switch. |
| Attribute | Availability |
| Stimulus → Response | One CPU fails → 0.999999 availability of the switch. |
| Backup CPU(s) | Sensitivity S2 · Risk R8 |
| No backup data channel | Sensitivity S3 · Tradeoff T3 · Risk R9 |
| Watchdog / Heartbeat / Failover routing | Sensitivities S4–S6 · Non‑risks N12–N14 |
The key artifact documenting the selected architecture itself.
Recaps the process, captures the scenario analysis, and explains the candidate architectures with the rationale behind the final choice.
Same 9‑step skeleton, built for smaller / lower‑risk projects — sometimes done in a single half‑day, entirely with people already inside the organization.
Speed. Internal‑only participants mean faster shared understanding — no external onboarding needed.
Depth and objectivity. Internal‑only reviewers probe the architecture less deeply than an outside evaluation team.
| Step | Time | What changes vs. full ATAM |
|---|---|---|
| 1. Present ATAM | 0h | Skipped — participants already know the process. |
| 2. Business drivers | 0.25h | Quick refresh only. |
| 3. Present architecture | 0.5h | Module + C&C views, 1–2 scenarios traced. |
| 4. Architectural approaches | 0.25h | Often folded into step 3. |
| 5. Utility tree | 0.5–1.5h | May reuse an existing tree from earlier work. |
| 6. Analyze approaches | 2–3h | Bulk of the time — unchanged in spirit from full ATAM. |
| 7. Brainstorm scenarios | 0h | Omitted — same internal people already contributed in step 5. |
| 8. Analyze approaches | 0h | Omitted — all analysis already happened in step 6. |
| 9. Present results | 0.5h | Review risks/non‑risks/sensitivities/tradeoffs; check for new risk themes. |
PCDRP — Priorities, Clarity, Docs, Reuse, Practice.
"Architects Sometimes Argue" — ATAM, SAAM, ARID.
PAUS (end‑user) / MPRTI (technical) / TLCB (business).
EPA — Evaluation team, Project decision‑makers, Architecture stakeholders.
TESPQ — Team leader, Evaluation leader, Scribe, Proceedings, Questioner.
3 Presents → Identify‑Generate‑Analyze → Brainstorm‑Analyze → Present.
0 preps, 1 does steps 1–6, 2 does steps 7–9, 3 reports.
Always (Importance, Difficulty) — "I before D."
Sensitivity=one attribute · Tradeoff=two+ opposite · Risk=maybe bad · Non‑risk=confirmed fine.