Decisions that are hard to make and / or costly to change.
Software architecture is those decisions which are both important and hard to change.
Needed to fulfill quality criteria.
High business value and / or technical risk.
I don't know why we do it, but i accept the decision. Maybe it was smart, i can't evaluate. Maybe not. I don't know
I don't know why we do it, but i want to change it. I don't understand motivation, circumstances and consequences, and maybe i damage the project.
Alternative A best meets user expectations and functional requirements as documented in user stories, use cases, and the business process model.
End users want it, but no evidence exists of a pressing business need.
A short name for the Decision and the document, including the identifier, and the problem targeted
ADR 1: Deployment on Ruby on Rails 3.0.10
or
ADR 9: LDAP for Multitenant Integration
Why we need this decision, the context and the problem that we want to solve.
We want to record architectural decisions made in this project. Which format and structure should these records follow?
The drivers and forces behind the decision - technical, social, political, legal and project local. Most of the time they are competing.
Clearly state the architecture's direction - that is, the position you've selected.
We will use Github Enterprise.
Describe what alternative options that would have made sense you had a look at, too.
The justification why this option is the chosen one - why is this the right decision, and not any other option.
Make the shortcomings and negative consequences of the decision visible and known.
What is the status, such as proposed, accepted, rejected, deprecated, superseded, etc.?
What is the issue that we're seeing that is motivating this decision or change?
What is the change that we're proposing and/or doing?
What becomes easier or more difficult to do because of this change?
Since ADRs are text, we could ...