Wie man Conway’s Law begegnet

Praxis-Check Software-Architektur: Conway’s Law auf der Spur

Hartmut Schlosser

©

In Diskussionen um zeitgemäße Software-Architektur darf das Gesetz von Conway nicht fehlen: Die Struktur einer Software hängt von der Organisationsstruktur des Unternehmens ab. Doch was bedeutet diese Beobachtung für die Praxis der Software-Entwicklung? Erfahrene Software-Architekten erklären, warum Conway’s Law im Kontext von Domain-driven Design und Microservices relevanter ist denn je.

Praxis-Check Software-Architektur

Melvin E. Conway hat 1968 die Beobachtung angestellt, dass das Design von Systemen Kopien der Kommunikationsstrukturen der Unternehmen darstellen, die diese Systeme entwickeln. Was bedeutet das konkret für  Software-Architekten?

Hängen Software-Architekten in ihrer Arbeit davon ab, wie ein Unternehmen mit den Kunden kommuniziert, wie sich die Abteilungen des Unternehmens untereinander austauschen, wie die IT intern aufgebaut ist, wie die Mitglieder der einzelnen Team miteinander reden und zusammenarbeiten?

Wir haben mit sieben Software-Architekten über die Erscheinungsformen und Auswirkungen von Conways Gesetz gesprochen. Im ersten Teil dieser Reihe verraten sie uns, wo ihnen Conway’s Law bereits begegnet ist und wie man festgefahrene Unternehmensstrukturen, die sich negativ auf Software-Architekturen auswirken, aufbrechen kann.

Conway’s Law in der Praxis

Die Experten

Dr. Carola Lilienthal ist CEO bei der WPS – Workplace Solutions GmbH. Seit 2003 analysiert sie die Zukunftsfähigkeit von Softwarearchitekturen und wendet in ihren eigenen Projekten DDD an.

Ralf D. Müller arbeitet als Architekt und Entwickler und erlebt täglich die Notwendigkeit effektiver Dokumentation. Er ist erklärter AsciiDoc-Fan und Committer bei arc42 sowie Gründer des docToolchain Projektes.

Stefan Tilkov ist Geschäftsführer und Principal Consultant bei der innoQ Deutschland GmbH, wo er sich vorwiegend mit der strategischen Beratung von Kunden im Umfeld von Softwarearchitekturen beschäftigt.

Dr. Gernot Starke (innoQ Fellow), ist Gründer und Maintainer der Open-Source-Architekturprojekte arc42 und aim42, (Mit-)Gründer und aktives Mitglied des iSAQB sowie Autor mehrerer Fachbücher.

Lars Röwekamp, Gründer des IT-Beratungs- und Entwicklungsunternehmens OPEN KNOWLEDGE GmbH, beschäftigt sich im Rahmen seiner Tätigkeit als „CIO New Technologies“ mit der eingehenden Analyse und Bewertung neuer Software- und Technologietrends.

Eberhard Wolff ist Fellow bei innoQ und arbeitet seit mehr als fünfzehn Jahren als Architekt und Berater, oft an der Schnittstelle zwischen Business und Technologie.

Matthias Bohlen ist Softwarearchitekt und Mitglied des iSAQB. Mit seinen Coaching-Programmen hilft er Führungskräften und Teams dabei, profitable Produkte zur Tür hinaus zu bekommen, ohne dabei den Verstand zu verlieren.

Ein Beispiel aus deiner Praxis: Wo wurde dir Conway’s Law ganz deutlich vor Augen geführt?

An den Schnittstellen traten häufig Missverständnisse auf.

