Conway's Law - Warum eure Software so aussieht wie eure Firma

Es gibt eine alte Weisheit in der Software-Entwicklung, die 1967 von Melvin Conway formuliert wurde und heute relevanter ist als je zuvor:

"Organisationen, die Systeme entwerfen, sind gezwungen, Entwürfe zu erstellen, die die Kommunikationsstrukturen dieser Organisationen abbilden."

Klingt abstrakt? Ist es aber nicht. Es bedeutet schlicht: Eure Software ist ein Spiegelbild eurer Team-Struktur.

• Ihr habt drei getrennte Abteilungen, die kaum miteinander reden? Dann werdet ihr drei Software-Module haben, die nicht gut zusammenarbeiten.
• Eure Teams sitzen in Silos? Eure Daten werden es auch sein.
• Ein einzelner Entwickler macht alles? Das System wird ein großer, verwobener Klumpen sein.

Dies nennt man Conway's Law. Und es hat massive Auswirkungen auf Kosten, Geschwindigkeit und Qualität eurer IT-Projekte – egal ob Tech-Startup oder mittelständischer Maschinenbauer.

Warum ist das ein Problem?

Die automatische Abbildung der Organisationsstruktur in der Software-Architektur wäre kein Problem, wenn unsere Organisationsstrukturen perfekt wären. Sind sie aber meistens nicht.

Das führt zu verpassten Chancen und unnötigen Kosten:

1. Doppelte Arbeit: Wenn Teams nicht kommunizieren, lösen sie dieselben Probleme doppelt. Team A baut eine Benutzerverwaltung, Team B baut eine Benutzerverwaltung. Das kostet doppelt Zeit und Geld.
2. Mangelnde Integration: Systeme, die eigentlich zusammenarbeiten sollten (z.B. Vertrieb und Produktion), tun es nicht, weil die Abteilungen getrennt sind. Daten müssen manuell übertragen werden – Fehler vorprogrammiert.
3. Hohe Wartungskosten: Wenn jeder "sein eigenes Ding" macht, entsteht ein Wildwuchs an Technologien und Tools, den am Ende niemand mehr beherrschen kann.

Nicht nur ein Problem großer Konzerne

Oft wird abgewunken: "Wir sind ja kein großer Konzern, das betrifft uns nicht." Ein gefährlicher Irrtum. Conway's Law gilt überall, wo Menschen zusammenarbeiten (oder eben nicht).

Szenario 1: Der "kleine" Mittelständler

Selbst in kleinen Firmen mit 3-4 externen Partnern schlägt Conway's Law zu.

Stell dir vor:

• Eine Agentur baut die Marketing-Website.
• Ein Dienstleister betreut den Webshop.
• Ein Freelancer hat mal ein internes Tool gebaut.

Weil diese Dienstleister nie miteinander gesprochen haben (und es auch nicht im Auftrag stand), sieht die Systemlandschaft so aus:

Die Folge: Ihr habt Kundendaten an drei Orten. Änderungen müssen dreifach eingepflegt werden. Niemand hat den Überblick, wie viel Umsatz ein Kunde wirklich macht. Das ist ineffizient und fehleranfällig.

Szenario 2: Der "Schnittstellen-Wildwuchs" im Großsystem

Ein Klassiker in größeren Umgebungen: Mehrere Teams benötigen dieselben Daten aus einem zentralen externen System (z.B. einem SAP ERP für Bestandsdaten oder einem CRM für Kundendaten).

Weil die Teams für "Checkout", "Customer Service" und "Marketing" in isolierten Silos arbeiten, baut jedes Team seine eigene Anbindung.

Das Problem:

1. Drei-fache Wartung: Ändert das ERP seine Schnittstelle, müssen drei Teams gleichzeitig ihre Arbeit unterbrechen, um ihre Integrationen zu fixen.
2. Inkonsistenz: Der Checkout Service cached Daten vielleicht für 10 Minuten, das Marketing Tool für 24 Stunden. Kunden sehen unterschiedliche Informationen.
3. Last-Probleme: Das externe System wird durch vielfältige Schnittstellen unnötig belastet.
4. Wartungskosten: Änderungen am System müssen jede Schnittstellentechnologie berücksichtigen – das treibt die Komplexität und Kosten in die Höhe.

