Architektur-Governance in agilen Organisationen

Wozu Architektur-Governance dient

Architektur-Governance ist die Gesamtheit der Praktiken, mit denen eine Organisation sicherstellt, dass ihre bedeutenden technischen Entscheidungen gut getroffen werden, mit ihren Zielen übereinstimmen und tatsächlich befolgt werden. Sie beantwortet vier Fragen: Wer darf welche Entscheidungen treffen, wie sollen sie getroffen werden, welche Richtung sollen sie nehmen, und woran erkennt man, ob das Ergebnis konform ist?

Die Zwecke sind praktisch. Governance richtet die Technologie an der Strategie aus, damit fünfzig Teams nicht fünfzig Arten wählen, Kundendaten zu speichern. Sie steuert Risiko und Compliance: Datenschutz, Sicherheit, Barrierefreiheit und Branchenregulierung verlangen alle Nachweise, dass Regeln befolgt werden. Sie begrenzt unnötige Vielfalt, denn jede zusätzliche Datenbank, Sprache oder Messaging-Lösung braucht Fachwissen, Patches und Rufbereitschaft. Sie schützt Qualitäten, die keinem einzelnen Team gehören, etwa End-to-End-Latenz, Sicherheit und Kosten. Und sie verbreitet Erfahrungen, damit eine Lektion, die ein Team teuer bezahlt hat, nicht vom nächsten noch einmal bezahlt wird.

Agile Organisationen spüren hier ein Spannungsfeld. Das Prinzip des Agilen Manifests, dass die besten Architekturen aus selbstorganisierten Teams hervorgehen (Abschnitt 1.8), zieht in Richtung Autonomie; Größe, Regulierung und gemeinsame Infrastruktur ziehen in Richtung Ausrichtung. Henrik Knibergs Beschreibungen der Engineering-Kultur von Spotify haben für dieses Ziel den Ausdruck Aligned Autonomy bekannt gemacht: Teams, die frei über das Wie entscheiden, innerhalb eines gemeinsamen Verständnisses von Was und Warum. Governance ist die Maschinerie, die das möglich macht. Schlecht gemacht, wird sie zum langsamen Genehmigungsprozess aus Abschnitt 11.2; gut gemacht, bemerken die Teams sie kaum, weil das Richtige zugleich das Einfache ist.

Prinzipien, Standards, Guardrails und Gates

Governance nutzt vier Arten von Instrumenten, die sich darin unterscheiden, wie stark sie einschränken und wann sie wirken. Prinzipien drücken eine dauerhafte Richtung aus und lassen Raum für Urteilsvermögen. Standards sind konkrete, verbindliche Festlegungen (alle Services liefern OpenTelemetry-Traces; alle öffentlichen APIs sind in OpenAPI beschrieben). Guardrails halten Teams während der Arbeit innerhalb sicherer Grenzen, meist automatisch und kontinuierlich. Gates halten die Arbeit an, bis jemand sie freigibt.

Der heutige Konsens, wenn auch kein allgemeiner, ist, Guardrails gegenüber Gates zu bevorzugen, wo immer sich eine Regel objektiv formulieren lässt, Gates für die wenigen Entscheidungen vorzubehalten, bei denen wirklich ein verantwortliches menschliches Urteil nötig ist, und diese Gates früh und zeitlich begrenzt abzuhalten. Eine Paved Road (der Begriff von Netflix; Spotify spricht von einem Golden Path) ergänzt beides: Wenn der unterstützte Weg, einen Service zu bauen, bereits freigegebene Images, Logging, Sicherheitsscans und Deployment enthält, halten sich die meisten Teams an die Regeln, ohne dass man es ihnen sagen muss, und die Governance kann sich auf bewusste Abweichungen konzentrieren. Abschnitt 10.7 behandelt die Plattformen, die solche Wege bereitstellen.

Architekturprinzipien formulieren