Carola Lilienthal: Bei einem Kunden von uns waren die Teams nach Programmiersprachen geschnitten, so dass ein Team für die C#-Clients, ein Team für die Java-Server-Komponenten und ein Team für das PLSQL in den Datenbanken zuständig war. Diese Aufteilung führte dazu, dass die fachlichen Begriffe in den einzelnen sprachlichen Teilen und auch Teams nicht einheitlich verwendet wurden und so an den Schnittstellen häufig Missverständnisse auftraten. Kunden, die verschiedene Clients benutzten, hatten ein einheitliches Frontend, aber die Abstimmung zwischen den Programmiersprachenteams kostete viel Zeit und führte immer wieder zu Hacks, damit die Teile zusammen passen.

Schließlich hat der Kunde auf Feature-Teams umgestellt, in denen jeweils Team-Mitglieder mit unterschiedlichen Programmiersprachenkenntnissen an einem Feature zusammen arbeiten. In der darauffolgenden Zeit wurde die fachliche Struktur der Software viel klarer. Es wurde allmählich möglich, fachlich geschnittene Microservices mit ihrem eigenen Datenbankschema und ihrem eigenen Client-Code zu separieren. Je länger die Teams so arbeiteten, desto eher kam es nun vor, dass die Oberfläche an Einheitlichkeit verlor. Jedes Team machte seine eigenen Oberflächen unabhängig von den anderen Teams.

Schließlich wurde ein kleines Team eingeführt, das dafür zuständig ist, auf die Einheitlichkeit der Oberfläche zu achten.

Ralf D. Müller: Die Auswirkungen von Conway’s Law sehe ich persönlich bei Web-Projekten vor allem direkt in den Projektteams, weniger in der Organisation, in die das Projektteam eingebettet ist. So macht es z.B. einen großen Unterschied, ob man in einem Web-Projekt reine “Full-Stack”-Developer einplant oder die Umsetzung auf Backend- und Frontend-Entwickler verteilt. Die entstehenden Softwarestrukturen unterscheiden sich nicht nur im Schnitt, sondern auch in der Komplexität. Dies macht sich aus meiner Sicht gerade bei modernen Frontend-Frameworks wie Angular oder React stark bemerkbar.

Aber auch der vertikale Schnitt durch die Aufteilung eines Projekts auf mehrere agile Teams hat einen entsprechend großen Einfluss auf das Ergebnis.

Lesen Sie auch: Das sind die Software-Architektur-Trends 2017

Stefan Tilkov: Das vielleicht offensichtlichste Beispiel sind die vielen Web- und E-Commerce-Systeme, die oft durch eine Initiative einer Marketing-Abteilung entstanden sind und oft auch dort betreut wurden, während sich die restlichen Fachabteilungen mit der IT-Abteilung abstimmt, von ihr betreut wird oder sich mit ihr auseinandersetzt. In der Gesamtarchitektur spiegelt sich das dann auf einmal in einer Vielzahl wenig sinnvoller Redundanzen wider, die im Moment in vielen Unternehmen gerade aufgelöst werden.

Doch man findet die Effekte von Conway’s Law auch bei den vielen Querschnittsabteilungen, die sich verselbständigen und Systeme betreuen, die dann in einer Architektur als Fremdkörper auftauchen. Das können zentrale Datenbanken, monolithische Systeme oder Integrationsserver sein, die von einer Organisationseinheit regelrecht bewacht werden, sodass die Prozesse unglaublich aufwändig werden und jede Änderung mit massiven Schmerzen verbunden ist.

Aber auch wenn fast alles richtig gelaufen ist, bekommt man manchmal durch Unachtsamkeit frische Conway-Effekte: Es gab bei der Neuentwicklung eines großen Shopsystems eine schöne SCS-artige Architektur [1], bei der knapp zehn Teams hervorragend parallel arbeiten konnten, da die von ihnen realisierten Teilsysteme über wenige, standardisierte Schnittstellen miteinander kommunizierten, mit Hilfe von Redundanz auf Autonomie geachtet wurde, jedes Team volle Verantwortung für alle Schichten von Persistenz bis UI hatte – eigentlich eine wunderbare Struktur, bei der Architektur und Organisation aufeinander abgestimmt waren. Aber dann gab es die Initiative, für die Auslieferung von Frontend-Komponenten und -Assets ein zentrales Team aufzusetzen.

