Implementierung von Conways Prinzipien für das teamgeführte Composable Enterprise
Die Composable-Infrastructure-Bewegung hat die Softwarebereitstellung revolutioniert. Es bedarf aber einiger Anstrengungen seitens des Managements, um diesen vielversprechenden Sprung hin zum Composable Enterprise zu schaffen. Mit diesem Begriff wird eine Organisation beschrieben, die sich dem schnellen Tempo der geschäftlichen Veränderungen agil anpassen kann.
Die Abstraktion von Rechen-, Speicher- und Netzwerkfunktionen hat es Entwicklern ermöglicht, softwaredefinierte Dienste schnell und kostengünstig in großem Maßstab einzuführen. Dies befeuerte die anhaltende Diskussion um das Composable Enterprise, da laut Gartner das Design und Redesign von Anwendungen »unter direkter Beteiligung von Business- und Technologieexperten« erfolgen.
Die meisten Unternehmen verfügen jedoch nicht über das kollaborative Umfeld, das erforderlich ist, um von der Entwicklung modularer Infrastrukturprojekte, zu integrierten, marktfähigen Unternehmensdienstleistungen zu gelangen. Hier ist ein neues Modell der Zusammenarbeit gefragt, das auf einer Architektur aufbaut, die zum einen flexibel zusammengesetzt beziehungsweise »komponiert« (compose) werden kann und zum anderen von der Führungsebene vorangetrieben wird.
Mehr als modular
Die Entwicklungen rund um das Thema »Composable« hat die Geschwindigkeit und den Umfang der Bereitstellung von Technologieinfrastrukturen für Unternehmen verändert. Modulare, containerbasierte Systeme, die in Kubernetes-Clustern laufen, sind die »Arbeitstiere« der Wirtschaft – sie lassen sich im Handumdrehen entwickeln, verwalten, skalieren und wenn nötig ersetzen.
Das Composable Enterprise braucht jedoch mehr. Es erfordert das, was Gartner einen »zusammenhängenden Satz gut definierter unternehmensspezifischer Fähigkeiten« nennt, die auf »gut implementierter Modularität« basieren. Das bedeutet, dass übergeordnete Klassen von Business-ready-Diensten aufgebaut werden müssen – zum Beispiel Daten-Streaming-Dienste, die auf spezialisierte Datenbanken, Kubernetes und serverlosen Lambda-Produkten aufsetzen. Diese Produkte werden integriert und ihre Ergebnisse fließen in den Betrieb der anderen Produkte in der Lieferkette ein. Das ist eine Weiterentwicklung der bestehenden Praxis, Produkte einzeln zu entwickeln – also die Datenbanken, die Kubernetes-Cluster und so weiter.
Das Problem besteht darin, dass jedes dieser Produkte von verschiedenen Organisationen entwickelt wurde und dass – so besagt es das Conway’sche Gesetz – Organisationen dazu neigen, Systeme zu entwickeln, die ihre Kommunikationsstruktur widerspiegeln. Das Ergebnis ist ein Mangel an Konsistenz bei Produkten auf Infrastrukturebene.
Dies kann bedeuten, dass Infrastrukturprodukte zu sehr in sich geschlossen sind oder so stark mit anderen Produkten integriert sind, dass sie nicht einfach geändert werden können, ohne dass alle (angrenzende) Produkte des Dienstes aktualisiert werden müssen.
Die herkömmliche Vorgehensweise wäre eine Umstrukturierung der Produktteams. Dies kann jedoch Jahre dauern und scheitert oft an internen Hindernissen wie Unternehmenspolitik und -kultur sowie aus finanziellen Gründen.
Die Composable Architecture schafft eine gemeinsame Sprache, die es Teams ermöglicht, Produkte zu entwickeln, die sich gegenseitig verstehen. Sie legt die Leitprinzipien für die Plattform fest, definiert die Supportmodelle und die Service-Konstrukte. Zudem bildet sie die Roadmap, die Entwicklungs- und die Release-Strategie ab.
Bezeichnenderweise verbindet diese Architektur die Anforderungen des Unternehmens mit der Entwicklerebene und schafft so eine Verbindung zwischen Infrastrukturprodukten, der C-Level-Strategie und Finanzen. Für Unternehmen ist das ein wichtiger Meilenstein auf dem Weg zum Composable Enterprise (flexiblen Unternehmen).
Darüber hinaus verändert eine zusammensetzbare Architektur die Bereitstellungskultur und unterstützt damit den langfristigen Übergang zur Entwicklung von Business-Services: Plattform-Engineers entwickeln sich zu Solution-Engineers, die z. B. einen Daten-Streaming-Dienst aus verschiedenen Speicher-, Rechen- und Netzwerkprodukten entwickeln, anstatt an einzelnen Produkten zu arbeiten. Engineering-Teams gehen von der Entwicklung einzelner Produkte zur Wiederverwendung bestehender Komponenten des Produktkatalogs ihres Unternehmens über.
Gegen den Strom schwimmen
Leider schreibt sich das Conway’sche Gesetz nicht von selbst: Die Idee der agilen Entwicklung, die der Composable Architecture zugrunde liegt, entstand zum Teil als Reaktion auf die großen Entwicklungs-Frameworks und -methoden der Vergangenheit. Es ist daher unwahrscheinlich, dass sich eine Composable Architecture organisch entwickelt.
Hier kommt die Führungsebene ins Spiel: Sie ist für die Festlegung der Unternehmensvision verantwortlich und verfügt über den notwendigen Einfluss, um sie zu verwirklichen. Noch besser ist, dass das Management im Unternehmen verwurzelt ist und damit die Entwicklung und Ausrichtung der Technologie beeinflussen kann.
Aber das ist noch nicht alles. Diese Führungskräfte befinden sich in einer starken Position, um den Umfang des IT-Betriebs und der Cloud-Nutzung voranzutreiben, der für den Übergang von einer produktbezogenen Denkweise zu einer auf Business-Services ausgerichteten Denkweise erforderlich ist, wobei alles auf den Grundlagen einer Composable Architecture basiert.
Der Umfang der Nutzung treibt die Nachfrage nach innovativen Diensten wie Streaming an und stellt die Betriebsteams vor die Herausforderung, dieser Nachfrage gerecht zu werden. Bei der Messung des Umfangs, werden Entwicklung, Bereitstellung und Nutzung anhand von bestimmten Faktoren bewertet. Dazu gehören die Anzahl der Anwendungen in Produktivumgebung sowie die Anzahl der täglichen Releases. Viele glauben, dass sie bereits die Skalierung von Betrieb und Nutzung erreicht haben, doch in Wirklichkeit haben sie noch nicht einmal an der Oberfläche gekratzt.
Composable Infrastructure ist natürlich schon seit Jahren auf dem Vormarsch. Für Führungskräfte stellt sich daher die Frage, wann sie sich darauf einlassen sollten. Es gibt drei Anzeichen, die es zu beachten gilt:
- Zunächst sollte das Projektportfolio des Unternehmens bewertet werden. Haben die Technologieteams einen tragfähigen Katalog erstellt und betreiben sie eine effektive Infrastrukturpraxis? Zu den Merkmalen gehören die Verwendung von Standard-APIs für die Interoperabilität und die regelmäßige Veröffentlichung von Zeitplänen.
- Als Nächstes sollte man nach den Anfängen einer Zusammenarbeit zwischen Teams in verschiedenen Abteilungen Ausschau halten. Es gibt zwei Arten der Kollaboration: Die erste findet zwischen den Eigentümern von Produkten und Dienstleistungen statt – zum Beispiel zwischen dem Eigentümer einer relationalen Datenbank und dem Eigentümer eines Dienstes zur Verwaltung von Geheimnissen. Bei der zweiten handelt es sich um die Zusammenarbeit zwischen – wiederum – einem Product Owner und dem Endnutzer oder Verbraucher. In diesem Szenario sind die ausschlaggebenden Hinweise Feedback, iterative Entwicklung, Änderungen und Verbesserungen.
- Zudem gilt es nach Hindernissen zu suchen und diese zu beseitigen. Damit sind Knackpunkte in dieser frühen Phase der Zusammenarbeit gemeint, die eine Durchführung des Projekts behindern. Dabei kann es sich um Arbeitsabläufe, Prozesse, die Unternehmenskultur oder die Organisation selbst handeln. Das Überwinden von Hindernissen hilft nicht nur bei der Durchführung des Projekts, sondern bietet auch die Möglichkeit, Grundsätze festzuhalten und sie als Best Practice für die Zusammenarbeit zu formulieren.
Fazit
Die Prinzipien der Composable Infrastructure sind bereits bekannt. Der nächste Schritt aber – das teamgeführte Composable Enterprise – wird ein Spiegelbild der Unternehmensstruktur sein. Um diesen Weg richtig anzugehen, muss eine gemeinsame Architektur aufgebaut werden, die von allen unterstützt wird. Es gilt einen Ansatz zu finden, der die Teams vereint und die Art und Weise verändert, wie Technologie bereitgestellt wird.
Kerim Satirli, Senior Developer Advocate bei HashiCorp
Kerim Satirli ist Senior Developer Advocat bei HashiCorp. In dieser Rolle coacht er Betreiber und Entwickler im Bereich nachhaltige Infrastruktur und Orchestrierungs-Workflows. Vor seiner Tätigkeit für HashiCorp arbeitete Kerim Satirli für das industrielle IoT am Amsterdamer Flughafen und unterstützte Museen dabei, einen größeren Teil ihrer Sammlungen online zu präsentieren.
Das Conway’sche Gesetz und seine Bedeutung in der Softwareentwicklung
Das Conway’sche Gesetz ist ein Prinzip, das besagt, dass die Struktur von Systemen, insbesondere von Software, tendenziell die Kommunikationsstrukturen der Organisationen widerspiegelt, die sie entwickeln. Dieses Gesetz wurde nach Melvin E. Conway benannt, einem US-amerikanischen Informatiker, der diese Beobachtung im Jahr 1968 formulierte. Conway stellte fest, dass Organisationen, die Systeme entwerfen, dazu neigen, Entwürfe zu erstellen, die den Kommunikationsstrukturen dieser Organisationen entsprechen.
Die Bedeutung dieses Gesetzes liegt in seiner Anwendung auf die Softwarearchitektur und das Systemdesign. Es hat weitreichende Implikationen für die Art und Weise, wie Teams organisiert und geführt werden sollten, um effektive und effiziente Systeme zu entwickeln. Das Gesetz von Conway basiert auf der Überlegung, dass für die Definition der Schnittstellen zwischen getrennten Softwaremodulen zwischenmenschliche Kommunikation notwendig ist. Daher haben die Kommunikationsstrukturen der Organisationen einen großen Einfluss auf die Strukturen dieser Schnittstellen.
Studien, wie eine von der Harvard Business School durchgeführte Untersuchung, haben starke Hinweise für die Korrektheit des Gesetzes von Conway gefunden. Bei allen untersuchten Produkten korrelierte die Kopplung der sie entwickelnden Organisationen mit der Modularität der Produkte. Eine Studie von Microsoft Research errechnete aus der Komplexität der mit der Entwicklung von Microsoft Windows Vista betrauten Organisationseinheiten von Microsoft die Komplexität und Fehlerquote von Windows Vista.
Ein praktisches Beispiel für das Gesetz von Conway könnte ein Unternehmen sein, das mit der Umsetzung eines großen Softwaresystems beauftragt wird. Wenn das Unternehmen drei Entwicklergruppen hat, die in dem Projekt zusammenarbeiten, würde das Gesetz von Conway vorhersagen, dass das entwickelte Softwaresystem wahrscheinlich aus drei großen Subsystemen bestehen wird, die jeweils von einer anderen Entwicklergruppe umgesetzt werden. Die Qualität und Art der Schnittstellen zwischen diesen Subsystemen würden dann der Qualität und Art der Kommunikation zwischen den entsprechenden Entwicklergruppen entsprechen.
Das Gesetz von Conway hat auch Auswirkungen auf die Organisationsstruktur und die Entscheidungsfindung innerhalb von Unternehmen. Es legt nahe, dass Unternehmen, die ihre interne Kommunikation verbessern und effizientere Kommunikationswege schaffen, letztendlich bessere und kohärentere Systeme entwickeln können. Dies unterstreicht die Bedeutung von guter Kommunikation und Zusammenarbeit in der Softwareentwicklung und darüber hinaus.
In einer Welt, in der Software immer komplexer wird und Teams zunehmend verteilt arbeiten, bietet das Conway’sche Gesetz wertvolle Einblicke in die Gestaltung von Organisationsstrukturen und Arbeitsprozessen. Es erinnert uns daran, dass die Art und Weise, wie wir kommunizieren, einen direkten Einfluss auf die Produkte und Dienstleistungen hat, die wir erschaffen.
Genki Absmeier
[Wikipedia](https://de.wikipedia.org/wiki/Gesetz_von_Conway )
6 Artikel zu „Composable Enterprise“
Die Analysten von Gartner definierten das Konzept des Composable Enterprise zunächst als »eine Organisation, die aus austauschbaren Bausteinen besteht«. Composability beruht auf Modularität – der Wiederverwendung von Komponenten, Bausteinen und Vorlagen zur Beschleunigung der Anwendungsentwicklung in großem Maßstab. »Composable Enterprise« ist daher keineswegs ein Modewort, sondern ein entscheidender nächster Schritt für jedes Unternehmen, um in…
Wie Unternehmen mittels No-Code- und Low-Code-Technologien die Verbreitung von Schatten-IT verhindern und Prozessautomatisierung erfolgreich gelingt. Meistens ist es gar nicht böse gemeint, und doch birgt Schatten-IT in Unternehmen und Organisationen große Gefahren. Wenn entnervte Mitarbeiter sich mit nicht genehmigten Cloud-Diensten oder Software selbst behelfen, weil die IT-Abteilung nicht die Zeit und die Kapazitäten hat,…
Ehrung für »Erfolgreichste Innovationsleistung« als Vordenker moderner Architekturen für Informationssystem. Am 13. Juli 2023 wurde in Augsburg die Rudolf-Diesel-Medaille, der älteste und renommierteste Innovationspreis, für die »erfolgreichste Innovationsleistung« an Prof. Dr. August-Wilhelm Scheer verliehen. Er wurde als Vordenker und unternehmerischer Umsetzer moderner Architekturen für Informationssysteme ausgezeichnet. Die Rudolf-Diesel-Medaille wird seit 1953 im Gedenken an…
Geschäftsanforderungen und neue Technologien wie GenAI treiben die Innovation von Cloud-Modellen voran. Laut der Prognose von Gartner, Inc. werden die weltweiten Ausgaben der Endnutzer für öffentliche Cloud-Dienste voraussichtlich um 20,4 % auf insgesamt 678,8 Milliarden US-Dollar im Jahr 2024 steigen, gegenüber 563,6 Milliarden US-Dollar im Jahr 2023. »Die Cloud ist aus der IT nicht mehr…
Ausgaben für IT-Dienste werden 2024 erstmals die Ausgaben für Kommunikationsdienste übertreffen. Laut der jüngsten Prognose von Gartner werden sich die weltweiten IT-Ausgaben im Jahr 2024 auf fast 5 Billionen US-Dollar belaufen, was einem Anstieg von 6,8 Prozent gegenüber 2023 entspricht. Dies ist ein Rückgang gegenüber der Vorquartalsprognose von 8 Prozent Wachstum. Während generative KI…