Ein Architecture Decision Record dokumentiert eine wichtige technische Entscheidung kompakt: welches Problem bestand, welche Optionen betrachtet wurden, was entschieden wurde und welche Konsequenzen daraus entstehen.
1. Titel und Status
Ein kurzer Titel benennt die Entscheidung, zum Beispiel „ADR-007: PostgreSQL als primäre Datenbank“. Zusätzlich sollte der Status klar sein: vorgeschlagen, akzeptiert, ersetzt oder verworfen.
2. Kontext beschreiben
Welche technische oder fachliche Situation macht eine Entscheidung notwendig? Relevante Randbedingungen, Qualitätsziele und Einschränkungen gehören hier hinein.
3. Entscheidung festhalten
Die gewählte Lösung präzise und ohne unnötige Historie beschreiben. Der Abschnitt sollte auch allein gelesen verständlich sein.
4. Alternativen nennen
Welche realistischen Alternativen wurden betrachtet? Ein bis drei ernsthafte Optionen reichen meist. Wichtig ist, warum sie im konkreten Kontext nicht gewählt wurden.
5. Konsequenzen dokumentieren
Welche positiven und negativen Folgen entstehen? Dazu können Wartungsaufwand, Kosten, Performance, Abhängigkeiten, Lernaufwand oder Betriebsrisiken gehören.
6. Entscheidung nicht nachträglich umschreiben
Wenn sich die Architektur später ändert, sollte ein neuer ADR den alten ersetzen oder ablösen. So bleibt nachvollziehbar, warum eine frühere Entscheidung zu ihrer Zeit sinnvoll war.
7. Kompakte ADR-Vorlage
Titel: ADR-XXX – …
Status: vorgeschlagen / akzeptiert / ersetzt
Datum: …
Kontext: …
Entscheidung: …
Alternativen: …
Konsequenzen: …