Das hat – wie jede Form der Zentralisierung – durchaus Vorteile, man muss z.B. alles nur an einer Stelle lösen. Es hat aber auch massive Nachteile – in diesem Fall konkret, dass das neu eingeführte zentrale Frontend-Team zum Bottleneck für alle anderen wurde. Die Architektur veränderte sich, mit allen Nachteilen, weil die Organisation sich im Zweifelsfall durchsetzt.

Gernot Starke: Darf ich voranstellen, dass ich „Conway’s Law“ für eine totale Fehlbenennung halte: Es sollte „Conway’s Observation“ heißen – weil es weder ein Gesetz noch eine eiserne Regel ist, sondern eine (empirische) Beobachtung.

Als Softwarearchitekten arbeiten wir häufig in einem Unternehmenskontext, bei dem wir auf organisatorische Randbedingungen meistens Rücksicht nehmen müssen, und selten einmal „organizational change“ anstoßen können, um diese Randbedingungen für unsere Entwicklung zu lockern. Meistens hingegen liegen organisatorische Änderungen außerhalb der uns zugestandenen Kompetenzen – und wir müssen mit der bestehenden Organisation leben.

Ich müsste eher überlegen, bei welchen meiner Projekte die interne Organisation keine Auswirkungen auf die Softwarestruktur hatte.

Zu der eigentlichen Frage, wo mir Conway bereits begegnet ist: Ich müsste eher überlegen, bei welchen meiner Kunden bzw. Projekte die interne Organisation keine Auswirkungen auf die Softwarestruktur hatte. Conway hat bei mir beispielsweise im Maschinenbau zugeschlagen:

Diverse Komponenten von Großmaschinen wurden von verschiedenen Ingenieurteams entwickelt, mit jeweils ziemlich speziellen Anforderungen. Die Software für die Rüstung dieser Maschinen war in komplett anderer Technologie entwickelt, genauso wie die Software zur Überwachung/Monitoring zur Laufzeit. Das hat Synergien gründlich verhindert 🙁

Ein zweites Beispiel stammt von Versicherungen: Dort habe ich Datenbankteams angetroffen, die losgelöst von den sogenannten Client/Server-Teams gearbeitet haben. Dann brauchte es noch eine dritte Gruppe, die Integrations-Leute, die C/S und DB zu den berüchtigten Deployment-Monolithen zusammengebracht haben.

Lars Röwekamp: Es ist für mich immer wieder faszinierend, feststellen zu „dürfen“, wie aktuell dieses vor fast 50 Jahren aufgestellte Gesetz heute noch ist. Wir als open knowledge sind häufig bei großen Kunden mit klassischen Konzernstrukturen im Einsatz. Die dort vorherrschenden, sehr komplexen Organisations- und Kommunikationsstrukturen sorgen nicht selten dafür, dass von speziellen Architektur-Teams extrem umfangreiche und hoch generische, konzernweite Architekturen vorgegeben werden.

Es ist faszinierend, wie aktuell dieses vor fast 50 Jahren aufgestellte Gesetz heute noch ist.

Die eigentlichen Anwendungen bzw. deren konkrete Fachlichkeiten werden dann via architekturspezifischer DSLs, XML-Konfigurationen oder irgendeinem anderen Voodoo-Ansatz auf mystische Art und Weise generiert. Was ursprünglich einmal gut gemeint war, führt in der Regel dazu, das selbst kleinste Features – dank Medienbruch – nur sehr umständlich umzusetzen sind und ein fachliches Debugging kaum noch möglich ist.

Als ich bei einem unserer größeren Kunden einmal Conway’s Law thematisiert habe, hat dieser das aktuelle Organisationsdiagramm und ein Schaubild der „gelebten“ Architektur gegenüber gestellt. Beide Schaubilder sahen sich erschreckend ähnlich und erinnerten eher an den U-Bahn-Fahrplan einer europäischen Großstadt als an ein strukturiertes und gut durchdachtes System.

