Von Mariami Minadze

Project Manager

Ansichten: 9

Partager l’article

In einem IT-Projekt hat jede technische Entscheidung Auswirkungen auf den zukünftigen Kurs des Unternehmens, manchmal über Jahre hinweg. Doch häufig entstehen diese Beschlüsse aus informellen Diskussionen, Zeitdruck oder nicht dokumentierten Routinen und führen zu technischer Verschuldung und internen Unstimmigkeiten.

Aus der Open-Source-Welt kommend und im Zentrum der Entwicklung des Internets entstanden, erweist sich diese Praxis als kraftvoller Hebel, um technische Governance zu strukturieren und eine nachhaltige Umsetzung zu beschleunigen.

Warum Sie technische Entscheidungen mit RFCs strukturieren sollten

RFCs bieten einen schlanken, kollaborativen Rahmen, um jede Entscheidung vor ihrer Implementierung zu dokumentieren. Sie beleuchten den Kontext, die Optionen, die Kompromisse und die geschäftlichen Auswirkungen.

Ursprünglich dienten RFCs dazu, die grundlegenden Protokolle des Internets festzulegen, indem die Community eingeladen wurde, die Spezifikationen zu kommentieren und zu erweitern. Übertragen auf Unternehmens­softwareprojekte verhindern sie, dass entscheidende Beschlüsse übereilt gefällt werden und später einer nachträglichen Analyse entgehen.

Ein standardisiertes Format deckt systematisch das Problem, die Alternativen, die Risiken und die langfristige Vision ab. Diese frühzeitige Transparenz senkt die Änderungskosten, indem sie die Diskussion auf einen Zeitpunkt lenkt, an dem sie am günstigsten ist.

Darüber hinaus erleichtern RFCs die Abstimmung zwischen IT-Abteilung, Fachbereichen und externen Partnern. Jeder Beteiligte verfügt über eine gemeinsame Referenz, um nachzuvollziehen, warum ein bestimmtes Framework, eine Architektur oder ein Tool gewählt wurde.

Herkunft und Grundprinzipien

RFCs entstanden in den 1960er-Jahren, um die TCP/IP-Protokolle zu formalisieren, und ebneten den Weg für eine dezentrale und transparente Governance des Internets. Ihr zentrales Prinzip ist einfach: Jede technische Vorschlag wird in einem öffentlichen, kommentierbaren Dokument festgehalten.

Im Unternehmenskontext bleibt der kollaborative Geist erhalten, während der Rahmen definiert wird: Ein Autor verfasst die RFC, benannte Reviewer (Architekten, Projektleiter, Fachverantwortliche) liefern Feedback, und schließlich erfolgt eine Entscheidung gemäß einer vordefinierten Governance.

Dieser Prozess zielt nicht auf Bürokratie ab, sondern auf die Strukturierung des Informations­austauschs. Die Rückmeldungen konzentrieren sich auf sachliche Aspekte: Integrationskosten, Wartbarkeit, Kompatibilität, Sicherheit und Übereinstimmung mit der IT-Strategie.

Struktur und typische Inhalte einer RFC

Eine RFC umfasst in der Regel: eine Einleitung mit Problem­darstellung, geschäftlichem Kontext und Rahmenbedingungen, eine Liste möglicher Optionen mit deren Vor- und Nachteilen, einen Abschnitt zu den Auswirkungen (technisch, organisatorisch, finanziell) und eine Empfehlung oder einen Umsetzungsplan.

Die Klarheit des Dokuments beruht auf standardisierten Abschnitten: Ziele, Umfang, beteiligte Stakeholder, Abhängigkeiten, Risiken und Migrationsplan. Diese Struktur stellt sicher, dass kein kritischer Aspekt übersehen wird.

Um die Erstellung zu beschleunigen, kann man auf eine Vorlage in Confluence oder ein internes Git-Repository zurückgreifen. Entscheidend ist eine verständliche Sprache für ein breites Publikum: Architekten, Entwickler, Fachverantwortliche und Führungskräfte.

Vorteile für Zusammenarbeit und Transparenz

agilen Projektmanagements basieren RFCs auf den Prinzipien des agilen Projektmanagements.

