Ein Gastbeitrag von Rico Neitzel, Mitgründer der E-Commerce-Agentur run_as_root.
Vorbei sind die Zeiten, in denen Onlineshops aus einem einzigen riesigen Programm gestrickt wurden. Ab jetzt kann man sich für jeden Teilbereich der Software einen eigenen Anbieter aussuchen und sich seine eigene E-Commerce-Welt schaffen. Oder doch nicht? Ein neuer Trend ist gerade in aller Munde: MACH! Aber was genau soll man „machen“? Und was hat das mit Composable Commerce zu tun?
Im Beitrag mehr, was mit MACH eigentlich gemeint ist, welche Vorteile es im E-Commerce haben könnte, aber auch welche Nachteile es im Moment noch mit sich bringt.
Composable Commerce
Bislang bestand ein typisches „Onlineshop“-Projekt darin, zusammen mit einem Dienstleister eine große Anwendung (den Onlineshop) zu entwickeln, die alle wichtigen Aspekte abdeckte: Produktkatalog, Suche, Bestell- und Bezahlprozess sowie Bestell- und Kundendatenmanagement.
Ein Nachteil dieser monolithischen Lösungen war stets die Abhängigkeit von einem einzigen Hersteller, dessen Updates sich auf die gesamte Anwendung auswirkten.
Composable Commerce zielt darauf ab, diese monolithische Struktur zu modularisieren und die Einzelteile austauschbar zu machen.
Im Grunde geht es technisch also darum, die Komponenten eines E-Commerce-Systems, beispielsweise Warenkorb, Zahlungsprozesse, Produktdatenmanagement oder Suche so voneinander zu trennen und durch APIs zu verbinden, dass jeder Teilbereich einzeln erweitert, ausgetauscht oder optimiert werden kann, ohne das restliche System zu beeinträchtigen.
Der offensichtliche Vorteil für den Händler besteht darin, für jeden Teilaspekt einen spezialisierten Anbieter zu suchen und am Ende seine eigene Lösung zusammenstellen zu können, ohne von einem einzigen Anbieter abhängig zu sein.
Das Fundament: MACH-Architekturen
Die MACH-Architektur (Microservices, API-first, Cloud-native, Headless) ist die Basis für Composable Commerce.
Das Konzept ist recht einfach: Jeder Teil des Systems („Microservice“) funktioniert unabhängig und kommuniziert ausschließlich über definierte Schnittstellen („APIs“) mit den anderen Komponenten. Diese Komponenten sind für den Einsatz auf verteilten Systemen entwickelt worden und nutzen deren Vorteile wie Skalierbarkeit, Zuverlässigkeit und Kosteneffizienz („Cloud-native“).
Die Trennung von Frontend – die Benutzeroberfläche, die der Kunde sieht – und Backend – etwa Datenverwaltung und Business-Logik – ermöglicht die unabhängige Weiterentwicklung jeder Komponente („Headless“).
Die MACH-Architektur zielt somit primär auf Investitions- und Zukunftssicherheit sowie größtmögliche Flexibilität ab.
MACH-Alliance
Eine Herausforderung dieses Ansatzes ist aber die Zusammenarbeit der unterschiedlichen Hersteller und Dienstleister. Um sie international zu koordinieren, hat sich eine Allianz gebildet, die nicht nur Aufklärungsarbeit leistet, sondern auch Dienstleister zertifiziert. Für Unternehmen soll es damit leichter werden, Anbieter zu beauftragen, die die MACH-Standards verstehen und umsetzen können.
Composable Commerce Projekte mit All-MACH-tsanspruch
Die Werbung vieler Dienstleister suggeriert, dass bei Composable Commerce im Grunde alle Bausteine schon fertig sind und nur noch „zusammengesteckt“ werden müssen. Die Realisierung einer solchen Plattform erfordert aber interne und externe Expertise sowohl in Bezug auf die Branche als auch auf die Technologie. Entsprechend muss auch die Anwendung selbst programmiert werden — und hier liegt die eigentliche Arbeit: Der Programmcode, der all diese Microservices über ihre APIs verbindet, muss präzise geplant und entwickelt werden.
Hier kommt jetzt das „Composable“ voll zum Tragen, denn wir können selbst entscheiden, welche Komponenten von welchem Anbieter wir anbinden möchten. Suche? Algolia! — Produktkatalog? Magento! — Warenkorb- und Bezahlvorgang? Commerce Tools! … und hier endet die Liste an Möglichkeiten und zu treffenden Entscheidungen noch lange nicht.
Selbst danach bleibt die Möglichkeit offen, in ein paar Jahren die Komponenten zu tauschen, falls eine passendere Lösung gibt.
Die Abhängigkeitshölle – Katzengold!
Auch wenn all das nach glänzendem Gold klingt, stellt sich bei näherer Betrachtung doch heraus: Es ist nur Katzengold. Denn die in der Werbung oft hochgelobte Austauschbarkeit der Komponenten ist so aktuell gar nicht gegeben.
Viele Anbieter bringen ihre eigenen Komponenten bereits mit und bewerben ein in sich geschlossenes System. Ja, es ist composable. Aber nein: Ich kann nicht ohne Weiteres beliebige Hersteller kombinieren.
Eine wichtige technische Voraussetzung für diese Interoperabilität ist – wie so oft – die Standardisierung. Und genau die ist aktuell nicht gegeben. Es existiert keine DIN „Produktkatalog“, in der die Datenformate für den Austausch zwischen den Komponenten definiert sind. Es ist noch nicht einmal standardisiert, über welche API-Befehle (sog. Endpunkte) kommuniziert werden muss.
Somit hat im Moment jeder Hersteller seine eigene API mit seinen eigenen Formaten.
Und an dieser Stelle geht der große Vorteil von Composable Commerce aktuell verloren. Man ist in Anbieterabhängigkeiten gefangen und kann Komponenten nicht einfach austauschen, ohne erneut Entwicklungsleistung für die Integration in Auftrag geben zu müssen.
Die Kosten für Composable Commerce
Oft liest man, dass die Kosten mit modernen Architekturen langfristig geringer sein sollen als mit den klassischen Monolithen. Dieser Effekt kommt zumindest heutzutage – wenn überhaupt – nur in seltenen Ausnahmefällen zum Tragen.
Vielfach bedeutet MACH-Architektur einen deutlich höheren Anspruch an Unternehmen und Menschen. Außerdem bringt die Integration neuer Funktionen oftmals Arbeit an mehreren dieser Komponenten mit sich. Im Zweifel müssen dann verschiedene Teams koordiniert werden.
Stellt man nun fest, dass das Gesamtsystem einen Fehler aufweist (der klassische Bug), beginnt die Suche in verteilten Systemen. Liegt es an der Applikation selbst? Oder an einer der Komponenten? Wenn ja, an welcher? Ist sie alleine Ursache des Problems oder müssen mehrere in unterschiedlichen Komponenten zusammenkommen, um den Fehler auszulösen? Die Fehlersuche ist also in diesen verteilten Systemen um ein Vielfaches schwieriger.
All diese Herausforderungen lassen auch das erforderliche Budget des Projekts steigen. Eine Kostenersparnis tritt im Zweifel nur dann ein, wenn alles reibungslos funktioniert — ein seltener Zustand.
Man steht also weiterhin vor der schwierigen Frage, wie man das eigene Projekt mit Blick auf die Zukunft realisieren will und welches Budget man dafür aufbringen möchte.
Quo Vadis?
Solange sich die großen Akteure der MACH Alliance nicht alle an einen Tisch setzen und entscheiden, dass das Wohl der Händler über ihre eigenen finanziellen Interessen gestellt wird, muss man mit dem schalen Geschmack von Microservice-basierten Monolithen leben. Nur mit festgelegten und zertifizierten Schnittstellen und Datenformaten kann das volle Potenzial von Composable Commerce zukünftig ausgeschöpft werden.
Ein Chance – aber mit Bedacht
Auch heute schon werden „Monolithen“ mit zusätzlichen Komponenten ausgestattet und bringen so neue Fähigkeiten in bestehende Systeme. Algolia ist hier ein gutes Beispiel, wie man die Shop-eigene Suche austauschen und durch einen externen Anbieter drastisch verbessern kann. Solche Lösungen funktionieren zuverlässig und kostengünstig.
Die Integrationen sind jedoch immer auf das jeweilige System zugeschnitten, manchmal sogar auf den einzelnen Anwendungsfall. Sie veranschaulichen aber wunderbar, dass die Idee von Composable Commerce in die richtige Richtung geht.
Es bleibt also spannend und letztlich wird die Zeit zeigen, ob die MACH Alliance gemeinsame Standards schafft, die branchenübergreifend Unterstützung finden. Im Moment ist es für Unternehmen wichtig, sich die Zeit zu nehmen, die Möglichkeiten aber auch die Auswirkungen und Kosten zu verstehen, um eine fundierte Entscheidung treffen zu können. Jeden Hype sollte man kritisch hinterfragen und stets daran denken, dass die Technologie nur ein Werkzeug für das Unternehmen sein sollte; nicht umgekehrt.
Autor
Rico Neitzel ist Mitgründer der E-Commerce-Agentur run_as_root. Neben konzeptioneller Arbeit zu neuen E-Commerce-Architekturen spielt auch künstliche Intelligenz für ihn eine große Rolle bei der Arbeit. run_as_root hat sich darauf spezialisiert, mit modernen, schlanken Prozessen E-Commerce-Projekte neu zu denken und mit internationalem Team Händlern wirkliches Wachstum zu ermöglichen.