Architecture Entscheidungsmethode

Request for Comments

Dokumentiert einen technischen Vorschlag so, dass Betroffene ihn asynchron prüfen, entscheiden und später nachvollziehen können.

Ein interner RFC übernimmt die Idee offener technischer Diskussion, ist aber kein IETF-Standardprozess. Problem, Kontext, Ziele, Nicht-Ziele, Design, Alternativen, Risiken, Migration und Decision Log werden lokal verbindlich definiert.

Kernfrage

Ist der Vorschlag mit Alternativen, Folgen und Migrationsweg entscheidungsreif?

Request for Comments (RFC) planen Methodenanleitung

Vergleich starten

Feedback gebenHilft dir diese Methode?

Teilnehmende: 3-20 Reviewer
Zeit: 1-3 Wochen vom Draft bis zur Entscheidung

Request for Comments (RFC) verwendet versionierter Vorschlag mit offener Reviewfrist, adressierten Kommentaren und explizitem Status. Bewertungen bleiben begründet und kontextgebunden.

Papierillustration von Request for Comments (RFC) mit dem methodenspezifischen Arbeitsmodell.

Draft
Draft
Problem, Ziele, Nicht-Ziele, Proposal, Alternativen und Migration schreiben.
Review
Review
Betroffene Reviewer mit Frist einladen und Kommentare sammeln.
Decision
Decision
Kommentare adressieren und Decision Owner mit Begründung entscheiden lassen.
Lifecycle
Lifecycle
Implementierung, Abweichungen und Supersession separat nachhalten.

Nach neuer Evidenz oder einer relevanten Kontextänderung aktualisieren und frühere Fassung erhalten.

Geeignet, wenn

Für reversible oder weitreichende technische Entscheidungen mit mehreren betroffenen Teams.

Ideal für

Größere Architektur- oder Produktänderungen
Verteilte Teams mit hohem Async-Anteil
Technische Standards und Plattform-Entscheidungen
Cross-Team-Initiativen mit vielen Stakeholdern

Nicht gut für

Triviale Refactorings
Sehr kleine, lokale Entscheidungen
Themen ohne klaren Entscheidungsbedarf
Zeitkritische Hotfixes

Ergebnisse

RFC Record
RFC Record mit nachvollziehbaren Quellen, Annahmen und fachlichen Entscheidungen.
Entscheidungs- und Prüfspur
Owner, Termine und nächste Prüfung für RFC Record.

RFC Record

Fiktives Arbeitsbeispiel

versionierter Vorschlag mit offener Reviewfrist, adressierten Kommentaren und explizitem Status als präzise Arbeitsstruktur mit fiktivem Beispiel.

Problem/Goals

Festzuhaltende Problem/Goals-Angaben

Schema Evolution; kein neuer Broker.

Proposal/Alternatives

Festzuhaltende Proposal/Alternatives-Angaben

CloudEvents+JSON Schema vs. Avro.

Review/Decision

Festzuhaltende Review/Decision-Angaben

Security-Einwand beantwortet; Accepted.

Migration/Status

Festzuhaltende Migration/Status-Angaben

30 Tage Dual Publish; Implementing separat.

Das Beispiel zeigt die Fachlogik von Request for Comments (RFC); eigene Vorlagen bleiben leer.

IETF RFC 2026: The Internet Standards Process

Erster Schritt

Beginne mit der Kernfrage: Ist der Vorschlag mit Alternativen, Folgen und Migrationsweg entscheidungsreif?

Zur Methodenanleitung

Davor sinnvoll

Architecture

Quality Attribute Workshop

Liefert priorisierte Architekturthemen, zu denen ein RFC einen Lösungsvorschlag macht.

Wie geht es weiter?

Papierillustration mit zwei betrachteten Optionen, die zu einem Entscheidungsdokument mit markiertem Status und sichtbaren Konsequenzen führen.

Architecture

Architecture Decision Record

Verankert die im RFC akzeptierte Entscheidung als dauerhaften Architekturentscheid.

