Conway's Law im Replatforming: Warum Org-Design über Composable-Erfolg entscheidet

Mel Conway hat seinen Beobachtungssatz 1968 aufgeschrieben. Mehr als ein halbes Jahrhundert später ist er der präziseste Erklärungsrahmen dafür, warum Composable-Projekte scheitern.

Kelly Goetsch zitiert ihn auf Seite 3 seines eBooks Microservices for Modern Commerce (O'Reilly, 2016) und nennt Microservices direkt "Hacking Conway's Law." Seine Formulierung: "Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure." Goetsch beschreibt dann, wie horizontal spezialisierte Org-Strukturen, Java-Entwickler in einer Gruppe, Storage-Admins in einer anderen, UI-Teams separat, zwangsläufig eng gekoppelte, monolithische Systeme produzieren.

2026 ist diese Erkenntnis immer noch nicht vollständig angekommen. Nicht aus Unwissenheit, sondern weil Org-Redesigns politisch und organisatorisch aufwendig sind, deutlich aufwendiger als das Kaufen neuer SaaS-Tools.

Warum Composable ohne Org-Change scheitert

Stell dir folgendes vor: Du ersetzt deinen Shopware-Monolithen durch einen Composable-Stack. Backend-Microservices via commercetools, Search via Algolia, Storefront via Next.js. Die Architektur ist modular. Die Verträge sind abgeschlossen. Die Domains sind registriert.

Aber deine Org-Struktur sieht so aus:

• Ein zentrales Frontend-Team, das alle UI-Tickets bearbeitet
• Ein Backend-Team, das Composable-APIs konfiguriert
• Ein Content-Team, das im alten CMS arbeitet und Tickets ins Frontend-Team schreibt
• Ein DevOps-Team, das Deployments genehmigt

Was passiert jetzt? Jede Frontend-Änderung läuft durch Tickets. Jedes Deployment durch einen Genehmigungsprozess. Jedes neue A/B-Test-Setup durch Abstimmungen zwischen drei Teams. Die technische Modularität ist vorhanden, aber die organisatorische Kopplung produziert dieselbe Trägheit wie der Monolith.

Goetsch beschreibt genau dieses Muster am Beispiel eines Java-Entwicklers, der eine neue Datenbankkolumne braucht: Zehn serielle Schritte, DBA-Ticketing-System, Übergaben, Wartezeiten, für eine Änderung, die inhaltlich zwei Minuten Arbeit ist. "These steps are exhausting even just to read, yet this is how even minor changes are implemented in enterprises."

Das Composable-Stack-Äquivalent 2026: Ein Content-Mensch will eine neue Landing-Page-Sektion. Technisch sind alle Komponenten vorhanden. Aber sechs Tickets und drei Abstimmungen später ist der Moment verpasst.

Was Conway's Law für Composable-Teams bedeutet

Conway's Law lässt sich nicht aushebeln. Du kannst es aber nutzen, indem du deine Org-Struktur bewusst auf die gewünschte Systemstruktur ausrichtest, das ist, was Goetsch mit "Hacking Conway's Law" meint.

Konkret: Wenn du ein Composable-System willst, das aus autonomen, entkoppelten Capabilities besteht (Storefront, Search, Checkout, Content), dann brauchst du autonome, entkoppelte Teams, die diese Capabilities ownen.

Das Muster, das dabei funktioniert, sind Cross-functional Product-Teams pro Business-Capability. Ein Team owned den Storefront, Frontend-Code, Deployment, Performance, A/B-Testing, alles. Es hat einen Product Manager, einen oder mehrere Entwickler, eine Person für Content Operations. Es wartet nicht auf Tickets aus anderen Teams. Es released selbst.

Goetsch beschreibt das Ownership-Prinzip für Microservices klar: "A single team of 2 to 15 people develop, deploy and manage a single microservice through its lifecycle. This team truly owns the microservice. Ownership brings an entirely different mentality."

Auf den Frontend-Layer übertragen heißt das: Ein Team, das den Storefront owned, kann Composable wirklich leben. Ein Team, das Storefront-Tickets bearbeitet, aber keine Deployment-Autonomie hat, ist strukturell ein Monolith, egal was die API-Architektur darunter macht.

Die häufigsten Org-Muster, die Composable blockieren

Aus der Praxis haben sich drei Muster herauskristallisiert, die fast immer problematisch sind:

Muster 1: Das zentrale Frontend-Team als Bottleneck Ein einziges Team, das für alle Frontend-Artefakte zuständig ist, skaliert nicht mit einem Composable-Stack. Wenn zehn Business-Teams gleichzeitig Storefront-Features wollen, wird das zentrale Frontend-Team zur Engstelle. Die Lösung ist nicht ein größeres zentrales Team, sondern dezentrale Ownership mit geteilter Infrastruktur.

Muster 2: Content-Teams ohne Deployment-Pfad In vielen Unternehmen können Content-Teams neue Seiten oder Sektionen nicht selbst live bringen. Sie brauchen Entwickler-Support für jedes neue Template. Das führt dazu, dass Content-Teams entweder im alten Monolith-CMS bleiben oder ständig Abhängigkeiten produzieren. Ein gutes FMP-Setup trennt Content-Autonomie von Code-Deployment.

Muster 3: DevOps als zentrales Genehmigungsorgan Wenn jedes Deployment durch eine zentrale DevOps-Genehmigung läuft, ist die Release-Frequenz gedeckelt, egal wie modular der Stack ist. Das Deployment-Ownership muss zum Team, das den Service owned.

Was ein FMP an dieser Stelle löst

Eine Frontend Management Platform adressiert die Schnittstelle zwischen Org-Struktur und technischem Stack. Sie schafft die Infrastruktur, die es verschiedenen Teams erlaubt, autonom an Frontend-Capabilities zu arbeiten, ohne sich ständig koordinieren zu müssen.

Konkret: Ein Content-Team kann neue Seiten-Layouts im Laioutr Studio konfigurieren, ohne auf Entwickler-Tickets warten zu müssen. Ein Growth-Team kann A/B-Tests aufsetzen, ohne Frontend-Deployments zu blockieren. Ein Entwickler-Team kann neue Komponenten bauen und im FMP registrieren, die dann von anderen Teams autonom genutzt werden können.

Das ist nicht nur ein technisches Feature, es ist das technische Enablement für das Cross-functional-Team-Modell, das Conway's Law fordert.

Die Alternative, jedes Team baut seinen eigenen Frontend-Stack und verwaltet eigene Deployments, produziert das, was Goetsch als duplication cost beschreibt: "Each microservices team selects, sometimes procures, and always runs their own stack. But the point of microservices is speed." Beim Frontend stimmt das nicht mehr ganz: Weil Frontend-Komplexität durch Shared Infrastructure besser handhabbar ist, nicht durch vollständige Dezentralisierung.

Drei Fragen für dein Replatforming-Briefing

Wenn du ein Composable-Replatforming vorbereitetest, lohnen sich diese drei Fragen vor dem ersten Architektur-Meeting:

1. Welche Teams haben heute Deployment-Autonomie für Frontend-Artefakte? Wenn die Antwort "keins" oder "nur das zentrale Frontend-Team" ist, dann hast du eine Org-Struktur, die Composable blockieren wird.

2. Können Content-Teams heute neue Seiten ohne Entwickler-Support live bringen? Wenn nicht, dann ist das kein Feature-Gap eures CMS, das ist ein Ownership-Gap in eurer Org.

3. Wie viele Teams würden von einem Storefront-Feature-Request betroffen sein? Wenn die Antwort mehr als zwei Teams ist, dann habt ihr eine Koordinations-Overhead-Struktur, die Composable-Speed verhindert.

Die Antworten auf diese Fragen entscheiden mehr über den Erfolg deines Replatformings als die Wahl zwischen Hygraph und Contentful.

Fazit: Composable ist eine Org-Frage, keine Tool-Frage

Goetschs Beobachtung aus 2016 gilt 2026 unverändert: Microservices, und Composable generell, sind mehr Organisationsthema als Technologie-Thema. Wer die Tools kauft, ohne die Org-Struktur anzupassen, kauft sich teurere Komplexität, keine höhere Geschwindigkeit.

Das bedeutet nicht, dass du vor einem Replatforming eine komplette Org-Transformation brauchst. Es bedeutet, dass du die Ownership-Fragen bewusst klären musst: Wer owned was? Wer kann was selbst deployen? Wer braucht wessen Genehmigung?

Ein FMP wie das von Laioutr kann dabei helfen, diese Ownership-Struktur technisch abzubilden, aber es ersetzt nicht die Entscheidung, wer welche Capability owned.

Mehr zur technischen Seite dieser Frage, wie Frontend-Layer-Standards den TCO im Composable-Stack beeinflussen, findest du in unserem Post 10 Jahre Microservices im Commerce und in Headless allein reicht nicht.

[Composable Replatforming besprechen, ohne Org-Re-Design geht es nicht](https://www.laioutr.com/demo)

Quelle: Goetsch, K. (2016). Microservices for Modern Commerce. O'Reilly Media.