Die persistente Dokumentation bildet ein gemeinsames Referenzsystem, das das Verständnis vergangener Entscheidungen erleichtert und die Koordination zukünftiger Änderungen unterstützt. Zudem dient es als Wissensspeicher für neue Teammitglieder.

Am Ende reduzieren sich Überarbeitungszyklen und kostspielige Rückschritte. Die Organisation gewinnt an Reaktions­fähigkeit, weil alle wissen, auf welche Vorgaben sie sich bei neuen technischen Fragestellungen beziehen müssen.

Beispiel: Eine Finanzinstitution hat RFCs bei der Auswahl ihrer Integrationsmiddleware eingeführt. Anhand von zehn Vorschlägen wurden unterschiedliche ESB-Architekturen und Microservices gegeneinander abgewogen, regulatorische Vorgaben und Daten­volumina dokumentiert. Der Prozess zeigte, dass die oft als zu ambitioniert bewertete Microservices-Option letztlich die bessere Skalierbarkeit und geringere Lizenzkosten bot und so die Robustheit des IT-Systems bereits in der Designphase stärkte.

Entscheidungsprozesse über Abteilungsgrenzen hinweg vereinfachen

RFCs bringen alle Stakeholder auf Grundlage objektiver Kriterien und einer gemeinsamen Roadmap zusammen. Sie formalisieren den Rahmen und stärken die Governance, ohne die Agilität zu verlieren.

In vielen Organisationen führt eine verstreute Entscheidungsfindung zu Silos: IT auf der einen, Fachbereiche auf der anderen Seite, externe Partner oft außen vor. RFCs schaffen einen Konvergenzpunkt, an dem alle Experten ihr Wissen einbringen, bevor die Umsetzung beginnt.

Die Effektivität einer RFC hängt stark von der sie umgebenden Governance ab: Rolle des Sponsors, Prüfungskomitee, Schlichtungsmechanismen und Validierungsfristen. Ein klarer Prozess verhindert, dass das Dokument zu einem Gegenstand endloser Debatten oder zu „Design by Committee“ wird.

Schließlich stärken Tracking-Tools (Tickets, CI-Pipelines, Dashboards) die Nachverfolgbarkeit der Diskussionen und stellen sicher, dass jedes Feedback erfasst, bearbeitet oder formell verworfen wird.

Einbindung der Stakeholder

Eine der Stärken von RFCs ist die direkte Beteiligung der Fachbereiche am technischen Prozess. Bereits bei der Erstellung definiert der Fachsponsor Erfolgsindikatoren und operationelle Risiken, die berücksichtigt werden müssen.

Architekten und Entwickler beschreiben die technischen Randbedingungen, während die IT-Abteilung den Governance-Rahmen festlegt (Compliance, Sicherheit, Budget). Jeder bearbeitet die Abschnitte, die ihn betreffen.

Dieser abteilungsübergreifende Ansatz verhindert „Projekte in abgeschotteten Gruppen“ und minimiert Widerstände in der Implementierungsphase. Einwände werden frühzeitig geklärt, Rückschritte und Interessenskonflikte reduziert.

Governance-Rahmen und schnelle Validierung

Damit eine RFC nicht zu Verzögerungen führt, müssen zwei Prinzipien festgelegt werden: Vollständigkeitskriterien (auszufüllende Abschnitte) und Entscheidungs­schwellen (Reviewer-Quorum, maximale Feedback-Fristen).

Ein agiles Validierungs­komitee, bestehend aus bis zu fünf Schlüsselpersonen, kann blockierende Punkte zügig schlichten. Nach dieser Phase dürfen nur noch schwerwiegende sachliche Einwände eine neue Version auslösen.

Diese prozessorientierte Disziplin stellt sicher, dass die RFC ein Entscheidungs­hilfsmittel bleibt und keine bürokratische Hürde darstellt. Sie bewahrt individuelle Verantwortung und kontrollierte Autonomie.

Automatisierung und unterstützende Tools

Kooperationsplattformen (GitLab, Confluence, SharePoint) können Vorlagen hosten und den Fortschritt von RFCs wie Projekt-Tickets verfolgen. Automatisierte Workflows benachrichtigen Reviewer, erinnern Autoren und schließen validierte Dokumente ab.

CI-Pipelines lassen sich so konfigurieren, dass genehmigte RFCs automatisch in die technische Dokumentation integriert werden und Code-Reviews oder vorläufige Tests auslösen.

