# Architectural Decision

**In short:** An architectural decision is a choice of one option from several, made against stated criteria. Writing down the reasons lets others understand and retrace the choice later.

## Explanation

An architectural decision means selecting one alternative from several, based on given criteria. The criteria matter. They show why one option won over the others.

**Record the why.** Answers to "why?" questions about a design are as important as any other part of that design. So the reasons belong in the record next to the choice itself.

**Describe the situation.** The context of a decision includes technical, political, social, and project aspects. These forces can pull in different directions. A good record names them, so a reader sees what the team was balancing.

**List all consequences.** A record should not only list the benefits. Every consequence belongs in it, including the unwelcome ones.

**Make it retraceable.** Stakeholders (people with an interest in the system) should be able to understand and retrace the decisions. A reader who was not in the room should still follow how the team got to the result.

For the record format, see the articles Architectural Decision Record and Architecture Decision Rationale.

## Example

A team must pick how two systems exchange data. They consider a shared database and messaging. Their criteria are ease of change and team skills. The project is under time pressure, and one department prefers the database. The team picks messaging. The record names both options, the criteria, and these pressures. It also lists the downsides, such as extra operating effort. A new colleague reads it a year later and sees why the team chose as it did.

## Trade-offs

Writing a decision down takes time. The benefit is that readers can retrace the choice. Listing negative consequences can feel uncomfortable, but a record that shows only the positives is incomplete.



## Checks

- Each decision states the alternatives considered and the criteria used to choose among them.
- Each decision records its rationale, answering why this option was chosen.
- The context of each decision covers technical, political, social, and project aspects.
- All consequences are listed, including negative ones.
- Stakeholders can comprehend and retrace the decisions.

## Related

- [Architectural Decision Record](https://arc.fuet.ch/concepts/forces-decisions/architectural-decision-record.md)
- [Architecture Decision Rationale](https://arc.fuet.ch/concepts/forces-decisions/architecture-decision-rationale.md)
- [arc42 Architecture Decisions](https://arc.fuet.ch/concepts/documentation/arc42-architecture-decisions.md)
- [Architecturally Significant Decision](https://arc.fuet.ch/concepts/forces-decisions/architecturally-significant-decision.md)
- [Architecture as Set of Design Decisions](https://arc.fuet.ch/concepts/forces-decisions/architecture-as-set-of-design-decisions.md)
- [Architectural Force](https://arc.fuet.ch/concepts/forces-decisions/architectural-forces.md)
- [Decision Dependencies](https://arc.fuet.ch/concepts/forces-decisions/decision-dependencies.md)
- [Levels of Architectural Decisions](https://arc.fuet.ch/concepts/forces-decisions/levels-of-architectural-decisions.md)

## Sources

- [9 - Architecture decisions | arc42 Documentation](https://docs.arc42.org/section-9/) — docs.arc42.org, accessed 2026-11-09
- [Architectural Decisions — The Making Of](https://ozimmer.ch/practices/2020/04/27/ArchitectureDecisionMaking.html) — ozimmer.ch, accessed 2026-11-09