Software, die sich schnell verändern kann, wird ein immer bedeutenderer Teil jedes Unternehmens. Cloud Native steht dabei als zentraler Katalysator dieser neuen Softwaregeneration aktuell hoch im Kurs und traditionelle Software-Architekturen werden damit mehr und mehr auf den Kopf gestellt. Die empirische Cloud Native Studie 2022 „Viel mehr als nur Technologie“, die Cloudflight zusammen mit IONOS by 1&1 erhoben hat, zeigt, dass 43 Prozent der Unternehmen in DACH planen Cloud Native auszubauen.
Jedoch ist es wichtig, dass beispielsweise Microservices, Serverless und Co. nicht eingesetzt werden, weil es gerade modern ist, sondern weil sich ein Unternehmen dadurch erfolgreich differenzieren und individualisieren kann. Gerade in Unternehmen mit einer fest eingefahrenen Organisation, geht die Einführung und der Einsatz von neuen Technologien nicht immer ganz leicht von der Hand. Hier kann darin sogar ein struktureller Nachteil liegen, der besonders bei Architekturinnovationen zur Geltung kommen. Doch gerade in der heutigen Zeit ist es wichtig, dass ein Architekturansatz anpassbar bleibt und auf Veränderungen reagieren kann. Systeme werden nicht mehr für die Ewigkeit (Built to Last), sondern zur Veränderlichkeit (Built to Replace) gebaut. Oder, wie der US-amerikanische Informatiker Fred Brooks[1] es sinngemäß formulierte: Weil wir am Anfang nie die beste Lösung gebaut haben, müssen wir in der Lage sein, das Konzept zu ändern und flexibel zu sein. Und das gilt für Systeme und Unternehmen gleichermaßen.
Der folgende Beitrag soll Entscheider:innen einen Einblick darüber geben, wie „Conways-Law-Projekte“ in Unternehmen beeinflussen kann. Gleichzeitig dient er als Hilfestellung, die zeigt, wie das Gesetz als Werkzeug bei der Einführung von Cloud Native und Co. genutzt werden kann. Sollten Sie bei Entwicklung und Betrieb Experten benötigen wenden Sie sich gerne an uns. Cloudflight unterstützt Sie bei der vollständigen Umstellung Ihrer Entwicklungsprozesse auf Cloud Native und stellt den Betrieb der von uns entwickelten Lösungen sicher.
Das Gesetz von Conway
JavaScript-Experte Douglas Crockford[2] hat kein Verständnis dafür, dass wir uns die ganze Zeit mit den Auswirkungen von Fehlern herumschlagen, die vor vielen Jahren gemacht wurden und weiß: ”The structure of software systems tend to reflect the structure of the organization that produce them.“ Doch die Strukturen in einem Unternehmen sind nicht immer eingefahren und starr, sondern verändern sich (z.B. durch neue Produkte oder im Zuge neuer Unternehmensziele). Entsprechend muss auch die IT-Infrastruktur angepasst werden. Andernfalls treten Spannungsverhältnisse auf, die darauf zurückzuführen sein können, das Unternehmen und Infrastruktur nicht (mehr) zusammenpassen.
Ganz so einfach ist es natürlich nicht. Wenn es nach dem Informatiker Melvin E. Conway[3] geht, sind die Strukturen von Systemen durch die Kommunikationsstrukturen der sie umsetzenden Organisationen vorbestimmt. Diese Beobachtung reichte er im Jahr 1968 mit dem Paper How Do Committees Invent? ein. “Organizations which design systems […] are constrained to produce designs which are copies of the communication structures of these organizations.”
Seine Aussage, dass Organisationen also Systeme entwerfen, die ihre Kommunikationsstrukturen kopieren, ist mittlerweile mehr als nur eine Hypothese. Wenngleich sein Paper aufgrund fehlender Belege vom Harvard Business Review abgelehnt wurde, gibt es mittlerweile zahlreiche Studien, die auf die Richtigkeit der Theorie hinweisen.
Vom Entwurf zum System
Der von Conway benutzte Begriff des Systems bezieht sich nicht nur auf die von einem Unternehmen genutzten IT-Systeme, sondern betrachtet ebenfalls Produkte und Dienstleistungen, die von diesem hervorgebracht werden.
Laut Conway wird jedes Unternehmen, welches ein System entwickelt, unausweichlich ein Design erzeugen, dass in der Struktur die Kommunikationsstruktur der Organisation kopiert. Das eigentliche Design kann aber erst entstehen, wenn bestimmte vorläufige Meilensteine erreicht sind. Dazu gehören:
- Das Verständnis der Grenzen, die sowohl der Entwurfstätigkeit als auch dem zu entwerfenden System durch Auftraggeber:innen und die realen Gegebenheiten gesetzt sind
- Das Erreichen einer vorläufigen Vorstellung von der Organisation des Systems, damit die Entwurfsaufgaben sinnvoll verteilt werden können.
Bei Aktivitäten, die sich auf das Systemdesign beziehen, müssen ständig Entscheidungen getroffen werden. Viele dieser Entscheidungen sind nicht nur Designentscheidungen, sondern auch persönliche Entscheidungen, die das Team von Personen, die an der Software arbeitet, über ihre eigene Zukunft trifft und die teilweise schon getroffen sind. So ist eine Implikation Conways, dass Personen ihren Beiträgen zu einem Softwareprojekt immer einen eigenen individuellen Stempel aufdrücken und dass sie von Natur aus nicht fähig sind, auf einheitliche Weise zusammenzuarbeiten, um Quellcode zu schreiben.
Weiterhin beschreibt Conway, dass es möglich ist, Aktivitäten an eine Untergruppe zu delegieren, sobald ein Unternehmen ein Designteam ausgewählt hat. Doch auch dabei wird das potentielle Ergebnis der Designaktivitäten geschmälert. Wenn die Tätigkeitsbereiche definiert sind, kann wiederum ein Koordinationsproblem entstehen.
In der Praxis sind die genannten Untergruppen beispielsweise UI, Back-End, Datenbank, Geschäftsprozesse, die in Kommunikation miteinander stehen müssen, um erfolgreich zusammenarbeiten zu können. Wenn die Kommunikation jedoch an einer Stelle einseitig ist oder fehlt, schlägt dies Wellen und andere Untergruppen leiden darunter. Eine effektive Kommunikation führt zu besseren Ergebnissen (z.B. Lieferzeiten, Qualität), die bei jedem Sprint weniger überarbeitet werden müssen.
Bei der Anforderungsanalyse mit Kunden gibt es unterschiedliche Geschäftsabläufe, Spezialisierungen und Bedürfnisse, die für die Software relevant sind und an ein Developer-Team weitergeleitet werden. Auch hierbei ist die Kommunikation entscheidend, denn jede Abteilung, ob Vertrieb oder Produktion, wird ihre eigene Ansicht vermitteln. So können Einschränkungen beim Entwerfen von IT-Systemen entstehen.
Christoph Holter, Project Lead bei Cloudflight bestätigt die Herausforderung: „Ich habe es schon selbst in Projekten erlebt, wie es ist, wenn die eine Hand nicht weiß was die andere tut. Engineering und Product haben nicht miteinander geredet. Engineering hat entsprechend Entscheidungen getroffen, die für das Team Product völlig unbrauchbar erschienen – und vice versa. Ich habe mich redlich bemüht als Vermittler zu agieren und bin fast schon in die Rolle eines Product Owners geschlüpft. Leider vergebens.“
It’s all about the team
Die Architektur eines IT-Systems hängt von Ort, Zeit, Wissen sowie Technologie ab und ist damit nicht absolut. Ein System, das durch eine Gruppe entwickelt wird, das Sub-System durch ein Team und die Schnittstelle von einem Teamleader – oder alternativ kann man das Ganze in ein Enterprise System, Microservices und Klassen aufteilen – schafft einen begrenzten Rahmen auf Organisationsebene. Das heißt Organisationen sind begrenzt flexibel. Unterschiedliche Teamkonstellationen kommen zu unterschiedlichen Lösungen. Je nach Wissensstand und Organisationsform wird das Ergebnis unterschiedlich beeinflusst.
Besonders komplexe IT-Systeme scheinen häufig große Schwierigkeiten in der Architektur zu verursachen und drohen nicht selten sogar zu zerfallen. Prominente Beispiele dafür gibt es zahlreiche, vor allem in Zusammenhang mit der Einführung von SAP. Neben Lidl, Haribo oder Otto, steckte auch die Deutsche Bank Millionensummen in ein SAP-Projekt, bevor es letztlich scheiterte, weil die Unternehmensprozesse nicht angepasst wurden.
Neben der fehlenden Anpassung, Zeitdruck oder Budgetschwierigkeiten kann es auch der Komplexität geschuldet sein, dass große IT-Projekte scheitern. Sind die Grenzen des Verständnis für die Komplexität eines Systems erreicht, werden die Systeme entweder so weit runtergebrochen, bis es verstanden wird oder bis die Kontrolle darüber verloren geht.
Probleme dieser Art münden häufig in Aussagen wie diesen: „Es ist wirklich ein großes Projekt. Ich habe es mit einem Team von 50 Entwickler:innen versucht und es funktioniert nicht.”
Aus einer rein buchhalterischen Sicht sind vier Entwickler:innen, die 50 Tage arbeiten das gleiche wie acht Entwickler:innen, die 25 Tage arbeiten. Im Ergebnis liefern die zwei Teams jedoch unterschiedliche Systeme. Das System der vier Entwickler:innen wird voraussichtlich besser sein als das des achtköpfigen Teams. Denn je mehr Personen an einem System beteiligt sind, desto mehr Kommunikationsbeziehungen existieren und desto komplexer wird es typischerweise, so Conway. Ähnlich beschreibt es Fred Brooks in seinem Buch The Mythical Man-Month: “Adding manpower to a late software project makes it later.”
Daraus leitete Parkinson[4] sein Gesetz ab: Arbeit lässt sich wie Gummi dehnen, um die Zeit auszufüllen, die für sie zur Verfügung steht. Wenn die Zahl der Arbeitnehmer:innen steigt, wird die Arbeit so aufgebläht, dass die Zeit aller zur Verfügung stehenden Arbeitnehmer:innen ausgelastet ist. Folglich werden aber auch die Kommunikationsbeziehungen immer komplexer, bis die Kommunikation zusammenbricht. Das gleiche geschieht mit der Architektur.
Inverse Conway Manöver
Im Rahmen des Inverse Conway Manöver werden die organisatorischen und systemgestalterischen Herausforderungen aus einer andere Perspektive betrachtet. Während Conway sagt, dass der Aufbau des Unternehmens und die zwischenmenschlichen Beziehungen der Personen im Unternehmen einen direkten Einfluss auf die Gestaltung der produzierten technischen Systeme haben, beschreibt das Inverse Conway Manöver das Prinzip der anderen Pfadrichtung. Wenn ein bestimmtes System das Ergebnis sein soll, muss das zunächst auf der Organisationsebene abgebildet werden. Entsprechend treibt es organisatorische Veränderungen voran, die auf die Kommunikationsstrukturen abzielen und die Interaktion der Teams betrachtet.
Die richtige Aufstellung – Ein Fazit
“You should never be able to reverse engineer a company’s organizational chart from the design of its product. ” Eric Schmidt[5], How Google Works.
Softwaresysteme entwickeln sich aus bloßen Tastatureingaben zu komplizierten funktionalen Netzwerken, die viele zusammenarbeitende Module, Objekte, Klassen, Methoden und Unterprogramme miteinander verbinden. Und gleichzeitig spiegeln sie die Kommunikationsstrukturen einer Organisation wieder.
Conways Law ist ein mächtiges Konzept, welches bislang noch von den wenigsten verinnerlicht wurde. Es beschreibt, wie tief die existierende Kommunikationsstruktur eines Unternehmens mit den Tätigkeiten oder dem Endprodukt des Unternehmens verbunden ist. Um nun also von einer flexiblen IT-Infrastruktur zu profitieren und Systeme schrittweise verändern zu können, müssen Unternehmen und deren Kommunikationsstrukturen ebenso schlank und anpassungsfähig aufgestellt sein. Bei Projektstart sollten die beteiligten Stakeholder sowie Schnittstellen klar identifiziert werden, sodass wirklich die Entscheidungen getroffen werden, die sicherstellen, dass im Ergebnis das richtige System entspringt.
Droht ein laufendes Projekten zu scheitern, hilft häufig Unterstützung von außen. Neben erfahrenen Projekt- oder Change Managern können Agile Coachs als Troubleshooter fungieren. Zur Lockerung starrer struktureller Grenzen haben vor allem Scrum Master einen wichtigen Wirkungsbereich. Aber auch im kleinen Rahmen können Events wie Teamausflüge oder eine Gruppe von Mitarbeiter:innen mit kreativen Methoden ins Erleben von Agilität gebracht werden, die sukzessive für Austausch und Kommunikation in der gesamten Organisation führen.
Um die Veränderung hin zu einer modernen Softwarearchitektur erfolgreich zu begleiten, braucht es vor allem Entscheider:innen, die bedingungslos hinter diesem Projekt stehen und ein Unternehmen dazu bewegen kann, die alten Prozesse und Abläufe dahingehend anzupassen. Sicherlich ist auch die Frage, ob solche komplexen neuen Systeme überhaupt notwendig sind, durchaus legitim. Wer zunächst dachte, dass Standardlösungen die pauschale Antwort auf Conway sind, lag falsch. Die meisten Standardlösungen haben sehr viele Konfigurationsmöglichkeiten und ermöglichen die Entwicklung eigener Erweiterungen, ohne den Kern der Software zu verändern. Standards gehören dann zur bevorzugten Strategie, wenn die eigenen Prozesse oder die technologischen Möglichkeiten nicht ausreichend verstanden sind und sie nicht eingesetzt werden, um sich vom Wettbewerb zu differenzieren.
Wer den Einsatz von Microservices und Co. fokussiert, weil die Entwicklung dadurch skaliert wird und mehr Personen in den Projekten mitarbeiten können, sollte aufpassen, das System nicht künstlich aufzublähen, um schließlich mit Architekturproblemen dazustehen.
Folgende Handlungsempfehlungen können im Weiteren daraus abgeleitet werden:
- Conscious Lock-In: Standards für Infrastruktur, Security, Monitoring etc. die nicht differenzieren, sollten genutzt werden. Dabei sollten bewusste Entscheidungen für einen Lock-In getroffen werden, die Cost of Change bekannt sein bzw. notwendige Maßnahmen vorbereitet sein (bspw. Infrastruktur-Wechsel, neue Tools, Skalierung usw.)
- Entkopplung und Microservices: Aufspaltung der Software- und Plattform-Architekturen in kleine Microservices, die unabhängig voneinander entwickelt, gewartet und integriert werden können (Es gibt aber auch Ausnahmen, wo Monolithen immer noch sinnvoll sein können!)
- APIs und Integration: Hoher Vernetzungsgrad und gute Dokumentation mit zentralen und standardisierten API-Management-Lösungen
- Trial and Error: Lieber schnell starten, statt bis Ultimo an dem perfekten Plan arbeiten
- If you can’t beat them, join them: Wenn es für einen Service oder eine Software einen besseren Standard gibt, sollte dieser eingesetzt werden
| [1] Fred Brooks: Frederick Phillips Brooks, Jr. (* 19. April 1931 in Durham, North Carolina, USA) ist ein US-amerikanischer Informatiker. Bekannt wurde Brooks zunächst als Verantwortlicher für die Entwicklung des OS/360 bei IBM und später für die ehrliche Beschreibung des Entwicklungsprozesses in seinem Buch The Mythical Man-Month (deutsch Vom Mythos des Mann-Monats: Essays über Software-Engineering). Quelle: https://de.wikipedia.org/wiki/Frederick_P._Brooks |
| [2] Douglas Crockford: Douglas Crockford ist ein US-amerikanischer Programmierer, der an der Entwicklung der JavaScript-Sprache beteiligt ist. Er hat das Datenformat JSON spezifiziert und verschiedene JavaScript-bezogene Tools, wie den statischen Codeanalysator JSLint und den Minifier JSMin entwickelt. Sein Buch “Javascript the Good Parts” wurde 2008 und “How Javascript Works” im Jahr 2018 veröffentlicht. Er war bis 2019 Senior JavaScript-Architekt bei PayPal und ist außerdem Autor und Redner zu JavaScript, JSON und verwandten Webtechnologien. Quelle: https://en.wikipedia.org/wiki/Douglas_Crockford |
| [3] Melvin E. Conway: Melvin Edward Conway ist ein US-amerikanischer Informatiker, Computerprogrammierer und Hacker, der das heute als Conway’s Law bekannte Gesetz prägte: „Organisationen, die Systeme entwerfen, […] sind gezwungen, Entwürfe zu erstellen, die die Kommunikationsstrukturen dieser Organisationen abbilden.“ Weiterhin ist er bekannt für die Entwicklung des Konzepts der Koroutinen. Conway prägte 1958 den Begriff Koroutine bzw. Coroutine und war der erste, der das Konzept auf ein Montageprogramm anwandte. Später verfasste er eine bahnbrechende Arbeit zum Thema Koroutinen mit dem Titel “Design of a Separable Transition-diagram Compiler.”
Quelle: https://en.wikipedia.org/wiki/Melvin_Conway |
| [4] Cyril Northcote Parkinson: Cyril Northcote Parkinson (* 30. Juli 1909 in Barnard Castle im County Durham; † 9. März 1993 in Canterbury) war ein britischer Historiker und Publizist. Er ist der Entdecker der nach ihm benannten Parkinsonschen Gesetze. Das erste Gesetz von Parkinson: „Arbeit dehnt sich in genau dem Maß aus, wie Zeit für ihre Erledigung zur Verfügung steht.“ Die Parkinsonsche Proportionalregel: „Bei Budgetdebatten ist die für die Diskussion eines Ausgabenpostens aufgebrachte Zeit umgekehrt proportional zu dessen Höhe.“ Er wurde durch über 60 Bücher weltweit bekannt. Quelle: https://de.wikipedia.org/wiki/Cyril_Northcote_Parkinson |
| [5] Eric Schmidt: Eric Emerson Schmidt ist ein US-amerikanischer Informatiker und Manager und war von April 2011 bis zum 10. August 2015 Executive Chairman (davor Chief Executive Officer) von Google. Im Zuge der Restrukturierung von Google wechselte Schmidt anschließend als Executive Chairman zur Alphabet Inc. bis er diese 2020 verließ. Zuvor arbeitete er von 1983 bis 1997 unter anderem als CTO bei Sun Microsystems, war von 1997 bis 2001 CEO bei Novell und von 2006 bis 2009 Mitglied des Board of Directors bei Apple. Ab 2009 gehörte Schmidt zum Beraterteam des damaligen US-Präsidenten Barack Obama in Technologiefragen und lehrt an der Stanford University. Quelle: https://de.wikipedia.org/wiki/Eric_Schmidt |