Ein zentrales Dashboard bietet einen kompakten Überblick über alle laufenden RFCs, ihren Status und die beteiligten Stakeholder und stärkt so Transparenz und Projekt-Governance.

Edana: Strategischer Digitalpartner in der Schweiz

Wir begleiten Unternehmen und Organisationen bei ihrer digitalen Transformation.

Sprechen wir über Sie

Technische Schulden verhindern und langfristige Konsistenz sichern

RFCs bilden ein Entscheidungs­gedächtnis und ein Instrument zur Wissensweitergabe. Sie verhindern, dass die gleichen Debatten bei jeder Weiterentwicklung erneut geführt werden.

In verteilten oder wachsenden Organisationen wird der Informations­fluss zu einer großen Herausforderung. Ohne strukturiertes Referenzsystem besteht die Gefahr, Entscheidungen zu wiederholen, die bereits ihre Grenzen gezeigt haben, und so technische Schulden zu erhöhen.

Durch die Archivierung jeder RFC und den zugänglichen Entscheidungs­verlauf entsteht eine stabile Basis für Onboarding, Audits und spätere Überarbeitungen. Neue Teammitglieder verstehen so schnell, warum ein bestimmter technischer Weg gewählt wurde.

Dies stärkt auch den Zusammenhalt zwischen geografischen Standorten oder Tochtergesellschaften. Jede Einheit kann sich auf RFCs stützen, um globale Entscheidungen an ihren lokalen Kontext anzupassen und gleichzeitig die strategische Ausrichtung beizubehalten.

Dokumentation und organisatorisches Gedächtnis

Jede validierte RFC fließt in die unternehmensweite Dokumentationsdatenbank ein und wird zu einem historischen Meilenstein, der jederzeit abrufbar ist – nützlich für Audits, regulatorische Erweiterungen oder bedeutende Migrationen.

Die Nachvollziehbarkeit von Diskussionen und Entscheidungen verhindert organisatorische “Amnesie”: Sechs Monate nach einer komplexen Entscheidung muss niemand den ursprünglichen Gedankengang rekonstruieren, da alles dokumentiert ist.

Dieses Informationskapital dient auch internen Schulungen und Post-Mortem-Analysen und fördert einen kontinuierlichen Verbesserungsprozess.

Onboarding und Wissensaustausch

Neue Mitarbeitende erhalten durch den Zugriff auf RFCs Einblick in technische Strategien, Rahmenbedingungen und geschäftliche Ziele, ohne zahlreiche Einarbeitungs-Meetings abhalten zu müssen.

Dieser Zeitgewinn entlastet die Experten für höherwertige Aufgaben und senkt das Risiko von Fehlern durch ungenaue Interpretation vergangener Entscheidungen.

RFCs können sogar als Grundlage für Schulungsmodule dienen, indem sie bewährte Praktiken und Lernerfahrungen aus realen Projekten veranschaulichen.

Ausrichtung auf IT-Strategie und Standards

RFCs sind in die IT-Roadmap und die auf Governance-Ebene festgelegte Architektur­richtlinie eingebettet. Sie stellen sicher, dass jeder Vorschlag mit den Leitprinzipien (Open Source, Modularität, Sicherheit …) in Einklang steht.

Reviewer achten darauf, dass keine RFC den internen Standards widerspricht und so isolierte Lösungen entstehen, die das Gesamtsystem schwächen würden.

Bei notwendigen Ausnahmen dokumentiert der RFC-Prozess eindeutig Abweichungen und Gegenmaßnahmen, um die langfristige Kohärenz der Plattform zu gewährleisten.

Beispiel: Ein nationaler Verkehrsbetrieb hat RFCs für seine neuen API-Services eingeführt. Jede Schnittstellen­spezifikation wurde in einem abteilungsübergreifenden Komitee beschrieben und freigegeben. Innerhalb von sechs Monaten führte die Harmonisierung der Endpunkte und Datenschemata zu einer Reduktion von Integrationsfehlern zwischen Fachanwendungen und externen Partnern um 40 %.

Schlüsselbedingungen für wirklich effektive RFCs