TOGAF, das Enterprise-Architecture-Framework der Open Group (the TOGAF Standard, 10th Edition, 2022), bietet eine weit verbreitete Vorlage für Prinzipien mit vier Teilen. Der Name ist kurz und einprägsam. Die Aussage formuliert die Regel in ein oder zwei eindeutigen Sätzen. Die Begründung erklärt den geschäftlichen Nutzen so, dass ein nicht technischer Auftraggeber ihn akzeptieren könnte. Die Auswirkungen sagen, was das Prinzip in der Praxis verlangt: was getan werden muss, was es kostet und was es ausschließt. TOGAF nennt außerdem Kriterien für einen guten Satz von Prinzipien: verständlich, robust (präzise genug, um schwierige Fälle zu entscheiden), vollständig, konsistent und stabil.

Zwei Tests entlarven die meisten schwachen Prinzipien. Erstens: Könnte eine vernünftige Organisation das Gegenteil wählen? „Systeme sollen sicher sein“ fällt durch; niemand würde Unsicherheit wählen. „Für generische Fähigkeiten Kaufen dem Selbstbauen vorziehen“ besteht, weil manche Organisationen zu Recht lieber selbst bauen. Zweitens: Ändert das Prinzip eine echte Entscheidung? Kann niemand eine Wahl nennen, die es entscheiden würde, ist es ein Slogan. Andrew Harmel-Law fordert einen Satz, der weder zu klein ist, um die wichtigsten Bedürfnisse abzudecken, noch zu groß, als dass die Teams ihn sich merken könnten, aus den Teams selbst stammend und an die Geschäftsstrategie gebunden, statt allgemeiner Programmiermaximen oder Praktiken. Weniger, schärfere Prinzipien werden behalten und genutzt; lange Listen nicht.

Dezentrale Entscheidungsfindung: der Advice Process

Wenn Entscheidungen nicht mehr über ein Board laufen, wer trifft sie dann? Andrew Harmel-Laws Artikel Scaling the Practice of Architecture, Conversationally (martinfowler.com, Dezember 2021) schlug eine Antwort vor, die von selbstorganisierten Unternehmen entlehnt ist: den Advice Process. Seine einzige Regel lautet, dass jede Person eine Architekturentscheidung treffen darf, sofern sie vor der Entscheidung Rat bei allen einholt, die spürbar betroffen sein werden, und bei Menschen mit einschlägiger Expertise. Wer entscheidet, muss den Rat anhören und dokumentieren, ihm aber nicht folgen; das Ziel ist breiter Input, kein Konsens. Die Verantwortung bleibt bei der Person oder dem Team, die entscheiden, und genau das lässt die Regel funktionieren: Wer weiß, dass er die Folgen trägt, holt ernsthaft Rat ein.

Harmel-Law beschreibt vier unterstützende Elemente. Entscheidungsdokumente (ADRs, Abschnitt 4.5) sind das Werkzeug zum Nachdenken und Festhalten und enthalten den erhaltenen Rat, von wem und wann. Ein Architecture Advisory Forum, meist wöchentlich für etwa eine Stunde und offen für alle, macht neue Spikes, vorgeschlagene und erneut aufgegriffene Entscheidungen sichtbar; entscheidend ist, dass es berät, aber nicht entscheidet. Von den Teams erarbeitete Architekturprinzipien geben eine gemeinsame Richtung. Und ein internes Technologieradar zeigt die aktuelle Technologielandschaft der Organisation und ihre Haltung dazu.

Der Advice Process hat Schwachstellen, die man kennen sollte. Wer entscheidet, fragt vielleicht nur die, die wahrscheinlich zustimmen; eine veröffentlichte Liste, wer bei welcher Art von Entscheidung konsultiert werden muss (die Sicherheit bei allem, was personenbezogene Daten berührt, das Plattformteam bei neuer Infrastruktur), hilft. Rat wird vielleicht zu spät eingeholt, wenn der Code schon geschrieben ist; es hilft, den vorgeschlagenen ADR zum Anfang der Arbeit zu machen, nicht zu ihrem Ende. Und manche finden es anfangs unbequem, dass das Forum nicht entscheidet. In regulierten Umgebungen kann der Prozess neben einer kleinen Zahl formaler Gates bestehen, die nur dort angewandt werden, wo das Gesetz oder die Risikobereitschaft der Organisation sie verlangt.

