# Architectural Decision Management **In short:** Architectural decision management is a set of habits for choosing which decisions to record, deciding them at the right time, justifying them well, and following through on them. ## Explanation Architectural decisions are choices that shape a system. Managing them means caring about the whole life of a decision, not only the moment of choosing. See *Architectural Decision Management Cycle* for the cycle itself. **Select what deserves a record.** Not every decision needs an Architectural Decision Record (ADR). arc42 advises documenting only architecturally significant decisions. These affect structure, quality characteristics and important dependencies, especially external ones. arc42 also points to decisions that are important, expensive, large-scale or risky. A significance test can help prioritize. It is a qualitative judgment, not an exact calculation. **Decide at the right time.** Each decision has a Most Responsible Moment (MRM). Hitting it matters. **Check readiness.** START is a definition of ready. It holds five criteria to answer before a decision is made. Once they are met, the decision should be made. **Check completeness.** ecADR names five exit criteria. It works as a quick yes/no test. Five "yes" answers mean the decision is done. **Justify well.** A good justification refers to the requirements and the information gathered. It also cites supporting evidence, criteria and agreement. Do not list fake alternatives just to satisfy a template. arc42 adds that all consequences belong in the record, not only the positive ones. **Decide with care.** One fallacy is assuming that what worked for others will work for you. The countermeasure is to make your requirements and context explicit. Some bias is unavoidable in big decisions, so blending in gut feeling is acceptable. **Involve people.** Plan stakeholder involvement ahead, at least a little. Otherwise it may be forgotten. At higher maturity levels, the ADR review process is documented and enforced, depending on the type of decision. Sharing decisions only pays off when people have architecting skills and experience. ## Example A team must pick how its web shop talks to a payment provider. The choice is external, costly to undo and affects reliability, so it passes the significance test and gets an ADR. The team waits until the requirements are clear enough, then checks its readiness criteria. It writes the justification with the requirements, evidence and the agreement of the people involved. It lists the downsides as well as the benefits. A short yes/no check confirms the decision is done. A minor choice, such as a button color, gets no ADR. ## Trade-offs Recording every decision costs effort and buries the important ones, so selection is needed. The significance test is only a rough guide, so judgment stays necessary. Gut feeling is acceptable, but it brings some bias. Higher maturity means documented and enforced reviews, which also asks for more skills and effort. ## Checks - The ADR log contains only architecturally significant decisions, those affecting structure, quality characteristics or important dependencies. - Each ADR justification refers to requirements, gathered information, evidence, criteria and agreement. - Alternatives listed in an ADR are real options, not filler added to satisfy a template. - Each ADR lists all consequences, not only the positive ones. - Stakeholder involvement in decisions is planned ahead. ## Related - [Architectural Decision Management Cycle](https://arc.fuet.ch/concepts/forces-decisions/architectural-decision-management-cycle.md) - [Architecturally Significant Decision](https://arc.fuet.ch/concepts/forces-decisions/architecturally-significant-decision.md) - [Architectural Decision Definition of Ready](https://arc.fuet.ch/concepts/forces-decisions/definition-of-ready-for-architectural-decisions.md) - [Definition of Done for Architectural Decisions](https://arc.fuet.ch/concepts/forces-decisions/definition-of-done-for-architectural-decisions.md) - [Architectural Decision Record](https://arc.fuet.ch/concepts/forces-decisions/architectural-decision-record.md) - [Last Responsible Moment](https://arc.fuet.ch/concepts/forces-decisions/last-responsible-moment.md) - [Architectural Decision Making Fallacies](https://arc.fuet.ch/concepts/forces-decisions/architectural-decision-making-fallacies.md) - [RACI Matrix](https://arc.fuet.ch/concepts/forces-decisions/raci-matrix.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 - [9 - Architecture decisions | arc42 Documentation](https://docs.arc42.org/section-9/) — docs.arc42.org, accessed 2026-11-09 - [A Definition of Done for Architectural Decision Making](https://ozimmer.ch/practices/2020/05/22/ADDefinitionOfDone.html) — ozimmer.ch, accessed 2026-11-09 - [Architectural Significance Criteria and Some Core Decisions Required](https://ozimmer.ch/practices/2020/09/24/ASRTestECSADecisions.html) — ozimmer.ch, accessed 2026-11-09 - [Seven Architectural Decision Making Fallacies (and Ways Around Them)](https://www.ozimmer.ch/practices/2025/09/01/ADMFallacies.html) — ozimmer.ch, accessed 2026-11-09 - [An Adoption Model for Architectural Decision Making and Capturing](https://www.ozimmer.ch/practices/2023/04/21/ADAdoptionModel.html) — ozimmer.ch, accessed 2026-11-09