Eberhard Wolff: Für mich ist das Gesetz von Conway ein wichtiges Werkzeug, um zu verstehen, was in Projekten vor sich geht. Wenn unterschiedliche Dienstleister für die verschiedenen Teile des Projekts verantwortlich sind, dann beeinflusst das die Kommunikation und die Architektur.

Kommunikation über Firmengrenzen hinweg ist aufwändig, insbesondere wenn die Teams am jeweiligen Firmenstandort des Dienstleisters arbeiten. So entstehen sehr isolierte Module. Ein Zusammenhalt der Architektur ist schwierig.

Dass Teams, die nach Fachlichkeiten aufgestellt sind, die Architektur beeinflussen, haben wir schon vor 15 Jahren in einem Projekt festgestellt. Allerdings haben wir es damals noch nicht zur Steuerung der Architektur genutzt.

Matthias Bohlen: Bei einem Kunden mit drei Entwicklungsteams wurde ich beauftragt, die Teams zu coachen, damit diese an der Architektur absichtlich und transparent arbeitennicht wie vorher auf Zuruf und bei absoluter Notwendigkeit, sondern mit der Absicht, Architekturarbeit als ganz normalen Bestandteil der täglichen Entwicklungsarbeit zu sehen. Es drehte sich um Medizintechnik.

Als ich mit den drei Teams in eine Bestandsaufnahme der Ist-Architektur ging, wurde schnell klar, dass Conway’s Law wirksam war: Das System war in drei Zuständigkeiten aufgeteilt: Team 1 machte EmbeddedSysteme, direkt an die Hardware angeschlossen. Team 2 machte die Management-Systeme zur Verwaltung der User und Geräte, und Team 3 kümmerte sich um HighSpeed-Netzwerktechnik, die zur Verbindung all dieser Geräte und der User diente. Die Kommunikationsgrenzen zwischen den Teams waren deutlich spürbar: Jedes Team löste seine Probleme selbst, teilweise redundant zu dem, was die anderen machten. Es gab jeden Frameworktyp (z.B. Loggingframework) jeweils in drei Geschmacksrichtungen.

Wo die Teams in Probleme gerieten, war folgende Stelle: Sie hatten das System in drei Aspekte aufgeteilt, die jedoch eng gekoppelt waren. Die High-Speed-Netzwerke konnte man nicht ohne die Embedded-Systeme betrachten, die Management-Systeme mussten wissen, wie viele Embedded-Geräte es gab und wie die Netzwerktopologie gestaltet war. So kam es, dass die Teams langsam wurden, weil sie trotz Teamgrenzen häufig etwas absprechen mussten.

Es wäre deutlich besser gewesen, sie hätten das System in klare Subsysteme geteilt, die wirklich unabhängig oder nur wenig abhängig sind, dann hätten sie deutlich schneller und entspannter arbeiten können.

W-JAX
Mike Wiesner

Data- und Event-driven Microservices mit Apache Kafka

mit Mike Wiesner (MHP – A Porsche Company)

Niko Köbler

Digitization Solutions – a new Breed of Software

with Uwe Friedrichsen (codecentric AG)

Wie man Conway’s Law begegnet

Man kann Conway’s Law als strukturalistisches Prinzip verstehen – die agierenden Objekte sind abhängig von den sie umgebenden Strukturen, d.h. auch den Beziehungen der Objekte untereinander. Was bedeutet das für den agierenden Software-Architekten?

Er kommt in ein Unternehmen, in dem bestimmte Strukturen vorherrschen – eine Unternehmenskultur, Abteilungsgrenzen, Teams, etablierte Prozesse und inoffizielle, als selbstverständlich angenommene Gepflogenheiten. Er ist aber auch mit Menschen konfrontiert, die diese Strukturen einerseits tragen und andererseits verändern können. Wo setzt man da als Architekt an, um negative Strukturen ein Stück weit aufzubrechen?

