Warum kommen wir nicht schneller voran?
Zwei bis vier Releases pro Jahr. Für ein Unternehmen, das in einem dynamischen Online-Markt bestehen will, ist das nicht nur langsam — es ist existenzbedrohend. Jede Änderung an einem System zog Abstimmungsschleifen mit drei, vier, manchmal fünf anderen Teams nach sich. Features, die technisch in zwei Wochen umsetzbar gewesen wären, brauchten Monate, bis alle Abhängigkeiten geklärt waren.
Die Ursache lag nicht in mangelnder Kompetenz der Entwickler oder fehlenden Tools. Sie lag tiefer — in der Struktur der Organisation selbst.
Bereits 1967 formulierte Melvin Conway eine Beobachtung, die bis heute zu den wichtigsten Erkenntnissen der Softwareentwicklung zählt:
Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.
Was ist Conways Law?
Conways Law ist keine Empfehlung und kein Designprinzip — es ist eine empirische Beobachtung. Melvin Conway stellte 1967 fest, dass die Architektur eines Systems unweigerlich die Kommunikationsstrukturen der Organisation widerspiegelt, die es entwickelt hat. Wenn drei Teams an einer Anwendung arbeiten, besteht das Ergebnis aus drei Teilsystemen — ob das architektonisch sinnvoll ist oder nicht. In der Praxis bedeutet das: Wer die Architektur ändern will, muss zuerst die Organisation ändern. Das Gesetz lässt sich nicht austricksen — aber bewusst nutzen.
Kurz gesagt: Wenn die Organisationsstruktur nicht zur gewünschten Architektur passt, wird das System die Organisationsstruktur gewinnen — nicht umgekehrt.
Hintergrund: Wenn Struktur und Architektur divergieren
Das Unternehmen — ein großer Online-Anbieter — war klassisch funktional organisiert: ein Team für Frontend-Entwicklung, eines für Backend, eines für Datenbanken, eines für den Betrieb. Jede Änderung, die über eine einzelne Schicht hinausging, erforderte teamübergreifende Koordination.
Das Problem: Fast jede relevante Änderung ging über eine einzelne Schicht hinaus.
Über die Jahre hatte sich eine Architektur entwickelt, die niemand so geplant hatte. Die Systeme waren historisch gewachsen, Schnittstellen unklar definiert, Verantwortlichkeiten verwaschen. Architektur-Erosion im klassischen Sinne — nicht durch schlechte Entscheidungen einzelner Entwickler, sondern durch eine Organisationsstruktur, die quer zur fachlichen Domäne geschnitten war.
Die Analyse der Change Requests bestätigte das Bild quantitativ: Rund 50% aller Änderungen erforderten Abstimmung zwischen mindestens zwei Teams — sogenannter Cross-Talk. Jede dieser Abstimmungen bedeutete Wartezeiten, Missverständnisse, Kompromisse. Die Release-Frequenz von zwei bis vier Mal pro Jahr war die logische Konsequenz.
Lösungsansatz: Domänen statt Schichten
Statt die Symptome zu bekämpfen — mehr Meetings, bessere Ticketing-Systeme, ausführlichere Dokumentation —, setzten wir an der Wurzel an: der Organisationsstruktur selbst.
Schritt 1: Fachliche Domänen identifizieren
Gemeinsam mit den Fachbereichen analysierten wir die zentralen User und Customer Journeys des Unternehmens. Daraus entstand ein fachliches Domänenmodell nach den Prinzipien des Domain-Driven Design (DDD). Die Frage war nicht „Welche Technologien haben wir?”, sondern „Welche Geschäftsbereiche gibt es, und wo liegen die natürlichen Grenzen?”
Schritt 2: Systeme an Domänen ausrichten
Die bestehenden Softwaresysteme wurden den identifizierten Domänen zugeordnet. Wo ein System mehrere Domänen bediente, wurde es mittelfristig entflochten. Wo eine Domäne auf viele Systeme verteilt war, wurden klare Verantwortlichkeiten definiert.
Schritt 3: Teams an Domänen ausrichten
Der entscheidende Schritt: Jede Domäne bekam ein cross-funktionales Team, das alle notwendigen Kompetenzen vereinte — Frontend, Backend, Datenbank, Betrieb. Jedes Team bekam einen eigenen Product Owner, der die fachliche Verantwortung für seine Domäne trug.
Das Prinzip dahinter stammt von Werner Vogels, CTO von Amazon:
You build it, you run it.
Die Teams waren nicht nur für die Entwicklung verantwortlich, sondern auch für den Betrieb ihrer Systeme. Kein Über-den-Zaun-Werfen mehr, kein Warten auf das Ops-Team. Wer Code schreibt, ist auch dafür verantwortlich, dass er in Produktion funktioniert.
Ergebnis: 80% weniger Abhängigkeiten
Die Umstellung war kein Schalter, den man umlegt. Sie dauerte Monate und erforderte Geduld, Kommunikation und die Bereitschaft, liebgewonnene Strukturen aufzugeben. Aber die Ergebnisse sprachen für sich:
Der Anteil teamübergreifender Abstimmungen sank von rund 50% auf 5–10% — eine Reduktion um ungefähr 80%. Die Teams konnten den Großteil ihrer Änderungen autonom umsetzen, ohne auf andere Teams warten zu müssen. Die Release-Frequenz stieg deutlich, weil die Abhängigkeiten, die vorher jeden Release-Zyklus verlangsamten, schlicht nicht mehr existierten.
Geschäftsführer
Michael Schwarze ist Geschäftsführer von atra consulting und erfahrener Softwareentwickler, -architekt und -manager mit über 30 Jahren Erfahrung. Er hat in Startups und Konzernen gearbeitet und begeistert sich für moderne Softwarearchitekturen und dynamisch-typisierte Sprachen.
