Composable Commerce

E-Commerce

Wieder so ein neuer Begriff. Composable Commerce. Soll laut Gartner das Nonplusultra sein, wenn es um eine zukunftssichere Herangehensweise bei Technologieentscheidungen geht. Blöd nur, wenn schon bei Headless Commerce und Microservices Fragezeichen auftauchen und nun wieder ein weiterer neuer Begriff im E-Commerce gehypt wird. Wie soll man da bitte mitreden können? Dir geht es auch so? Dann lass uns mal Licht in den Begriffsdschungel bringen. Los geht´s!

Headless Commerce war 2013 in aller Munde. Auslöser war ein Bericht von Forrester Research. Darin schlug das Marktforschungsunternehmen vor, Front- und Backends von E-Commerce-Shops zu trennen, um Shop-Daten flexibler in unterschiedliche Ausgabekanäle leiten zu können und somit eine bessere Benutzererfahrung zu ermöglichen. Dieser Anstoß führte dazu, dass monolithische Systeme nach und nach durch eine cloudbasierte Headless-Technologie abgelöst wurden. Heute finden sich in der Headless-Architektur Frontend, Backend und APIs. Innerhalb der Teilsysteme können verschiedene Microservices eingesetzt werden, also aus einer Reihe von kleinen, unabhängigen und spezialisierten Services, die über definierte Schnittstellen und Protokolle miteinander kommunizieren. Diese Services können unterschiedliche Technologien und Datenbanken verwenden und separat skaliert und aktualisiert werden.

Baut man hingegen seine E-Commerce-Lösung rein aus Microservices zusammen, die über APIs kommunizieren, spricht man von einer Microservice-basierten Anwendung. Doch jetzt reden plötzlich alle davon, dass die Zeit von Microservices vorbei ist. Adieu Microservices hört man all zu oft. Liegt vielleicht daran, dass führende Analysten festgestellt haben, dass über 50 % der Microservice orientierten E-Commerce Projekte scheitern. Die Gründe können verschieden sein, allen voran sicherlich die einhergehende Komplexität, denn es müssen hier viele verschiedene Microservices betrieben werden. Der Aufwand für den Betrieb steigert sich dadurch enorm, denn wenn man einmal den Überblick verloren hat, wo welcher Service läuft, ist Chaos vorprogrammiert. Composable Commerce ist zum Schlagwort der E-Commerce-Stunde geworden. Soll Schnelligkeit und Anpassbarkeit ermöglichen. Zwei Fähigkeiten, die im E-Commerce unerlässlich sind. Doch was hat es bitte mit dem Begriff auf sich? Lass mich kurz ausholen.

Wie kam es zu Headless Commerce?

Heute gibt es eine Vielzahl an Endgeräten (Handy, Tablet, Computer, Smartwatch bzw. alle webfähigen Endgeräte). Daher müssen Shopbetreiber Sorge dafür tragen, dass ihr Online-Shop über jedes Endgerät einwandfrei und optimiert für das jeweilige Gerät (z.B. Gestensteuerung, um das Handy ohne Berührung zu bedienen) genutzt werden kann. Bedeutet: Anpassung des Online-Shops an jedes Endgerät. Das lässt sich am besten realisieren, indem die Datenverwaltung von der späteren Darstellung losgelöst wird. Aus diesem Gedanken heraus entstand Headless Commerce. Man hat im wahrsten Sinne des Wortes eine Anwendung ohne Head, also ohne User Interface geschaffen, damit man verschiedene Frontends flexibel für jedes Endgerät gestalten kann.

Der große Vorteil liegt nicht nur im problemlosen Bespielen der Endgeräte und der damit erforderlichen Darstellungsvarianten. Es geht vielmehr darum, mit der Zukunft Schritt zu halten, denn Anforderungen und Technologie wandeln sich bekanntlich unaufhörlich. Mit Headless Commerce sind Shopbetreiber daher im Stande, die bestehenden Frontends jederzeit anzupassen und weiter zu optimieren, um die Benutzererfahrung zu verbessern. Das Backend bleibt davon unberührt. Umgekehrt kann auch das Backend unabhängig vom Frontend weiterentwickelt werden. Mit Headless Commerce können E-Commerce-Unternehmen schnell auf Veränderungen im Markt oder im Kundenverhalten reagieren, weil Inhaltsersteller und Entwickler parallel arbeiten können. Der Haken? Headless Commerce ist komplex, da mehrere Systeme verwaltet werden müssen. Zudem ist Headless um den Kopf der Vorschau gekürzt und besitzt daher keine Vorschaufunktion. Previews von Änderungen sind somit nicht ersichtlich.

Wäre dann eine All-in-One-Lösung nicht doch besser?

