1967 machte der Informatiker Melvin Conway eine Beobachtung, die bis heute gilt:
„Organisationen, die Systeme entwerfen, sind gezwungen, Entwürfe zu produzieren, die Kopien der Kommunikationsstrukturen dieser Organisationen sind."
Einfacher: Deine Software sieht aus wie dein Organigramm.
Was Conway's Law bedeutet
Das Grundprinzip
ORGANISATION
Team A ←→ Team B ←→ Team C ↓ ↓ ↓
SYSTEM
Modul A ←→ Modul B ←→ Modul C
Die Teams kommunizieren → Die Module kommunizieren Die Teams sind isoliert → Die Module sind isoliert
Warum es funktioniert
KOMMUNIKATION KOSTET
Innerhalb eines Teams:
- Kurze Wege
- Gemeinsamer Kontext
- Schnelle Abstimmung
→ Enge Kopplung ist einfach
Zwischen Teams:
- Lange Wege
- Unterschiedlicher Kontext
- Aufwändige Abstimmung
→ Lose Kopplung ist einfacher
→ MENSCHEN NEHMEN DEN WEG DES GERINGSTEN WIDERSTANDS
→ ARCHITEKTUR FOLGT KOMMUNIKATION
Conway's Law in der Praxis
Beispiel 1: Der Monolith
ORGANISATION
Ein großes Team, alle arbeiten zusammen.
┌─────────────────────┐
│ Entwicklerteam │
│ (15 Entwickler) │
└─────────────────────┘RESULTAT
Ein großer Monolith, alles verbunden.
┌─────────────────────┐
│ MONOLITH │
│ Alles in einer │
│ Codebase │
└─────────────────────┘WARUM
- Jeder kann überall zugreifen
- Keine Grenzen = keine Grenzen im Code
- Schnelle Abstimmung = keine APIs nötig
Beispiel 2: Microservices
ORGANISATION
Kleine, autonome Teams.
┌───────┐ ┌───────┐ ┌───────┐ │Team A │ │Team B │ │Team C │ └───────┘ └───────┘ └───────┘
RESULTAT
Microservices mit klaren Grenzen.
┌───────┐ ┌───────┐ ┌───────┐ │Svc A │←→│Svc B │←→│Svc C │ └───────┘ └───────┘ └───────┘
WARUM
- Jedes Team ownt seinen Service
- Kommunikation über APIs (wie Teams über Meetings)
- Klare Grenzen = klare Interfaces
Beispiel 3: Frontend/Backend Split
ORGANISATION
Frontend-Team und Backend-Team.
┌──────────┐ ┌──────────┐ │ Frontend │ │ Backend │ │ Team │───────│ Team │ └──────────┘ └──────────┘
RESULTAT
Klare Frontend/Backend-Trennung.
┌──────────┐ API ┌──────────┐ │ Frontend │───────│ Backend │ └──────────┘ └──────────┘
PROBLEM
- Features brauchen beide Teams
- Koordination aufwändig
- Jedes Feature = Cross-Team-Projekt
Die Probleme
Unbeabsichtigte Architektur
TYPISCHER ABLAUF
- Firma wächst → Teams werden aufgeteilt
- Aufteilung oft nach: Skills, Standort, Historie
- Nicht nach: Optimaler Architektur
- Architektur folgt der (suboptimalen) Struktur
- Jahre später: „Warum ist unser System so?"
Silos werden zu APIs
WENN TEAMS NICHT KOMMUNIZIEREN
→ Ihre Services kommunizieren auch nicht gut → Schlechte oder keine APIs → Duplizierung statt Wiederverwendung → Inkonsistente Datenmodelle
Reorgs ändern nichts
TYPISCHER FEHLER
„Wir machen jetzt Microservices!" (Aber Teams bleiben gleich)
RESULTAT
- „Microservices" die wie ein verteilter Monolith sind
- Oder: Endlose Koordination zwischen Teams
- Architektur passt nicht zur Organisation
DIE ARCHITEKTUR ZU ÄNDERN OHNE DIE ORGANISATION ZU ÄNDERN FUNKTIONIERT NICHT.
Das Inverse Conway Maneuver
Wenn Conway's Law stimmt, können wir es umdrehen:
Designe deine Organisation so, dass die gewünschte Architektur entsteht.
Der Ansatz
TRADITIONELL
Organisation → (Conway's Law) → Architektur (zufällig)
INVERSE CONWAY
Gewünschte Architektur → Organisation designen → Architektur (intentional)
Beispiel
ZIEL-ARCHITEKTUR
Drei unabhängige Domänen (Checkout, Inventory, User).
TEAMS DESIGNEN
┌──────────────┐ │ Checkout Team│ → Ownt Checkout-Service └──────────────┘
┌──────────────┐ │Inventory Team│ → Ownt Inventory-Service └──────────────┘
┌──────────────┐ │ User Team │ → Ownt User-Service └──────────────┘
RESULTAT
Die Teamstruktur erzwingt die gewünschte Architektur.
Team Topologies
Das Buch „Team Topologies" (Matthew Skelton & Manuel Pais) baut auf Conway's Law auf und definiert vier Team-Typen:
1. Stream-Aligned Team
FOKUS
Ein Stück End-to-End-Wertschöpfung. Z.B. ein Feature, ein Produkt, eine Customer Journey.
BEISPIEL
„Checkout Team" – alles was mit Checkout zu tun hat.
EIGENSCHAFTEN
- Cross-funktional (FE, BE, Ops)
- Langlebig
- Aligned mit Business-Strom
2. Enabling Team
FOKUS
Andere Teams befähigen. Expertise teilen, nicht selbst bauen.
BEISPIEL
„DevOps Enablement Team" – hilft Teams, selbst zu deployen.
EIGENSCHAFTEN
- Temporärer Einsatz bei Teams
- Wissenstransfer, nicht Ownership
- Arbeitet sich selbst überflüssig
3. Complicated Subsystem Team
FOKUS
Komplex spezialisierte Komponente. Zu schwer für Stream-Aligned Teams.
BEISPIEL
„ML Team" – komplexe Modelle, die andere nutzen.
EIGENSCHAFTEN
- Tiefe Expertise
- Stellt APIs/Services bereit
- Reduziert Cognitive Load anderer Teams
4. Platform Team
FOKUS
Interne Plattform für andere Teams. Self-Service-Infrastruktur.
BEISPIEL
„Internal Developer Platform Team" – Deployment, Monitoring, Infrastruktur.
EIGENSCHAFTEN
- Behandelt interne Teams als Kunden
- APIs und Self-Service
- Reduziert Cognitive Load
Die Interaktionsmodi
- COLLABORATION
- Teams arbeiten eng zusammen
- Für: Discovery, neue Lösungen
- Temporär, nicht permanent
- X-AS-A-SERVICE
- Team bietet Service an
- Andere konsumieren via API
- Klare Boundaries
- FACILITATING
- Enabling Team hilft anderem Team
- Coaching, nicht Übernehmen
- Ziel: Unabhängigkeit
Conway's Law für Architektur-Entscheidungen
Vor einer Architektur-Entscheidung fragen
FRAGEN
- Welche Teamstruktur haben wir?
- Welche Architektur begünstigt diese Struktur?
- Ist das die Architektur, die wir wollen?
- Wenn nein: Können wir die Teams ändern?
- Wenn nein: Müssen wir mit der emergenten
Architektur leben?
Wann Microservices (nicht) funktionieren
MICROSERVICES FUNKTIONIEREN WENN
- Teams klein und autonom sind
- Klare Domänen-Grenzen existieren
- Teams können End-to-End liefern
- Wenig Cross-Team-Abhängigkeiten
MICROSERVICES FUNKTIONIEREN NICHT WENN
- Ein großes Team alles macht
- Ständige Cross-Team-Koordination nötig
- Domänen-Grenzen unklar
- Shared Ownership überall
Wann Monolith Sinn macht
MONOLITH PASST WENN
- Ein kleines Team (< 10)
- Enge Zusammenarbeit
- Schnelle Iteration wichtiger als Isolation
- Domäne noch unklar
NICHT: Monolith ist „legacy" SONDERN: Monolith passt zu manchen Organisationen
Praktische Anwendung
Architektur-Review mit Conway's Law
ÜBUNG
- Zeichne dein aktuelles System
(Komponenten und ihre Verbindungen)
- Zeichne dein Organigramm
(Teams und ihre Kommunikation)
- Vergleiche:
- Wo spiegeln sich die Strukturen?
- Wo gibt es Mismatches?
- Was erklärt das über Probleme?
- Frage:
- Ist das die Architektur, die wir wollen?
- Welche Team-Änderung würde helfen?
Bei Reorgs
VOR EINER REORG
- Welche Architektur wollen wir?
- Welche Team-Struktur unterstützt das?
- Reorg dementsprechend designen
NICHT
Reorg nach anderen Kriterien → Und hoffen, dass Architektur passt
Bei neuen Teams
WENN EIN NEUES TEAM ENTSTEHT
- Was wird dieses Team ownen?
- Welche System-Boundaries folgen daraus?
- Wie kommuniziert es mit anderen Teams?
- Wie werden die APIs aussehen?
TEAM-DESIGN = ARCHITEKTUR-DESIGN
Limitationen
Conway's Law ist keine Ausrede
NICHT
Unsere Architektur ist halt so weil Conway's Law.
SONDERN
Unsere Architektur spiegelt unsere Organisation. Wollen wir das ändern?
CONWAY'S LAW BESCHREIBT – ES ENTSCHULDIGT NICHT.
Technik kann auch Organisation beeinflussen
UMGEKEHRTER EFFEKT
Manchmal zwingt Technologie zu anderen Strukturen.
- Neue Tools ermöglichen neue Arbeitsweisen
- Plattformen reduzieren Team-Abhängigkeiten
- APIs können Team-Grenzen überbrücken
→ Es ist keine Einbahnstraße
Fazit: Architektur ist Teamarbeit
Conway's Law ist weder gut noch schlecht – es ist eine Beobachtung. Die Frage ist: Nutzt du sie bewusst?
Die Kernprinzipien:
- Bewusstsein: Deine Organisation formt deine Architektur
- Inverse Conway: Designe Teams für gewünschte Architektur
- Team Topologies: Strukturierte Denke über Team-Typen
- Alignment prüfen: Regelmäßig Org vs. Architektur vergleichen
- Intentional handeln: Architektur-Entscheidungen = Team-Entscheidungen
Deine Challenge:
Zeichne dein System und dein Organigramm. Wo siehst du Conway's Law in Aktion? Was erklärt das über eure Architektur-Probleme?
Du willst verstehen, wie du Teams optimal strukturierst? Unser Guide zu Stakeholder Management zeigt, wie du mit verschiedenen Team-Interessen umgehst.