Conway’s Law trifft Azure: Euer Tenant ist ein Selfie eurer Organisation

Oder: Warum eure Subscription-Liste mehr über eure Firma verrät als jedes Organigramm.

Kennt ihr das? Ihr bekommt Zugriff auf den Azure-Tenant eines neuen Kunden, öffnet die Subscription-Übersicht und wisst nach dreißig Sekunden, wie die Firma organisiert ist. Wer mit wem redet. Wer mit wem nicht redet. Welche Abteilung 2019 einen Alleingang gemacht hat. Und dass es mal ein "Projekt Phoenix" gab, über das niemand mehr sprechen möchte.

Das ist kein Zufall. Das ist ein Naturgesetz. Es heißt Conway's Law, es ist älter als die meisten von uns, und es formt eure Azure-Umgebung gerade in diesem Moment. Ob ihr wollt oder nicht.

Moment, wer ist Conway?

Melvin Conway schrieb 1968 einen Aufsatz mit der These, die heute als Conway's Law bekannt ist. Sinngemäß: Organisationen entwerfen Systeme, deren Struktur die Kommunikationsstruktur der Organisation widerspiegelt.

Sein berühmtes Beispiel: Lasst vier Teams gemeinsam einen Compiler bauen, und ihr bekommt einen Vier-Pass-Compiler. Nicht weil vier Pässe technisch optimal wären. Sondern weil vier Teams da waren.

1968! Da war "die Cloud" noch das Ding am Himmel, aus dem es regnet. Und trotzdem beschreibt dieser Satz euren Azure-Tenant präziser als jedes Architektur-Review. Denn Azure hat eine besondere Eigenschaft: Jede organisatorische Grenze lässt sich mit einem Klick in eine technische Grenze verwandeln. On-Prem musste man wenigstens noch einen Server bestellen, um sein Silo zu zementieren. In Azure reicht ein az account create und zack, das Abteilungssilo hat eine Subscription.

Schauen wir uns die Tatorte an.

Tatort 1: Die Subscription-Landschaft: Kostenstellen mit Compute

Subscriptions sind in Azure eine Grenze für Verwaltung, Skalierung, Policies und Billing. Das Cloud Adoption Framework empfiehlt, sie als Workload-Grenzen zu denken: nach Anwendungsportfolio, Umgebung (Prod/Non-Prod), Kritikalität.

Und was findet man in freier Wildbahn? sub-marketing, sub-vertrieb, sub-hr, sub-it-allgemein. Die Subscriptions folgen nicht den Workloads, sie folgen den Kostenstellen. Warum? Weil die erste Frage bei der Cloud-Einführung nie "Wie schneiden wir Workloads?" lautet, sondern "Wer bezahlt das?". Und wer bezahlt, bekommt eine Subscription. Conway nickt zufrieden.

Das Tückische: Es funktioniert ja erstmal. Bis Marketing und Vertrieb eine gemeinsame Anwendung brauchen und plötzlich niemand weiß, in wessen Subscription die läuft, wessen Budget belastet wird und wessen Policies gelten. Die Anwendung landet dann meistens in der Subscription der Abteilung mit dem durchsetzungsstärkeren Abteilungsleiter. Auch das ist Architektur. Irgendwie.

Tatort 2: Management Groups: Das Organigramm schlägt zurück

Management Groups sind eigentlich ein Governance-Werkzeug: Azure Policies und RBAC-Zuweisungen werden von oben nach unten vererbt, damit man Compliance einmal definiert statt hundertmal.

Microsofts Empfehlung in den Azure-Landing-Zone-Designprinzipien ist dabei erstaunlich deutlich: Strukturiert Management Groups nach Workload-Archetypen, also z. B. Platform (Identity, Management, Connectivity), Landing Zones (Corp, Online), Sandbox, Decommissioned. Und ausdrücklich nicht als Kopie des Organigramms.

Warum schreibt Microsoft das so explizit hin? Aus demselben Grund, aus dem auf Mikrowellen-Fertiggerichten "Folie vor dem Erhitzen entfernen" steht: Weil es sonst alle falsch machen.

Denn was passiert da draußen? mg-konzern → mg-geschaeftsbereich-nord → mg-abteilung-4b. Sieht im Portal wunderbar aufgeräumt aus. Bis zur nächsten Reorganisation. Und die kommt so sicher wie das nächste Azure-Portal-Redesign. Dann werden Subscriptions zwischen Management Groups verschoben, andere Policy-Zuweisungen greifen, geerbte RBAC-Rollen fallen weg und das Standup am Montag beginnt mit dem schönen Satz: "Weiß Jemand™, warum Prod seit Freitag keine Deployments mehr annimmt?"

