Architecture Change Requests: Pull Requests fur Ihr C4-Modell
Letzten Monat hat ein Ingenieur in einem Team, das ich berate, einen zentralen Service in ihrem Architekturdiagramm umbenannt. Keine Diskussion. Keine Prufung. Die Anderung war sofort live, und drei Teams verbrachten das nachste Standup damit, sich zu fragen, ob der eigentliche Service umbenannt wurde oder nur das Diagramm. War er nicht. Jemand fand das Label einfach unklar und hatte es "korrigiert".
Dieser Vorfall hat etwas kristallisiert, worüber wir schon eine Weile nachgedacht hatten. Code hat Pull Requests. Infrastruktur hat Plan/Apply. Datenbankschemas haben Migrationen. Aber Architekturdiagramme? Jeder mit Bearbeitungszugriff kann alles jederzeit andern, und der Rest des Teams erfahrt es... irgendwann.
Heute andern wir das. Architecture Change Requests bringen den Pull-Request-Workflow in Ihr C4-Modell.
So funktioniert es
Das Konzept ist bewusst vertraut. Wenn Sie jemals einen Pull Request auf GitHub erstellt haben, wissen Sie bereits, wie das funktioniert.
Sie beginnen mit dem Erstellen einer Change Request. Geben Sie ihr einen Titel, beschreiben Sie, was Sie vorschlagen und warum. Dann fugen Sie Ihre Anderungen hinzu: neue Systeme erstellen, bestehende Container aktualisieren, ungenutzte Komponenten loschen, Beziehungen andern. Jede Anderung ist eine diskrete Operation: Erstellen, Aktualisieren oder Loschen eines bestimmten C4-Elements.
Die Change Request beginnt als Entwurf. Sie konnen weiter Anderungen hinzufugen und verfeinern, bis Sie bereit sind. Wenn der Vorschlag vollstandig ist, offnen Sie ihn zur Prufung.
Ihre Teammitglieder sehen die offene Anfrage in der Change-Request-Liste des Projekts. Sie konnen jede vorgeschlagene Anderung prufen, genau sehen, was erstellt, geandert oder entfernt wird. Sie hinterlassen Reviews: genehmigen, Anderungen anfordern oder kommentieren. Sobald die erforderliche Anzahl an Genehmigungen erreicht ist, kann die Anfrage zusammengefuhrt werden — alle Anderungen werden in einer einzigen atomaren Operation auf das Live-C4-Modell angewendet.
Visuelle Vorschau
Eine Sache, die wir nicht wollten, war eine Diff-Ansicht, die sich wie ein JSON-Blob liest. Architektur ist visuell, und die Prufung von Architekturanderungen sollte es auch sein.
Jede Change Request enthalt eine Live-Vorschau des Diagramms. Die Vorschau rendert das aktuelle C4-Modell mit allen vorgeschlagenen Anderungen uberlagert. Neue Elemente erscheinen mit gruner Hervorhebung. Geanderte Elemente erhalten einen bernsteinfarbenen Ring. Geloschte Elemente zeigen einen roten Indikator. Sie konnen durch die C4-Ebenen navigieren — System, Container, Komponente, Code — und die vollstandige Auswirkung des Vorschlags auf jeder Tiefe sehen.
Es ist dasselbe interaktive React-Flow-Canvas, das Sie fur das Live-Diagramm verwenden, mit demselben Drill-Down, Zoom und Schwenken. Der einzige Unterschied sind die Daten: Es ist eine berechnete Projektion dessen, wie die Architektur nach dem Zusammenfuhren aussehen wird.
Der Review-Prozess
Reviews folgen einem einfachen Modell. Ein Reviewer kann:
- Genehmigen — "Sieht gut aus, zusammenfuhren wenn bereit."
- Anderungen anfordern — "Ich habe Bedenken, lass uns das besprechen, bevor es rein kommt."
- Kommentieren — "Kein Einwand, aber hier ist etwas Kontext."
Jedes Review enthalt ein Freitextfeld fur detailliertes Feedback. Die Change Request verfolgt ihre Genehmigungsanzahl gegenuber dem erforderlichen Schwellenwert des Projekts. Standardmassig ist eine Genehmigung erforderlich, aber Sie konnen dies pro Projekt konfigurieren — null Genehmigungen fur kleine Teams, die ein schlankes Tracking wunschen, zwei oder drei fur grossere Organisationen, die eine formelle Freigabe benotigen.
Nur-Anfragen-Modus
Fur Teams, die noch weiter gehen wollen, haben wir einen Nur-Anfragen-Modus in den Projekteinstellungen hinzugefugt. Wenn aktiviert, sind direkte Bearbeitungen am C4-Modell gesperrt. Der einzige Weg, die Architektur zu andern, fuhrt uber eine Change Request.
Das bedeutet nicht, dass das Diagramm schreibgeschutzt wird. Sie konnen weiterhin navigieren, erkunden, ADRs und Dokumentation mit Elementen verknupfen, Kommentare hinzufugen. Sie konnen nur keine Elemente verschieben, umbenennen, erstellen oder loschen, ohne den Change-Request-Workflow zu durchlaufen.
Wir haben dies fur Organisationen gebaut, in denen Architektur-Governance wichtig ist — regulierte Branchen, grosse Ingenieurteams, Plattformteams, die gemeinsame Infrastruktur verwalten. Die Architektur wird zu einem kontrollierten Artefakt, bei dem jede Anderung nachvollziehbar und gepruft ist.
Aktivitatsverfolgung
Jedes Lifecycle-Ereignis einer Change Request erscheint im Aktivitats-Tab des Projekts. Wenn eine Anfrage geoffnet, geschlossen, wieder geoffnet oder zusammengefuhrt wird, wird ein Historieneintrag mit Autor, Zeitstempel und Anfragetitel aufgezeichnet. Das gibt Ihnen eine Zeitleiste, wie sich die Architektur entwickelt hat — nicht nur, wie sie heute aussieht, sondern die Abfolge von Vorschlagen und Entscheidungen, die sie geformt haben.
Kombiniert mit ADRs und Dokumentationslinks erhalten Sie eine vollstandige Erzahlung: was sich geandert hat (die Change Request), warum es sich geandert hat (der ADR) und wie es in den breiteren Kontext passt (die Dokumentation).
Anderungen erstellen
Der Change Builder lasst Sie Vorschlage Element fur Element aufbauen. Fur jede Anderung geben Sie an:
- Operation: Erstellen, Aktualisieren oder Loschen
- Elementtyp: System, Container, Komponente, Code-Element, Beziehung oder Overlay
- Elementdaten: die vollstandige Spezifikation des Elements — Name, Beschreibung, Technologie, Typ und alle Felder, die Sie beim direkten Erstellen ausfüllen würden
Fur Aktualisierungen erfasst das System sowohl den aktuellen als auch den vorgeschlagenen Zustand, damit Reviewer genau sehen, was sich andert. Fur Loschungen werden die bestehenden Elementdaten in der Anfrage zur Referenz aufbewahrt.
Sie konnen Operationen frei mischen. Eine einzelne Change Request kann zwei neue Container erstellen, eine Beziehung aktualisieren und eine veraltete Komponente loschen. Beim Zusammenfuhren werden alle Anderungen gemeinsam angewendet.
Was das fur Teams bedeutet
Architecture Change Requests sind nicht dazu da, Burokratie hinzuzufugen. Sie sind dazu da, architektonische Weiterentwicklung bewusst zu gestalten.
In einer Codebasis ist der Pull Request nicht nur eine Schranke — er ist ein Kommunikationswerkzeug. Er sagt "hier ist, was ich vorschlage, hier ist warum, was denkt ihr?" Er schafft einen naturlichen Moment fur Wissensaustausch, um Fehler fruh zu erkennen, um ein gemeinsames Verstandnis aufzubauen.
Architektur verdient die gleiche Behandlung. Wenn jemand vorschlagt, einen neuen Service hinzuzufugen, ist das ein Gesprach, das es wert ist, gefuhrt zu werden, bevor er auf dem Diagramm erscheint. Wenn jemand die Komponentenhierarchie umstrukturieren mochte, sollte das Team das vollstandige Bild sehen, bevor es zur neuen Realitat wird.
Die Change Request ist dieses Gesprach, strukturiert und nachvollziehbar gemacht.
Erste Schritte
Architecture Change Requests sind ab sofort auf allen Team-Planen verfugbar. Navigieren Sie zu einem beliebigen Projekt, und Sie finden den Bereich "Anfragen" in der Seitenleiste. Erstellen Sie Ihre erste Anfrage, fugen Sie einige Anderungen hinzu und offnen Sie sie zur Prufung.
Wenn Sie den Workflow durchsetzen mochten, aktivieren Sie den Nur-Anfragen-Modus in Ihren Projekteinstellungen. Konfigurieren Sie die erforderliche Genehmigungsanzahl entsprechend den Governance-Anforderungen Ihres Teams.
Ihre Architektur ist eine Teamentscheidung. Jetzt machen Ihre Werkzeuge das explizit.
Mochten Sie mehr uber kollaborative Architektur erfahren? Lesen Sie uber die Echtzeit-Zusammenarbeit an C4-Diagrammen, oder erfahren Sie, wie Architecture Decision Records Change Requests erganzen, indem sie das "Warum" hinter jeder architektonischen Weiterentwicklung festhalten.