Von unscharfem technischen Problem zu dokumentierter, nachvollziehbarer Architekturentscheidung.
Ein akzeptiertes ADR mit klarem Kontext, geprüften Optionen, Trade-offs und Folgeaktionen.
Du kannst entscheiden, welche Architektur-Option gewählt wird, welche Nachteile bewusst akzeptiert werden und wer die Umsetzung verantwortet.
Das ADR reviewen, im Architektur-Repository verankern und die Folgeaktionen in Backlog oder Roadmap überführen.
Sprechen alle Beteiligten über dieselbe Entscheidung, mit denselben Optionen, Kriterien und Rollen?
Der Einstieg klärt, welche Entscheidung wirklich ansteht, wer entscheidet und welche Evidenz für eine tragfähige Empfehlung gebraucht wird.
Der Decision Frame grenzt den Raum ein, in dem die Optionen anschließend vergleichbar ausgearbeitet werden.
Welche Handlungsoptionen sind wirklich vergleichbar, vollständig und entscheidungsreif?
Option Framing macht Lösungswege vergleichbar, ohne sie zu früh als Gewinner oder Verlierer zu behandeln.
Die strukturierten Optionen liefern die Grundlage für eine explizite Trade-off-Bewertung.
Welche Option akzeptiert welche Nachteile, und welcher Kompromiss passt am besten zu den Entscheidungskriterien?
Trade-off Analysis zeigt, welche Nachteile jede Option bewusst einkauft und welche Qualitätsziele davon betroffen sind.
Die akzeptierten Trade-offs werden anschließend in der Architekturentscheidung dokumentiert.
Welche Architekturentscheidung trifft das Team jetzt, vor welchen Alternativen, und welche Konsequenzen akzeptiert es dafür?
Das ADR hält Kontext, Entscheidung, Alternativen und Konsequenzen so fest, dass spätere Teams die Begründung nachvollziehen können.
Aus dem ADR entstehen konkrete Umsetzungsaufgaben, Review-Punkte und Kommunikationsbedarfe.
Die Artefakte bleiben zugeklappt, bis du sie wirklich brauchst.
Vorlage, um eine unklare Entscheidung in Frage, Rollen, Optionen und Evidenzbedarf zu übersetzen.
# Decision Frame: Thema
## Entscheidungsfrage
Welche Entscheidung muss jetzt getroffen werden?
## Kontext
Warum ist die Entscheidung nötig, was passiert ohne Entscheidung?
## Decider und Rollen
- Decider:
- Input:
- Reviewer:
- Informiert:
## Optionen
1. ...
2. ...
3. ...
## Kriterien
- ...
## Constraints
- ...
## Evidenzbedarf
Welche Daten, Tests oder Reviews fehlen noch?
## Nächster Schritt
Owner, Datum, Format.Einheitliche Beschreibung von Handlungsoptionen, damit sie fair vergleichbar werden.
# Option Frame: Optionstitel
## Kurzbeschreibung
Was ist die Option in einem Satz?
## Scope
Was ist enthalten, was ausdrücklich nicht?
## Nutzen
Welches Ziel unterstützt diese Option?
## Kosten und Aufwand
Welche Ressourcen, Laufzeit und Abhängigkeiten entstehen?
## Risiken
Welche negativen Folgen oder offenen Punkte bleiben?
## Annahmen
Welche Voraussetzungen müssen stimmen?
## Entscheidungssignal
Woran erkennen wir, dass diese Option bevorzugt werden sollte?Markdown-Matrix, um Optionen entlang konkurrierender Kriterien und akzeptierter Nachteile zu vergleichen.
# Trade-off Matrix: Entscheidung
| Kriterium | Gewicht | Option A | Option B | Option C |
|---|---:|---|---|---|
| Nutzen | 30 | | | |
| Kosten | 20 | | | |
| Risiko | 20 | | | |
| Time-to-Learn | 15 | | | |
| Reversibilität | 15 | | | |
## Akzeptierte Nachteile
- Option A akzeptiert:
- Option B akzeptiert:
- Option C akzeptiert:
## Empfehlung
Welche Option wird empfohlen und warum?
## Sensitivität
Welche kleine Änderung an Gewichtung oder Annahme würde die Empfehlung kippen?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:
- ...