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 [1] [2].

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 [2]. 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 [3]. 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 beispielsweise 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 [4]. 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 ist Senior Developer Advocate 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.

[1] https://www.gartner.com/en/newsroom/press-releases/2021-10-18-gartner-survey-of-over-2000-cios-reveals-the-need-for-enterprises-to-embrace-business-composability-in-2022

[2] https://www.computerweekly.com/feature/How-to-design-enterprise-applications-that-are-composable-by-default

[3] https://martinfowler.com/bliki/ConwaysLaw.html

[4] https://fortelabs.com/blog/theory-of-constraints-101/

Illustration: © Ljubov | Dreamstime.com

8 Artikel zu „Composable Enterprise“

NEWS | BUSINESS PROCESS MANAGEMENT | DIGITALISIERUNG | LÖSUNGEN

Low-Code als Katalysator des Composable Enterprise

5. September 2023

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…

[1] https://www.gartner.com/en/newsroom/press-releases/2021-10-18-gartner-survey-of-over-2000-cios-reveals-the-need-for-enterprises-to-embrace-business-composability-in-2022

[2] https://www.computerweekly.com/feature/How-to-design-enterprise-applications-that-are-composable-by-default

[3] https://martinfowler.com/bliki/ConwaysLaw.html

[4] https://fortelabs.com/blog/theory-of-constraints-101/

8 Artikel zu „Composable Enterprise“

68 Artikel zu „Agilität modular“