Nachhaltiger Erfolg von RFCs erfordert einen klar definierten Rahmen, festgelegte Verantwortlichkeiten und das richtige Gleichgewicht zwischen Formalisierung und Agilität. Ohne diese Voraussetzungen können sie kontraproduktiv werden.

Bevor ein RFC-Prozess gestartet wird, müssen die betroffenen Entscheidungs­arten festgelegt werden (Architekturentscheidungen, Sicherheitsstandards, API-Richtlinien …) und jene, die weiterhin im Rahmen lokaler Schnellschüsse fallen.

Die Benennung eines RFC-Verantwortlichen gewährleistet die Nachverfolgung: Er sammelt Feedback, moderiert den Austausch und achtet auf Termine. Er kann sich auf ein Review-Komitee stützen, das schnelle Entscheidungen sicherstellt.

Schließlich darf die Dokumentation nicht die Notwendigkeit verdecken, schnell zu prototypisieren oder Tests durchzuführen. RFCs müssen mit Proof of Concepts und Beta-Versionen verknüpft sein, um besonders kritische Ansätze zu validieren.

Klare Definition von Umfang und Scope

Zunächst gilt es, die Entscheidungen zu identifizieren, die eine RFC erfordern: wesentliche Architektur­änderungen, Wahl von Technologie-Stacks, Einführung neuer Standards usw.

Für weniger strukturierende Themen (Optimierung interner Workflows, Tool-Experimente) empfiehlt sich ein leichteres Format wie ein Cadrage-Dokument oder ein gezielter Workshop.

Dieses anfängliche Scoping verhindert Überlastung der Teams und konzentriert RFCs auf wirklich strategische, risikobehaftete Entscheidungen.

Explizite Rollen und Verantwortlichkeiten

Von Beginn an wird definiert, wer den RFC-Entwurf erstellt, wer validiert und wer entscheidet. Der Verantwortliche verfasst den ersten Entwurf, der Fachsponsor legt Kriterien fest und das technische Komitee übernimmt das Review.

Jeder kennt seinen Beitrag: Feedback geben, förmliches Votum oder stillschweigende Zustimmung nach Ablauf einer Frist.

Diese Klarheit vermeidet mehrfache Review-Schleifen und beschleunigt den Entscheidungszyklus bei gleichzeitiger Verantwortung der Schlüsselpersonen.

Gleichgewicht zwischen Formalisierung und Prototyping

Ein RFC ersetzt keinen Prototyp oder Proof of Concept, sondern ergänzt die Experimente. Nach einer theoretischen Validierung folgt die Entwicklung eines Prototyps, um die Entscheidungen zu bestätigen.

Umgekehrt kann ein Prototyp ohne RFC zu ständiger Neuerfindung ohne Dokumentation und Governance führen.

Die Verzahnung von RFC, Prototyping und Testzyklen sichert den richtigen Mix aus Disziplin und Agilität für eine schnelle und zuverlässige Inbetriebnahme.

Beispiel: Eine stark wachsende FinTech hat einen verschlankten RFC-Prozess implementiert. Für jede neue Drittanbieter-Integration fasste ein zweiseitiges Dokument Umfang, Ziel-API und geplante Sicherheitstests zusammen. Dieses Format bewies, dass hohe Umsetzungsgeschwindigkeit und Nachvollziehbarkeit der Entscheidungen vereinbar sind und reduzierte Korrekturschleifen nach der Integration um 25 %.

RFCs einführen: Beschleuniger für sichere und nachhaltige Entscheidungen

RFCs sind weder ein bürokratisches Gimmick noch eine lästige Vorgabe: Sie sind ein Hebel für Entscheidungsreife. Durch die Dokumentation jeder Vorschlag, die Einbindung der richtigen Stakeholder und einen agilen Validierungsrahmen reduzieren sie technische Schulden, beschleunigen die Umsetzung und stärken die Kohärenz des IT-Systems.

Mehr als nur ein Format verkörpern RFCs die Philosophie von Edana: Open Source, Modularität, Vermeidung von Vendor-Lock-in und Kontextualisierung jeder Lösung. Unsere Expert:innen unterstützen Ihre Teams bei der Einführung dieses Prozesses, der Anpassung der Vorlagen und der Integration von RFCs in Ihre IT-Governance.

Besprechen Sie Ihre Herausforderungen mit einem Edana-Experten