It should be as easy as possible to a) write down the decisions and b) to version the decisions.
Here's an example of an Architectural Decision Record (In Markdown format) for deciding to adopt Architectural Decision Records.
# Use Markdown Architectural Decision Records ## Context and Problem Statement We want to record architectural decisions made in this project. Which format and structure should these records follow? ## Considered Options * [MADR](https://adr.github.io/madr/) 2.1.2 – The Markdown Architectural Decision Records * [Michael Nygard's template](http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions) – The first incarnation of the term "ADR" * [Sustainable Architectural Decisions](https://www.infoq.com/articles/sustainable-architectural-design-decisions) – The Y-Statements * Other templates listed at <https://github.com/joelparkerhenderson/architecture_decision_record> * Formless – No conventions for file format and structure ## Decision Outcome Chosen option: "MADR 2.1.2", because * Implicit assumptions should be made explicit. Design documentation is important to enable people understanding the decisions later on. See also [A rational design process: How and why to fake it](https://doi.org/10.1109/TSE.1986.6312940). * The MADR format is lean and fits our development style. * The MADR structure is comprehensible and facilitates usage & maintenance. * The MADR project is vivid. * Version 2.1.2 is the latest one available when starting to document ADRs.
We use this practice to:
Have a look at some of the available templates and start reading about them. You can choose to use one of the ones linked below or create your own adaptation of the template in a format which works for your team and your organization.
Check out these great links which can help you dive a little deeper into running the Architectural Decision Records (ADR) practice with your team, customers or stakeholders.