Wenn man schon mehr als 20 Jahre im eCommerce unterwegs ist und noch länger mit Software-Architekturen zu tun hat, dann gewinnt man eine gewisse Skepsis zu Hypes und einen Riecher, sie als solche zu identifizieren. Sobald Gartner in seinen Trend-Reports neue Begrifflichkeiten prägt, dauert es nicht lange und viele andere Anbieter ziehen nach. Gehört „Composable Commerce“ zur Kategorie Bullshit-Bingo oder steckt dahinter mehr?
Was ist Composable Commerce?
Aufbauend auf den MACH-Prinzipien, also Microservices, API, Cloud und Headless, werden im Composable Commerce "Packaged Business Components“ (PBC) nach Geschmack miteinander kombiniert, um spezifische und sich ständig wandelnde Business Modelle schnell abzubilden.
Packaged Business Components definiert Gartner als “software component that represents a well-defined business capability, recognizable as such by a business user…[and] consists of a bounded collection comprising a data schema and a set of services, APIs and event channels.”
Wie hängen Headless und Composable Commerce zusammen?
Die Idee der modularen Software-Architektur besteht schon seit eh und je. Sie wird auch bereits mit einer headless Software-Architektur umgesetzt: Trennung von Backend und Frontend. Da ist es dann auch nur konsequent, dass sich eine solche modulare Struktur noch weiter herunterbricht entlang passender Service-, Prozess- und Datenebenen, wie zum Beispiel (Shop-) Produktdarstellung, Produktsuche, Checkout, My-Account-Bereiche, … und natürlich sämtliche angrenzenden Software-Components, wie PIM, Ordermanagement, Logistik, Rechnungswesen, CDM, usw.
Die Vorteile modularer Software-Architektur
Für diese Fragmentierung gibt es handfeste Argumente:
- Mit gut strukturierten Components und APIs kommt man einer Plug & Play Herangehensweise immer näher und es gelingt eine schnellere Umsetzung von Commerce Projekten und daher eine schnellere time-to-market.
- Auf sich verändernde Markttrends bzgl. Verkaufskanälen oder innovativer Software kann viel schneller reagiert werden, weil nur die entsprechenden Funktionen und Components ausgetauscht werden.
- Der Fokus liegt darauf, sein Commerce Business am Kunden zu orientieren und nicht an den Möglichkeiten der Commerce Software.
- Komponentenbasierte Modularität erlaubt überhaupt erst das partielle Einbinden von best-of-breed- und / oder Legacy-Software und -Services. (Naja, sofern die das natürlich unterstützen…;) )
Zerlegen und Composen
Es ist allerdings schon seit jeher eine Gretchenfrage der IT, wie fein granularisiert Datenstrukturen sein müssen oder können und wie umfangreich dazugehörige Funktionen und Services sind. Das Zerlegen einer monolithischen Software in Module, Components, Mircroservices oder PBCs ist eine Sache. Die andere Frage, die gleich im Anschluss kommt, besteht darin, mit welchem Aufwand die einzelnen Software-Komponenten im aktuellen Wunschszenario dann wieder „composed“, also zusammengebaut, verwaltet und stabil betrieben werden können.
Die Vorteile beispielsweise einer Einbindung von best-of-breed-Bausteinen müssen auf jeden Fall so viel Mehrwert generieren, dass sie den Aufwand des „Composens“ übersteigen. Der Erfolg von Composable Commerce wird stark davon abhängen, wie gut das „Composen“ funktioniert. Das ist nicht nur eine technologische Frage. Früher lag diese Verantwortung ausschließlich bei den Software-Herstellern.
Dirigenten sind gefragt
Mit Composable Commerce sitzen die Dirigenten jetzt auch im Business, die die einzelnen best-of-breed Bausteine kombinieren müssen. Mit gut strukturierten PBCs und APIs unterstützt mit Low-Code- oder No-Code-Engines lassen sich heutzutage einfach mehr als jemals zuvor eigene Datenflüsse und Prozesse „technisch“ umsetzen. Teilweise sogar ohne „klassische IT-Abteilung“. (Ob das wirklich gut oder schlecht ist in Zeiten von Fachkräftemangel wird sicherlich in einem späteren Beitrag erläutert! J ).
Diese Dirigenten gibt es aber leider auch nicht wie Sand am Meer, die die gesamten Prozesse überschauen und konzipieren.
Mit den Freiheiten und Möglichkeiten von Composable Commerce geht automatisch die Verantwortung einher, aus Komponenten ein funktionierendes großes Ganzes zu erstellen. Und damit entstehen neue Aufwände: Zeit, sich die eigenen Business Anforderungen zu überlegen, die best-of-breed-Lösungen und andere Components auszuwählen, die übergreifenden Prozesse zu definieren und sie dann auch ausführbar umzusetzen.
Nicht zuletzt wird Composable Commerce erst dann erfolgreich, wenn die individuellen Lösungen genutzt werden. Wenn sich übergreifende Prozesse leicht modellieren lassen, beispielsweise durch Flows-Anwendungen. Wenn es übergreifende Oberflächen gibt, die genauso einfach anpassbar sind und mit denen die Prozesse überhaupt ausführbar werden. Und letztendlich alle Beteiligte auf allen Seiten des Warenkorbs wirklich einfach damit „arbeiten“ können.
