Das eigentliche Problem liegt nicht in der Prüfung
Das Problem ist nicht, dass Regeln fehlen. Und es ist auch nicht so, dass sie nicht überprüft würden. Das eigentliche Problem ist, dass Governance in den meisten Fällen kein Gedächtnis hat. Jeder automatisierte Check bewertet ein architektonisches Artefakt zu genau einem Zeitpunkt. Es werden Verstöße angezeigt, sie werden vielleicht behoben oder auch ignoriert, und danach verschwindet das Signal wieder. Es bleibt nichts zurück, das über diesen Moment hinaus Bedeutung hätte. Es gibt keine systematische Speicherung, keine Verbindung zwischen einzelnen Ergebnissen und vor allem keine Entwicklung über die Zeit. Am Ende bleibt eine Abfolge isolierter Prüfungen.
Governance ohne Persistenz bleibt blind
Diese fehlende Persistenz ist kein technisches Detail, das man irgendwann noch ergänzen könnte. Sie ist die zentrale Schwäche vieler Governance-Ansätze. Wenn Ergebnisse nicht gespeichert und miteinander in Beziehung gesetzt werden, kann eine Organisation nicht lernen. Dann wiederholen sich die gleichen Verstöße immer wieder, ohne dass sie als Muster erkennbar werden. Teams stoßen an denselben Stellen auf Probleme, ohne dass das auf einer übergreifenden Ebene sichtbar wird. Manche Regeln werden konsequent ignoriert, andere werden sehr strikt umgesetzt. Aber ob das tatsächlich sinnvoll ist, lässt sich kaum beurteilen, weil die Grundlage fehlt. Entscheidungen basieren dann auf Einzelfällen und Bauchgefühl statt auf belastbaren Beobachtungen. Governance reduziert sich so auf Momentaufnahmen. Was fehlt, ist ein Verständnis für das System dahinter.
Von Einzelbeobachtungen zu Mustern
Die spannende Frage ist nicht, ob ein einzelnes Artefakt eine Regel verletzt. Die eigentliche Frage ist, was sich aus der Summe dieser Verstöße erkennen lässt. Wenn viele Teams immer wieder an derselben Regel scheitern, dann ist das in den seltensten Fällen ein Disziplinproblem. Es ist eher ein Hinweis darauf, dass die Regel nicht klar genug ist, nicht zur Arbeitsrealität passt oder schlicht nicht praktikabel ist. Ähnlich verhält es sich mit Sicherheitsvorgaben oder Versionierungsregeln. Wenn sie regelmäßig umgangen werden, steckt dahinter meist mehr als individuelles Fehlverhalten. Oft zeigt sich hier Reibung im System, die man ohne einen Blick auf das große Ganze gar nicht erkennen kann. Ohne Persistenz bleiben genau diese Zusammenhänge unsichtbar. Und damit bleibt auch das eigentliche Verbesserungspotenzial ungenutzt.
Signale richtig lesen
Jeder automatisierte Check erzeugt Signale. In vielen Organisationen werden diese Signale vor allem als Hinweise auf fehlende Compliance verstanden. Das greift zu kurz. Wiederkehrende Verstöße sind selten nur Fehler. Sie sind oft ein sehr direktes Feedback aus der Praxis. Vielleicht ist eine Regel unklar formuliert. Vielleicht fehlen Beispiele. Vielleicht ist das Tooling nicht gut genug integriert. Oder die Regel steht im Widerspruch zu dem, was Teams im Alltag leisten müssen. Wenn diese Signale nicht erhalten bleiben, gehen genau diese Hinweise verloren. Governance bleibt dann zwangsläufig reaktiv und korrigierend. Sobald man beginnt, diese Signale über die Zeit hinweg zu betrachten, verändert sich die Perspektive. Die Frage verschiebt sich weg von der reinen Einhaltung von Regeln hin zu der Frage, was Teams eigentlich daran hindert, innerhalb dieser Leitplanken gut arbeiten zu können.
Wenn Governance beginnt, sich zu erinnern
Sobald Governance anfängt, ihre eigenen Ergebnisse zu speichern und auszuwerten, verändert sich ihre Rolle spürbar. Aus punktueller Kontrolle wird ein System, das dazulernt. Wiederkehrende Muster werden sichtbar, und genau dort kann man ansetzen. Regeln lassen sich anpassen, weil man sieht, wie sie tatsächlich genutzt werden. Teams, die immer wieder an denselben Stellen Probleme haben, können gezielt unterstützt werden, statt immer wieder die gleichen Korrekturen zu bekommen. Mit der Zeit entsteht so ein anderes Zusammenspiel. Dokumentation wird präziser, weil klar ist, wo Missverständnisse entstehen. Vorlagen werden besser, weil man erkennt, wo sie nicht helfen. Tooling wird sinnvoller integriert, weil man Reibung nicht mehr nur vermutet, sondern beobachten kann. Governance rückt damit näher an die tatsächliche Arbeit der Teams heran und beginnt, diese aktiv zu verbessern.
Architektur als Feedback-System
Was hier am Beispiel einzelner Artefakte beschrieben wird, gilt in gleicher Weise für die gesamte Architektur. Ob es um Schnittstellen, Code-Strukturen, Infrastrukturvorgaben oder organisatorischem Zuschnitte geht, spielt dabei kaum eine Rolle. Überall, wo automatisiert geprüft wird, entsteht dasselbe Muster. An diesem Punkt wird deutlich, dass es nicht mehr nur um einzelne Governance-Mechanismen geht. Es geht um eine grundlegend andere Sicht auf Architektur insgesamt. Architektur ist dann nicht mehr nur ein Set von Regeln, die definiert und überprüft werden. Sie wird zu einem System, das kontinuierlich Feedback verarbeitet und darauf reagiert. Automatisierte Prüfungen liefern in diesem Bild zunächst nur die Rohdaten. Erst durch Persistenz und Auswertung entsteht daraus Erkenntnis. Und erst durch die Rückkopplung in Regeln, Werkzeuge und Arbeitsweisen wird daraus tatsächliche Wirkung. Das passt sehr gut zu dem Gedanken der Architecture Fitness Functions, die genau diesen Anspruch auf die gesamte Architektur ausweiten. Architektur wird nicht einmalig definiert und dann umgesetzt, sondern kontinuierlich überprüft und weiterentwickelt. Der entscheidende Punkt ist dabei einfach. Ohne Gedächtnis gibt es keine Entwicklung. Es bleibt bei der Wiederholung desselben Musters.
Warum Persistenz den Unterschied macht
Mit Persistenz kommt eine Dimension hinzu, die bisher gefehlt hat. Zeit. Erst über Zeit lassen sich Trends erkennen. Erst über Zeit wird sichtbar, ob sich etwas verbessert oder verschlechtert. Erst über Zeit kann man beurteilen, ob eine Regel sinnvoll ist oder angepasst werden sollte. Dadurch entsteht ein Kreislauf, der vorher nicht existiert hat. Regeln setzen Leitplanken. Automatisierte Prüfungen zeigen, wo sie eingehalten oder verletzt werden. Persistenz macht daraus ein Bild über die Zeit. Und auf dieser Basis können Regeln, Werkzeuge und Unterstützungsangebote weiterentwickelt werden. Ohne diesen Kreislauf bleibt Governance lokal und reaktiv. Mit ihm wird sie zu einem System, das sich selbst verbessert.
Fazit: ohne Gedächtnis keine Entwicklung
Viele Organisationen haben heute den Schritt gemacht, Architektur automatisiert zu prüfen. Das ist ein echter Fortschritt. Aber es ist nur ein erster Schritt. Solange Governance sich nicht merkt, was sie prüft, kann sie sich nicht verbessern. Solange keine Muster sichtbar werden, bleibt jedes Problem ein Einzelfall. Und solange keine Rückkopplung stattfindet, bleiben Regeln statisch, egal wie gut sie gemeint sind. Governance ohne Gedächtnis ist am Ende Kontrolle ohne Lernen. Und damit bleibt auch die Architektur stehen. Die nächste Evolutionsstufe liegt nicht in noch mehr Regeln. Sie liegt in der Fähigkeit, aus ihrer Anwendung zu lernen. Erst dann entsteht aus überprüfbarer Architektur eine Architektur, die sich tatsächlich weiterentwickelt.
Und genau hier wird es unbequem. Wir haben gelernt, Architektur zu prüfen. Wir haben aber noch nicht gelernt, aus ihr zu lernen. Die notwendigen Bausteine existieren längst. Regeln sind definiert. Pipelines sind etabliert. Was fehlt, ist das verbindende Element dazwischen. Ein System, das Signale nicht nur erzeugt, sondern sammelt. Das nicht nur Verstöße erkennt, sondern Muster versteht. Das nicht nur kontrolliert, sondern zurückspielt. Solche Systeme sind heute die Ausnahme. Stattdessen betreiben viele Organisationen Governance wie ein zustandsloses System. Jeder Check ist für sich korrekt, aber nach dem nächsten Durchlauf beginnt alles wieder von vorn. Man könnte es auch so formulieren:
- Wir haben eine Architektur, die geprüft wird.
- Aber keine Architektur, die sich erinnert.
- Und solange das so ist, bleibt Governance reaktiv.
Und Architektur bleibt erstaunlich unbeweglich für etwas, das eigentlich Orientierung in Bewegung geben soll.
[1] https://www.sigs.de/artikel/wenn-der-build-rot-wird-weil-architektur-verletzt-wurde/
