> Ensures that [[Decision making|decisions]] are made **transparently** and systematically and **can be reviewed** during the life cycle of the software ^definition --- ## [[Impact-oriented decision making]] Bridge the gap by documenting technical decisions in a way that business stakeholders can understand ![[Impact-oriented decision making#^parts|The Ws of Impact-oriented decision making]] ## Problems without ADRs Decisions made by previous teams or architects may be forgotten, leading to repeated discussions or redundant work. - [[Knowledge management]] - [[Decisions and Single source of truth]] - [[Team collaboration]] - [[Decisions and Onboarding]] - [[Decisions and Tribal knowledge]] - [[Decisions and Impact on other teams]] - [[Decisions and Process quality]] - [[Tech debt]] accumulation - [[Decisions and Change and Refactorization]] ## Templates - https://github.com/joelparkerhenderson/architecture-decision-record?tab=readme-ov-file#adr-example-templates ## Practices Decompose decisions if needed > Break one decision into multiple if an architectural decision is going to result in multiple phases, such as short-term, mid-term, long-term approaches. Log each phase as its own decision record. #todo works in similar manner as [[User Story Splitting]]