Ich gebe es zu. Die Verwaltung mehrerer Systeme wie bei Headless Commerce kann abschreckend wirken. Da ist man dann eher geneigt, eine All-in-One-Lösung in Betracht zu ziehen. Schließlich hat man hier eine Software für alles. Front- und Back-End sind vereint, so das Previews möglich sind. Allerdings sollte man nicht vergessen, dass die Webentwicklung und Technologien wie Endgeräte sehr schnelllebig sind. So kann es vorkommen, dass man mit einer All-in-One-Lösung zwar ein aktuelles Backend hat, aber an ein veraltetes Frontend gebunden ist. Das kann sich negativ auf die Benutzerinteraktion auswirken, da man moderne Webanwendungen möglicherweise nicht zum eigenen Vorteil nutzen kann. Ganz zu schweigen, dass man bei einer All-in-One-Lösung immer an die gegebene Anpassbarkeit des Monolithen gebunden ist. Ok, und was ist jetzt mit den Microservices?

Charakteristisch für Microservices ist die Entkoppelung hinsichtlich Entwicklung und Skalierbarkeit. So kann jeder Microservice autark entwickelt, angepasst oder ersetzt werden (zum Beispiel Austausch Google Translator gegen den DeepL Translator). Auch der Ausfall ist entkoppelt, wodurch ein Microservices weiterlaufen kann, wenn ein anderer ausfällt.

Der große Vorteil besteht darin, dass man sich für spezifische Anwendungsfälle wirklich die Best-of-Breed-Technologie holt, also die bestmögliche Lösung dank einer feinen Auslese. Im Detail bringen Microservices folgende Vorteile:

• Skalierbarkeit: Microservices können je nach Bedarf einzeln skaliert werden, ohne die gesamte Anwendung zu beeinträchtigen. Dies ermöglicht eine bessere Anpassung an die Last und die Ressourcenverfügbarkeit.
• Flexibilität: Microservices erlauben es, verschiedene Technologien, Programmiersprachen und Datenbanken für jeden Dienst zu verwenden, je nachdem, was am besten geeignet ist. Dies fördert die Innovation und die Experimentierfreudigkeit.
• Schnelligkeit: Microservices ermöglichen eine schnellere Entwicklung, Bereitstellung und Aktualisierung der Anwendung, da jedes Team unabhängig an seinem eigenen Dienst arbeiten kann. Dies führt zu kürzeren Entwicklungszyklen und einer höheren Agilität.
• Isolation: Microservices reduzieren die Kopplung zwischen den Diensten und erhöhen die Kohäsion innerhalb eines Dienstes. Dies verbessert die Wartbarkeit, Testbarkeit und Fehlertoleranz der Anwendung. Wenn ein Dienst ausfällt, hat dies keinen Einfluss auf die anderen Dienste, solange die Schnittstellen eingehalten werden.

Natürlich haben auch Microservices Nachteile. Das kann die Verhaspelung im Klein-Klein sein und ein erhöhter Aufwand im Betrieb. Zu den Herausforderungen gehören:

• Komplexität: Microservices erhöhen die Komplexität der Anwendung, da sie mehr Komponenten, Schnittstellen und Abhängigkeiten erfordern. Dies erfordert mehr Koordination, Integration und Überwachung zwischen den Teams und den Diensten. Außerdem müssen Herausforderungen wie Netzwerklatenz, Sicherheit, Transaktionsmanagement und Datenkonsistenz berücksichtigt werden.
• Management: Microservices erfordern mehr Aufwand für das Management der Infrastruktur, der Konfiguration und der Bereitstellung der Dienste. Dies erfordert den Einsatz von Werkzeugen und Plattformen wie Containern, Orchestrierungssystemen und Service-Meshes, die zusätzliche Kosten und Lernkurven verursachen können

Zusammengefasst

Bei einer All-in-One-Lösung, also einem Monolithen, bekomme ich ein Gesamtsystem samt Modulen. Das bedeutet, dass beim Betrieb alle Bausteine gemeinsam ausgerollt werden, da sie miteinander verbunden und voneinander abhängig sind. Auch Frontend und Backend sind vereint. Das Gegenteil von All-in-One-Lösungen sind Anwendungen, die auf Microservices basieren. Hier habe ich ein System, dass aus einzelnen, unabhängigen Softwarebausteinen zusammengestellt ist. Ich habe quasi viele verschiedene Legobausteine, die ich einzeln zu einem Gesamtkonstrukt zusammenbaue. Headless Commerce ist zwar auch das Gegenstück einer All-in-One-Lösung, es stellt aber mit Backend, APIs und einem externen Frontend noch keine echte Microservice-Landschaft dar. Denn eine echte Microservices-Architektur ermöglicht eine vollständige Entkopplung der Plattform und der serviceorientierten Architektur, wohingegen bei Headless das Frontend und Backend in einzelne Teilsysteme unterteilt ist, in denen wiederum Microservices enthalten sein können.

Champions League: Composable Commerce

