"Composable Architecture" - Vorteile und Herausforderungen aus Business Sicht

Vielleicht kennen Sie als Business-Vertreter die folgende Situation?

Sie haben eine einfache Anforderung, die es im bestehenden Webshop umzusetzen gilt. Das Feedback Ihrer IT ist jedoch ernüchternd: mehrere Dutzend Tage Entwicklung sind notwendig für die Umsetzung, das Testing noch nicht eingerechnet. Die Arbeiten können zudem frühestens für das nächste Jahr eingeplant werden, da das Team noch an einem Upgrade der Webshop-Software von Version X auf Y arbeitet. Dieses hat sich leider als sehr viel komplizierter herausgestellt als erwartet, ist jedoch dringend notwendig, um bestehende Sicherheitslücken zu schliessen und den Produktsupport nicht zu verlieren. Und eigentlich empfiehlt die IT sowieso, diese Anpassung nicht vorzunehmen: “never touch a running system”. Resultat: Frust.

Falls man den aktuell in der Branche herumgereichten Buzzwords glauben schenken darf, hätten Sie solche Probleme mit einer “MACH Architektur”, bzw. einer “Composable Architecture” nicht. Auch wir bei diselva sind überzeugte Verfechter dieser Ansätze, möchten jedoch auch das Bewusstsein schaffen, dass dieses Thema aus unterschiedlichen Perspektiven betrachtet werden muss. In diesem Blogpost möchten wir auf die spezifischen Vorteile dieser Ansätze eingehen und sie mit Beispielen veranschaulichen. Zusätzlich werden wir jedoch auch die Kehrseite der Medaille beleuchten und Herausforderungen beschreiben und wie man diesen begegnen kann. 

"MACH Architektur" & "Composable Commerce" - was bedeuten diese Begriffe überhaupt?

Die MACH Alliance (ein Zusammenschluss diverser Produkt-, Infrastruktur- und Serviceanbietern) bietet ihrem Artikel verständliche Erklärungen für Leser mit unterschiedlichem Vorwissen. Für nicht-technische Leser wird der Ansatz einer “Composable Architecture” dort wie folgt beschrieben:

“[ein Ansatz], bei dem ein großes, komplexes Problem in kleinere, besser handhabbare Teile zerlegt wird. Im Zusammenhang mit der Software Architektur ermöglicht es die Composable Architecture den Entwicklern, Systeme aus kleineren, wiederverwendbaren Komponenten zu erstellen, die leicht kombiniert und neu konfiguriert werden können, um die spezifischen Anforderungen eines bestimmten Projekts zu erfüllen.”

MACH ist ein Akronym aus den dabei anzuwendenden Prinzipien: Microservices, API first, Cloud Native und Headless. Mein Kollege, Cuno, geht in seinem Blogpost, genauer auf diese Prinzipien ein und beschreibt, wie man eine Composable Commerce Architektur aufbaut. 

Aus Business Sicht versuche ich vereinfacht zusammenzufassen: 
Statt eines komplexen, monolithischen Systems wird die Gesamtlösung in kleinere, abgetrennte Komponenten unterteilt. Diese Komponenten können beliebig kombiniert und über die Zeit um weitere Komponenten erweitert werden. Die User Interfaces werden dabei bewusst von der Applikationslogik getrennt, damit mit den gleichen Komponenten oder Services unterschiedlichste Kanäle bedient werden können.

Von welchen Vorteilen profitiert eine Organisation?

Die beschriebenen Ansätze sind die Antwort auf die Frustration über Situationen wie die eingangs Aufgezeigte. Über diese neuen Herangehensweisen schafft man sich einige Vorteile.

Die Entkopplung und der Einsatz geeigneter Infrastruktur und Tools führt dazu, dass man in unterschiedlichen Dimensionen mehr Flexibilität in der Zusammenstellung und Erweiterung der Gesamtlösung hat. 

Beispielsweise kann eine eingekaufte Saas Commerce Engine mit einer selbstgebauten Applikation zur Preisberechnung kombiniert werden. Es gibt keine Notwendigkeit, zwischen “Make” (die komplette Commerce Lösung selbst zu bauen) und “Buy” (eine teure Commerce Engine einzukaufen, die auch komplexere Preismodelle abdeckt) eine entweder/oder Entscheidung zu fällen.

Diese Flexibilität führt zu weniger Abhängigkeiten als bei grossen, komplexen und teuren Monolith-Lösungen, die häufig einen Lock-in Effekt über hohe Lizenzgebühren und langfristige Verträge verursachen. Auch sind Kunden häufig im Bereich der Funktionalitäten abhängig von der Priorisierung der Produktroadmap des Anbieters. Statt darauf zu warten, dass der Anbieter der Commerce Engine personalisierte Produktempfehlungen in die eigene Software integriert, kann in einer Composable Architecture bei Bedarf ein entsprechender, spezialisierter Dienst integriert werden.

