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

id, title, category, status, canonical_id, aliases, duplicate_of, source_trust_level, confidence_score, verification_status, tags, raw_sources, last_reinforced, github_commit, tech_stack

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

# 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)

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

| 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)

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

# 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)

# 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