What is risk-storming as an architecture practice, how is a session actually run, and why is the first step done silently and individually?

## What it is **Risk-storming** is a lightweight, collaborative technique for identifying and prioritising risk in a software architecture, described by Simon Brown (author of the C4 model). Instead of a risk workshop producing an abstract spreadsheet, risks are attached **visually to the architecture itself** — sticky notes (physical or virtual) placed on the diagram element they threaten. **Risk** here means an uncertain future event with a negative consequence — a component that may not meet its throughput target, an integration whose partner may be unavailable, a data store that may not survive a region outage, a technology nobody on the team has run in production. ## Running a session 1. **Agree the canvas.** Put up the diagrams everyone will annotate — commonly a system-context diagram and one or more container/component diagrams. Everyone must understand the notation before risks are collected; ambiguity in the diagram becomes ambiguity in the risks. 2. **Identify risks individually and in silence.** Each participant writes risks on their own, one risk per note, for a fixed period. No discussion. 3. **Place the notes.** Participants attach each note to the diagram element it concerns. Notes that belong to no element usually reveal something missing from the diagram — itself a finding. 4. **Converge.** Walk the board together: merge duplicates, clarify wording, split compound risks. Duplicate notes from independent participants are a signal of shared concern, not noise to discard before scoring. 5. **Prioritise.** Score each risk on **probability × impact**, typically low/medium/high on each axis, often colour-coded — red for high priority, amber for medium, green for low. 6. **Mitigate.** For the top risks, agree concrete actions with owners: a spike, a load test, a fallback design, a bulkhead, a written decision record, or an explicit accept-and-monitor decision. These become backlog items, not workshop artefacts. ## Why the first pass is silent and individual This is the load-bearing design choice of the technique, and interviewers probe it: - **Anchoring** — the first risk voiced frames everyone's subsequent thinking; independent writing prevents it. - **Authority bias** — the architect or most senior engineer speaking first suppresses dissent from those closest to the code or to operations. - **Coverage** — diverse participants (developers, testers, operations, security, product, support) hold non-overlapping risk models; group discussion tends to converge early and lose the tails. - **Signal from duplication** — if five people independently flag the same component, that convergence is evidence, which is only meaningful if the writing was independent. Groupthink is the failure mode being engineered out: a room that discusses first typically produces fewer, more conventional risks. ## Who to invite Mixed roles beat a room of architects. Operations people surface failure and recovery risks; testers surface observability and verifiability risks; support surfaces what actually breaks for users; security surfaces trust-boundary risks; product surfaces risks about assumptions on volume and change. Keep it small enough for everyone to speak during convergence. ## Where it fits - **Risk-driven design** (George Fairbanks): choose architecture *effort* by risk — do the design work that retires your biggest risks and no more. Risk-storming supplies the prioritised risk list that drives that choice. - **Iteration.** Run it early (before committing to structure), again when the architecture changes materially, and after significant incidents. Date the output; a risk board from a year ago describes a system that no longer exists. - **Relationship to other practices.** It complements rather than replaces threat modelling (security-specific, typically a structured method such as STRIDE over data-flow diagrams), failure-mode analysis, and pre-mortems. Risk-storming is broader and cheaper; a hotspot it reveals often triggers one of the deeper techniques. ## Outputs and pitfalls Good outputs: a prioritised risk list tied to diagram elements, mitigations with owners and dates, and often diagram corrections. Common pitfalls: no scoring (a wall of notes with no priority is not a decision); no owner (risks re-identified verbatim next session); scoring theatre (invented numeric probabilities implying precision nobody has — coarse low/medium/high is more honest); treating it as a one-off ceremony; and confusing risks with issues — an issue is already happening and belongs on the backlog now, a risk is uncertain and needs a probability.