methodatlas
Architecture

Request for Comments

Bereitet größere Änderungen mit Motivation, Lösung, Alternativen und offenen Fragen revisionsfest auf.

Kernfrage
Welche Änderung schlägt das Team vor, mit welcher Begründung, welchen Alternativen und welchen Tradeoffs, und wer entscheidet bis wann?
MittelAsync1-3 Wochen vom Draft bis zur Entscheidung
Runsheet öffnenSession planenVergleich starten
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.

Visuelle Orientierung

Methodenskizze für ein schnelles Grundgefühl.

Request for Comments · schriftlich prüfbar entscheidenKontext, Proposal, Trade-offs und Kommentare zu einem nachvollziehbaren Entscheidungsartefakt verbinden
Kontext -> Proposal -> Trade-offs -> CommentsEin Änderungsvorschlag wird schriftlich prüfbar, kommentierbar und entscheidungsfähig.Kontext bis EntscheidungEin Änderungsvorschlag wird schriftlich prüfbar, kommentierbar und entscheidungsfähig.schriftlich denkenReview vor CommitDecision LogKontextProblem, Motivation, ScopeProposalkonkreter LösungsvorschlagTrade-offsAlternativen und RisikenCommentsReview und offene FragenEntscheidungaccepted, revised oder rejected mit nachvollziehbarer Spur

Ablauf

  1. 1Problem und Kontext beschreiben
  2. 2Motivation und Ziele schärfen
  3. 3Lösungsvorschlag detaillieren
  4. 4Alternativen und Tradeoffs ausführen
  5. 5Offene Fragen und Risiken markieren
  6. 6Review-Runde mit Stakeholdern starten
  7. 7Kommentare einarbeiten und Status setzen
  8. 8Entscheidung dokumentieren und in ADR übersetzen

Das Runsheet führt mit 7 Phasen, Timeboxen, 6 Stolperfallen und klaren Abbruchkriterien durch die Umsetzung.

Runsheet öffnen

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

Vertiefung

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.

Output-Artefakte
RFC-DokumentReviewer-KommentareEntscheidung mit BegründungFolge-ADR oder Tickets
Tags
architecturedecisionasyncproposalgovernance

Quellen

Request for Comments - Wikipediaen.wikipedia.org
Artefakt-Vorlagen
Request for Comments ArbeitsvorlageKompakte Arbeitsvorlage für Request for Comments mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
markdown

rfc-working-template.md

Kompakte Arbeitsvorlage für Request for Comments mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.

Request for Comments Arbeitsvorlage

Ziel

Strukturiertes Vorschlagsdokument, das eine nicht-triviale Änderung beschreibt und gezielt Feedback einsammelt.

Kontext

Wann und wofür nutzen wir diese Methode?

Input

Welche Daten, Beobachtungen, Entscheidungen oder Materialien liegen vor?

Durchführung

Kurze Notizen entlang des Runsheets.

Ergebnisartefakte

  • RFC-Dokument:
  • Reviewer-Kommentare:
  • Entscheidung mit Begründung:
  • Folge-ADR oder Tickets:

Annahmen und offene Fragen

  • ...

Entscheidung / Nächster Schritt

Owner, Datum und Erfolgssignal.

Wann stattdessen?

Kurze Entscheidungshilfe für vorhandene Alternativen.

Architecture Decision Record

Statt Request for Comments, wenn eine einzelne Architekturentscheidung dokumentiert und später leicht wiederauffindbar sein soll.

Ähnliche Methoden

Alle Methoden
Architecture
Architecture Inception Canvas

Bündelt Problem, Ziele, Stakeholder und Risiken zu einem Startbild, das frühe Architekturfragen sortiert.

Architecture
Risk Storming

Sammelt Risiken direkt auf einem Architekturdiagramm und macht Priorität, Wirkung und nächste Schritte sichtbar.

Architecture
Architecture Decision Record

Dokumentiert eine Architekturentscheidung mit Kontext, Alternativen und Konsequenzen, damit spätere Reviews nachvollziehbar bleiben.

Statt Request for Comments, wenn eine einzelne Architekturentscheidung dokumentiert und später leicht wiederauffindbar sein soll.

Architecture
Quality Attribute Workshop

Sammelt Qualitätsziele, priorisiert Risiken und macht daraus Architekturthemen, die gemeinsam bewertet werden.

Architecture
Views and Beyond

Verbindet mehrere Sichten auf große Systeme und hält Cross-view-Informationen für das Gesamtbild fest.

Architecture
arc42

Strukturiert Architekturwissen über Ziele, Kontext, Laufzeit und Deployment zu einer lebendigen Systemdokumentation.