# Architectural Decision Records as Evaluation Prerequisite

**In short:** Writing down key architectural decisions, with the reasons for each choice, gives an evaluation something concrete to check against the quality goals. Reviewers can then see which decisions support which goals.

## Explanation

An architectural decision means choosing one alternative from several, based on given criteria. Important, expensive, large-scale or risky decisions should be documented together with their rationales. Stakeholders must be able to comprehend and retrace them.

**What a record holds**

Lightweight formats exist. A Nygard-style record has a Context section. It describes the forces at play: technical, political, social and project aspects. Its Consequences section should list all consequences, not only the positive ones.

MADR is another format. Its Decision Outcome names the chosen option and gives a justification. Its optional consequences list good and bad effects on the desired qualities. See the articles on Markdown Architectural Decision Records and Y-Statement.

**Why evaluation needs them**

An evaluation asks whether the architecture supports the quality goals. The Architecture Tradeoff Analysis Method (ATAM) works this way. It turns business drivers into scenarios. It then lists the architectural decisions made in support of each scenario. Analyzing those decisions yields risks, non-risks, sensitivity points and trade-off points. The article on ATAM findings explains these terms.

Without recorded decisions, this step has little to work from. A record that names the criteria and the chosen alternative lets reviewers judge whether the choice fits the goal.

**Proportionality**

Record only significant decisions: those that matter and are hard and costly to change. The same logic points to evaluation effort. Spend more where a wrong decision would cost more.

**Finding risks early**

ATAM exposes architectural risks that could keep an organization from reaching its business goals. The SEI lists identifying such risks early in the life cycle as a benefit.

## Example

A team must pick how a web shop stores orders. One quality scenario says the shop must stay usable during a database failure. The team records two alternatives, the chosen one, and the criteria used. The consequences list a cost as well as a benefit. A reviewer reads the record. They check whether the chosen option supports the scenario. They also note where the choice carries a risk.

## Trade-offs

Recording decisions takes time, so record only the significant ones. A record that lists only positive consequences hides the costs a reviewer needs to see. Evaluation effort should match the cost of a wrong decision. Spending heavily on minor decisions wastes effort.



## Checks

- Important, expensive, large-scale or risky decisions are documented with their rationales.
- Each recorded decision names the chosen alternative and the criteria used to select it.
- Each record lists all consequences, including negative ones.
- Each decision links to the quality scenario it supports.

## Related

- [Architectural Decision Record](https://arc.fuet.ch/concepts/forces-decisions/architectural-decision-record.md)
- [Architecture Tradeoff Analysis Method (ATAM)](https://arc.fuet.ch/concepts/evaluation/architecture-tradeoff-analysis-method-atam.md)
- [ATAM Findings: Risks, Non-Risks, Sensitivity Points and Trade-off Points](https://arc.fuet.ch/concepts/evaluation/atam-findings-risks-non-risks-sensitivity-points-and-trade-offs.md)
- [Markdown Architectural Decision Records](https://arc.fuet.ch/concepts/forces-decisions/markdown-architectural-decision-records-madr.md)
- [Y-Statement](https://arc.fuet.ch/concepts/forces-decisions/y-statement.md)
- [arc42 Architecture Decisions](https://arc.fuet.ch/concepts/documentation/arc42-architecture-decisions.md)
- [Software Architecture Evaluation](https://arc.fuet.ch/concepts/evaluation/software-architecture-evaluation.md)
- [Quality Attribute Scenario](https://arc.fuet.ch/concepts/quality-attributes/quality-attribute-scenario.md)

## Sources

- [9 - Architecture decisions | arc42 Documentation](https://docs.arc42.org/section-9/) — docs.arc42.org, accessed 2026-11-09
- [Architecture Tradeoff Analysis Method® Collection | CMU Software Engineering Institute](https://www.sei.cmu.edu/library/architecture-tradeoff-analysis-method-collection/) — sei.cmu.edu, accessed 2026-11-09
- [About MADR | MADR](https://adr.github.io/madr/) — adr.github.io, accessed 2026-11-09
- [Architectural Decisions — The Making Of](https://ozimmer.ch/practices/2020/04/27/ArchitectureDecisionMaking.html) — ozimmer.ch, accessed 2026-11-09