Architektur-Rationale sichern und wiederkehrende Debatten reduzieren.
Architecture Decision Record
Kurzer Record für eine wichtige Architekturentscheidung, Kontext, Optionen und Konsequenzen.
Eine Entscheidung wird als versioniertes Dokument nahe am Code mit Status, Kontext und Folgen abgelegt.
Visuelle Orientierung
Konkretes Schema mit deutschen Bezeichnungen.
Ablauf
- 1Entscheidung benennen
- 2Kontext beschreiben
- 3Optionen erfassen
- 4Entscheidung dokumentieren
- 5Konsequenzen festhalten
Ideal für
- Architecture Governance
- Team Memory
- High-Change-Codebases
Nicht gut für
- Triviale Entscheidungen
- Lange Spezifikationen
Vertiefung
Architecture Decision Record folgt einer klaren Arbeitslogik: Entscheidung benennen, Kontext beschreiben, Optionen erfassen, Entscheidung dokumentieren und Konsequenzen festhalten. Dadurch wird die Methode nicht nur als Gespräch geführt, sondern als sichtbarer Denkprozess aufgebaut. Die Beteiligten bewegen sich schrittweise von Rohmaterial, Beobachtungen oder Optionen zu einer gemeinsamen Struktur. Als Ergebnis entstehen ADR File, Decision Log und Rationale, die Entscheidungen, Lernen oder weitere Planung anschlussfähig machen.
Architecture Decision Record eignet sich besonders für Architecture Governance, Team Memory und High-Change-Codebases. Die Methode unterstützt Arbeit rund um architecture, rationale und documentation und hilft, implizite Annahmen explizit zu machen. Vorsicht ist in Kontexten wie Triviale Entscheidungen und Lange Spezifikationen geboten; dann sollte vorher geklärt werden, ob genug Kontext, Beteiligung und Entscheidungsspielraum vorhanden sind.
Bereite eine klare Leitfrage, die passenden Informationen und eine sichtbare Arbeitsfläche vor. Plane etwa 15-45 min mit 1-3 Personen und nutze das Format asynchron. Die Durchführung bleibt leichtgewichtig; hilfreich sind kurze Timeboxes, sichtbare Zwischenergebnisse und ein Parkplatz für offene Fragen.
Quellen
ADR Markdown TemplateKompakte Vorlage für Architecture Decision Records im Repository oder Wiki.markdown
# 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:
- ...Ähnliche Methoden
Alle MethodenDokumentiert Architektur über stakeholderrelevante Views plus Cross-view-Information.
Pragmatisches Template für strukturierte, lebendige Softwarearchitektur-Dokumentation.
Strukturiertes Vorschlagsdokument, das eine nicht-triviale Änderung beschreibt und gezielt Feedback einsammelt.
Leichter Canvas für frühe Architekturausrichtung über Ziele, Constraints, Risiken und Systemform.
Diagramm-Hierarchie für Context, Container, Component und Code.
Kollaborative Risiko-Identifikation direkt am Architektur- oder Plan-Artefakt.