Single Source of Truth: Organisationsweite Systeme, die Sie einmal definieren und ueberall nutzen

Hier ist ein Muster, das in jeder Organisation ab einer bestimmten Groesse auftaucht. Team A dokumentiert seine Architektur. Sie fuegen eine Box fuer den Authentifizierungsdienst hinzu — Name, Beschreibung, Technologie-Stack. Team B macht dasselbe in seinem Projekt. Team C auch. Drei Projekte, drei separate Definitionen desselben Systems, jede leicht unterschiedlich. Eine sagt "Auth Service", eine andere "Authentifizierungsplattform", die dritte "Identity Provider". Dasselbe System. Drei Namen. Drei Beschreibungen, die unterschiedliche Aspekte betonen. Keine Verbindung zwischen ihnen.

Sechs Monate spaeter benennt das Authentifizierungsteam den Dienst um und aktualisiert seinen Technologie-Stack. Die Aenderung propagiert zu null dieser drei Diagramme. Die Version der Realitaet jedes Projekts weicht stillschweigend vom tatsaechlichen System und voneinander ab.

Das ist das Konsistenzproblem. Es entsteht nicht aus Nachlaessigkeit. Es entsteht aus Architektur-Tools, die jedes Projekt als Insel behandeln. Wenn die einzige Moeglichkeit, ein System darzustellen, darin besteht, es innerhalb eines Projekts zu erstellen, dann erhaelt jedes Projekt, das dieses System beruehrt, seine eigene Kopie. Kopien driften. Das tun Kopien.

Wir haben organisationsweite Systeme gebaut, um dieses Problem zu loesen.

Systeme, die zur Organisation gehoeren, nicht zum Projekt

Archyl unterstuetzt jetzt zwei Geltungsbereiche fuer C4-Systeme. Projektbezogene Systeme funktionieren genau wie bisher — sie gehoeren zu einem einzelnen Projekt und leben auf dem Diagramm dieses Projekts. Organisationsbezogene Systeme gehoeren zu Ihrer Organisation. Sie existieren unabhaengig von jedem Projekt, und jedes Projekt kann sich mit ihnen verknuepfen.

Die Unterscheidung ist wichtig, weil sie widerspiegelt, wie echte Architektur funktioniert. Einige Systeme sind projektintern — ein Microservice, der nur innerhalb dieses begrenzten Kontexts existiert, eine Datenbank, die eine einzelne Anwendung bedient. Diese gehoeren zum Projekt. Aber viele Systeme ueberschreiten Projektgrenzen — gemeinsame Infrastruktur, Plattformdienste, Drittanbieter-Integrationen, zentrale Geschaeftsfaehigkeiten, von denen mehrere Teams abhaengen. Diese gehoeren zur Organisation.

Wenn Sie ein System auf Organisationsebene erstellen, machen Sie eine Aussage: Dieses System ist eine gemeinsame Realitaet. Sein Name, seine Beschreibung, seine Technologie und seine Tags werden einmal definiert. Jedes Projekt, das darauf verweist, sieht dieselbe Definition.

So funktioniert es

Organisationssysteme erstellen

Organisationssysteme werden ueber einen eigenen Bereich in der Plattform erstellt. Sie definieren das System genauso wie in einem Projekt — Name, Beschreibung, Typ (Softwaresystem, externes System oder Person), Technologie und Tags. Der Unterschied ist, dass es an kein Projekt gebunden ist. Es lebt auf Organisationsebene, sichtbar fuer alle Teams.

Systeme mit Projekten verknuepfen

Wenn Sie an einem Projektdiagramm arbeiten und auf ein Organisationssystem verweisen moechten, verknuepfen Sie es. Ein Modal zeigt Ihnen alle verfuegbaren Organisationssysteme mit Suchfunktion. Aktivieren Sie die gewuenschten — sie erscheinen sofort auf Ihrem Diagramm.

Verknuepfte Systeme verhalten sich wie native Systeme auf dem Diagramm. Sie koennen sie positionieren, wo es fuer das Layout dieses Projekts sinnvoll ist. Sie koennen Beziehungen zu und von ihnen erstellen. Sie koennen in ihre Container und Komponenten hineinnavigieren. Der einzige Unterschied ist, dass die Kernidentitaet des Systems — Name, Beschreibung, Technologie — aus der Organisationsdefinition stammt, nicht aus dem Projekt.

Jedes Projekt speichert seine eigene Position fuer das verknuepfte System, sodass dasselbe System an verschiedenen Stellen auf verschiedenen Diagrammen stehen kann. Das Layout ist pro Projekt. Die Definition ist geteilt.

Verknuepfung aufheben

Wenn ein Projekt nicht mehr von einem gemeinsamen System abhaengt, heben Sie die Verknuepfung auf. Das System verschwindet vom Projektdiagramm, existiert aber weiterhin auf Organisationsebene und in jedem anderen Projekt, das darauf verweist. Keine Daten gehen verloren. Kein anderes Team ist betroffen.

Warum das wichtig ist

Konsistenz ohne Koordination

Der traditionelle Ansatz, um die Konsistenz der Architekturdokumentation zu wahren, ist Prozess. Sie schreiben Namenskonventionen. Sie halten Review-Meetings ab. Sie bitten die Leute zu pruefen, wie andere Teams dasselbe System benannt haben. Prozess funktioniert, bis er nicht mehr funktioniert — was normalerweise der Moment ist, in dem jemand es eilig hat, was meistens der Fall ist.