Zusätzlich erhöht man über Modularisierung und Entkopplung die Anpassungsfähigkeit des Gesamtsystems. Da Funktionalitäten logisch voneinander getrennt sind, kann zum Beispiel eine Anpassung der Preisberechnung isoliert im definierten Preis-Service vorgenommen werden. Im Idealfall ändert sich dadurch an den bestehenden Schnittstellen nichts. Und falls doch, müssten nur die tatsächlich angebundenen Komponenten ebenfalls angepasst werden. Dies reduziert einerseits die Komplexität und damit den Aufwand solcher Anpassungen signifikant und ermöglicht andererseits auch eine gewisse Parallelisierung der Entwicklungsarbeit. 

Durch die Nutzung von Cloud Infrastruktur in Kombination mit der funktionalen Entkopplung ist zudem eine bessere Skalierung möglich. Lösungen können so gebaut werden, dass bei Bedarf eine Hochskalierung einerseits automatisch abläuft und andererseits zielgerichtet für jene Applikationen vorgenommen wird, die die tatsächliche Last verarbeiten müssen. An einem Online Aktionstag wie Black Friday würden so beispielsweise alle Services, die mit dem Bestellvorgang zusammenhängen, automatisch an die zwischenzeitlich sehr hohe Last angepasst werden.

Zu guter Letzt gilt es, sich erfolgreich für die Zukunft zu rüsten. Denn sowohl die Analysten (wie Gartner) als auch die Marketingabteilungen der Software Anbieter sind sich einig: der Markt entwickelt sich in die Richtung von API zentrierten SaaS Lösungen, die in Composable Architekturen ihren natürlichen Platz finden. 

Welche Herausforderungen sind zu beachten?

Zusammengefasst ist die grösste Herausforderung, die beschriebenen Vorteile in tatsächlichen Business Nutzen umzuwandeln. Einige der genannten Aspekte können nämlich bei falscher Herangehensweise auch negative Effekte mit sich bringen.

Der erste Schritt ist immer der schwerste. Vielleicht eine Binsenwahrheit, trotzdem insbesondere für dieses Thema passend. Auch für Composable Architecture Ansätze ist es essentiell, erst saubere Grundlagen zu schaffen, bevor man sich in die Umsetzung stürzt. Dies gelingt, wenn zu Beginn eine Übersicht über den Status quo geschaffen wird: 

• Welche Systeme sind bereits im Einsatz, welche Funktionalitäten bieten Sie und wo stehen sie in ihrem Produktlebenszyklus? 
• Welche Business Prozesse sind über diese Systeme abgebildet und wo sind die grössten Hebel für positive betriebswirtschaftliche Effekte? 
• Welche Touchpoints werden aktuell angeboten und wo gibt es Hindernisse oder Lücken, um eine nahtlose Customer Journey zu bieten?
• ...

Auf dieser Basis sollte in Einklang mit der Unternehmensstrategie eine übergreifende Vision für die digitale Landschaft erarbeitet werden, die die Richtung für alle folgenden Initiativen vorgibt. Ziel ist es, eine ganzheitliche Roadmap zu formulieren, die die notwendigen Schritte vom IST- zum SOLL-Zustand in sinnvoll priorisierten Schritten und Ausbaustufen abbildet. Wie diese Grundlagenarbeit erfolgreich gemeistert werden kann, beschreibt mein Kollege Jörg Brunschwiler sehr anschaulich in diesem Fachartikel.

Sind Vision und Roadmap definiert, liegt die nächste Herausforderung in der Planung und Steuerung des Projekts, bzw. des Programms. Hier zeigen sich einige der genannten Vorteile auch in ihrem negativen Gewand. Flexibilität, Anpassungsfähigkeit und parallelisiertes Arbeiten können schnell im Chaos enden. Deshalb sind folgende zwei Aspekte zentral, um Komplexitäten und Abhängigkeiten im Griff zu behalten.

Einerseits geht es darum, eine Projekt- oder Programmorganisation (je nach Umfang der Vorhaben), die eine übergreifende, inhaltliche Steuerung aller Aktivitäten ermöglicht, beziehungsweise sogar forciert. Dies, um in kurzen Zeitabständen zu überprüfen, ob die gemeinsame Vision weiterhin Bestand hat und alle Beteiligten in die gleiche Richtung arbeiten.

Andererseits ist es aus technischer Sicht unentbehrlich, die Ownership über die Gesamtlösung zentral zu organisieren. Rasch kommt eine grosse Anzahl von Tools und Services zusammen, was die Komplexität der Lösungsarchitektur gegenüber einem monolithischen Ansatz signifikant erhöht. Je nach Grösse der Organisation sollte deshalb eine Einzelperson oder ein Gremium die technische Gesamtlösung verwalten und die Verantwortung für die Erweiterung tragen. Wichtig sind hierbei eine laufende Dokumentation des Gesamtbilds, klare Vorgaben zur Umsetzung, schnelle Entscheidungsfindung, sowie die aktive Mitarbeit am Ausbau der Lösung. 

Um diese Punkte erfolgreich angehen zu können, benötigt es in vielen Organisationen einen Wechsel der Denkweisen und Einstellungen auf allen Stufen. 