Kommen wir nun zu Composable Commerce. Laut Gartner ist es die Zukunft im digital Commerce. Doch wer jetzt denkt, dass Composable Commerce nur die maßgeschneiderte Zusammensetzung von besten Microservices im E-Commerce ist, der irrt sich. Bei Composable Commerce geht es um viel mehr, denn Technologie ist hier nur Mittel zum Zweck. Der Unterschied zwischen Microservice-Architektur und Composable Commerce ist, dass die Microservice-Architektur eine technische Grundlage für Composable Commerce ist, aber nicht ausreicht, um Composable Commerce zu realisieren. Die unternehmerische Herausforderung steht bei Composable Commerce an erster Stelle. Daher lautet die Devise „Outcome first“. Das setzt wiederum ein völlig neues Denken voraus. Weg vom Tech-Fokus, hin zur Ergebnisorientierung. Denn nur, wer sich seiner Ziele und Anforderungen bewusst ist, kann die richtige Technologieentscheidung treffen, um die gewünschten Ergebnisse zu erzielen (Umsatz, Kundenbindung, Geschwindigkeit etc.).

Für Gartner besteht eine echte Composability daher aus diesen drei Bestandteilen: Composable Thinking, Composable Business Architecture und Composable Technology. Wie aus der Reihenfolge eindeutig ersichtlich, steht das Denken an erster Stelle. Ergo: Stelle Deine Herausforderung an erster Stelle, ordne alle weiteren Entscheidungen dem Ergebnisziel zu und bleib fortlaufend anpassbar. Hüte Dich aber vor falscher Anpassbarkeit, indem Du gehypte Technologien kombinierst. Was bei einem funktioniert, muss nicht zwangsläufig für Dich gelten. Think before you compose! So vermeidest Du, glorifizierte Anwendungen und Dienste zu beschaffen, die für Deinen Anwendungsfall wohlmöglich ungeeignet sind und keinen Wertbeitrag bringen.

Und ja, technologisch betrachtet, hat Composable Commerce alle Vorteile von Headless Commerce: Flexibilität, Geschwindigkeit und Anpassungsfähigkeit. Aber… Auch wenn das Frontend alle Freiheiten ermöglicht, kann im Backend von Headless Commerce eine ganze Software stecken (z.B. ERP oder PIM). Von wahrem Composable Commerce bzw. Composable Technologie spricht man, wenn wirklich alle Services beliebig zu einer benutzerdefinierten Anwendung verbunden und zusammengesetzt werden können. Die Sicherstellung der Kompatibilität zwischen den Services spielt in diesem Zusammenhang eine wichtige Rolle. Daher sind beim Composable Commerce die Konnektoren, Schnittstellen und APIs sogar noch wichtiger als beim Headless Commerce.

Noch eine letzte Sache. PBCs. Das ist eine Abkürzung für Packages Business Capabilities. Composable Commerce ist nämlich ein architektonischer Ansatz für den digitalen Handel, bei dem Anwendungen mit Hilfe von PBCs erstellt werden. PBCs sind dabei Softwarekomponenten, die eine klar definierte Geschäftsfähigkeit repräsentieren und von einem Geschäftsanwender funktional als solche erkannt werden können. Gemeint ist damit die Bündelung von Microservices. Warum? Du bekommst mit PBCs weiterhin gute Services, die lediglich zusammengefasst sind, weil sie gut miteinander funktionieren. Eine PBC könnte beispielsweise ein Warenkorb und die Kasse sein. PBC gibt Dir die volle Flexibilität und erspart Dir den zusätzlichen Aufwand, benötigte Microservices einzeln herauszusuchen.

Hinweis: Die Microservice-Architektur ist eine Möglichkeit, PBCs zu implementieren, aber nicht die Einzige. Andere Aspekte von Composable Commerce sind API-first, Cloud-native und Headless.

• API-first bedeutet, dass die Schnittstellen zwischen den PBCs zuerst definiert werden, be-vor die Implementierung erfolgt. Dies ermöglicht eine bessere Integration und Interoperabilität zwischen den Komponenten.
• Cloud-native bedeutet, dass die PBCs für den Einsatz auf verteilten Systemen entwickelt werden und deren Vorteile wie Skalierbarkeit, Zuverlässigkeit und Kosteneffizienz nutzen.
• Headless bedeutet, dass durch die Trennung von Frontend (die Benutzeroberfläche, die der Kunde sieht) und Backend (etwa Datenverwaltung und Business-Logik) die unabhängige Weiterentwicklung jeder Komponente ermöglicht wird.

Zusammenfassend kann man sagen: Composable Commerce ist ein Konzept, das auf der MACH-Architektur (Microservices, API-first, Cloud-native, Headless) basiert, aber darüber hinausgeht, indem es die Geschäftsanforderungen in den Mittelpunkt stellt und aus dieser Zielsetzung heraus eine modulare und flexible E-Commerce-Technologie ermöglicht.

So jetzt noch Werbung in eigener Sache: In dem von Gartner im Februar 2023 veröffentlichten Bericht „What Data and Analytics Leaders Need to Know About Composable PIM“ wird apollon als ein Anbieter von Composable PIM aufgeführt. Ja, wir können auch Composable PIM, aber… Wir setzen Microservices nicht blind um, weil es jetzt gerade angesagt ist. Wir handeln mit Bedacht und implementieren neue Technologien erst dann, wenn diese auch tatsächlich sinnvoll für unsere Kunden sind.

Wir wären am Ende. Konnte ich Licht ins Dunkel bringen? Schreib mir doch einfach: marketing@apollon.de