Architecture Decision Template: https://www.fabian-kleiser.de/blog/documenting-architecture-decisions

AD-XX-template.md

AD-XX: <TOPIC - short, concise summary>

• Date: <DATE - when the decision was made>
• Driver: <DRIVER - list a single person driving consenus and decision making>
• Stakeholders: <STAKEHOLDERS - list all relevant stakeholders affected by this decision>
• Status: [PROPOSED | DECIDED | SUPERSEDED]
• Categories: <CATEGORIES - use a simple grouping to help organize the set of decisions (e.g. backend, payment, user management, ...)>
• Outcome: <OUTCOME - once decided, provide a short summary of the decision outcome here>

Context

Briefly describe the background information required to understand the problem of the decision being made. Try to answer:

• Are there any assumptions for this decision? (think about: cost, schedule, technology, other projects ...)
• Are there any constraints for this decision? (think about: accepted technology standards, common patterns, ...)

Related

If you have related decisions, requirements, documents or guidelines that affect this decision, link them here. When linking another document, also add one sentence describing why the linked document influences this decision. If there are no related documents, remove this section.

Alternatives

Alternative X

Briefly describe alternative 1 and then list arguments in favor for and against alternative X. You may also list harsh numbers, figures, charts, or anything that helps your future self to understand the decision's motivation.

Pros:

• You may list advantages using bullet points that speak for this alternative.

Cons:

• Oftentimes, you find that pros of one alternative are cons to another. In this case you can also reference another "all the pros of alternative Y are cons here", or you can add some additional context on why these are actually cons.

Decision

The decision was made in favor for alternative X.

After stating the decision, briefly explain the motivation that led to choosing the alternative (e.g., by stating which arguments were most important to the team).

Consequences

Mention the consequences the decision has on the project.

Oh, wow, this is very close to our MADR template. Maybe, we should think of joining forces? MADR seems to be the very lean alternative, whereas yours is more the verbose one... Currently, we skip the whole meta data such as Date, Deciders, Status, Category.