Chapter 22: Analyzing Architecture Risk
fsa architecture-risk risk-storming risk-matrix
Status: Notes complete
Overview
Chapter 22 equips architects with concrete techniques for identifying, quantifying, and mitigating architectural risk before it becomes a production incident. Risk analysis is often treated as a project-management concern, but the authors argue it is fundamentally an architectural responsibility — because the decisions that create risk are architectural ones. The chapter introduces the risk matrix as a quantification tool, risk storming as a collaborative identification technique, and user-story-level risk analysis for sprint-level prioritization. Three worked use cases — availability, elasticity, and security — illustrate how these techniques apply to real architecture concerns.
Risk Matrix
A risk matrix is the foundational tool for quantifying and communicating architectural risk. It provides a shared vocabulary for comparing risks and prioritizing mitigation effort.
Two Dimensions
Every risk is evaluated on two independent dimensions:
| Dimension | Levels | What It Measures |
|---|---|---|
| Likelihood | Low / Medium / High | Probability that the risk event actually occurs |
| Impact | Low / Medium / High | Severity of the consequence if the risk event does occur |
Risk score = Likelihood × Impact
The 3×3 grid produces nine risk cells that collapse into three priority bands:
The 3×3 Risk Matrix
| Impact: Low | Impact: Medium | Impact: High | |
|---|---|---|---|
| Likelihood: High | Medium Priority | High Priority | Critical |
| Likelihood: Medium | Low Priority | Medium Priority | High Priority |
| Likelihood: Low | Acceptable | Low Priority | Medium Priority |
Reading the Matrix
- Critical (High Likelihood × High Impact): Requires immediate mitigation. These risks are both likely to occur and catastrophic if they do. Acceptable only temporarily with a documented mitigation plan and timeline.
- High Priority (High/Medium likelihood × High/Medium impact along the diagonal): Should be mitigated in the near term. Assign an owner and a mitigation strategy.
- Medium Priority: Monitor. Mitigate if resources allow.
- Low Priority / Acceptable (Low Likelihood × Low Impact): Document and accept. Revisit periodically.
Assigning Likelihood and Impact Ratings
Ratings should be based on:
- Likelihood: Historical incident data, architecture analysis (single points of failure, dependency topology), operational experience
- Impact: Business impact analysis (revenue loss, data loss, compliance violations, SLA breach), user-facing consequence
Ratings are always relative to a specific architectural context. A “Low” likelihood in one system may be “High” in another with different operational maturity.
Risk Assessments
A risk assessment is the structured process of applying the risk matrix to a specific architecture.
Steps for Conducting a Risk Assessment
- Enumerate components and services: Identify all meaningful architectural components — services, databases, message queues, external dependencies, load balancers, etc.
- Identify risk events for each component: For each component, ask: What could go wrong? (Failure modes: crashes, data corruption, latency spikes, security breaches, capacity exhaustion)
- Rate likelihood and impact: For each risk event, assign a likelihood and impact rating. Use team consensus; do not let one person rate everything alone.
- Plot on the risk matrix: Place each risk in its matrix cell.
- Prioritize: Focus attention and mitigation effort on the Critical and High Priority cells.
- Document: Record the assessment with dates and owners. A risk assessment is only useful if it is a living document.
Risk Assessment Output
The output of a risk assessment is:
- A prioritized list of risks with likelihood, impact, and combined priority
- Assigned owners for each risk
- Proposed mitigations for high-priority risks
- A review schedule (risk assessments go stale as the architecture evolves)
Risk Storming
Risk storming is a collaborative, facilitated risk identification technique performed against an architecture diagram. It borrows the parallel-independent-work structure from event storming but focuses exclusively on risk. The key insight is that different stakeholders — developers, operations, security, product — see different risks, and a solo architect will miss the risks outside their own mental model.
Risk storming is structured as three sequential phases.
Phase 1: Identification (Independent)
Goal: Surface as many risks as possible, without social filtering.
How it works:
- All participants receive (or can view) the architecture diagram.
- Each participant independently writes risks on sticky notes — one risk per note.
- Participants place their sticky notes on the component or connection in the diagram that the risk affects.
- No discussion during this phase. This rule is critical: discussion during identification causes participants to self-censor, anchor on others’ ideas, or defer to authority figures.
What counts as a risk: Anything that could cause the architecture to fail to meet a quality attribute or business requirement — failures, bottlenecks, security vulnerabilities, single points of failure, integration weaknesses, operational gaps.
Output: A diagram covered in sticky notes, with clusters forming naturally around the most-discussed components.
Phase 2: Consensus (Collaborative Discussion)
Goal: Review all identified risks, agree on severity ratings (likelihood + impact), and resolve disagreements.
How it works:
- The facilitator reads each sticky note aloud.
- Uncontested risks (where participants quickly agree on severity) are rated and moved on.
- Contested risks (where participants disagree on likelihood or impact) are discussed until consensus is reached or a decision is made by a designated tie-breaker.
- Duplicate risks are merged; each unique risk receives its final likelihood and impact rating.
- Each risk is placed in its corresponding risk matrix cell.
Key principle: The goal is not agreement for its own sake — it is to surface the reasoning behind disagreements. A security engineer who rates a risk “High Impact” where a developer rates it “Low Impact” is revealing a knowledge gap that is itself valuable.
Output: A fully populated risk matrix with agreed severity ratings for all identified risks.
Phase 3: Risk Mitigation (Action Planning)
Goal: For the highest-priority risks, define concrete mitigations and assign ownership.
How it works:
- Focus on the Critical and High Priority cells of the risk matrix.
- For each high-priority risk, the team brainstorms mitigation strategies:
- Design changes: Eliminate the risk at the architecture level (e.g., add redundancy, remove a SPOF)
- Monitoring and alerting: Detect the risk event early enough to respond before it becomes an incident
- Redundancy and fallback: Tolerate the risk event without service degradation
- Process controls: Operational procedures that reduce likelihood (e.g., staged rollouts, chaos engineering)
- Each mitigation is assigned an owner — a named person or team responsible for implementation.
- A target completion date is set for each mitigation.
Output: A mitigation plan — a prioritized list of actions with owners and timelines, ready to be tracked as work items.
User-Story Risk Analysis
Risk assessment does not have to operate only at the architecture level. Architects and teams can apply risk thinking at the individual user story level, which integrates risk management into the delivery process.
How It Works
For each user story in a sprint or backlog, assess:
- Which architectural components does this story touch? Stories that touch high-risk components inherit that risk.
- Does this story introduce new risk? New integrations, schema changes, and cross-service interactions all create risk.
- What is the likelihood and impact of this story going wrong?
High-risk stories should be:
- Front-loaded in the sprint — implement risky stories early so there is time to discover and address problems
- Assigned to the most experienced engineers on the team
- Given more explicit acceptance criteria and more thorough testing requirements
Value of Story-Level Risk Analysis
Story-level risk analysis connects architecture risk to the delivery process. Instead of risk living in a separate document that developers ignore, risk ratings inform which stories get more care, more test coverage, and more pairing. It makes risk visible at the level where work actually happens.
Risk Storming Use Cases
Three characteristic quality attributes illustrate how risk storming is applied in practice.
Availability Risk Storming
Focus question: Where are the single points of failure, and what happens when any given component goes down?
What participants look for:
- Components with no redundancy (single instances, no failover)
- Synchronous dependency chains where one failure cascades
- Databases with no replication or backup strategy
- External third-party dependencies with no fallback or circuit breaker
- Deployment processes that require downtime
Common high-severity risks identified:
- “The authentication service has no redundancy — if it goes down, no user can log in” (High Likelihood × Critical Impact)
- “We have no database read replica — a single slow query blocks all reads” (Medium Likelihood × High Impact)
Mitigations: Active-passive failover, circuit breakers, health-check-driven load balancing, chaos engineering exercises, runbooks for failure scenarios.
Elasticity Risk Storming
Focus question: What can’t scale, and where are the bottlenecks when load increases?
Elasticity is the ability to scale up and back down rapidly in response to changing load — distinct from raw scalability (the ability to handle load at all).
What participants look for:
- Services that require manual intervention to scale (not auto-scaled)
- Shared resources that become bottlenecks (single database write path, shared caches)
- Synchronous call chains where one slow service degrades the whole request path
- In-process state that prevents horizontal scaling
- Third-party APIs with rate limits that become binding at scale
Common high-severity risks identified:
- “The inventory service stores session state in-process — adding instances loses user sessions” (High Likelihood if traffic spikes × High Impact)
- “The payment gateway rate-limits us to 100 requests/second — we have no queue to absorb spikes” (Medium Likelihood × High Impact)
Mitigations: Externalize state (Redis, distributed cache), introduce async queues to absorb spikes, pre-warm capacity before known traffic events, load test at 2–3× expected peak.
Security Risk Storming
Focus question: What are the attack surfaces, where is sensitive data vulnerable, and where are authentication/authorization weaknesses?
What participants look for:
- Unencrypted data in transit between services (missing TLS on internal calls)
- Sensitive data at rest without encryption (PII in plaintext columns)
- Missing authentication on internal API endpoints (“trusted network” assumption)
- Overly permissive IAM roles or service accounts
- User input that reaches SQL queries or shell commands without sanitization
- Third-party dependencies with known vulnerabilities
Common high-severity risks identified:
- “Internal service-to-service calls use HTTP, not HTTPS — lateral movement after compromise is trivial” (High Impact regardless of likelihood)
- “The admin API has no rate limiting — credential stuffing is straightforward” (Medium Likelihood × Critical Impact)
Mitigations: Mutual TLS for service-to-service, field-level encryption for PII, zero-trust network model, regular dependency vulnerability scanning (Dependabot, Snyk), penetration testing, security-focused ADRs.
Common Antipatterns
Risk Theater: Conducting risk assessments to check a compliance box, with no intention of acting on findings. The output is a document that is filed and forgotten. Detectable by risk assessments that never result in work items.
Risk Monoculture: Having a single architect or security person perform all risk assessments solo. They identify the risks within their mental model and miss everything outside it. Risk storming’s multi-participant design directly addresses this.
Severity Inflation: Rating every risk as “High” to be safe. This destroys the prioritization value of the risk matrix — if everything is critical, nothing is. Enforce honest ratings by requiring quantitative justification.
Stale Risk Registers: Treating a risk assessment as a one-time exercise. As architecture evolves, new risks emerge and old ones are mitigated. Risk assessments must be re-run (or risk storming sessions re-held) at meaningful architecture change points.
Mitigation Without Ownership: Identifying risks and agreeing on mitigations but not assigning an owner to each. Ownerless mitigations are never implemented. Phase 3 of risk storming is incomplete without named owners and timelines.
Key Takeaways
- Risk = Likelihood × Impact: Every architectural risk should be evaluated on both dimensions independently; the combined score drives prioritization.
- 3×3 Risk Matrix: The nine-cell grid creates three priority bands — Critical, Medium, and Acceptable — giving teams a shared language for risk conversations.
- Risk Storming Phase 1 Rule: Identification must be done independently with no discussion; social pressure and authority gradients suppress risk identification if discussion is allowed during this phase.
- Phase 2 Goal: The consensus phase is not about forced agreement but about surfacing the reasoning behind disagreements — which reveals knowledge gaps as valuable as the risks themselves.
- Phase 3 Output: Every high-priority risk mitigation must have a named owner and a deadline; ownerless mitigations are never implemented.
- Multi-Stakeholder Necessity: Different roles see different risks; a solo architect will systematically miss risks outside their domain expertise — risk storming’s collaborative structure is not optional.
- User-Story Risk Analysis: Applying risk thinking at the story level integrates risk management into delivery; high-risk stories should be front-loaded in the sprint.
- Availability Focus: Risk storming for availability targets single points of failure and synchronous dependency chains that enable cascading failures.
- Elasticity Focus: Risk storming for elasticity targets components that cannot scale horizontally, in-process state, and third-party rate limits that bind at scale.
- Security Focus: Risk storming for security targets attack surfaces, unencrypted data in transit/at rest, missing authentication on internal APIs, and overly permissive access controls.
Related Resources
- ch21-architectural-decisions — ADRs are the documentation vehicle for recording risk mitigations as architectural decisions
- ch04-architecture-characteristics-defined — Nonfunctional characteristics (availability, elasticity, security) are the quality attributes risk storming evaluates
- ch09-foundations-of-architecture-styles — Architecture style choices determine which risk categories are inherent to a system
Last Updated: 2026-05-29