Conway’s Law: Warum Ihr Organigramm Ihre Datenarchitektur diktiert

Ihr Organigramm bestimmt Ihre Datenplattform — ob Sie es so geplant haben oder nicht. Conway’s Law, eine 57 Jahre alte Beobachtung darüber, wie Organisationen Systeme bauen, ist zum wichtigsten strategischen Denkmodell für Datenverantwortliche geworden. Für CTOs und CDOs ist die Konsequenz unmissverständlich: Wer seine Datenarchitektur reparieren will, ohne seine Teamstruktur anzufassen, wird scheitern.

Das Gesetz, das alles erklärt

1967 formulierte der Informatiker Melvin Conway eine These, die heute als Conway’s Law bekannt ist: „Organisationen, die Systeme entwerfen, sind gezwungen, Designs zu produzieren, die die Kommunikationsstrukturen dieser Organisationen abbilden.” Was als soziologische Beobachtung begann, ist heute eines der wenigen Prinzipien, auf das sich praktisch alle Software-Architekten einigen können. Martin Fowler bringt es auf den Punkt: Conway’s Law sei so mächtig, dass man zum Scheitern verurteilt sei, wenn man dagegen ankämpfe.

Das ist kein Folklore. Eine Studie der Harvard Business School verglich Codebasen losgekoppelter Open-Source-Teams mit eng gekoppelten kommerziellen Teams und fand starke empirische Belege: Lose gekoppelte Organisationen produzieren signifikant modularere Produkte. Microsofts eigene Analyse von Windows Vista kam zum selben Schluss — organisatorische Strukturmetriken waren signifikante Prädiktoren für Softwarequalität.

In der modernen Kurzform: Sie liefern Ihr Organigramm aus.

Datensilos sind kein Technologieproblem

Die sichtbarste Manifestation von Conway’s Law im Datenbereich ist das universelle Problem der Datensilos. Laut Forrester berichten 72 % der Unternehmen, dass ihre Daten in disparaten Silos existieren. Durchschnittlich nutzt ein Unternehmen über 200 SaaS-Anwendungen über Abteilungen hinweg, viele davon nicht integriert. Mitarbeiter verschwenden bis zu 12 Stunden pro Woche mit der Suche nach Daten, die in Silos gefangen sind.

Der Mechanismus ist so einfach wie destruktiv: Wenn Abteilungen — Finance, Marketing, Sales, Operations — als autonome Einheiten mit separaten Budgets und eigener Technologiebeschaffung operieren, wählt jede Tools, die für ihre eigenen Workflows optimiert sind. CRM-Daten leben in einem System, ERP in einem anderen, Marketing-Automatisierung in einem dritten. Jedes System speichert Daten anders. Jedes definiert Kennzahlen anders. Marketing berechnet den Customer Lifetime Value auf eine Weise, Finance auf eine andere. Im Schnitt nutzen Unternehmen 3,8 verschiedene BI-Tools — jedes mit eigenen Metrik-Definitionen.

Joe Reis, Co-Autor von Fundamentals of Data Engineering und eine der einflussreichsten Stimmen im Data-Engineering, formuliert es klar: Wenn verschiedene Abteilungen unabhängig und mit eingeschränkter Kommunikation operieren, entwickeln sie zwangsläufig eigene Datenmodelle und -systeme. Das sei keine rein technische Unannehmlichkeit, sondern eine direkte Steuer auf die unternehmerische Agilität. Die Kosten sind erheblich: Gartner schätzt, dass schlechte Datenqualität Unternehmen durchschnittlich 12,9 Millionen Dollar pro Jahr kostet.

Der Fluch von Conway im Data-Bereich

Die organisatorische Trennung zwischen Software-Engineering und Data-/Analytics-Teams — typischerweise mit unterschiedlichen Berichtslinien bis hinauf zur Geschäftsführung — hat sowohl eine kulturelle als auch technologische Kluft geschaffen. Die Konsequenzen zeigen sich in drei destruktiven Mustern.

Erstens: Fragile Integrationen zwischen operativen und analytischen Systemen, bei denen Data Engineers direkt auf Anwendungsdatenbanken zugreifen, statt wohldefinierte Schnittstellen zu konsumieren. Zweitens: Permanente Break-Fix-Zyklen, bei denen Änderungen in vorgelagerten Systemen — ein Timestamp-Feld wechselt von Lokalzeit auf UTC, ein Schema wird reorganisiert — kaskadierende Pipeline-Ausfälle verursachen, weil die organisatorischen Kommunikationsstrukturen die Lücke zwischen Produzent und Konsument nicht überbrücken. Drittens: Software-Engineering-Best-Practices, die im Data-Bereich ignoriert werden — Versionskontrolle, Testing, CI/CD und Code-Review-Standards, die in der Softwareentwicklung selbstverständlich sind, bleiben in vielen Data-Organisationen bloße Absichtserklärungen.

Chad Sanderson hat es auf den Punkt gebracht: „Datenqualität ist das Ergebnis schlecht gemanagter Erwartungen zwischen Datenproduzenten und Datenkonsumenten.” Das ist im Kern ein Conway’s-Law-Problem. Wenn die Teams, die Daten produzieren (Software-Engineers), und die Teams, die Daten konsumieren (Data Engineers, Analysten), in unterschiedlichen Organisationsstrukturen mit unterschiedlichen Anreizen und unterschiedlichen Führungslinien sitzen, ist das unvermeidliche Ergebnis: Fehlende Abstimmung und kaputte Pipelines.