Welches Mittel hat sich in deiner Praxis bewährt, um den Effekten von Conway’s Law zu begegnen?

Das einzige Mittel, das sich in meiner Praxis bewährt hat, ist, mit Menschen direkt zu sprechen.

Carola Lilienthal: Das einzige Mittel, das sich in meiner Praxis bewährt hat, ist, mit Menschen direkt zu sprechen. Wenn ich in ein Unternehmen komme, um Veränderungsprozesse anzustoßen, dann gelingt mir das nur, indem ich zu den Beteiligten gehe und mit ihnen spreche. Für vorhandene Strukturen und Prozesse gibt es in jeder Organisation viele Gründe und Geschichten, die die Mitarbeiter miteinander erlebt haben und auf die sich ihr Verhalten aufbaut. Diese Geschichten muss man als Externer verstehen und würdigen, um Veränderungen in Gang setzen zu können.

Ralf D. Müller: Wie bei so vielen Problemen in der Softwareentwicklung gibt es hier wohl nicht die “Silver Bullet”, so dass man Probleme dieser Art je nach Situation angehen muss.

Stefan Tilkov: Am wichtigsten ist aus meiner Sicht, sich darüber klar zu werden, welchen Kampf man für den wichtigsten hält, um sich nicht an X Fronten gleichzeitig aufzureiben (wenn mir die militaristische Metapher gestattet ist). Also am besten das dringendste Problem identifizieren und sich zunächst auf dessen Lösung konzentrieren, anstatt gleich zu versuchen, alles auf einmal zu ändern. In unserer Architekturarbeit, aber auch in unseren Entwicklungsprojekten versuchen wir in aller Regel als erstes, wenige globale Regeln in Verbindung mit viel lokaler Autonomie zu etablieren. Damit beschränkt man die Entscheidungsfreiheit bestehender Strukturen und Teams zwar, aber nicht in einem zu großen Maße. Gleichzeitig schafft man die Möglichkeit, schrittweise Verbesserungen einzuführen.

Gernot Starke: Ja, Separation-of-Concern: für organisatorische Änderungen Leute dazuholen, die das professionell und Full-time machen. Als Softwarearchitekten neben der Entwicklungsarbeit noch schnell eine Abteilung oder gar Unternehmen umorganisieren wäre aus meiner Sicht ein etwas vermessener Anspruch…

Einer meiner Kunden hat das beherzigt und einen Profi für „Change Management“ angeheuert – eine erfahrene, empathische und trotzdem durchsetzungsstarke Dame. Sie hatte sowohl strategisches wie politisches Verständnis, hat die Software-Teams „mitgenommen“, aber auch das Management. Diese Zusammenarbeit war für mich eine positive Erfahrung, weil sich durch ihre Arbeit in diesem Unternehmen wirklich Dinge positiv verändert haben – was viele Software-Teams in den Jahren vorher nicht annähernd geschafft hatten.

Lars Röwekamp: Hier sprichst du ein sehr wichtiges Thema an. In vielen Unternehmen herrschen historisch bedingt Strukturen vor, die von den meisten Mitarbeitern einfach als von Gott gegeben hingenommen und somit nicht mehr hinterfragt werden. Es kommt daher nicht von ungefähr, dass sich gerade in großen Unternehmen immer wieder kleine Lab-ähnlich Teams herausbilden. Dies ist häufig die einzige Möglichkeit, legitim aus den vorgegebenen Strukturen auszubrechen. Projekte werden als Prototypen oder Proof-of-Concepts getarnt, da für diese weniger starre Auflagen gelten als für normale Software-Projekte.

Lesen Sie auch: Domain-driven Design im Experten-Check: Warum ist DDD heute relevanter denn je?

