---
id: wiki-2026-0508-sara-software-architecture-revie
title: SARA (Software Architecture Review and Assessment)
category: 10_Wiki/Topics
status: verified
canonical_id: self
aliases: [SARA, Architecture Review, Architecture Assessment]
duplicate_of: none
source_trust_level: A
confidence_score: 0.85
verification_status: applied
tags: [architecture, review, governance, sei, atam]
raw_sources: []
last_reinforced: 2026-05-10
github_commit: pending
tech_stack:
  language: none
  framework: ATAM/ARID/SAAM
---

# SARA (Software Architecture Review and Assessment)

## 매 한 줄
> **"매 architecture 를 매 quality-attribute 관점에서 systematic review 하는 프로세스"**. SEI (Carnegie Mellon) 의 SAAM (1996) → ATAM (2000) → ARID (2002) 계보의 generic 명칭. 매 핵심: stakeholder, scenario, tradeoff, risk 의 명시적 enumeration. 매 2026 modern variant: AWS Well-Architected Review, Architecture Decision Records (ADR), Wardley Mapping 과 결합.

## 매 핵심

### 매 SEI 계보
- **SAAM** (Software Architecture Analysis Method, 1996): scenario-based, modifiability 위주.
- **ATAM** (Architecture Tradeoff Analysis Method, 2000): multi-quality, tradeoff 명시.
- **ARID** (Active Reviews for Intermediate Designs, 2002): incomplete design review.
- **CBAM** (Cost-Benefit Analysis Method): economic angle.

### 매 ATAM 9-step (Kazman et al.)
1. Present ATAM
2. Present business drivers
3. Present architecture
4. Identify architectural approaches
5. Generate quality attribute utility tree
6. Analyze approaches (round 1)
7. Brainstorm scenarios + prioritize
8. Analyze approaches (round 2)
9. Present results

### 매 산출물
- Utility tree: quality attribute → scenario → priority/difficulty.
- Risk / non-risk / sensitivity point / tradeoff point.
- Architectural decision record (ADR) update.

### 매 응용
1. Pre-launch architecture sign-off.
2. Major refactor / re-platforming 의사결정.
3. M&A due diligence.
4. AWS/GCP Well-Architected formal review.

## 💻 패턴

### Utility tree (markdown)
```markdown
- Performance
  - Latency
    - [H, M] p99 checkout < 300ms under 10k rps
    - [M, L] search autocomplete < 80ms
  - Throughput
    - [H, H] sustained 50k rps with 3 AZ failover
- Availability
  - [H, M] 99.95% monthly, RPO=5min, RTO=15min
- Security
  - [H, H] all PII encrypted at rest, TLS 1.3 in transit
- Modifiability
  - [M, M] new payment provider 매 < 2 sprint
# [Importance, Difficulty]: H/M/L
```

### Scenario template
```yaml
id: SCN-007
quality: availability
source: AZ outage in us-east-1a
stimulus: complete loss of one AZ for 30 min
artifact: checkout service
environment: peak traffic, Black Friday
response: traffic auto-shifts to remaining 2 AZ
response_measure: error rate < 0.5% for full 30 min
priority: H
difficulty: M
```

### Risk / Tradeoff log
```markdown
| ID | Type | Description | Affected QAs |
|----|------|-------------|--------------|
| R1 | Risk | Single Redis primary; failover untested | Availability |
| T1 | Tradeoff | Multi-region active-active raises consistency cost | Availability ↔ Consistency |
| S1 | Sensitivity | p99 latency depends on connection-pool size | Performance |
| NR1| Non-risk | Stateless API tier, autoscale verified | Scalability |
```

### ADR (Architecture Decision Record)
```markdown
# ADR-0042: Adopt event-driven checkout via Kafka

Date: 2026-05-10
Status: accepted
Context: synchronous REST chain causes p99 spikes and tight coupling.
Decision: introduce Kafka topic `orders.v1`; checkout publishes; downstream
  services (inventory, fulfilment, notify) consume independently.
Consequences:
  + Decoupling, replayability, easier multi-region.
  - New ops surface (Kafka), schema-registry overhead.
  - Eventual consistency: UI must surface "processing" state.
Alternatives considered: SQS (vendor lock), gRPC streaming (still coupled).
```

### Wardley Map sketch (text)
```text
Visible
  ^  User --- Checkout UI
  |              |
  |          Order API ---- Payment Gateway (Stripe, product)
  |              |
  |          Order DB (Postgres, custom-built→product)
  |              |
  |          Compute (k8s on EKS, commodity)
  v
Invisible
[Genesis] -- [Custom] -- [Product] -- [Commodity]
```

### AWS Well-Architected lens (CLI)
```bash
# 매 AWS WA Tool — SARA-equivalent at AWS scale
aws wellarchitected create-workload \
  --workload-name checkout-2026 \
  --description "Checkout platform" \
  --environment PRODUCTION \
  --aws-regions us-east-1 us-west-2 \
  --lenses arn:aws:wellarchitected::aws:lens/wellarchitected \
            arn:aws:wellarchitected::aws:lens/serverless
```

### Lightweight LARA (lightweight ARID, 1-day variant)
```text
09:00 kickoff + business drivers
10:00 architect 30-min walkthrough
10:30 utility tree workshop
12:00 lunch
13:00 scenario brainstorm + dot voting
14:00 round-1 analysis (top 5 scenarios)
16:00 risk/tradeoff log finalize
17:00 readout to stakeholders
```

## 매 결정 기준
| 상황 | Approach |
|---|---|
| Greenfield, pre-launch | Full ATAM (3-day) |
| Time-boxed, single team | LARA (1-day) |
| Cloud-native AWS | Well-Architected Review per pillar |
| Continuous | ADR + monthly architecture council |
| Incomplete design | ARID (active review) |
| Cost-driven | CBAM |

**기본값**: 매 ADR + 매 quarterly LARA + 매 cloud Well-Architected annual.

## 🔗 Graph
- 부모: [[Software Architecture]] · [[Quality Attributes]]
- 변형: [[ATAM]] · [[SAAM]] · [[ARID]] · [[CBAM]]
- 응용: [[Architecture Decision Records]] · [[AWS Well-Architected]] · [[Wardley Mapping]]
- Adjacent: [[Risk_Management]] · [[Threat Modeling]] · [[Tech Radar]]

## 🤖 LLM 활용
**언제**: 매 utility tree 초안, 매 scenario 생성, 매 ADR 작성, 매 tradeoff 분석.
**언제 X**: 매 final sign-off — human architect + stakeholder accountability 필수.

## ❌ 안티패턴
- **Architecture astronautics**: 매 utility tree 만 만들고 매 scenario 분석 skip.
- **Single-quality focus**: 매 performance 만 — security/modifiability 무시.
- **Review without authority**: 매 결과를 매 누구도 implement 강제 못함.
- **One-shot review**: 매 launch 전 한 번 — drift 후 재평가 없음.
- **No ADR**: 매 결정의 *why* 가 없어 매 6개월 뒤 누구도 이유 모름.
- **Theatre review**: 매 형식적 sign-off, 매 실제 risk 미공개.

## 🧪 검증 / 중복
- Verified: SEI ATAM technical reports (Kazman, Klein, Clements 2000–2002); Bass et al. *Software Architecture in Practice* 4e (2021); AWS Well-Architected Framework (2025).
- 신뢰도 A.

## 🕓 Changelog
| 날짜 | 변경 |
|---|---|
| 2026-05-08 | Phase 1 |
| 2026-05-10 | Manual cleanup — ATAM 9-step, utility tree, ADR, Well-Architected |