Architecture-Decision-Record-Workshop

Typische Dauer:: 1h

Eine strukturierte Sitzung, in der das Team Architekturoptionen bewertet, eine Entscheidung trifft und sie als Architecture Decision Record (ADR) dokumentiert.

Zweck

Architekturentscheidungen sind teuer rückgängig zu machen und leicht zu vergessen. Dieser Workshop strukturiert den Entscheidungsprozess: Das Team bewertet Optionen gegen Kriterien, wählt die beste aus und hält die Begründung in einem ADR fest.

Auf einen Blick

Merkmal	Detail
Gruppengröße	3 – 8
Dauer	60 Minuten
Schwierigkeit	Mittel–Hoch
Moderationsstil	Moderierte Diskussion mit strukturierter Bewertung
Setting	Vor Ort oder Videocall mit geteiltem Dokument

Ablauf

Kontext darstellen (10 Min.) — Welche Architekturfrage muss beantwortet werden? Welche Kräfte und Constraints wirken?
Optionen auflisten (10 Min.) — Mögliche Ansätze brainstormen. Status quo als Option einbeziehen.
Bewertungskriterien definieren (5 Min.) — Was zählt am meisten? Performance, Wartbarkeit, Kosten, Team-Skills, Time-to-Market.
Optionen bewerten (20 Min.) — Pro Option Vor- und Nachteile gegen Kriterien diskutieren.
Entscheiden (5 Min.) — Konsens- oder Consent-basierte Entscheidung.
ADR schreiben (10 Min.) — Festhalten: Titel, Status, Kontext, Entscheidung, Konsequenzen. Im Repository neben dem Code speichern.

Material

ADR-Template (Titel, Status, Kontext, Entscheidung, Konsequenzen)
Entscheidungsmatrix-Template
Whiteboard oder geteiltes Dokument
Architekturdiagramme für den Kontext

Stolperfallen & häufige Fehler

Kein schriftlicher Record — Mündliche Entscheidungen werden vergessen. Immer ADR schreiben.
Analyse-Paralyse — Bewertung timeboxen. Eine ausreichend gute Entscheidung jetzt schlagt eine perfekte später.
Nicht überarbeiten — ADRs als abgelöst markieren, wenn sich die Entscheidung ändert.

Inklusion & Barrierefreiheit

Kontext und Optionen vorab teilen.
Entscheidungsmatrizen für transparente Bewertung nutzen.
Schriftliche Beiträge ermöglichen.

Varianten

Lightweight ADR — Ein-Absatz-Record für kleine Entscheidungen.
MADR-Format — Markdown Architectural Decision Records im Git-Repository.
Spikes vor ADR — Timeboxte Spikes zur Datenbeschaffung vor dem Entscheidungsworkshop.

Wann NICHT einsetzen

Für triviale, leicht reversible Entscheidungen.
Wenn die Architektur durch Policy vorgegeben ist.

Quelle & Weiterlesen

Nygard, M. (2011). „Documenting Architecture Decisions.“ cognitect.com
Keeling, M. (2017). *Design It!* Pragmatic Bookshelf.

Aus den Bausteinen eine Agenda machen

Leg den Tag an, zieh die Blöcke in die Reihenfolge, die dir vorschwebt, und lass die Zeiten sich selbst ausrechnen. Oder beschreib deiner KI, was du vorhast, und lass sie den ersten Entwurf schreiben.

14 Tage kostenlos testen