Technologieradare

Thoughtworks veröffentlicht sein Technology Radar seit 2010 zweimal im Jahr. Jede Ausgabe ordnet rund hundert Blips (Techniken, Werkzeuge, Plattformen sowie Sprachen und Frameworks: die vier Quadranten) Ringen zu, die eine Empfehlung ausdrücken. Adopt bedeutet bewährt und empfohlen; Trial bedeutet, es lohnt sich, das in einem Projekt zu verfolgen, das mit dem Risiko umgehen kann; Assess bedeutet, es lohnt sich zu erkunden, um die Wirkung zu verstehen; und der äußerste Ring, der den größten Teil der Geschichte des Radars Hold hieß und in den jüngsten Ausgaben Caution heißt, bedeutet: mit Vorsicht vorgehen. Jeder Blip hat eine kurze schriftliche Begründung, und die ist der wertvollste Teil.

Viele Organisationen bauen ihr eigenes Radar, für sich selbst statt für die Branche. Thoughtworks stellt mit Build Your Own Radar ein Open-Source-Werkzeug bereit, das ein Radar aus einer Tabelle oder CSV-Datei mit den Spalten name, ring, quadrant, isNew und description erzeugt. Der Wert liegt weniger im Bild als im Prozess: Teams schlagen Blips vor, eine kleine Gruppe mit Vertretern vieler Teams diskutiert sie, die Ringe werden mit schriftlicher Begründung vergeben, und das Radar wird jedes Quartal oder Halbjahr aktualisiert. Ein Hold-Ring ist ein sanftes, aber wirksames Governance-Werkzeug: Er sagt „keine neuen Einsätze“, ohne zu verbieten, was bereits existiert. Ein Radar unterscheidet sich von einer Liste freigegebener Technologien dadurch, dass es ausdrücklich vorläufig und begründet ist und festhält, was die Organisation gelernt hat, einschließlich ihrer Fehler.

name,ring,quadrant,isNew,description
Debezium for outbox relay,Trial,Tools,TRUE,"Change data capture from the order database's write-ahead log to Kafka, replacing polling relays. Trial in ordering only; see ADR-0031. Owner: ordering team. Review: Q3."
Polling outbox relay,Hold,Techniques,FALSE,"Adds load and latency at peak; no new uses. Existing relays move when Debezium leaves Trial."

# ADR-0031: Use Debezium change data capture for the ordering outbox relay

Status: Accepted (2026-05-14)   Decision-taker: Priya N., ordering team
Context: The polling relay queries the outbox table every 500 ms. At 100 orders/s
it adds measurable database load and up to 1 s of event delay to dispatch.
Options: (1) tune polling; (2) Debezium CDC on the write-ahead log; (3) managed CDC
from the cloud provider.
Decision: Option 2, for the ordering service only, as a Trial on the radar.
Advice received:
- Platform team (2026-05-06): supports; will run Kafka Connect, needs runbook.
- Data team (2026-05-07): concern about replication slot growth if Connect stops;
  asks for an alert on slot lag. Accepted.
- Security (2026-05-08): CDC user must have replication rights only. Accepted.
- Advisory forum (2026-05-09): suggested option 3; rejected for portability (P3).
Consequences: lower load and delay; a new component to operate; slot-lag alert
and a fitness function on event delay (p99 under 2 s) added.
Review: after one quarter, or before any second service adopts it.

Die Rolle der Unternehmensarchitektur heute

Unternehmensarchitektur (Abschnitt 1.2) hatte in agilen Organisationen einen zwiespältigen Ruf: zentrale Teams, die Frameworks, Standards und Genehmigungsprozesse produzierten, die die Delivery-Teams als Hindernisse erlebten. Die Rolle hat sich gewandelt. In Organisationen, in denen es gut funktioniert, kuratieren Unternehmensarchitekten die Prinzipien und das Radar, statt sie vorzuschreiben, pflegen die Landkarte der Geschäftsfähigkeiten und Systeme, die kein einzelnes Team überblicken kann, treffen oder moderieren die wirklich organisationsweiten Einwegtür-Entscheidungen (Identität, Kerndaten, Cloud-Strategie, wichtige Anbieter), leiten das Advisory Forum und gestalten mit den Plattformteams die Plattform und die Paved Road.

