Conway's Law
Systemaufbau folgt dem Aufbau der Organisation
Die Idee und ihr Nutzen
Eine Versicherung will ihr Schadensystem in drei getrennte Dienste für Schadenmeldung, Regulierung und Zahlung aufteilen; Regulierung heißt dabei die Prüfung und Bearbeitung eines Schadens. Ihre IT-Teams sind aber nach Technik aufgeteilt: ein Team für die Bildschirmoberflächen, eines für die Programme auf dem Server und eines für die Datenbank. Nach zwei Jahren besteht das System statt aus den geplanten drei Diensten aus einer großen Oberfläche, einem großen Serverdienst und einer gemeinsamen Datenbank, also genau aus den Teilen, für die die drei Teams zuständig sind. Dass die Teile einer Software den Zuständigkeiten der Teams entsprechen, die sie bauen, beschreibt Conway's Law, das Gesetz von Conway.
Wie funktioniert es?
Im ersten Anlauf sind die drei Teams nach Technik aufgeteilt. Das Frontend-Team ist für die Bildschirmoberflächen zuständig und baut die eine große Oberfläche. Das Backend-Team ist für die Programme auf dem Server zuständig und baut den einen großen Serverdienst. Das Datenbankteam baut die gemeinsame Datenbank. Die Fachabteilung braucht bei der Zahlung eine neue Angabe und meldet diese Anforderung beim Frontend-Team. Das Frontend-Team kann das neue Feld nicht allein einführen und stimmt sich mit dem Backend-Team ab. Das Backend-Team braucht vom Datenbankteam eine neue Spalte in der gemeinsamen Datenbank. Erst nach der Absprache aller drei Teams erhält die Fachabteilung die neue Angabe. So braucht jede fachliche Änderung alle drei Teams, und das System hat drei technische Teile, genau wie die Organisation.
Im zweiten Anlauf bildet die Versicherung drei neue Teams, je eines für Meldung, Regulierung und Zahlung. In jedem Team arbeiten Fachleute aus der Fachabteilung mit Entwicklern für Oberfläche, Serverprogramm und Datenbank zusammen. Jedes Team verantwortet seinen eigenen Dienst: das Team Meldung den Meldedienst, das Team Regulierung den Regulierungsdienst und das Team Zahlung den Zahlungsdienst. Dieselbe Anforderung der Fachabteilung geht jetzt nur an das Team Zahlung. Das Team Zahlung ändert Oberfläche, Serverprogramm und Datenbank des Zahlungsdienstes selbst. Der Zahlungsdienst und der Regulierungsdienst tauschen Daten nur über eine Schnittstelle aus, also über festgelegte Aufrufe und Datenformate. Diese Schnittstelle haben das Team Regulierung und das Team Zahlung miteinander vereinbart. Über diese Schnittstelle gibt der Regulierungsdienst eine freigegebene Zahlung an den Zahlungsdienst weiter.
Der Informatiker Melvin Conway beschrieb diese Beobachtung 1968: Organisationen, die Systeme entwerfen, bringen Entwürfe hervor, die ihre eigenen Kommunikationswege nachbilden. Innerhalb eines Teams braucht Abstimmung wenig Aufwand. Die Mitglieder sitzen zusammen, sprechen kurz und ändern gemeinsam. Deshalb hängt Code, den ein Team verantwortet, meist eng zusammen. Im großen Serverdienst des Backend-Teams rufen sich zum Beispiel die Programmteile für Meldung, Regulierung und Zahlung direkt gegenseitig auf. Zwischen zwei Teams, etwa dem Frontend-Team und dem Backend-Team, braucht Abstimmung Termine, Absprachen und schriftliche Vereinbarungen. Deshalb entstehen genau dort feste Grenzen im System, an denen Programme über vereinbarte Schnittstellen Daten austauschen. Im ersten Anlauf baut jedes Team seinen Teil einer Änderung deshalb dort ein, wo es selbst zuständig ist: in der einen großen Oberfläche, dem einen großen Serverdienst und der einen gemeinsamen Datenbank. Für die neue Angabe bei der Zahlung müssen deshalb Oberfläche, Serverdienst und Datenbank gemeinsam geändert werden. Geplant war, dass jeder Dienst seine Oberfläche, sein Serverprogramm und seine Daten selbst enthält, damit er unabhängig von den anderen Diensten geändert werden kann.
Welche Teams es gibt und wofür jedes zuständig ist, entscheidet die Führung der Versicherung, nicht wer die Architektur plant. Conway's Law ist deshalb kein Entwurfsmuster, das ein Team einbaut, sondern eine Beobachtung aus der Praxis, die bei jeder Planung einer Architektur mitbedacht werden muss. Die Beobachtung erzwingt kein bestimmtes Ergebnis. Eine Organisation kann mit ihr auf zwei Arten umgehen. Die erste Art ist, die Beobachtung zu berücksichtigen: Die Organisation erwartet, dass die Architektur dem Aufbau der Organisation folgt, und plant Schnittstellen dort, wo Teamgrenzen ohnehin liegen. Die zweite Art ist, die Beobachtung gezielt zu nutzen: Die Organisation legt zuerst fest, welche Teile das System haben soll, und stellt die Teams dann so auf, dass jedes Team genau einen fachlichen Teil erhält. Dieses Vorgehen heißt Inverse Conway Maneuver, auf Deutsch umgekehrtes Conway-Manöver. Der zweite Anlauf der Versicherung ist ein solches Manöver.
Die neuen Teams allein legen aber noch nicht fest, welcher Dienst welche Aufgabe übernimmt, etwa ob der Regulierungsdienst oder der Zahlungsdienst die Bankverbindung prüft. Das mussten die Teams auch im zweiten Anlauf ausdrücklich festlegen.
Conways Gesetz: Teamgrenzen werden zu Systemgrenzen
Wann ist es sinnvoll und wann nicht?
Conway's Law hilft
- Eine Organisation mit mehreren Teams baut Software. Die Beobachtung trifft auf praktisch jede solche Organisation zu. Wer sie bei der Planung nicht beachtet, plant wie die Versicherung im ersten Anlauf drei fachliche Dienste und erhält nach zwei Jahren drei technische Teile.
- Die Architektur wird grundlegend umgebaut. Ein Beispiel ist das Aufteilen eines großen Systems in viele kleine Dienste. Plant die Versicherung nur die neuen Dienste, bauen die Teams sie weiter nach ihrer alten Aufteilung. Die Teamaufteilung muss deshalb mitgeplant werden, und die Versicherung kann schon bei der Planung festlegen, welche Teams sie für die neue Architektur braucht.
- Fachliche Änderungen brauchen regelmäßig Absprachen zwischen mehreren Teams, obwohl sie nur einen fachlichen Bereich betreffen. Ein Beispiel ist die neue Angabe bei der Zahlung im ersten Anlauf. Ohne die Beobachtung bleibt die Ursache unerkannt, und jede neue Angabe braucht weiter alle drei Teams. Mit der Beobachtung erkennt die Versicherung, dass die Aufteilung der Teams nach Technik diese Absprachen erzwingt.
- Das System weicht von der geplanten Architektur ab. Wer die Beobachtung kennt, erklärt die Abweichung mit der Teamaufteilung. Wer die Beobachtung nicht kennt, versucht die Abweichung mit Richtlinien zu korrigieren. Das gelingt selten, weil die Teams nach Technik aufgeteilt bleiben und jedes Team weiter nur seinen technischen Teil ändert.
Conway's Law hilft nicht
- Die Versicherung bildet die Teams Meldung, Regulierung und Zahlung, legt aber nicht fest, welche Aufgabe zu welchem Dienst gehört, und das Team Zahlung braucht für Änderungen am Zahlungsdienst weiter die Zustimmung des Teams Regulierung. Conway's Law sagt nur, dass zwischen zwei Teams eine Grenze im System entsteht, aber nicht, welcher der beiden Dienste eine Aufgabe übernimmt. Die geplante Architektur entsteht dann trotz der neuen Teams nicht. Die Versicherung legt deshalb vor dem Umbau der Teams fest, welche Aufgaben jeder Dienst übernimmt, etwa dass der Zahlungsdienst die Bankverbindung prüft, und lässt jedes Team über seinen Dienst selbst entscheiden. Das Team Regulierung und das Team Zahlung bauen dann nicht beide eine Prüfung der Bankverbindung, und keine Änderung am Zahlungsdienst wartet auf die Zustimmung des Teams Regulierung.
- Ein kleines System wird von einem einzigen Team gebaut. Dann gibt es keine Teamgrenzen, an denen Grenzen im System entstehen könnten. Das Team legt die Teile des Systems allein nach fachlichen Gesichtspunkten fest, und eine Teamaufteilung muss niemand mitplanen.
- Die Beobachtung soll begründen, Teams in kurzen Abständen immer wieder umzubauen. Im ersten Anlauf hat das System zwei Jahre gebraucht, bis es der Aufteilung der Teams folgte. Baut die Versicherung die Teams in kürzeren Abständen um, passt die Architektur immer zur vorherigen Organisation. Die Versicherung lässt die Teams deshalb nach einem Umbau über mehrere Jahre in derselben Aufteilung. In dieser Zeit können die Teams ihre Dienste nach der neuen Aufteilung umbauen, und für jeden Dienst gibt es weiter ein zuständiges Team.
- Ein Umbau der Teams ist nicht durchsetzbar, oder das System wird nur selten fachlich geändert. Im ersten Fall lässt sich das umgekehrte Conway-Manöver nicht umsetzen. Im zweiten Fall warten zu wenige fachliche Änderungen auf Absprachen zwischen den drei Teams, als dass sich ein Umbau der Teams mit neuen Zuständigkeiten, Führungsaufgaben und Budgets lohnt. Die Versicherung behält dann die heutige Aufteilung nach Technik und plant feste Schnittstellen zwischen Oberfläche, Serverdienst und Datenbank, weil dort die Teamgrenzen liegen.
Nachteile und typische Fehler
Teams umzubauen ist aufwendiger als Code umzubauen. Ein solcher Umbau betrifft Menschen, Führungsaufgaben und oft Budgets. Nach Fachgebiet aufgestellte Teams brauchen außerdem in jedem Team Fachleute aus der Fachabteilung und Entwickler für Oberfläche, Serverprogramm und Datenbank. Die Datenbankfachleute, die vorher gemeinsam im Datenbankteam gearbeitet haben, arbeiten danach in drei verschiedenen Teams. Das Team Meldung, das Team Regulierung und das Team Zahlung müssen sich dann über gemeinsame Regeln eigens abstimmen, etwa zum Betrieb der Datenbanken. Absprachen fallen auch nicht weg. Will das Team Regulierung einer freigegebenen Zahlung eine neue Angabe mitgeben, muss es die Schnittstelle zum Zahlungsdienst mit dem Team Zahlung neu vereinbaren.
Typische Fehler und woran man sie erkennt:
- Häufiger Umbau: Die Versicherung baut die Teams so oft um, dass die Architektur nie zur aktuellen Organisation passt. Nach einem Umbau gibt es zum Beispiel das Team Regulierung nicht mehr, der Regulierungsdienst läuft aber weiter. Erkennbar ist das an Diensten, für die sich kein heutiges Team zuständig fühlt.
- Unbeachtete Teamgrenzen: Die Versicherung plant drei fachliche Dienste, lässt die Teams aber nach Technik aufgeteilt. Jedes Team baut seinen Teil einer Änderung in den technischen Teil ein, für den es zuständig ist. Feste Schnittstellen entstehen so zwischen Oberfläche, Serverdienst und Datenbank statt zwischen den fachlichen Diensten. Erkennbar ist das an fachlichen Änderungen, die regelmäßig drei Teams und mehrere Termine brauchen.
- Teams ohne festgelegte Zuständigkeit: Die Versicherung bildet fachliche Teams, aber niemand legt fest, welche Aufgabe zu welchem Dienst gehört. Das Team Regulierung und das Team Zahlung bauen dann zum Beispiel beide eine Prüfung der Bankverbindung, weil jedes Team die Prüfung seinem Dienst zuordnet. Erkennbar ist das an Aufgaben, die in zwei Diensten doppelt oder in keinem umgesetzt werden.
- Richtlinie statt Ursache: Wer die Architektur plant, schreibt in einer Richtlinie vor, den großen Serverdienst nach Meldung, Regulierung und Zahlung zu trennen. Die Teams bleiben aber nach Technik aufgeteilt. Das Backend-Team baut neue Änderungen weiter in den großen Serverdienst ein, weil es nur dafür zuständig ist. Erkennbar ist das an Richtlinien, die immer wieder bekräftigt und trotzdem nicht eingehalten werden.
Weiterführend
Verwandte Ansätze
- Bounded Context: ein fachlicher Bereich, in dem Begriffe eine eindeutige Bedeutung haben. Solche Bereiche eignen sich gut als Zuständigkeit eines Teams.
- Microservices: Bauweise mit vielen kleinen, eigenständigen Diensten. Diese Dienste lassen sich leichter unabhängig entwickeln, wenn jedes Team für genau einen Dienst zuständig ist.
- Loose Coupling High Cohesion: der Grundsatz, dass Teile eines Systems wenig voneinander abhängen und innen eng zusammengehören sollen. Ist jedes Team für genau einen Dienst zuständig, hängen die Dienste meist nur über vereinbarte Schnittstellen voneinander ab.
- Modular Monolith: eine einzige Anwendung mit fachlich getrennten Teilen. Auch eine solche Anwendung lässt sich so aufteilen, dass jedes Team einen Teil verantwortet, ohne dass getrennte Dienste entstehen.
Hilfsmittel zur Analyse
Conway's Law ist eine Beobachtung, kein Werkzeug. Diese Projekte helfen, Team- und Architekturgrenzen sichtbar zu machen:
- Context Mapper: beschreibt fachliche Bereiche und ihre Beziehungen und stellt sie als Grafik dar. Welche Teams für die Bereiche verantwortlich sind, muss man zusätzlich festhalten.
- Backstage: Verzeichnis aller Dienste eines Unternehmens mit ihren verantwortlichen Teams. Es zeigt, ob Zuständigkeiten und Dienstgrenzen zueinander passen.
Quellen
- Melvin E. Conway: How Do Committees Invent?: Aufsatz von 1968 in der Zeitschrift Datamation, in dem Conway die Beobachtung zuerst beschrieb.
- Martin Fowler: Conway's Law: ordnet die Beobachtung ein und erklärt das umgekehrte Conway-Manöver und seine Grenzen.