Eine zentrale "Gateway"-Komponente (gebaut von einem Plattform-Team oder gemeinsam abgestimmt) hätte diese Probleme gelöst – aber die Orga-Struktur hat es verhindert.

Wie man es heute besser macht: "Team-Autonomie" vs. "Chaos"

Früher versuchte man, alles zentral zu steuern ("Einer denkt, alle arbeiten"). Das war zu langsam. Heute will man autonome Teams, die schnell entscheiden und liefern können.

Aber Autonomie darf nicht Chaos bedeuten.

Das Konzept der "Leitplanken" (Makro-Architektur)

Erfolgreiche moderne Unternehmen nutzen einen hybriden Ansatz. Sie definieren Leitplanken, die für alle gelten (Makro-Architektur), und lassen innerhalb dieser Leitplanken den Teams freie Hand (Mikro-Architektur).

Beispiel: Das chaotische Startup

Ein Startup wächst schnell. Jedes Team löst das Thema "Monitoring & Logging" anders.

Ergebnis (Negativ):

• Team A schreibt unstrukturierte Text-Logs in Dateien.
• Team B nutzt ein teures SaaS-Tool nur für sich.
• Team C vertraut auf "wird schon laufen" und hat gar keine Logs.

Wenn ein systemweiter Fehler auftritt, ist die Ursachenforschung unmöglich, weil die Spuren in drei verschiedenen Formaten (oder gar nicht) vorliegen.

Die Lösung: Leitplanken setzen

Das Management (oder der Architekt) gibt vor: "Wir nutzen strukturierte Logs und eine einheitliche Monitoring Infrastruktur als Standard für unser Monitoring. Alles andere (z.B. die Programmiersprache oder Datenbank) entscheidet ihr selbst."

Der Vorteil: Teams sind schnell, weil sie nicht ständig Grundsatzentscheidungen treffen müssen. Und wenn es brennt, kann Team A auch mal bei Team B aushelfen.

Der "Gamechanger": Generative KI

Hier wird es spannend besonders für die Zukunft: Künstliche Intelligenz (wie GitHub Copilot, Claude Code, etc.) verändert gerade, wie wir mit diesem Thema umgehen.

Früher sagten Kritiker: "Wenn jedes Team seine eigene Suppe kocht, programmieren wir vieles doppelt. Das ist Verschwendung!"

Heute sagt die KI: "Kein Problem, ich schreib euch den Boilerplate-Code in 30 Sekunden."

Das bedeutet:

• Die "Kosten" für Team-Autonomie sinken.
• Teams können sich noch mehr darauf konzentrieren, Business-Probleme zu lösen, statt technische Infrastruktur zu bauen.
• Aber: Die Kommunikation wird noch wichtiger. Wenn jeder mit KI superschnell Code produziert, entsteht auch superschnell ein großes Chaos, wenn man nicht miteinander redet oder Leitplanken ignoriert.

Fazit & Checkliste für Entscheider

Conway's Law ist keine theoretische Spielerei für Informatiker. Es ist ein realer Kostenfaktor. Wenn eure Organisation nicht kommuniziert, wird eure Software teuer und fehleranfällig sein.

Was ihr tun könnt:

1. Schaut auf eure Orga: Bevor ihr neue Software plant, prüft eure Teams. Reden die Leute miteinander, deren Systeme später Daten austauschen sollen?
2. Definiert "Leitplanken": Legt fest, was unternehmensweit gleich sein muss (z.B. "Wie loggen wir uns ein?", "Welche Datenbank nutzen wir?").
3. Erlaubt Freiheit im Detail: Lasst den Teams Freiraum bei der Umsetzung, solange sie die Leitplanken einhalten.
4. Investiert in Breite: Die wichtigste Aufgabe von Senior-Techies ist heute nicht mehr, den kompliziertesten Code zu schreiben, sondern sicherzustellen, dass alle Teams voneinander wissen und profitieren.

Gute Architektur ist am Ende einfach gute Kommunikation.

Unterstützung benötigt?

Habt ihr das Gefühl, dass eure IT-Landschaft eher ein historisch gewachsenes Chaos ist als ein geplanter Erfolg? Wir helfen euch, die Strukturen zu analysieren und pragmatische Leitplanken einzuziehen – für mehr Geschwindigkeit und weniger Frust. Meldet euch einfach über unsere Kontaktseite.