2nd/10_Wiki/Topic_Programming/Architecture/ATAM (Architecture Trade-offs Analysis Method).md

---
id: wiki-2026-0508-atam-architecture-trade-offs-ana
title: ATAM (Architecture Trade-offs Analysis Method)
category: 10_Wiki/Topics
status: verified
canonical_id: self
aliases: [atam, architecture-evaluation, architecture-review]
duplicate_of: none
source_trust_level: A
confidence_score: 0.9
verification_status: applied
tags: [architecture, evaluation, atam, sei, quality-attributes]
raw_sources: []
last_reinforced: 2026-05-10
github_commit: pending
tech_stack:
  language: process
  framework: sei-atam
---

# ATAM (Architecture Trade-offs Analysis Method)

## 매 한 줄
> **"매 architecture 의 quality attribute 의 trade-off 의 reveal 한다"**. 매 ATAM 의 SEI (Software Engineering Institute, CMU) 의 1998 의 published — 매 Bass, Clements, Kazman 의 *Software Architecture in Practice* 의 codified. 매 2026 의 lightweight 의 RFC/ADR + LLM-assisted scenario generation 의 evolved 됨 — 매 core 의 still scenario-driven trade-off analysis.

## 매 핵심

### 매 9 phases (classical ATAM)
1. Present ATAM (method intro).
2. Present business drivers.
3. Present architecture.
4. Identify architectural approaches.
5. Generate quality attribute utility tree.
6. Analyze approaches against scenarios.
7. Brainstorm + prioritize scenarios (stakeholders).
8. Re-analyze.
9. Present results.

### 매 outputs
- **Utility tree**: quality goals → attributes → scenarios (H/M/L priority + difficulty).
- **Risks**: 매 architecture decision 의 negative consequence.
- **Non-risks**: 매 sound decision 의 confirmation.
- **Sensitivity points**: 매 single decision 의 single attribute 의 strongly affect.
- **Trade-off points**: 매 single decision 의 multiple attributes 의 differently affect.

### 매 scenario template
```
Stimulus (event) — Source (actor) — Environment (state) →
  Artifact (component) → Response (system action) → Measure (latency, %, etc.)
```

### 매 응용
1. Pre-build architecture review.
2. Major refactor 의 GO/NO-GO.
3. Vendor selection — 매 candidate 의 same scenarios 의 score.
4. Tech radar 의 input.

## 💻 패턴

### Utility tree (Markdown)
```markdown
# Utility Tree — Order Service v3

## Performance
- (H, H) p95 checkout latency < 300ms at 10k RPS
- (H, M) Cold start < 500ms (serverless)
- (M, L) Background job throughput > 1k/s

## Availability
- (H, H) 99.99% monthly SLO for /checkout
- (H, M) Graceful DB failover < 30s
- (M, M) Region evacuation < 5min

## Modifiability
- (H, M) New payment method added in < 5 dev-days
- (M, L) Tenant-specific pricing rules without redeploy

## Security
- (H, H) PCI-DSS compliance for card data path
- (M, M) PII encryption at rest

(H/M/L = Importance, Difficulty)
```

### Scenario (concrete)
```yaml
id: PERF-01
quality_attribute: performance
priority: H
difficulty: H
stimulus: "10,000 concurrent checkout submissions"
source: "authenticated mobile clients"
environment: "normal operations, peak hour"
artifact: "checkout-api + payment-gateway"
response: "process to confirmed order"
measure: "p95 < 300ms, p99 < 800ms, error rate < 0.1%"
analysis:
  approach: "Read-through Redis cache + async write to Kafka"
  sensitivity: ["Redis cluster size", "Kafka partition count"]
  tradeoff: "Cache adds read latency variance vs DB-direct correctness"
  risk: "Cache stampede on Redis failover"
  mitigations: ["request coalescing", "stale-while-revalidate"]
```

### Risk / Non-risk / Sensitivity / Trade-off ledger
```markdown
| ID | Type | Decision | Affects | Status |
|----|------|----------|---------|--------|
| R-01 | Risk | Sync DB write in checkout | Avail, Perf | Open — needs async branch |
| R-02 | Sensitivity | Redis TTL = 60s | Performance | Confirmed — measured |
| R-03 | Tradeoff | Multi-region active-active | Avail+ / Cost-, Consist- | Accepted in ADR-014 |
| N-01 | Non-risk | JWT for auth | Security | OK — standard practice |
```

### Lightweight ATAM (modern, 2-day workshop)
```markdown
Day 1 AM:  Business drivers + architecture walkthrough (2h)
Day 1 PM:  Utility tree co-construction (3h)
Day 2 AM:  Scenario analysis — top 5 (4h)
Day 2 PM:  Risks/tradeoffs ledger + ADR drafts (3h)
Output:    1-page exec summary + per-scenario deep dives
```

### Tooling — Structurizr + ADR + LLM
```bash
# 1. Architecture in Structurizr DSL
# 2. ADRs in /docs/adr/*.md (adr-tools)
adr new "Use Redis cache for checkout reads"

# 3. LLM-assisted scenario brainstorm
claude --prompt "Given utility tree and arch, propose 10 stress scenarios"

# 4. CI gate — utility-tree.yml diff = ADR required
```

### CBAM extension (cost-benefit)
```python
# Cost-Benefit Analysis Method (Kazman, Asundi, Klein 2002)
def score(scenario):
    benefit = scenario.utility * scenario.weight
    cost = scenario.implementation_cost
    return benefit / cost  # ROI for prioritization
```

## 매 결정 기준
| 상황 | Method |
|---|---|
| Greenfield, high-stakes | Full ATAM (5-day) |
| Iteration / sprint review | Lightweight ATAM (1-2 day) |
| Single decision | ADR with trade-off section |
| Cost-aware prioritization | CBAM |
| Solo / startup | RFC + scenario list (informal) |
| Continuous | Fitness functions + ADR |

**기본값**: ADR-per-decision + lightweight ATAM 의 quarterly.

## 🔗 Graph
- 부모: [[Software Architecture]] · [[Quality Attributes]]
- 응용: [[ADR]] · [[RFC]] · [[Architecture_Refactor]]
- Adjacent: [[Architecture Evaluation (아키텍처 평가)]] · [[Architecture Review (아키텍처 및 설계 리뷰)]] · [[Architectural-Constraint-Enforcement]]

## 🤖 LLM 활용
**언제**: 매 utility tree 의 first-draft generation, 매 scenario 의 stress-test brainstorm, 매 risk ledger 의 categorization.
**언제 X**: 매 final risk acceptance — 매 stakeholder consensus 의 필수.

## ❌ 안티패턴
- **Theatre review**: 매 architect-only attendance — 매 stakeholder buy-in 의 X.
- **Scenario without measure**: 매 "fast" / "scalable" — 매 unfalsifiable.
- **No follow-up**: 매 risks 의 logged 의 forgotten — 매 ADR 의 link 의 필수.
- **One-time**: 매 architecture 의 evolves — 매 evaluation 의 also.
- **Skip business drivers**: 매 quality attributes 의 prioritization 의 wrong.

## 🧪 검증 / 중복
- Verified (Bass, Clements, Kazman — *Software Architecture in Practice* 4th ed; SEI tech reports CMU/SEI-2000-TR-004).
- 신뢰도 A.

## 🕓 Changelog
| 날짜 | 변경 |
|---|---|
| 2026-05-08 | Phase 1 |
| 2026-05-10 | Manual cleanup — utility tree + scenarios + risk ledger + lightweight ATAM |