Das bekannteste Anti-Pattern ist dabei der Bottleneck des zentralen Data-Teams. Organisationen investieren in einen zentralisierten Data Lake und ein Data-Engineering-Team — nur um festzustellen, wie schnell dieses zentrale Team zum Engpass wird. Es produziert One-Size-Fits-All-Datensätze, die keinen Use Case richtig abdecken. Frustrierte Fachbereiche bauen Workarounds, es entsteht eine „Schatten-Data-IT”, die die Datenlandschaft weiter fragmentiert.

Praxisbeispiel: Wie Netflix den Inverse Conway Maneuver anwandte

Das überzeugendste Gegenmodell zu Conway’s Law ist der sogenannte Inverse Conway Maneuver: Statt die Teamstruktur als gegeben hinzunehmen, strukturiert man Teams bewusst so um, dass die gewünschte Architektur entsteht.

Ein konkretes Beispiel liefert Netflix. Das Observability-Team hatte rund 20 unabhängige Monitoring-Applikationen, verteilt auf drei Teams. Nutzer beschwerten sich über eine fragmentierte Debugging-Erfahrung — sie mussten dieselbe Query über mehrere Tools replizieren und zwischen Tabs hin- und herspringen.

Der entscheidende Schritt: Bevor über Technologie gesprochen wurde, führte das Management eine Reorganisation durch. Statt drei separater Teams mit jeweils eigenen Tools wurde ein einheitliches „Explore”-Team geschaffen, das auf eine einheitliche User Experience ausgerichtet war. Erst danach begann die technische Umsetzung — und das Ergebnis entsprach exakt dem, was die neue Teamstruktur vorgab: eine integrierte Plattform statt fragmentierter Einzellösungen.

Auch bei Netflix’ Metadaten-Management zeigte sich dasselbe Muster. Der interne Katalog (Metacat) hatte zu viel Last auf das zentrale Plattform-Team gelegt, was zu Engpässen bei der Datenverwaltung führte. Die Lösung: Migration auf ein System, das Self-Service-Cataloging ermöglichte und die Verantwortung für Metadaten den jeweiligen Quellsystem-Besitzern übertrug — also eine bewusste Verschiebung von zentraler zu domänenspezifischer Ownership.

Die Lehre für Entscheider: Netflix hat nicht zuerst ein neues Tool evaluiert, sondern zuerst die Teamstruktur verändert. Die Technologie folgte der Organisation — nicht umgekehrt.

Der Werkzeugkasten für Data-Leader

Drei strategische Hebel haben sich in der Praxis bewährt, um Conway’s Law im Datenbereich gezielt zu nutzen:

Team Topologies als Organisationsmodell. Das Framework von Skelton und Pais definiert vier Teamtypen, die sich direkt auf Data-Organisationen übertragen lassen: Domain-Data-Teams, die für einen Fachbereich End-to-End-Verantwortung tragen; ein Data-Platform-Team, das Infrastruktur und Self-Service-Tooling bereitstellt; ein Enabling-Team für Governance und Befähigung der Fachbereiche; und spezialisierte Teams für ML/AI, die tiefes Expertenwissen bündeln. Die häufigste Fehlkonfiguration: Ein einzelnes Data-Team versucht, alle drei Rollen gleichzeitig zu erfüllen — Infrastruktur, Datenprodukt-Ownership und Governance. Die resultierende kognitive Überlastung ist der erste Hebel, an dem Entscheider ansetzen sollten.

Data Contracts als Grenzvereinbarungen. Analog zu API-Verträgen in der Softwareentwicklung formalisieren Data Contracts die Schnittstelle zwischen Datenproduzenten und -konsumenten. Software-Engineers verpflichten sich, stabile Schemata und Semantiken für nachgelagerte Konsumenten zu pflegen. Das adressiert direkt das Conway’s-Law-Problem der fehlenden organisationsübergreifenden Kommunikation.

Semantic Layer als einheitliche Wahrheitsquelle. Ein Unified Semantic Layer löst das Problem, dass unterschiedliche Teams dieselben Metriken unterschiedlich definieren. Ohne ihn führen abweichende Definitionen dazu, dass verschiedene Teams bei derselben Fragestellung zu divergierenden Einschätzungen kommen — und die resultierende Debatte darüber, wessen Realität die richtige ist, untergräbt das Vertrauen in datengetriebene Entscheidungen.

Die strategische Erkenntnis

Conway’s Law transformiert Datenarchitektur von einer rein technischen Frage in eine organisatorische Design-Herausforderung. Der Befund ist eindeutig: Ihre Datenplattform wird Ihre Teamstruktur widerspiegeln — unabhängig davon, welche Technologie Sie einsetzen.

ThoughtWorks schätzt, dass Ineffizienzen durch schlechte Team-Architektur-Alignment mittelgroße Organisationen bis zu 30 Millionen Dollar jährlich kosten können. Die empfohlene Reihenfolge ist klar: Organisatorischer Wandel muss technologischem Wandel vorausgehen oder ihn begleiten — niemals umgekehrt.

Martin Fowler warnt allerdings vor zu schnellem Handeln: Wenn ein bestehendes System eine rigide Architektur habe, die man ändern wolle, sei eine Reorganisation der Entwicklungsabteilung kein sofortiges Heilmittel. Es resultiere eher in einem Mismatch zwischen Entwicklern und Code, der zusätzliche Reibung erzeuge. Organisatorischer und architektonischer Wandel müssten koordiniert, inkrementell und durch nachhaltiges Executive Commitment gestützt sein.

Für CTOs und CDOs bedeutet das: Die nächste große Verbesserung Ihrer Datenplattform ist wahrscheinlich keine Technologiemigration — sondern ein organisatorisches Redesign. Die Unternehmen, die Datenarchitektur als soziotechnisches Problem begreifen, werden die Plattformen bauen, die das Versprechen datengetriebener Entscheidungsfindung tatsächlich einlösen.