Organisationsweite Systeme machen Konsistenz strukturell. Es gibt eine Definition. Projekte verweisen darauf. Wenn jemand die Beschreibung oder den Technologie-Stack des Systems aktualisiert, spiegelt jedes verknuepfte Projekt die Aenderung automatisch wider. Keine Slack-Nachrichten. Kein "bitte aktualisiert euer Diagramm". Die Architektur bleibt konsistent, weil das Architekturmodell es erzwingt.

Praezise projektuebergreifende Abhaengigkeiten

Wenn mehrere Projekte mit demselben Organisationssystem verknuepft sind, kennt die Plattform diese Verbindungen. Das ist keine visuelle Konvention — es ist eine Datenbeziehung. Impact Radar kann Abhaengigkeiten durch Organisationssysteme ueber Projektgrenzen hinweg verfolgen. Wenn Sie die Auswirkungen der Aenderung eines gemeinsamen Plattformdienstes analysieren, sehen Sie jedes Projekt, das davon abhaengt, weil sie alle mit demselben System verknuepft sind, anstatt unabhaengige Kopien zu pflegen.

Onboarding und Entdeckung

Neue Teammitglieder, die einem Projekt beitreten, sehen dieselben Systemnamen, Beschreibungen und Technologie-Labels, die alle anderen Projekte verwenden. Es gibt keinen "welcher Auth Service ist das?"-Moment. Das Organisationssystem traegt seine Identitaet mit sich, und diese Identitaet ist ueberall gleich.

Reduzierte Duplikation

Ueber den Konsistenzvorteil hinaus reduzieren Organisationssysteme schlicht die Arbeit. Anstatt dass jedes Projekt unabhaengig dieselbe Infrastruktur dokumentiert — den Message Broker, das API Gateway, den Identity Provider, den Monitoring-Stack — definieren Sie jedes einzelne einmal. Projekte verknuepfen sich in Sekunden. Die Zeit, die fuer das Neuerstellen derselben Boxen mit leicht unterschiedlichen Labels aufgewendet wird, sinkt auf null.

Was sich im Datenmodell aendert

Unter der Haube unterstuetzt die C4-System-Entitaet jetzt zwei sich gegenseitig ausschliessende Geltungsbereiche. Ein System gehoert entweder zu einem Projekt oder zu einer Organisation — nie beides, nie keines. Dies wird auf Datenbankebene durch eine Constraint erzwungen.

Eine separate Verknuepfungstabelle verfolgt, welche Projekte auf welche Organisationssysteme verweisen, zusammen mit der projektspezifischen Position auf dem Diagramm. Das bedeutet, dass dasselbe System auf zehn verschiedenen Projektdiagrammen erscheinen kann, jeweils unterschiedlich positioniert, jeweils mit eigenem Satz von Beziehungen zu projektlokalen Elementen.

Wenn Sie das C4-Modell eines Projekts laden, ruft die Plattform sowohl die eigenen Systeme des Projekts als auch alle verknuepften Organisationssysteme ab. Sie verschmelzen nahtlos auf dem Diagramm. Die Unterscheidung ist in der Oberflaeche sichtbar — Organisationssysteme tragen einen dezenten Indikator, der zeigt, dass sie geteilt sind — aber funktional nehmen sie am Architekturmodell genauso teil wie Projektsysteme.

Das groessere Bild

Dieses Feature ist Teil einer groesseren Richtung: Archyl so zu gestalten, wie Organisationen tatsaechlich arbeiten. Architektur ist keine Sammlung unabhaengiger Projekte. Es ist ein Netzwerk aus gemeinsamen Systemen, Plattformfaehigkeiten und Querschnittsthemen. Die Tools sollten das widerspiegeln.

Organisationsweite Systeme sind der erste Schritt zu einem Modell, in dem gemeinsame Infrastruktur einmal dokumentiert und ueberall referenziert wird. Kombiniert mit der Globalen Architekturansicht fuer projektuebergreifende Visualisierung und Impact Radar fuer projektuebergreifende Abhaengigkeitsanalyse haben Sie jetzt eine Plattform, die Ihre Architektur als verbundenes Ganzes versteht — nicht als eine Sammlung unverbundener Diagramme.

Erste Schritte

Organisationsweite Systeme sind ab sofort verfuegbar. Gehen Sie zum Organisationsbereich, erstellen Sie Ihre gemeinsamen Systeme und verknuepfen Sie sie dann mit jedem Projekt ueber die Diagrammansicht. Wenn Sie dasselbe System bereits in mehreren Projekten dokumentiert haben, ist dies Ihre Gelegenheit zur Konsolidierung — definieren Sie es einmal, verknuepfen Sie es ueberall und lassen Sie die Kopien in den Ruhestand gehen.

Ihre Architektur hat eine Single Source of Truth. Ihre Dokumentation sollte das auch haben.

Mehr ueber projektuebergreifende Architektur erfahren Sie unter Globale Architektur und Echtzeit-Zusammenarbeit. Um zu verstehen, wie sich Aenderungen an gemeinsamen Systemen ausbreiten, probieren Sie Impact Radar. Fuer kontrollierte Aenderungen an gemeinsamen Systemen erkunden Sie Architektur-Aenderungsanfragen.