Risk & Constraint Management

Risks are things that could go wrong; constraints are things that can’t be changed. Naming both upfront prevents them from surfacing as “nobody told us that” mid-project.

At a glance

• What it is: Explicitly identifying and tracking risks (a vendor API might be unreliable) and constraints (must use the existing identity provider) as part of the solution design, rather than discovering them during build.
• Why it matters: undocumented assumptions are one of the most common sources of mid-project surprises — a risk register turns “nobody mentioned that” into “we knew and planned for it.”
• For developers: if a design assumes a dependency will “probably be fine,” that assumption belongs in a risk register with a named mitigation, not left implicit in someone’s head.
• When to use it: alongside Component & Integration Design, since new components and integrations are where most new risks and constraints appear.
• When not to use it: as a box-ticking exercise with generic entries like “the project might be delayed” — risks should be specific to this solution.
• Prerequisites: a component and integration design to evaluate for new dependencies and risks.

Mental model

flowchart LR
    A[Identify risk or constraint] --> B[Assess likelihood & impact]
    B --> C[Define mitigation or accept]
    C --> D[Track in risk register]
    D --> E[Review periodically]

A risk register isn’t a one-time list — items are added as the design evolves, and each needs a named mitigation (or an explicit, accepted decision to do nothing).

Step-by-step walkthrough

1. Review the component and integration design for new external dependencies, single points of failure, and unproven assumptions.
2. List each as a risk (something that might happen) or a constraint (something that’s fixed and can’t be changed).
3. For each risk, estimate likelihood and impact, and define a mitigation — or explicitly accept the risk if mitigation isn’t worthwhile.
4. Record constraints so later design decisions don’t silently violate them.
5. Include the risk register in the Solution Architecture Document and revisit it as the design changes.

Worked example

The real-time analytics design (storefront events streamed asynchronously to a separate analytics store) introduces a new dependency on a message queue.

• Input: a new async integration that didn’t exist before.
• Process: the team asks what could go wrong — a traffic spike could cause the queue to back up faster than the analytics store can consume it.
• Output: a risk register entry: risk — “queue backlog during traffic spikes delays dashboard freshness”; impact — dashboards lag, but checkout is unaffected since it only publishes and doesn’t wait; mitigation — backpressure limits and an alert when queue depth exceeds a threshold.

Common use cases

Use case	When to use	Notes
New external dependency introduced	A new vendor, API, or queue is added to the design	Ask what happens if it’s slow, unavailable, or changes behavior unexpectedly
Fixed organizational constraint	Must use an existing platform, identity provider, or data residency rule	Document it so later design choices don’t have to rediscover it the hard way
Project risk review before build	Gate before committing engineering time	Confirm every named risk has either a mitigation or an explicit acceptance decision
New customer-facing system with no regional redundancy	Availability NFR requires surviving a regional outage	A single Azure region is a single point of failure — pair with the replication/failover options in Non-Functional Requirements rather than accepting it silently

Advanced details

• Risks need an owner and a mitigation, not just a description: an unmitigated, unowned risk on a list isn’t actually being managed.
• Constraints aren’t risks: a constraint (e.g. “must use the existing identity provider”) isn’t something to mitigate — it’s a fixed boundary the design must work within.
• Accepting a risk is a valid outcome: not every risk needs an expensive mitigation; explicitly deciding to accept a low-impact risk is fine, as long as it’s a documented decision, not an oversight.

Quick reference

Term	Meaning
Risk	Something that might go wrong, with an estimated likelihood and impact
Constraint	A fixed limitation the design must work within and cannot change
Mitigation	The action taken to reduce a risk’s likelihood or impact
Risk register	The tracked list of risks, their assessments, and mitigations

Troubleshooting

Symptom	Likely cause	Fix
A dependency failure causes a project-wide surprise	The risk was never identified or written down	Review every new external dependency for risk before build starts
Design violates a known organizational rule	Constraint was never documented or checked	Maintain a constraints list and check new design decisions against it
Risk register has only generic entries	Risks weren’t derived from the actual design	Walk through the component/integration diagram and ask “what could go wrong here specifically”

Check your understanding

• What’s the difference between a risk and a constraint?
• Take a dependency in a system you work on and write one specific risk, its impact, and its mitigation.

Related pages

Part of Introduction to Solution Architecture. Works alongside Component & Integration Design; feeds into the Solution Architecture Document and Transition & Roadmap Planning. See also the Glossary.