Assessing architecture risk
Every architecture has weak spots: a component that can't scale, a single point of failure, an unproven technology, a part only one person understands. The architect's job isn't to eliminate risk but to find it early, rate it honestly, and spend effort where it matters most. This module covers the risk matrix, risk assessments across the architecture, risk storming with a team, and stress-testing an architecture against events nobody predicted.
1. The idea
The risk matrix
Rate each risk on two scales from 1 to 3: impact (how bad if it happens) and likelihood (how probable). Multiply: 1–2 low, 3–4 medium, 6–9 high. Rate impact first, then likelihood, so the severity doesn't colour your estimate of the odds.
| Impact ↓ / Likelihood → | Low (1) | Medium (2) | High (3) |
|---|---|---|---|
| High (3) | 3 | 6 | 9 |
| Medium (2) | 2 | 4 | 6 |
| Low (1) | 1 | 2 | 3 |
A risk assessment applies the matrix to the whole architecture: components (or services) as rows, the top characteristics as columns, a score in each cell. It shows where risk concentrates (a row: one fragile component) and which characteristic is most at risk (a column). Unproven or unknown technology should raise likelihood: what you can't explain, you can't rate low.
Risk storming
A collaborative exercise in three steps. Identify: each participant scores risks on the architecture diagram alone, so nobody anchors on the loudest voice. Consensus: put everyone's scores together; where they agree, move on; where they differ widely, talk, because divergence means someone knows something the others don't. Mitigate: for each high risk, choose a change and estimate its cost, so the business can decide what to pay for.
2. How it works
A risk-storming session on elasticity
Three people rate the elasticity risk of a ticket site's components, alone first. Watch what the disagreement reveals.
Stressor analysis: events nobody listed
Risk lists cover what you can imagine. Stressor analysis (part of an approach called residuality theory) deliberately throws unexpected events at the architecture and asks what's left standing. The goal isn't to predict the future but to find an architecture that survives many futures.
3. Try it yourself
A risk assessment you can edit
Five components of a ticket site, three characteristics. Click a cell to change its score (1 → 2 → 3 → 4 → 6 → 9). Rows and columns total as you go, and the summary shows where to act first.
4. Trade-offs
Precision vs honesty
Risk scores are judgements, not measurements. Precise-looking numbers can hide guesses. Keep the scale coarse (1–3) and write down the reason for each high score.
Individual vs group
Rating in a group is quick but people anchor on the first or loudest opinion. Rating alone first and then comparing surfaces what each person knows.
Mitigate vs accept
Every mitigation costs something. Some risks are cheaper to accept and monitor than to remove. The business decides, given the cost; the architect makes the trade-off visible.
Known risks vs resilience
Listing known risks protects against what you can predict. Stressor analysis builds an architecture that also copes with what you can't. Do both.
5. In real projects
Keep it current. Re-run the assessment at milestones and after big changes. A risk score that's improved (a high fixed to medium) is evidence that architecture work is paying off, which is useful when asking for time for the next piece.
Use it to talk to the business. "Payments has an elasticity risk of 9: on sale day we'd lose sales after the first minute. Fixing it costs three weeks." That's a decision a product owner can make; "the architecture has scaling issues" isn't.
Storm one characteristic at a time. A risk-storming session that tries to cover everything produces a shallow list. Pick one dimension (elasticity, security, availability) per session.
Say it in the interview
- "How do you assess architecture risk?" A matrix of components against the top characteristics, each cell scored impact times likelihood, so risk concentrations stand out. Unknown technologies get a higher likelihood by default.
- "What's risk storming?" Team members score risks on the diagram individually, then compare; big disagreements get discussed because they reveal hidden knowledge. Then we agree mitigations and their costs.
- "How do you prepare for risks nobody predicted?" Stressor analysis: apply many unlikely events to the architecture, see what breaks, and change it so it survives as many as possible.
- "We don't have any major risks."
- Risks described without impact, likelihood or a mitigation cost.
- An unproven technology rated low risk.
6. Remember it
How this hook works: what "score alone, argue together" means
What the slogan means, phrase by phrase
- "Score alone"
- Each person rates impact and likelihood without seeing others' scores.
- "argue together"
- Where scores diverge, someone knows something; talking it out finds the real risk.
Why this picture fits: the most valuable output of a risk session is usually one fact one person knew and nobody else did.
The story → the concept
| Pre-flight check | Risk assessment |
|---|---|
| The walk-around checklist | The risk matrix |
| Dent noted, fuel leak grounds the plane | Low risk accepted, high risk mitigated |
| Two pilots' independent checks | Individual scores in risk storming |
| Simulator emergencies | Stressor analysis |
The trap it saves you from
Risk decided by whoever speaks first and most confidently.
7. Common mistakes
8. Design exercise (30 minutes)
- Build the grid (10 min). Your system's main components against its top three characteristics. Score every cell alone.
- Compare (10 min). Ask a colleague to score the same grid without seeing yours. Discuss every cell that differs by more than one level.
- Apply three stressors (10 min). Pick three unlikely events (a provider doubles prices, a region goes down, a regulation changes). What breaks, and what would make it survive?
9. Self-check quiz
High impact (3), medium likelihood (2). What's the risk score?
Why do participants score risks alone first in risk storming?
One person scores a risk 1, another 9. What does that mean?
How should an unproven technology affect a risk score?
What is stressor analysis?
10. Go deeper
| Resource | Time | Why |
|---|---|---|
| Risk-storming (Simon Brown) | 15 min | The collaborative technique, with a format you can run tomorrow. |
| Fundamentals of Software Architecture, 2nd edition | book | The chapter on analysing architecture risk, with risk matrices and assessments. |
| Residues (Barry O'Reilly) | book | Residuality theory and stressor analysis from their originator. |