In meiner Rolle als Architekt hinterfrage ich grundsätzlich den Nutzen bestehender Strukturen, Frameworks etc. Kann mir keiner der Beteiligten einen sinnvollen Grund für das Vorhandensein nennen – „das war schon immer so“ ist übrigens KEIN sinnvoller Grund – dann stelle ich dass Konstrukt auf den Prüfstand und entsorge es gegebenenfalls.

Psychologisch gesehen sollte man hier natürlich mit einem gewissen Feingefühl vorgehen. Oftmals wird ein architektonisches Refactoring als eine Art Schuldeingeständnis für eine Fehlplanung der Vergangenheit interpretiert. Dies ist insbesondere dann der Fall, wenn sich spezielle Teams für die Architektur verantwortlich zeichnen und andere für die Implementierung der Anwendungen auf Basis dieser Architektur. Hier ist ein Finger-Pointing quasi vorprogrammiert. Es ist also wichtig zu vermitteln, dass Software lebt und Refactoring somit einen ganz natürlich Prozess darstellt, um auf geänderte Anforderungen bzw. einen geänderten Kontext zu reagieren.

Software-Architektur ist nur scheinbar ein technisches Thema.

Eberhard Wolff: Bei der Einstellung von Mitarbeiten oder bei Umorganisationen werden Architekten oft mit einbezogen, da sie die technische Expertise der Personen am besten abschätzen können. Dann können sie auch andere organisatorische Maßnahmen vorschlagen, um die Architektur zu beeinflussen.

Generell ist Software-Architektur nur scheinbar ein technisches Thema. Ein Architekt muss Ideen und Kritik aus den Teams aufnehmen und die Architektur kommunizieren. Diese Maßnahmen beeinflussen die Kommunikationsstrukturen und damit die Architektur.

Matthias Bohlen: Als erstes Transparenz herstellen. Die beteiligten Teams sind meist schon so lange im Geschäft, dass sie wegen leichter Betriebsblindheit nicht mehr in jedem Fall erkennen, wenn Architektur und Organisation nicht mehr zusammenpassen. Gerade wenn sich (wie heute) das Geschäft stark verändert, sind andere Architekturen hilfreicher als früher, um agil zu bleiben und schnell reagieren zu können. Es ist gut, wenn ein Architekt, der das erkennt, mal kurz prüft, wie es mit Conway’s Law bestellt ist und darauf aufmerksam macht. Dann können die Führungskräfte und Teams entscheiden und notwendige Veränderungen herbeiführen.

Im zweiten Teil dieser Reihe verraten die Experten, was gute Software-Architektur ausmacht und welchen Grad der Flexibilität für ein System gesund ist. Bleiben Sie dran!

Hintergrund zum Thema:

Conway 2.0: Wie Architekturstile agile Zusammenarbeit fördern oder behindern

Verwandte Themen:

Geschrieben von
Hartmut Schlosser
Hartmut Schlosser
Hartmut Schlosser ist Redakteur und Online-Koordinator bei Software & Support Media. Seine Spezialgebiete liegen bei Java-Enterprise-Technologien, JavaFX, Eclipse und DevOps. Vor seiner Tätigkeit bei S & S Media studierte er Musik, Informatik, französische Philologie und Ethnologie.
Kommentare
  1. Praxis-Check Software-Architektur: Conway’s Law auf der Spur – Bizzcheck.de2017-08-14 14:03:13

    […] Ein Beispiel aus deiner Praxis: Wo wurde dir Conway’s Law ganz deutlich vor Augen geführt? An den Schnittstellen traten … (Orginal – Story lesen…) […]

  2. Praxis-Check Software-Architektur: Conway’s Law auf der Spur – JAXenter – BB-10 – Aktuell2017-08-14 15:05:16

    […] JAXenter […]

  3. TestP2017-08-14 17:04:08

    Tolle Interviews, danke. :)

    Grüße

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.