Conway's Law
 |
| Bild: Pixabay / Succo - Lizenz |
Wenn irgendwo über gute und schlechte Software-Architektur diskutiert wird, wird mit grosser Wahrscheinlichkeit früher oder später das so genannte Conway's Law erwähnt werden, und zwar entweder als Antipattern das man unbedingt vermeiden sollte oder als häufig anzutreffender Wildwuchs, der möglichst schnell zu beseitigen ist. Einigkeit besteht aber immer darüber, dass es etwas Schlechtes ist. Es lautet folgendermassen:
Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.
Auf Deutsch: Organisationen die IT-Systeme entwerfen neigen dazu, die System-Designs so zu gestalten, dass sie Kopien ihrer Kommunikationsstrukturen sind.
Dieses "Gesetz" verdanken wir Melvin Conway, einem amerikanischen Software-Entwickler, der die Beobachtung auf der es beruht bereits in den 60er Jahren machte. Popularisiert (und mit seinem heutigen Namen versehen) wurde Conway's Law erst ein Jahrzehnt später von Frederick Brooks in seinem bis heute häufig zitierten Buch The Mythical Man Month. Und gültig und in vielen Organisationen zu beobachten ist es bis heute.
Dass Conway's Law immer wieder auftritt erklärte Conway damit, dass in grossen Organisationen häufig eine nur eingeschränkte Sicht auf Abläufe und Strukturen vorliegt. Eine Abteilung erkennt zwar wer ihr Informationen übergibt (z.B. ein Manager) oder wer sie von ihr entgegennimmt (z.B. eine nachgelagerte Organisationseinheit), wo sie ursprünglich entstehen, wo sie letztendlich enden oder durch welche anderen Stationen sie gehen ist aber nicht nachvollziehbar.
Bedingt dadurch wird bei vielen Digitalisierungs- oder Automatisierungs-Vorhaben immer nur an den Bereichen gearbeitet die bekannt sind, also zwischen der eingehenden und ausgehenden Kommunikationsschnittstelle liegen. Da das nicht nur in einer Abteilung stattfindet, sondern tendenziell jede so vorgeht, entsteht nach und nach für jede der Abteilungen ein entsprechendes IT-System, so dass die Systemlandschaft am Ende dem Organisationsaufbau entspricht.
Dieser Effekt mag auf den ersten Blick unproblematisch erscheinen, er ist es aber nicht. Wenn z.B. zwei Abteilungen unabhängig voneinander eine Übersicht über die Firmenkunden erhalten, sie aufgrund von Conway's Law in verschiedenen Systemen ablegen und sie nur um die jeweils eigenen Informationen zu Verkäufen, Verträgen, Beschwerden, etc. erweitern, dann wird eine firmeweite Sicht auf die Kundenbeziehungen unmöglich.
Auch weitere Probleme sind leicht vorstellbar. Verschiedene Abteilungen können z.B. die selben Daten benötigen, die dadurch von Kunden oder Kollegen redundant in verschiedene Systeme eingegeben werden müssen, sie können unterschiedliche Dateiformate verwenden, die nicht in andere Systeme übertragbar sind oder sie können unterschiedliche Vorgaben für Datenmengen oder IT-Sicherheit haben, durch die die verschiedenen Systeme inkompatibel werden.
Zuletzt werden Änderungen von übergreifender Bedeutung schwierig und aufwändig. Soll etwa in alle personenbezogenen Datensätze das neue Information "Arbeitsadresse" eingeführt werden muss ermittelt werden an welchen Stellen das nötig ist und ob es überall gleich umgesetzt werden kann, dazu muss die zeitgleiche Umsetzung koordiniert werden, möglichweise einschliesslich der Auflösung von Planungs- und Priorisierungskonflikten. All das kostet Zeit und Geld.
Um diese Auswirkungen zu vermeiden sollte versucht werden die Ursachen für Conway's Law zu beseitigen, indem Digitalisierungs- oder Automatisierungs-Vorhaben immer aus einer übergreifenden Perspektive konzipert werden. Um das zu erreichen gibt es zwei grundlegend unterschiedliche Ansätze: man kann zentrale Kontroll- und Koordinationsinstanzen schaffen, oder die Code Ownership auflösen und allen Einheiten erlauben übergreifend am Gesamtsystem zu arbeiten.
Der klassische Weg in den meisten Organisationen ist der erste, also die zentrale Kontroll- und Koordinationsinstanz, die versucht den zentralen Überblick zu wahren. Aus einer "agilen Weltsicht" ist dagegen die zweite besser, die aber eine Reihe von Voraussetzungen erfordert: übergreifendes System- und Business-Verständnis der Entwicklungsteams, Clean Code, hohe Testabdeckung und eine Einigung auf gemeinsame Standards in Formatierung, Programmierung, etc.
