How does SAAM (Software Architecture Analysis Method) differ from ATAM (Architecture Tradeoff Analysis Method), and when would you choose the simpler one?

## SAAM in detail **SAAM** — Software Architecture Analysis Method — was the first widely documented scenario-based architecture review (SEI, early-mid 1990s). Its steps: 1. **Describe candidate architectures** in a notation everyone understands (components, connectors, responsibilities). 2. **Develop scenarios** — stakeholders brainstorm uses and, crucially, *anticipated changes*: new features, new platforms, new integrations, new regulations. 3. **Classify scenarios**: - **Direct** — executable with the architecture as it stands, no modification. - **Indirect** — requires modification: new components, changed interfaces, altered connectors. 4. **Evaluate indirect scenarios** — for each, enumerate the components/connectors that change and estimate cost/effort. 5. **Assess scenario interaction** — count how many *semantically unrelated* scenarios require changing the same component. High interaction is a smell: that component carries several concerns at once, so unrelated future work will collide there. It is often a symptom of poor decomposition or a missing abstraction. 6. **Create an overall evaluation** — weight scenarios by business importance and compare candidates. SAAM's superpower is **comparison**: run the same scenario set over architecture A and architecture B and you get an evidence-based, non-religious answer. SAAM's limits: it is dominated by modifiability; it says little about performance, availability or security; and it has no way to express that a decision helping one attribute harms another. ## ATAM in detail (as an evolution) **ATAM** keeps the scenario core and adds: | Aspect | SAAM | ATAM | |---|---|---| | Quality attributes | mainly modifiability | many, explicitly (performance, availability, security, modifiability…) | | Scenario organisation | brainstormed list | **utility tree**: attributes → refinements → six-part scenarios, rated (importance, difficulty) | | Design vocabulary | components/connectors | named **architectural approaches/tactics** (replication, caching, layering, bulkheads…) with attribute-specific question sets | | Conflict handling | none | **sensitivity points** and **trade-off points** | | Outputs | change-cost comparison, interaction hot spots | risks, non-risks, sensitivity points, trade-off points, risk themes → business drivers | | Process | one pass | two phases, second with a broad stakeholder group that votes | | Cost | low | higher — days, many stakeholders, prepared architect | ATAM's name earns the "T": its distinctive contribution is making conflicts between attributes explicit and forcing a conscious decision. ## Choosing Use **SAAM-style** analysis when: - The question is narrow and mostly about change cost ("which decomposition absorbs the next two quarters of roadmap more cheaply?"). - You are comparing concrete alternatives. - Stakeholder time is scarce; you want a half-day, not a week. - The system is small or the decision is reversible. Use **ATAM-style** analysis when: - Several quality attributes are in genuine tension (latency vs consistency, security vs usability). - The decision is expensive or hard to reverse (data-store choice, regionalisation, service decomposition, platform migration). - Multiple stakeholder groups — ops, security, product — hold different, unstated priorities. - You need findings tied to business drivers to unlock funding. In practice most teams run hybrids: an internally facilitated one-day review that borrows ATAM's utility tree and finding vocabulary at SAAM's cost. Related relatives worth naming: **ARID** (Active Reviews for Intermediate Designs — stakeholders try to *use* a partial design), **ATAM's follow-on CBAM** (Cost Benefit Analysis Method — attaches utility and cost to candidate responses so investment can be ranked), and **LAAAM**-style lightweight matrix reviews. ## Pitfalls - Running SAAM and concluding the system "is fine" — it only tells you about the scenarios you wrote, mostly change scenarios. - Ignoring scenario interaction, the single most useful signal SAAM produces. - Running the ATAM ceremony for a two-week reversible decision. - Scoring architectures by counting direct vs indirect scenarios without weighting by business importance.