What is ATAM (the Architecture Tradeoff Analysis Method), and what does running one actually produce?

## What ATAM is **ATAM** = Architecture Tradeoff Analysis Method, developed at the Software Engineering Institute (Carnegie Mellon) in the late 1990s, successor to SAAM. It is a *review method*, not a tool or a notation: a facilitated workshop that examines an architecture against measurable quality goals, before large amounts of money are spent building on it. Key framing: an architecture is a set of **decisions**, each decision helps some quality attributes and hurts others, and the point of the review is to make those interactions visible and traceable to business goals. ## Participants (three groups) 1. **Evaluation team** — ideally outside the project: leader, facilitator, scenario scribe, proceedings scribe, questioner(s). 2. **Project decision makers** — project manager, business/product owner, chief architect — people who can commit to change. 3. **Architecture stakeholders** — developers, testers, ops/SRE, security, support, integrators, sometimes users. They are the source of the scenarios; they do not need authority to change anything. ## The nine steps, in two phases **Phase 1 (small group: evaluation team + decision makers)** 1. Present the ATAM — set expectations: no score, no redesign, findings only. 2. Present business drivers — the business owner states goals, constraints, and what "success" means. 3. Present the architecture — the architect walks the structures and the technical constraints at a level the room can follow. 4. Identify architectural approaches — name the patterns/tactics used (layering, publish–subscribe, replication, cache, bulkhead, circuit breaker, CQRS…) without analysing them yet. 5. Generate the quality attribute utility tree — root utility → quality attributes → refinements → concrete six-part scenarios; each leaf rated (importance, difficulty) as H/M/L. 6. Analyse architectural approaches — take the top-rated leaves and, scenario by scenario, ask the architect *how* the design satisfies it; record risks, non-risks, sensitivity points, trade-off points. **Phase 2 (wider stakeholder group)** 7. Brainstorm and prioritise scenarios — the larger group adds scenarios (especially growth and exploratory ones) and votes; the merged list is compared with the utility tree — a large mismatch is itself a finding about shared understanding. 8. Analyse architectural approaches again — same as step 6 on the newly top-voted scenarios. 9. Present results — findings grouped into **risk themes** and mapped back to the business drivers they endanger. Many organisations run it lighter (one day, internal facilitator); the step order is what carries the value, not the ceremony. ## The four output categories - **Risk** — a decision (or missing decision) that may prevent a scenario being met; phrased as decision → consequence → endangered goal. - **Non-risk** — a decision that is fine, *given stated assumptions*. Documenting it is valuable: it records the assumption, so when the assumption dies, the non-risk becomes a risk. - **Sensitivity point** — a parameter/decision where a small change swings one quality attribute a lot (e.g. replication factor drives availability). - **Trade-off point** — a decision that is a sensitivity point for two or more attributes pulling opposite ways (e.g. synchronous cross-region replication improves durability and worsens write latency). Trade-off points are the reason for the "T" in ATAM. These roll up into **risk themes** — recurring patterns such as "no operational visibility" or "single points of failure in the data tier" — each tied to a business driver, which is what makes leadership act. ## What ATAM is not - Not a certification, score, or gate with a number. - Not a design session — fixing is the project's job afterwards. - Not a code review — it examines decisions and their documented rationale. - Not free: it needs the architect prepared, real stakeholders present, and someone empowered in the room. ## Cost, timing, failure modes Best run when the architecture is settled enough to describe but before heavy implementation — late enough to be real, early enough to be changeable. Common failure modes: no measurable scenarios (review degenerates into opinion), no ops/security stakeholders (whole attribute classes unreviewed), the architect defending rather than explaining, findings recorded but never assigned an owner, and letting the meeting drift into solutioning so no risks get written down. **CBAM** (Cost Benefit Analysis Method) is the usual follow-on: it puts utility and cost on the candidate responses to ATAM risks so investment can be ranked.