Wenn die Teamstruktur die API diktiert, ist das kein Zufall; Conways Law sagt, dass Systeme die Kommunikationsstruktur ihrer Schöpfer widerspiegeln, und das bestimmt, wie schnell Features entstehen und wie stabil sie laufen.
Warum das jetzt zählt
Mit Cloud, Microservices und verteilten Teams wird die Frage, wer mit wem spricht, zentral für die technische Wettbewerbsfähigkeit; Unternehmen, die schnell innovieren wollen, stehen vor einem Spannungsfeld zwischen feingranularer Verantwortung und steigenden Koordinationskosten, und die Akteure sind Entwickler, Architekten, Produktmanager und Führungskräfte.
Technik trifft Organisation
Conways Law wirkt auf zwei Ebenen: technisch durch Schnittstellen, Coupling und Release-Pipelines, wirtschaftlich durch Time-to-Market, Wartungskosten und Personalstruktur; Architekten müssen deshalb nicht nur Module entwerfen, sondern auch Teamgrenzen bedenken, denn falsch angeordnete Teams erzeugen Duplikation, schlechte APIs und erhöhte Integrationskosten, während gezielte Umstrukturierungen wie das 'Inverse Conway Maneuver' helfen können, gewünschte Architekturresultate zu erzwingen.
Die Zahlungsplattform
Eine große Zahlungsplattform organisierte Teams nach technischen Schichten, woraufhin jede Gruppe eigene API-Versionen baute und Integrationen explodierten; erst die Umstellung auf domänenorientierte Teams mit einem kleinen Plattform-Team für gemeinsame SDKs senkte die Fehlerquote und beschleunigte Auslieferungen.
Das IoT-Startup
Ein IoT-Startup setzte von Anfang an auf feature-orientierte Teams und klare API-Verträge; das resultierte in schnellerem Rollout neuer Gerätefunktionen, aber auch in anfänglicher Redundanz, bis ein Architekt Richtlinien für wiederverwendbare Komponenten einführte.
Risiken und Chancen
Wer Conways Law ignoriert, zahlt in Form von Verzögerungen und technischem Schuldenberg; wer es bewusst nutzt, kann Lieferungsgeschwindigkeit und Qualität steigern, doch die Kehrseite ist, dass starre Teamstrukturen Innovation ersticken können, weshalb iterative Anpassungen und Messgrößen wie Deployment-Frequenz und Kopplungsmetriken nötig sind.
Was Architekten jetzt tun sollten
Solution- und Software-Architekten sollten Teamgrenzen aktiv mitgestalten, Schnittstellen als Produkte behandeln, Entwickler in API-Design schulen und Manager bei Anreizstrukturen unterstützen, damit Produkt- und Plattformziele kongruent werden; Projektmanager und Product Owner helfen, indem sie Domänenverantwortung definieren und Metriken zur Messung von Kopplung und Lieferzeit einführen.