Workload-Archetypen überleben Reorgs. Organigramme nicht. Baut eure Hierarchie auf das, was stabil bleibt.

Tatort 3: Hub-and-Spoke: eine Netzwerktopologie als Machtverhältnis

Hub-and-Spoke ist das Referenzmuster für Azure-Netzwerke, und das völlig zu Recht: Ein zentrales Hub-VNet mit Azure Firewall, VPN-Gateway oder ExpressRoute und privatem DNS, drumherum Spoke-VNets für die Workloads, verbunden per Peering. Technisch sauber, gut dokumentiert, bewährt.

Aber jetzt die Conway-Brille aufgesetzt: Wer betreibt den Hub? In neun von zehn Fällen: das zentrale Netzwerk-Team. Dasselbe Team, das on-prem die Firewalls verwaltet hat. Und siehe da, die Prozesse sind gleich mitgewandert. Neuer Spoke? Ticket. Neue Firewall-Regel? Ticket. Peering? Ticket, aber bitte mit Netzwerkdiagramm als Visio-Anhang.

Der Hub ist dann keine Netzwerkarchitektur mehr. Der Hub ist die alte IT-Abteilung, in Terraform gegossen inklusive drei Wochen Bearbeitungszeit.

Und die Applikationsteams? Die finden Wege. "Nur für den Test" wird ein Public Endpoint aufgemacht. "Nur übergangsweise" eine SAS-URL verschickt. Das ist die dunkle Seite von Conway: Wenn der offizielle Kommunikationsweg zu langsam ist, baut sich die Organisation inoffizielle und eure Architektur gleich mit. Jeder Schatten-Endpoint ist ein Denkmal für ein unbeantwortetes Ticket.

Das Gegenteil gibt es auch: Firmen mit maximal autonomen Teams, in denen jedes Team sein eigenes VNet baut und "Peering später geklärt wird". Kleiner Spoiler aus der Praxis: Später klärt das niemand. Bis zum ersten Pentest.

Tatort 4: AKS: die Gretchenfrage der Cluster-Anzahl

Kubernetes auf Azure ist der ehrlichste Conway-Detektor überhaupt. Die Frage lautet: Ein gemeinsames AKS-Cluster mit Namespace-Isolation oder ein Cluster pro Team?

Beide Modelle sind legitim, und Microsoft dokumentiert beide Multi-Tenancy-Ansätze ausführlich. Die technischen Trade-offs sind bekannt: Geteilte Cluster sparen Kosten und Betriebsaufwand, brauchen aber saubere Isolation (Namespaces, Resource Quotas, Network Policies, ggf. dedizierte Node Pools). Getrennte Cluster isolieren stärker, multiplizieren aber Upgrade-Aufwand, Node-Overhead und Kosten.

Aber Hand aufs Herz: In den wenigsten Firmen wird diese Entscheidung anhand der Trade-off-Tabelle getroffen. Sie wird anhand einer viel einfacheren Frage getroffen: Vertrauen sich die Teams?

Firmen mit einem funktionierenden Plattform-Team und guter interner Kommunikation fahren entspannt ein gemeinsames Cluster. Firmen, in denen Team A dem Team B nicht mal den Kaffeevollautomaten anvertrauen würde, haben dreißig Cluster. Dreißigmal Kubernetes-Version-Upgrades. Dreißigmal System-Node-Pools, die vor sich hin idlen. Und einen Azure-Kostenbericht, bei dem der CFO erst lacht und dann einen Termin einstellt.

Ihr habt keine dreißig Cluster, weil eure Workloads das brauchen. Ihr habt dreißig Cluster, weil eure Teams nicht miteinander reden. Das ist keine Container-Orchestrierung. Das ist Paartherapie-Bedarf mit YAML.

Tatort 5: Entra ID: RBAC-Archäologie für Fortgeschrittene

Öffnet mal die Rollenzuweisungen einer Subscription, die älter als drei Jahre ist. Was ihr dort seht, ist keine Zugriffsverwaltung. Das ist Sedimentgestein. Jede Schicht erzählt von einer Epoche eurer Firmengeschichte:

• Ganz unten: Direktzuweisungen an Einzelpersonen aus der Pionierzeit ("machen wir kurz Owner drauf, damit's läuft").
• Darüber: Gruppen mit Namen wie SG_Projekt_Merkur_Devs_NEU_final2, deren Projekt seit vier Jahren abgeschlossen ist.
• Obendrauf: Der halbherzige Aufräumversuch von 2024, der nach zwei Sprints eingeschlafen ist.