Aus Sicht Management gilt es zu verstehen, dass die inhaltliche Arbeit mit dem Formulieren einer Vision und dem Verabschieden einer Roadmap nicht erledigt ist. Die Bereitschaft muss vorhanden sein, getroffene Entscheidungen kritisch zu hinterfragen, Pläne anzupassen und so laufend das Zielbild zu schärfen. Nur so können die Vorteile bezüglich Flexibilität, Unabhängigkeit und Anpassungsfähigkeit auch zielführend ausgespielt werden. Mit der Einstellung, dass man ja eine 5-Jahres-Strategie formuliert hat und es diese nur noch umzusetzen gilt, würde man viele der genannten Vorteile nicht optimal nutzen können.

Auf Level Projekt- und Programmsteuerung sollte man einen starken Fokus auf die inhaltliche Ebene legen. Es mag eine Umgewöhnung sein, sich aktiv an der inhaltlichen Ausgestaltung zu beteiligen, statt von oben definierte Lieferobjekte und Meilensteine abzuarbeiten. Aber auch hier gilt es, die vorhandenen Vorteile so zu spielen, dass am Ende der höchstmögliche Nutzen erzielt werden kann. Dies bedingt eine ständige und konsequente Priorisierung der Anforderungen und täglichen Arbeiten. Je grösser das Unternehmen und / oder das Programm, desto wichtiger ist es, diese inhaltlichen Abhängigkeiten zu managen, um eine abgestimmte Gesamtlösung zu erhalten.

Auf der operativen Ebene in den einzelnen Projekten und Initiativen ist eine nahe und interdisziplinäre Zusammenarbeit zwischen allen beteiligten Bereichen unabdingbar, um Lösungen zu erarbeiten, die aus den bestehenden Voraussetzungen den maximalen Nutzen schaffen. Anforderungen und die zugrundeliegenden Business Prozesse müssen gemeinsam diskutiert, verändert, umgesetzt und getestet werden. Die reine Übergabe von Artefakten (z.B. Fachkonzepte, technische Konzepte, etc.) an die nächste Person oder Stelle würde viele der beschriebenen Vorteile eines Composable Architecture Ansatzes zunichtemachen. 

Zu guter Letzt benötigt es eine neue Betrachtungsweise hinsichtlich der Kosten. Sowohl die initiale, als auch die laufende Einschätzung der Kosten ist aufgrund der beschriebenen Flexibilität und modularen Erweiterbarkeit schwieriger, als wenn man sich für eine all-in-one Strategie entscheidet und für mehrere Jahre ein Produkt mit fixen Lizenzkosten einkauft. Natürlich muss eine Total-Cost-of-Ownership Rechnung im Einzelfall immer durchgeführt werden. Wir würden uns auch nicht anmassen, an dieser Stelle eine globale Aussage zu treffen, dass ein Composable Architecture Ansatz immer günstiger ist. Es steht jedoch ausser Frage, dass man sich als Entscheider oder Einkäufer auf variable Infrastruktur- und Lizenzkosten einlassen muss, um die Vorteile hinsichtlich bedürfnisorientierter Skalierung und modularer Erweiterung maximal nutzen zu können. Dies ist in vielen Organisationen und für viele Menschen eine Herausforderung. 

Zeit für ein Fazit

Nein, der Composable Architecture Ansatz ist kein einfaches Patentrezept oder die allseits bekannte “Silver Bullet”. Das zeigen die beschriebenen Herausforderungen. Trotzdem überwiegen aus unserer Sicht die Vorteile klar. Insbesondere da die Risiken identifizierbar sind und Möglichkeiten und Ansätze bestehen, um sie zu meistern. Zudem kann man sich diese herausfordernden Themen über eine schrittweise Herangehensweise in verdaubare Häppchen schneiden und Ausbaustufe um Ausbaustufe dazu lernen.

Die erwähnten Wechsel im Mindset sind zwar je nach individueller Ausgangslage unterschiedlich schwierig, sie können jedoch sehr gut durch programm-begleitendes Change Management und individuelle oder unternehmensweiten Weiterbildungsmassnahmen unterstützt werden. Wenn diese Themen frühzeitig durch das Management identifiziert und mitgetragen werden, kann das in unserer Erfahrung sehr positive Effekte auf die gesamte Organisation haben - auch über den Projekt- und Programmkontext hinaus. 

Wir von diselva helfen Ihnen gerne weiter mit unserem umfassenden Erfahrungsschatz im Aufbau von Composable Architectures. Sei es aus strategischer Sicht oder aus technischer Sicht im Aufbau einer neuen Zielarchitektur, sowie deren Implementierung. Begleitend können wir unsere Expertise in Konzeption und Beratung sowie im Projektmanagement anbieten, um ihre Initiativen zum Erfolg zu führen. Zu guter Letzt wissen wir auch, wie man eine gesamte Organisation auf solche Paradigmenwechsel vorbereitet und zu einer lernenden Organisation weiterentwickelt. 

Wir freuen uns auf Ihre Kontaktaufnahme!

Quellen

Gartner - Composable Commerce Must Be Adopted for the Future of Applications

MACH Alliance - MACH at different levels

Jörg Brunschwiler - Digitale Transformation: Warum ist sie so schwierig?