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:
1. Firma wächst → Teams werden aufgeteilt
2. Aufteilung oft nach: Skills, Standort, Historie
3. Nicht nach: Optimaler Architektur
4. Architektur folgt der (suboptimalen) Struktur
5. 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
1. COLLABORATION
- Teams arbeiten eng zusammen
- Für: Discovery, neue Lösungen
- Temporär, nicht permanent
2. X-AS-A-SERVICE
- Team bietet Service an
- Andere konsumieren via API
- Klare Boundaries
3. 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:
1. Welche Teamstruktur haben wir?
2. Welche Architektur begünstigt diese Struktur?
3. Ist das die Architektur, die wir wollen?
4. Wenn nein: Können wir die Teams ändern?
5. 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:
1. Zeichne dein aktuelles System
(Komponenten und ihre Verbindungen)
2. Zeichne dein Organigramm
(Teams und ihre Kommunikation)
3. Vergleiche:
- Wo spiegeln sich die Strukturen?
- Wo gibt es Mismatches?
- Was erklärt das über Probleme?
4. Frage:
- Ist das die Architektur, die wir wollen?
- Welche Team-Änderung würde helfen?
Bei Reorgs
VOR EINER REORG:
1. Welche Architektur wollen wir?
2. Welche Team-Struktur unterstützt das?
3. Reorg dementsprechend designen
NICHT:
Reorg nach anderen Kriterien
→ Und hoffen, dass Architektur passt
Bei neuen Teams
WENN EIN NEUES TEAM ENTSTEHT:
1. Was wird dieses Team ownen?
2. Welche System-Boundaries folgen daraus?
3. Wie kommuniziert es mit anderen Teams?
4. 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.
