Risk Storming: Turning Architecture Concerns into Action

A practical guide to assessing architecture risks independently, reconciling different perspectives, and choosing mitigations the team can track.

Takahiro Iwasa

2026-08-29

6 min read

Many system failures begin with a concern that someone noticed but never made it into the design. Operations engineers remember past incidents, developers understand implementation constraints, and security engineers see weaknesses at trust boundaries. No single reviewer can reliably surface all of that knowledge.

Risk storming brings those perspectives together around an architecture diagram. Participants first assess risks independently, then compare their reasoning and decide what to do. A shared scoring model keeps the exercise from becoming a list of vague worries by tying each concern to a priority, a design change, or continuous measurement.

The three stages of risk storming

What is risk storming?

Begin by selecting one risk dimension such as availability, performance, scalability, data loss, single points of failure, security, or unproven technology. Using an up-to-date architecture diagram, participants work through three stages:

Identification: Each participant independently marks risky areas and assigns risk scores without consulting the group.
Consensus: The group combines the results and discusses conflicting scores and concerns found by only one person.
Mitigation: The group decides whether each agreed risk requires a design change, an operational control, measurement, or explicit acceptance.

Keeping identification independent is essential. Starting with a conversation makes later assessments vulnerable to anchoring and the influence of the most confident speaker. Recording perspectives first preserves the breadth of the team’s knowledge.

Establish a common scale with a risk matrix

Labels such as “high risk” are ambiguous unless participants share their meaning. Score each concern on two dimensions instead:

Impact: How severely would the event affect users, the business, data, or operations?
Likelihood: Given the current design and operating conditions, how likely is the event to occur?

Assign low (1), medium (2), or high (3) to each dimension and multiply them to obtain the risk score.

Likelihood \ Impact	Low (1)	Medium (2)	High (3)
High (3)	3: Medium	6: High	9: High
Medium (2)	2: Low	4: Medium	6: High
Low (1)	1: Low	2: Low	3: Medium

Assess impact first, then likelihood. A database outage might have high impact, but redundancy and a proven recovery process could make its likelihood low, producing an overall score of 3. An unfamiliar technology is different because the team cannot estimate its failure modes with confidence. Treat it as high risk until an experiment provides evidence.

The score is not an objective truth. It is a shared language for comparing rationale. The value comes from discussing why one person chose 6 and another chose 3, not from averaging the two numbers.

Prepare the exercise

One or two days before the collaborative session, the facilitator should share:

The system or change in scope
The single risk dimension to assess
An up-to-date architecture diagram
The risk matrix and annotation method
The deadline for individual assessment and the time of the group session

Do not limit participation to architects. Include senior developers, technical leads, SREs, and security engineers. Add a product owner when the group will need to judge business impact or mitigation cost. Use a broad diagram for a holistic assessment and a contextual diagram, including relevant dependencies, for a feature-specific assessment.

Mixing dimensions makes annotations ambiguous: a score of 6 beside a database might refer to availability or security. Focus each session on one dimension whenever possible.

Run the three stages

1. Identify risks independently

Each participant reviews the diagram and places an annotation on every risky element or interaction. At minimum, record the target, score, and rationale. Physical sessions can use color-coded sticky notes; remote sessions can use a shared whiteboard.

Participants should neither consult one another nor see existing scores during this stage. An area without an annotation does not represent a vote of “no risk”; it may simply have escaped that participant’s attention.

2. Reach consensus as a team

Combine all annotations on the architecture diagram and review them in this order:

Areas with widely different scores
Risks identified by only one person
High-risk areas on which several people agree

A minority view is not necessarily noise. Someone may know the incident history of a component, or a developer’s lack of familiarity with a selected technology may reveal delivery and operational risk invisible to others. Share assumptions and evidence, then agree on a score and explanation instead of voting.

3. Decide how to mitigate each risk

Start with the highest risks. Consider how to reduce likelihood, limit impact, or improve detection and recovery. Options include redundancy, isolation, asynchronous communication, back pressure, caching, stronger authorization boundaries, monitoring, and recovery exercises.

Not every risk must be eliminated. When a mitigation costs more than the expected loss, explicit acceptance may be the sound decision. Record the response, owner, due date, and condition for reassessment. Score residual risk with the same matrix after implementing a mitigation so that the team can compare its effect.

Keep the practice effective

Avoid turning risk storming into a sticky-note ceremony:

Keep the scope narrow: Select one dimension and an area for which the group can make decisions.
Do not treat the diagram as ground truth: A mismatch between diagram and implementation is itself a risk.
Do not stop at colors: Attach a rationale and a response to every accepted risk.
Evaluate mitigations carefully: Compare cost, added complexity, and any new risks they introduce.
Repeat the exercise: Run it after significant features, architecture changes, or at an iteration boundary.

Continuous measurements or architecture fitness functions can turn the assessment from a snapshot into an improvement loop. A filtered view of high risks and their changes since the previous assessment also communicates the system’s direction more clearly to decision-makers.

What the exercise leaves behind

Risk storming cannot predict every failure. Its more practical result is a record of where the team sees risk, why it matters, and who will act on it.

Repeating the exercise at meaningful design boundaries keeps that record current. The aim is not a system that never fails, but one that exposes unknown problems earlier, limits their effects, and recovers more effectively.

Reference: Mark Richards and Neal Ford, Fundamentals of Software Architecture, 2nd Edition, Chapter 20, “Analyzing Architecture Risk.”

Back to posts