Gregor Hohpes Bild vom Architekten, der mit dem Aufzug zwischen Vorstandsetage und Maschinenraum pendelt (Abschnitt 11.7), beschreibt die Fähigkeit, die das erfordert: Strategie in technische Richtung zu übersetzen und technische Zwänge in die Sprache des Geschäfts. Fachleute sind sich weiterhin uneinig, wie viel zentrale Autorität gesund ist. Manche argumentieren, eine starke zentrale Funktion sei in regulierten, von Übernahmen geprägten oder stark integrierten Unternehmen unverzichtbar; andere meinen, der größte Teil ihres Werts lasse sich über Plattformen, Prinzipien und Beratung erbringen. Die Antwort hängt von der Größe der Organisation ab, von ihrer Regulierung und davon, wie viel ihrer Systemlandschaft wirklich gemeinsam genutzt wird.

Compliance durch Automatisierung

Wie auch immer das Organisationsmodell aussieht: Die günstigste Compliance ist automatisiert. Fitness Functions (Abschnitt 11.3) prüfen Architekturmerkmale. Policy as Code tut dasselbe für organisatorische Regeln: Die Regeln werden in einer maschinenlesbaren Sprache geschrieben, in der Versionsverwaltung gehalten, wie Code reviewt und getestet und automatisch gegen Infrastrukturdefinitionen, Deployment-Manifeste oder API-Anfragen ausgewertet. Open Policy Agent, ein Graduated-Projekt der Cloud Native Computing Foundation, ist eine weit verbreitete Allzweck-Engine mit eigener Policy-Sprache, Rego; Conftest wendet Rego-Policies in einer Pipeline auf Konfigurationsdateien an, und Admission Controller wie OPA Gatekeeper oder Kyverno setzen Policies innerhalb von Kubernetes-Clustern durch.

Automatisierte Compliance hat einen weiteren Vorteil, den regulierte Organisationen sehr schätzen: Nachweise. Ein Pipeline-Log, das zeigt, dass jedes Release dieselben Prüfungen bestanden hat, ist für Prüfer ein weit stärkerer Nachweis als ein unterschriebenes Formular, und es entsteht ohne Zusatzkosten.

package main

import rego.v1

# Guardrail: images must come from the organisation's scanned registry
deny contains msg if {
    input.kind == "Deployment"
    some c in input.spec.template.spec.containers
    not startswith(c.image, "registry.fooddelivery.example/")
    msg := sprintf("%s: image %s is not from the approved registry", [input.metadata.name, c.image])
}

# Guardrail: every container declares a memory limit
deny contains msg if {
    input.kind == "Deployment"
    some c in input.spec.template.spec.containers
    not c.resources.limits.memory
    msg := sprintf("%s: container %s has no memory limit", [input.metadata.name, c.name])
}

Autonomie und Ausrichtung ausbalancieren

Die praktische Frage ist, welche Entscheidungen wie gesteuert werden. Eine nützliche Regel folgt aus Abschnitt 1.6: Je umkehrbarer und lokaler eine Entscheidung ist, desto näher am Team sollte sie getroffen werden; je irreversibler und weitreichender, desto mehr Rat und gelegentlich Freigabe braucht sie. Die Tabelle zeigt eine typische Verteilung; jede Organisation passt ihre eigene an.

Governance sollte selbst gemessen werden. Nützliche Signale sind, wie lange bedeutende Entscheidungen vom Vorschlag bis zur Annahme brauchen, wie viele Ausnahmen von Standards beantragt und gewährt werden, welcher Anteil der Services auf der Paved Road läuft, wie viele Hold-Technologien sich noch ausbreiten und ob Incidents auf Entscheidungen zurückgehen, bei denen kein Rat eingeholt wurde. Sind Entscheidungen langsam, ist die Governance zu schwer; gehen Incidents immer wieder auf nicht abgestimmte Entscheidungen zurück, ist sie zu leicht.