Technology: Conway's Law
Conway's Law besagt: "Organisationen, die Systeme entwerfen, sind dazu verdammt, Systeme zu produzieren, die Kopien der Kommunikationsstrukturen dieser Organisationen sind." Der Umkehrschluss, Inverse Conway Maneuver, ist ein aktives Gestaltungsprinzip: Wir organisieren Teams so, wie wir uns die Architektur wünschen.
Conway's Law ist keine Warnung, sondern ein Werkzeug. Wer Teams bewusst gestaltet, gestaltet damit auch die Architektur.
Effects in Practice
- Klassischer Fall: Ein monolithisches Backend-Team produziert einen monolithischen Backend-Service.
- Mikroservice-Falle: Teams nach Technologie (Frontend/Backend/DB) statt nach Domänen geschnitten, erzeugen Distributed Monoliths.
- Richtig: Teams entlang von Bounded Contexts (DDD) strukturieren, damit jedes Team seinen Service vollständig besitzt.
Inverse Conway Maneuver
Der aktive Einsatz von Conway's Law: Wir definieren zuerst die gewünschte Zielarchitektur und organisieren danach die Teams.
- Team Topologies: Das Framework von Matthew Skelton und Manuel Pais formalisiert dieses Prinzip in vier Team-Typen (Stream-aligned, Platform, Enabling, Complicated Subsystem).
Focus: Architecture is People Work
Keine technische Entscheidung ist rein technisch. Jede Architekturentscheidung ist auch eine Organisationsentscheidung.
FAQ
Gilt Conway's Law auch für kleine Teams?
Ja, in kleiner Ausprägung. Selbst in einem 5-Personen-Team entstehen informelle Zuständigkeitsgrenzen, die sich in der Codebasis widerspiegeln.
Müssen wir uns ständig umorganisieren?
Nein. Aber bei grossen Architekturveränderungen (z. B. Monolith zu Microservices) muss die Teamorganisation mitgedacht werden, sonst scheitert die Migration.
Reference Guide
- Team Topologies: Das Praxisbuch zu Conway's Law. teamtopologies.com
- Conway's Original Paper (1968): melconway.com
- Inverse Conway Maneuver: martinfowler.com