An architecture decision record (ADR) is a document which provide an important architectural decision records along with its context and consequences.

Scope of the ADR process

Project members should create an ADR for every architecturally significant decision that affects the software project or product, including the following:

• Structure (for example, patterns such as microservices)
• Non-functional requirements (security, high availability, and fault tolerance)
• Dependencies (coupling of components)
• Interfaces (APIs and published contracts)
• Construction techniques (libraries, frameworks, tools, and processes)
• Functional and non-functional requirements are the most common inputs to the ADR process.

What are the outcomes of ADRs target business:

• They align current and future team members.
• They set a strategic direction for the project or product.
• They avoid decision anti-patterns by defining a process to properly document and communicate architectural decisions.

How ADRs can help stakeholders to take the decision to inform future:

• A collection of ADRs provide a hand-over experience and reference documentation.
•  Team or project members use the ADR collection for follow-up projects and product feature planning.
•  Being able to reference ADRs reduces the time required during development, reviews, and architectural decisions.
•  ADRs also allow other teams to learn from, and gain insights into, considerations made by other project and product development teams.