Ein ADR hält eine Architekturentscheidung mit Kontext, Abwägung und Konsequenz dauerhaft fest. Es schafft Anschlussfähigkeit für spätere Änderungen, weil der Entscheidungsweg nachvollziehbar bleibt.
Architecture Decision Record
Dokumentiert eine Architekturentscheidung mit Kontext, Alternativen und Konsequenzen, damit spätere Reviews nachvollziehbar bleiben.
Welche Architekturentscheidung trifft das Team jetzt, vor welchen Alternativen, und welche Konsequenzen akzeptiert es dafür?
Zuerst werden Problem, Ziele und Rahmenbedingungen präzise beschrieben. Danach dokumentiert das Team die Optionen, die gewählte Lösung und die wichtigsten Tradeoffs. Abschließend wird der Eintrag mit Datum, Status und Verweis auf Folgearbeit versioniert.
Visuelle Orientierung
Methodenskizze für ein schnelles Grundgefühl.
Ablauf
- 1Entscheidung benennen
- 2Kontext beschreiben
- 3Optionen erfassen
- 4Entscheidung dokumentieren
- 5Konsequenzen festhalten
Das Runsheet führt mit 7 Phasen, Timeboxen, 7 Stolperfallen und klaren Abbruchkriterien durch die Umsetzung.
Runsheet öffnenIdeal für
- Architecture Governance
- Team Memory
- High-Change-Codebases
Nicht gut für
- Triviale Entscheidungen
- Lange Spezifikationen
Vertiefung
Ein ADR wirkt, weil Architekturentscheidungen dadurch nicht nur festgehalten, sondern mitsamt Kontext und Folgen später wieder lesbar werden. Gute Nutzung dokumentiert die eigentliche Spannung zwischen Optionen und benennt die Tragweite der gewählten Richtung offen. So verhindert das Format, dass Teams Monate später nur noch das Ergebnis kennen, aber weder Anlass noch bewusste Tradeoffs nachvollziehen können.
Sammle vor dem Schreiben die echte Entscheidungsfrage, die wichtigsten Alternativen und die Qualitätsziele, die unter Spannung stehen. Seinen Wert zeigt das Format genau dort, wo die gewählte Option eine klare Konsequenz für Betrieb, Entwicklung oder Kopplung bekommt. Schließe mit präzisem Status, klarer Begründung und einem Verweis darauf, wann eine Revision fällig wäre.
ADR Markdown TemplateKompakte Vorlage für Architecture Decision Records im Repository oder Wiki.markdown
adr-markdown.md
Kompakte Vorlage für Architecture Decision Records im Repository oder Wiki.
ADR-0001: Titel der Entscheidung
Status: proposed Datum: YYYY-MM-DD Decider: Vorname Nachname Trigger: Ticket, Incident oder RFC
Kontext
Welche Situation macht die Entscheidung nötig? Welche Constraints, Quality Attributes oder früheren Entscheidungen sind relevant?
Optionen
Option 1: ...
- Pro:
- Contra:
Option 2: ...
- Pro:
- Contra:
Entscheidung
Wir entscheiden uns für ...
Konsequenzen
Positive Folgen:
- ...
Negative Folgen und Risiken:
- ...
Folge-ADRs oder Tickets:
- ...
Wann stattdessen?
Kurze Entscheidungshilfe für vorhandene Alternativen.
Statt Architecture Decision Record, wenn du die ersten Architekturfragen in einer knappen Startfolie bündeln willst.
Ähnliche Methoden
Alle MethodenVerbindet mehrere Sichten auf große Systeme und hält Cross-view-Informationen für das Gesamtbild fest.
Strukturiert Architekturwissen über Ziele, Kontext, Laufzeit und Deployment zu einer lebendigen Systemdokumentation.
Bereitet größere Änderungen mit Motivation, Lösung, Alternativen und offenen Fragen revisionsfest auf.
Bündelt Problem, Ziele, Stakeholder und Risiken zu einem Startbild, das frühe Architekturfragen sortiert.
Statt Architecture Decision Record, wenn du die ersten Architekturfragen in einer knappen Startfolie bündeln willst.
Macht System, Container und Bausteine in abgestuften Sichten lesbar und erleichtert Architekturkommunikation.
Sammelt Risiken direkt auf einem Architekturdiagramm und macht Priorität, Wirkung und nächste Schritte sichtbar.