Und niemand traut sich zu löschen, denn es könnte ja etwas kaputtgehen. Also wächst das Sediment weiter. Eure Entra-ID-Gruppen sind das fossile Protokoll jeder Reorg, die eure Firma je hatte. Conway schreibt eben nicht nur eure Architektur. Er schreibt auch eure Access Reviews.

Die gute Nachricht: Genau dafür gibt es Werkzeuge. Entra ID Governance mit Access Reviews und Entitlement Management, PIM für zeitlich begrenzte privilegierte Rollen statt Dauer-Owner. Die schlechte Nachricht: Ein Werkzeug räumt nicht auf. Das Aufräumen ist ein organisatorisches Problem. Jemand™ muss zuständig sein. Und Jemand™ ist bekanntlich der unzuverlässigste Mitarbeiter der Welt.

Tatort 6: Pipelines: fünfzig Repos, sieben Deployment-Philosophien

Azure DevOps oder GitHub, ein Projekt pro Team oder eines für alle, zentrale Pipeline-Templates oder Copy-Paste-YAML. Auch hier entscheidet nicht die Architektur-Doku, sondern das Organigramm.

Teams, die eng zusammenarbeiten, teilen sich Template-Repositories, wiederverwendbare Workflows und eine gemeinsame Bicep- oder Terraform-Modulbibliothek. Teams, die per Ticket kommunizieren, kopieren sich die Pipeline vom Nachbarteam und passen sie "kurz an". Zwei Jahre später existieren sieben verschiedene Arten, nach Azure zu deployen. Vier davon funktionieren, zwei sind deprecated, und eine darf nur Kevin ausführen, aus Gründen, die mit Kevin in Elternzeit gegangen sind.

Der Klassiker: "Wir machen jetzt Landing Zones!" und nichts ändert sich

Irgendwann kommt der Punkt, an dem das gewachsene Chaos offiziell zum Problem erklärt wird. Die Lösung ist schnell gefunden: Azure Landing Zones! Enterprise-Scale! Alles neu, diesmal richtig, diesmal mit Bicep-Modulen und einem Wiki!

Und dann passiert Folgendes: Die neue Landing Zone wird gebaut von denselben Teams, mit denselben Zuständigkeiten, denselben Ticket-Prozessen und denselben Kommunikationswegen wie vorher. Das Netzwerk-Team bekommt die Connectivity-Subscription, das Security-Team schreibt Policies im stillen Kämmerlein, jede Abteilung bekommt ihre Landing Zone, und miteinander geredet wird weiterhin ausschließlich über das Ticketsystem.

Das Ergebnis: dasselbe Silo-System wie vorher, nur mit besserer Namenskonvention und einem hübschen Architekturdiagramm im Confluence. Ihr habt Conway nicht besiegt. Ihr habt ihm ein Rebranding spendiert.

Die unbequeme Wahrheit, die in keinem Deployment-Guide steht: Eine Landing Zone ist kein technisches Projekt mit organisatorischen Nebenwirkungen. Sie ist ein organisatorisches Projekt mit technischen Nebenwirkungen. Das Cloud Adoption Framework hat nicht umsonst ganze Kapitel zu Operating Model, Rollen und Verantwortlichkeiten Das sind nicht die langweiligen Kapitel, die man überspringt, um schneller zum Terraform-Code zu kommen. Das sind die Kapitel, die darüber entscheiden, ob der Terraform-Code irgendetwas verbessert.

Die Wende: Das Inverse Conway Maneuver

Jetzt der konstruktive Teil. Wenn Organisationsstruktur zwangsläufig Architektur erzeugt, dann können wir den Spieß umdrehen: Erst die Ziel-Architektur entwerfen, dann die Organisation so schneiden, dass sie genau diese Architektur hervorbringt. Das ist das Inverse Conway Maneuver, populär geworden durch das Team-Topologies-Umfeld, und es ist der vielleicht mächtigste "Azure-Architektur-Trick", der keine einzige Zeile Code enthält.

Konkret übersetzt in Azure-Sprache:

Ihr wollt autonome Workload-Teams auf einer stabilen Plattform? Dann braucht ihr ein echtes Plattform-Team, nicht die alte Infrastruktur-Abteilung mit neuem Teams-Kanal, sondern ein Team, das die Landing Zone als Produkt betreibt. Mit den Workload-Teams als Kunden. Mit Subscription-Vending als Self-Service-Automatisierung statt als E-Mail an Frank. Mit Dokumentation, die man freiwillig liest. Team Topologies nennt das Platform Team, und das Zusammenspiel mit den Stream-aligned Teams ist exakt das Betriebsmodell, das moderne Landing-Zone-Konzepte voraussetzen. Meist ohne es so deutlich zu sagen.

