- Teil 1: Die Angemessenheit von Komplexität
- Teil 2: Der Foerster und die Softwarearchitektur
- Teil 3: Mythos Teamautonomie
- Teil 4: Autonomie und Entscheidungen
- Teil 5: Ich, Du und Conway’s Law
- Teil 6: Conway hat immer Recht (dieser Artikel)
- Teil 7: Illegale Softwarearchitekturen
- Teil 8: Paradoxical Safety
- Teil 9: New Work: Taylorismus 2.0
Conway schrieb vor mehr als 50 Jahren:
The basic thesis of this article is that organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations. [1]
Diese Aussage ging als Conway’s Law in die Geschichte der IT ein und wird immer wieder zitiert, wenn es um Strukturen von Softwaresystemen geht. Das ist naheliegend, weil die Aussage einfach und logisch erscheint. Dazu kommt, dass sie in den meisten Fällen dem eigenen Bauchgefühl entspricht, wenn ein Softwaresystem betrachtet wird.
In der Praxis bringt Conway’s Law jedoch einige Stolperfallen mit sich und sollte mit Bedacht zitiert werden.
Eine Frage der Situation
Conway’s Law wird gewöhnlich in zwei Situationen referenziert: Entweder, weil ein neues Softwaresystem entstehen soll und die entsprechenden Organisationsstrukturen definiert werden müssen oder wenn ein existierendes Softwaresystem auditiert wird und Erklärungen für seinen Zustand gesucht werden.
Diese beiden Situationen müssen in Hinsicht auf Conway’s Law deutlich unterschieden werden. Denn auch wenn Conway’s Law in beiden Fällen Bestätigung findet, sind die Gründe anders als häufig angenommen.
Im ersten Fall wird gerne eine Idee wie das Inverse Conway Maneuvre referenziert. Auf diesem Weg wird versucht, Kommunikationsstrukturen in der Organisation zu erzeugen, die entsprechende Kommunikationsstrukturen in dem neuen Softwaressystem entstehen lassen. Es wird also der Versuch unternommen, durch Upfront-Design der Kommunikationsstrukturen die Entwicklung eines Systems zu beeinflussen.
Gerade genug Upfront-Design
Die Idee, dass das Schaffen bestimmter Kommunikationsstrukturen in einer Organisation, die ein Softwaresystem entwickelt, dazu führt, dass diese Kommunikationsstrukturen in dem Softwaresystem reproduziert werden, ist nach Conway’s Law naheliegend. Aus einer naiven Perspektive erscheint es logisch und sogar wissenschaftlich-theoretische erklärbar, warum das plausibel sein muss. Dabei führt die Umkehrung von Conway’s Law nicht einfach kausal zum intendierten Ergebnis.
Im Gegenteil: häufig funktioniert diese als Inverse Conway Maneuvre bezeichnete Idee in der Praxis nicht wie erwartet. Das liegt nicht etwa daran, dass Conway’s Law vielleicht falsch wäre. Ursache ist vielmehr, dass viele Menschen, die das Inverse Conway Maneuvre anwenden wollen, eine unvollständige Vorstellung von Kommunikationsstrukturen in Organisationen haben.
Im Softwareengineering gibt es klare Kommunikationsstrukturen. Zwei Softwarebausteine kommunizieren über eine wohl definierte technische Schnittstelle miteinander. Die Technologie einer solchen Schnittstelle kann verschieden sein, aber jede Kommunikation, die zwischen Softwarebausteinen stattfindet, wird immer über eine solche Schnittstelle laufen. Es gibt keinen kurzen Dienstweg zwischen zwei Komponenten - und wenn er „frecherweise“ doch implementiert wurde, dann als wohldefinierte Schnittstelle, die vielleicht nicht in der Dokumentation enthalten, aber definitiv im Code zu finden ist.
Diese Vorstellung übertragen viele Menschen auch auf Organisationen. Das Organigramm, in der Regel die Darstellung der Linienorganisation oder der Aufbauorganisation, wird als Abbild der organisationalen Kommunikationsstruktur begriffen, wie sie auch in Softwaresystemen beschrieben wird. Das ist nicht völlig falsch, denn dieses Modell der Organisation beschreibt die Seite der Organisation, die als formale Struktur bezeichnet wird. Diese formale Struktur ist das, was beispielsweise durch entschiedene Entscheidungsprämissen (siehe Heft 2022–02)[2] beschrieben werden kann und spiegelt einen Teil der Kommunikationsstruktur wider.
Neben der formalen Struktur gibt es aber noch zwei weitere Seiten einer Organisation. Das ist zum einen die sogenannte Schauseite, die Art und Weise, wie sich eine Organisation nach außen präsentiert. Die Schauseite ist für die Betrachtung von Conway’s Law eher uninteressant. Zum anderen gibt es die informelle Struktur. Diese besteht unter anderem aus den nicht entschiedenen Entscheidungsprämissen (siehe Heft 2022–03)[3] und aus informellen Kommunikationsstrukturen, die für das Verstehen von Conway’s Law von großer Bedeutung sind.
Conway hat bei seinen Beobachtungen nicht zwischen den formalen und informellen Kommunikationsstrukturen unterschieden. Da sich seine Beobachtung auf fertige Systeme bezog, war die Kommunikationsstruktur innerhalb des designten Systems sichtbar geworden und damit auch die Kommunikationsstruktur der Organisation. Es ist praktisch sehr aufwendig, retrospektiv zu unterscheiden, was Folge der formalen oder der informellen Kommunikationsstruktur ist. Möglicherweise ist das der Grund, warum Conway diese Unterscheidung nicht getroffen hat.
Genau darin liegt die Stolperfalle, die häufig übersehen wird, wenn das Inverse Conway Maneuvre angewendet werden soll. Wäre nur die formale Kommunikationsstruktur ausschlaggebend, würde dieses Vorgehen deterministisch zur intendierten Struktur des Softwaresystems führen. Aber in der Praxis wirkt sich die informelle Kommunikationsstruktur mindestens ebenso stark aus, wie die formale – häufig ist sie sogar die stärkere Kraft. Aber diese informelle Kommunikationsstruktur lässt sich eben nicht intentional gestalten. Die informelle Struktur (und damit auch die informelle Kommunikationsstruktur) ist die Reaktion der Organisation auf Gestaltungsversuche an der formalen Struktur. Diese Reaktion ist nur eingeschränkt vorhersagbar und kann nicht direkt gesteuert werden. Die Kommunikationsstruktur entsteht aus dem Zusammenwirken der formalen und der informellen Kommunikationsstruktur.
Die informelle Struktur von Organisationen wird heute gerne als Unternehmenskultur bezeichnet. Und weil, wie Peter F. Drucker es einst sagte, Kultur Strategie zum Frühstück verspeist, bleiben von der Strategie des Inverse Conway Maneuvre unter Umständen auch nicht viel mehr als Brotkrumen übrig.
Das heißt keinesfalls, dass es sich nicht lohnt, den Versuch zu unternehmen, bessere formale Strukturen für die Entwicklung guter Softwaresysteme zu schaffen. Ganz im Gegenteil: es ist in vielen Organisationen dringend nötig. Aber es bedeutet auch, dass das Definieren der formalen Strukturen nicht ausreicht. Sie müssen ständig angepasst werden an das, was als Struktur im Softwaresystem zu erkennen ist.
Strukturelle Denkfehler
Wie oben beschrieben, gibt es eine zweite Situation, in der Conway’s Law bemüht wird. Vor dem Hintergrund solcher Situationen wurde Conway’s Law überhaupt erst entdeckt. In einer solchen Situation wird zurückschauend nach Ursachen für Probleme eines Softwaresystems gesucht.
Die Probleme, nach deren Ursachen gesucht wird, können vielfältig sein: Die Weiterentwicklung geht nicht mehr so schnell, wie gewünscht; es treten häufiger Fehler auf oder die Migration auf eine neuere Technologie erscheint als nicht möglich oder ist gar gescheitert. So vielfältig die Probleme sind, so vielfältig können die Ursachen sein. Steht jedoch Conway’s Law im Raum, werden mit Sicherheit die Strukturen der Organisation als Ursache der Probleme identifiziert. Diese sind notwendigerweise in der Software zu finden, wie oben bereits erklärt.
Für die Tendenz, Conway’s Law retrospektiv als Ursache von Problemen heranzuziehen, ließen sich vielerlei Gründe finden. Eine spannende Erklärung lässt sich anhand von kognitiven Verzerrungen formulieren, die mittlerweile in der Psychologie sehr gut erforscht sind.
Als Beispiel sei der Rückschaufehler genannt, mit der Annahme, die Kommunikationsstruktur hätte nur rechtzeitig anders gestaltet werden müssen – oben wurde bereits argumentiert, warum das so einfach nicht ist. Ein weiteres Beispiel ist der Bestätigungsfehler, der dazu führt, dass beim Verdacht Conway’s Law sei schuld an den Problemen, Indizien, die das bestätigen, häufiger gefunden werden, weil primär nach ihnen gesucht wird – und andere Indizien einfach übersehen werden. Und das, obwohl Conway’s Law einfach einen Sachverhalt beschreibt und keinesfalls Ursache von irgendetwas ist. Auch der Überzeugungsfehler, die Clustering-Illusion, Dichotomie oder sogar eskalierendes Commitment können dazu führen, dass Conway’s Law als Erklärung für Probleme des Softwaresystems herhalten muss.
Dabei hilft Conway’s Law überhaupt nicht bei der Aufklärung und es nützt auch nichts, nach Bestätigung zu suchen, denn die Soziologie zeigt:
retrospektiv ist Conway’s Law immer zutreffend.
Es ist praktisch nicht möglich, dass Conway’s Law nicht zutrifft. Denn jedes Softwaresystem, egal ob es ein gutes oder schlechtes Design aufweist, ist eine Reproduktion der Kommunikationsstrukturen der Organisation, die es erschaffen hat.
Conway’s Law bietet keine Handlungsleitung, außer der, Strukturen zu beobachten und zu verändern. Deshalb sind Fragen, wie gut eine Organisation Conway’s Law erfüllt, nicht zielführend. Conway’s Law kann nicht nicht erfüllt werden. Conway’s Law sagt aber eben auch nichts über die Qualität der Strukturen eines Softwaresystems aus, sondern nur über die Zwangsläufigkeit ihres Entstehens.
Diese Desillusionierung in Bezug auf die praktische Bedeutung von Conway’s Law wirkt sehr ernüchternd. Das mag daran liegen, dass es so einfach und einleuchtend erscheint und von so vielen als handlungsleitend beschrieben wird. Aber gerade weil sich da ein Gefühl der Ernüchterung breit machen kann, sollten Sie in Bezug auf Conway’s Law auf keinen Fall dem Wahrheitseffekt zum Opfer fallen.