Delivery

Communication Plan

Kommuniziert die akzeptierte Änderung an betroffene Teams und Reviewer.

Vertiefung

Zweck

Ein RFC hält größere Architektur- oder Produktänderungen als prüfbaren Vorschlag fest. Die Methode schafft einen transparenten Weg von Motivation über Alternativen bis zur Entscheidung.

Funktionsweise

Zuerst beschreibt das Team Problem, Ziel und Lösungsvorschlag. Dann folgen Alternativen, Tradeoffs und offene Fragen im Review. Abschließend wird der Status gesetzt und eine angenommene Entscheidung bei Bedarf in ein ADR überführt.

Im Detail

Ein RFC funktioniert, weil größere Änderungen erst dann gut diskutierbar werden, wenn Motivation, Lösungsidee, Alternativen und offene Fragen gemeinsam lesbar sind. Gute Nutzung behandelt Kommentare nicht als formale Freigabe, sondern als echte Schärfung der vorgeschlagenen Richtung. Der Wert liegt darin, dass Entscheidungen in einem größeren Kreis geprüft werden können, ohne dass das Gespräch in verstreuten Chats oder Meetings zerfällt.

Durchführung

Fasse den Anlass so zusammen, dass Lesende sofort verstehen, warum jetzt eine Richtungsentscheidung nötig ist. Prägend wird die Diskussion, wenn Einwände nicht nur Ablehnung zeigen, sondern die Begründung oder den Scope verbessern. Schließe mit sichtbarem Status, klarer Antwort auf die Kernfrage und einem Anschlussweg für Umsetzung oder ADR Übernahme.

Die Methodenanleitung führt mit 4 Phasen, Zeitrahmen, 4 Stolperfallen und klaren Abbruchkriterien durch die Umsetzung.

Methodenanleitung öffnen

Deine Einschätzung

Hilft dir diese Methode für dein Vorhaben?

Mit deinem Feedback hilfst du, den Methodatlas weiterzuentwickeln.

Quellen und Themen

Themen

Architektur Entscheidung Asynchron Governance

Quellen

IETF RFC 2026: The Internet Standards Processrfc-editor.orgRFC Editor im Auftrag des IAB; definiert den IETF-Standardisierungsprozess mit Reifegraden und Dokumenttypen.

In Playbooks

Architekturqualität vor Umsetzung absichernVon den Leitplanken einer Architekturinitiative über priorisierte Qualitätsszenarien zu einer zur Diskussion gestellten Lösung.

Artefakt-Vorlagen

Request for Comments: ArbeitsvorlagePlane Request for Comments (RFC) entlang der fachlichen Schritte und der konkreten Entscheidungsfrage.

markdown

rfc-working-template.md

Plane Request for Comments (RFC) entlang der fachlichen Schritte und der konkreten Entscheidungsfrage.

Request for Comments: Arbeitsvorlage

Fragestellung

Noch zu klären

Gewünschtes Ergebnis

Noch zu klären

Rahmen

Praxis einrichten und überprüfen Zeit: 2–10 Arbeitstage je Tragweite

Diese Vorlage während der Arbeit auf Papier oder in einem eigenen Dokument ausfüllen.

Vorbereitung für diesen Umfang

Methodische Grundausstattung

Materialien: Problem und Constraints, Designentwurf und Alternativen, Reviewer und Decision Owner, gemeinsame Arbeitsfläche, Quellenlinks und Entscheidungslog.
Rollen: Author · Reviewers · Decision Owner · affected implementers
Vorab-Infos: Problem und Constraints, Designentwurf und Alternativen, Reviewer und Decision Owner vorab zusammentragen und offene Annahmen markieren.
Gesamter Zeitbedarf: 2–10 Arbeitstage je Tragweite
Setup: versionierter Vorschlag mit offener Reviewfrist, adressierten Kommentaren und explizitem Status sichtbar vorbereiten und Bewertungsbegriffe vor Beginn kalibrieren.