# Decision Dependencies

**In short:** Architectural decisions depend on each other. One decision can trigger or split into others. Recording these links helps teams see which decisions to make early and where follow-on work comes from.

## Explanation

Decisions rarely stand alone. Making one choice often creates the need for others. Decision models can capture these relations between decisions (see Architectural Decision).

**Abstract decisions cause detailed ones.** A high-level decision usually leads to follow-on decisions about design details, technology and product choices. This is a refinement or triggering link, running from the conceptual level (abstract, pattern-like choices) down to the technology level. Decisions can reach all the way down to implementation and DevOps.

**Principles trigger decisions.** A strategic decision or a principle such as loose coupling immediately raises a question: how will the team promote that principle? This is one reason such decisions are made early.

**One decision can split into several.** Composite patterns, such as an integration broker, require further decisions about topology, technologies and message delivery. Here one decision decomposes into several issues.

**Many outgoing links mark a big decision.** A decision with many or unclear outgoing dependencies is a "one thing leads to another" case. Teams flag it as a big or early decision.

**Dependencies feed back into the process.** Newly found design issues can start another round of decision making.

**Models can check consistency.** Research on formal definitions of decision models aims at consistency checking. Earlier models supported such checks only to a very limited degree.

**In arc42.** Relations between decisions are only lightly recorded. A decision can be marked as superseded, ideally with a reference to its replacement. The decisions section should refer to decisions already captured in the solution strategy section.

## Example

A team adopts loose coupling as a principle. That raises a new question: how will services exchange data? They choose an integration broker. The broker in turn requires decisions on topology, technologies and message delivery. Later, they pick a specific product, which is a technology-level decision. Each step follows from the one before. The team can trace the product choice back to the principle.

## Trade-offs

Tracking dependencies takes effort, and arc42 itself records them only lightly. Formal models support consistency checks, but the facts here show only that this is a research goal and that earlier models offered little support. Decisions with many unclear outgoing links need early attention, which can push teams to decide before they are ready.

One decision triggers and splits into follow-on decisions.

```mermaid
flowchart TD
  P[Principle: loose coupling] -->|triggers| I[Issue: how to exchange data]
  I --> A[Alternative: integration broker]
  A -->|decomposes into| T[Issue: topology]
  A -->|decomposes into| M[Issue: message delivery]
  A -->|decomposes into| X[Issue: technology]
```

## Checks

- Decisions that trigger follow-on decisions (for example a principle leading to technology choices) are identified.
- Decisions with many or unclear outgoing dependencies are flagged as big or early decisions.
- A superseded decision points to its replacement.
- The decisions section refers to decisions already captured in the solution strategy section.

## Related

- [Architectural Decision](https://arc.fuet.ch/concepts/forces-decisions/architectural-decision.md)
- [Levels of Architectural Decisions](https://arc.fuet.ch/concepts/forces-decisions/levels-of-architectural-decisions.md)
- [Architectural Decision Record](https://arc.fuet.ch/concepts/forces-decisions/architectural-decision-record.md)
- [arc42 Architecture Decisions](https://arc.fuet.ch/concepts/documentation/arc42-architecture-decisions.md)
- [Architectural Decision Management](https://arc.fuet.ch/concepts/forces-decisions/architectural-decision-management-practices.md)
- [Architectural Design Issue](https://arc.fuet.ch/concepts/forces-decisions/formulation-of-decision-issues.md)
- [Architecture Principle](https://arc.fuet.ch/concepts/principles/architecture-principle.md)
- [Broker Pattern](https://arc.fuet.ch/concepts/styles-patterns/broker-pattern.md)

## Sources

- [A Definition of Ready for Architectural Decisions (ADs)](https://ozimmer.ch/practices/2023/12/01/ADDefinitionOfReady.html) — ozimmer.ch, accessed 2026-11-09
- [[1807.02798] Formal Semantics of Architectural Decision Models](https://arxiv.org/abs/1807.02798) — arxiv.org, accessed 2026-11-09
- [ADG: A Light Architectural Decision Guidance and Management Tool](https://ozimmer.ch/practices/2025/07/17/ArchitectureDecisionGuidanceTool.html) — ozimmer.ch, accessed 2026-11-09
- [9 - Architecture decisions | arc42 Documentation](https://docs.arc42.org/section-9/) — docs.arc42.org, accessed 2026-11-09