Design-PatternInfrastructureTechnical Excellence

Architecture Decision Records

Architektur-Entscheidungen werden dokumentiert – Kontext bleibt erhalten.

infrastructurearchitekturdokumentation

Typ

Design-Pattern

Cluster

Infrastructure

Sichtbarkeit

PUBLIC

Status

PUBLISHED

Beschreibung

Architecture Decision Records (ADRs) sind kurze Dokumente, die architektonische Entscheidungen festhalten: Kontext, Entscheidung, Begründung, Konsequenzen. Sie werden versioniert und mit Code abgelegt.

Das Pattern macht Architektur nachvollziehbar. Neue Teammitglieder verstehen, warum Dinge so sind. Entscheidungen können später im Kontext bewertet werden. Architektur wird lernfähig.

Framework-Struktur

B.U.I.L.D.

B - Backdrop

Architektur-Entscheidungen gehen verloren. Kontext verblasst. Neue Teammitglieder verstehen Entscheidungen nicht. Dieselben Diskussionen wiederholen sich.

B.U.I.L.D.

U - Underlying Shift

Von implizitem zu explizitem Architektur-Wissen: Entscheidungen werden dokumentiert statt nur getroffen.

B.U.I.L.D.

I - Implementation

ADR-Template definieren (Kontext, Entscheidung, Begründung, Konsequenzen). ADRs in Versionskontrolle ablegen. Bei architektonischen Entscheidungen ADR schreiben. In Onboarding nutzen.

B.U.I.L.D.

L - Leverage

Bessere Nachvollziehbarkeit, schnelleres Onboarding, weniger wiederholte Diskussionen, lernfähigere Architektur.

B.U.I.L.D.

D - Development

Template erstellen. Bei nächsten Architektur-Entscheidungen anwenden. Sammlung aufbauen. In Entwicklungsprozess integrieren.

Use Cases, Stories & Hinweise

Anwendung: Bei Software-Entwicklung, IT-Architektur, Plattform-Design, Technologie-Entscheidungen.

Praxisbeispiel: Team entscheidet sich für Microservices statt Monolith. ADR dokumentiert: Kontext (Skalierungsanforderungen), Entscheidung (Microservices), Begründung (Team-Autonomie, unabhängige Skalierung), Konsequenzen (höhere Komplexität, bessere Skalierbarkeit).