Ihr wollt, dass Security kein Flaschenhals ist? Dann darf Security kein Gate am Ende der Pipeline sein, sondern muss als Guardrail in der Plattform leben: Azure Policy mit Deny- und DeployIfNotExists-Effekten, Defender for Cloud, definierte Ausnahme-Prozesse. Die organisatorische Änderung (Security berät und befähigt, statt am Ende zu blockieren) erzeugt die technische: Leitplanken statt Schlagbaum. Wer im Team-Topologies-Sprech bleiben will: Security wird zum Enabling Team.

Ihr wollt saubere Workload-Grenzen? Dann schneidet Teams entlang von Produkten und Wertströmen, nicht entlang von Technologien. Ein Team "Datenbanken" plus ein Team "Frontend" erzeugt garantiert eine Architektur, in der jedes Feature zwei Tickets braucht. Ein Team "Checkout" mit End-to-End-Verantwortung erzeugt fast von selbst eine Subscription, die genau diesen Workload kapselt. Mit eigenen Pipelines, eigenem Monitoring über Azure Monitor und Application Insights, eigenem Budget samt Cost-Alerts. Die Architektur folgt dem Teamschnitt. Immer. Also schneidet mit Absicht.

Ihr wollt weniger AKS-Wildwuchs? Dann investiert in das, was ein geteiltes Cluster wirklich braucht: klare Ownership, ein Plattform-Team, das Upgrades und Node-Management wegabstrahiert, und Isolation, der die Teams vertrauen. Das klingt nach Soft Skills, ist aber am Ende der Unterschied zwischen drei Clustern und dreißig.

Der Conway-Audit: Sechs Tests für euren Tenant

Nehmt euch eine Stunde, macht euch einen Kaffee und geht ehrlich durch:

1. Der Subscription-Test: Könnt ihr zu jeder Subscription in einem Satz sagen, welcher Workload darin lebt? Oder nur, welche Abteilung sie bezahlt? Letzteres = Treffer.
2. Der Reorg-Test: Zwei Abteilungen fusionieren morgen. Was passiert in eurem Tenant? Wenn die Antwort ein sechsmonatiges Migrationsprojekt ist, habt ihr euer Organigramm in Infrastruktur gegossen.
3. Der Ticket-Test: Wie viele Tickets braucht ein neues Team von null bis zum ersten Prod-Deployment? Jedes Ticket ist eine Kommunikationsgrenze und jede Kommunikationsgrenze wird Conway früher oder später in eure Architektur einbrennen.
4. Der Peering-Test: Wie lange dauert es, bis zwei Workloads miteinander reden dürfen? Netzwerk-Latenz misst man in Millisekunden. Organisatorische Latenz in Wochen.
5. Der Template-Test: Wie viele grundverschiedene Deployment-Ansätze gibt es bei euch? Mehr als zwei? Da reden Teams nicht miteinander, die Pipelines beweisen es.
6. Der Friedhofs-Test: Wie viele Resource Groups gehören Teams, die nicht mehr existieren? Das ist kein technischer Debt. Das ist ein organisatorisches Nachlassverzeichnis.

Fazit: Conway gewinnt immer. Die Frage ist nur, für wen.

Conway's Law ist kein Bug, den das nächste Azure-Feature fixt. Es ist Gravitation. Ihr könnt es ignorieren. Doch dann formt eure historisch gewachsene Org-Struktur euren Tenant, und ihr wundert euch in drei Jahren im Architecture Board, warum "alles so kompliziert geworden ist". Oder ihr nehmt es ernst! Dann entwerft ihr Organisation und Azure-Architektur, als das, was sie sind: zwei Seiten derselben Medaille.

Die wichtigste Azure-Architekturentscheidung dieses Jahres fällt deshalb vielleicht gar nicht im Architecture Board. Sie fällt im nächsten Workshop zum Teamschnitt.

Und wenn euch das nächste Mal Jemand™ stolz sein Subscription-Diagramm zeigt: Schaut genau hin. Ihr seht kein Cloud-Design. Ihr seht ein Selfie der Organisation.

Die eigentliche Frage ist nur: Gefällt euch, was ihr da seht?

Wie sieht's bei euch aus? Erkennt ihr euer Organigramm in eurer Subscription-Liste wieder? Schreibt's in die Kommentare. Und falls ihr gerade dreißig AKS-Cluster betreibt: kein Urteil. Aber vielleicht mal ein Gespräch?