After some searching, I found this one
https://github.com/SouliCool/architecture_decision_record
https://github.com/SouliCool/architecture_decision_record/blob/main/Simple%20ADR.md

Which is nice and simple.

The "Simplest Template for ADRs"!

ADRs (Architectural Decisions Records) are a fantastic way to document, communicate, and rationalize significant design choices in software architecture. Here's a simple template to get you started:

Title

• What: A brief summary of the Architectural Decision

Context

• Why: The problem or need that prompted this decision
• Why not: Alternative approaches considered but rejected

Decision

• What: A clear and concise statement of the Architectural Decision
• Why: The reasoning and criteria that led to this decision

Consequences

• What: The expected outcomes and trade-offs of this decision
• Rationale: The assumptions and justifications that support the decision

History

• Date: When the decision was made
• Who: The individuals involved in the decision-making process

References

• Links to relevant documentation, such as design documents, meeting notes, or code repositories

Here's an example of how this template could be used:

Title

"The Choice of Microservices Architecture"

Context

In our e-commerce platform, we've identified a significant increase in traffic and sales. To improve scalability and maintainability, we must refactor our monolithic architecture to a microservices-based system.

• Alternative approaches considered but rejected: A full-scale rewrite of the entire application.

Decision

Based on the analysis of our performance issues, we decide to adopt a microservices architecture to improve scalability and maintainability.

Consequences

We expect this decision to:
+ Reduce the complexity of our codebase by decomposing the monolith into smaller, independent services.
+ Improve scalability by allowing us to horizontally scale individual services independently.
+ Enhance maintainability by providing a more granular, modular architecture.

We assume that this decision will not compromise the performance of our existing system during the transition period.

History

• Date: 2023-02-15
• Who: John Doe, Lead Developer; Jane Smith, Technical Architect

References

• Design Document: microservices-architecture.md (link to GitHub repository)
• Meeting Notes: 2023-02-10-design-meeting.md (link to GitHub repository)

By following this simple template, you'll be able to effectively document your ADRs and communicate them clearly to your team and stakeholders.

An Architectural Decision Record (ADR) is a document that captures an important architectural decision that has been made along with its context and consequences. The simplest template for recording an ADR should include the following key sections:

1. Title

A concise, descriptive name for the decision, often in the form of a question or a brief statement. For example: "Database Choice: SQL vs NoSQL".

2. Context

Provide background information that describes the situation leading to the decision. Include relevant details such as:

• The problem at hand
• The stakeholders involved
• Any constraints or requirements
• Alternatives considered

3. Decision

Clearly state the decision made. This section should be straightforward, summarizing the chosen approach or solution.

4. Consequences

Outline the implications of the decision, both positive and negative. Explain how the decision impacts the system and its stakeholders:

• Benefits
• Risks
• Trade-offs
• Any follow-up actions needed

5. Status

Indicate the status of the decision. Common statuses include:

• Proposed
• Accepted
• Rejected
• Deprecated

6. Date

Note the date when the decision was made.

7. Author

Identify who made the decision or who is recording it.

Simplified ADR Template Example

Title: Database Choice: SQL vs NoSQL

Context:
We need to select a database technology for our new web application. The application requires high scalability, flexibility to handle different data structures, and strong consistency for transactions. Stakeholders include project managers, developers, and operations teams. Constraints involve limited budget and a tight timeline.

Decision:
We have decided to use a NoSQL database (MongoDB) for its flexibility in handling various data structures and its scalability features.

Consequences:

• Positive:
  • Flexibility in data modeling
  • Easier to scale horizontally across multiple servers
• Negative:
  • Learning curve for developers not familiar with NoSQL
  • Potential issues with complex transactions and strong consistency requirements

Status: Accepted

Date: 2023-10-15

Author: Jane Doe

This simplest template ensures that important architectural decisions are well-documented and can be referenced in the future, promoting transparency and clarity within the development team and stakeholders.