Composable Commerce im Einsatz

oder wie mit einem MVP der Architektur-Grundstein für die zukünftige Gesamtlösung gelegt werden kann.

Nachdem Cuno eine Übersicht gegeben hat, um was es sich bei Composable Commerce handelt und Michael auch auf die Vorteile und Herausforderungen von diesem Konzept aus Business Sicht eingegangen ist, werde ich hier den Architekturansatz anhand eines konkreten Beispiels erläutern.

Warum eine Änderung ansteht

Das heutige Shop System des Kunden ist eine All-In-One Lösung und schon mehrere Jahre im Einsatz. Es wurde erst vor kurzem auf die neueste Version aktualisiert und auch das UI bekam eine Auffrischung. Jedoch ist es nicht auf Multi-Brand und auch nicht auf Multi-Country ausgelegt. D.h. für das Vorhaben des Kunden, eine neue Marke in einem neuen Markt zu etablieren, müsste man eine Kopie ziehen und als zweites System daneben stellen. Der Copy&Paste Ansatz wäre in der Umsetzung sicher die einfachste Variante, doch aus Pflegesicht bzw. aus dem Potential des Synergieeffektes, definitiv die falsche Herangehensweise. Auch hinsichtlich der weiteren Ausbaufähigkeit mit einer zusätzlichen Marke und/oder Markt.

Wo soll die Reise hingehen?

Die neue Lösung basiert auf einem modernen und modularen Tech Stack und ist von Beginn an auf Multi-Brand und Multi-Country ausgelegt. Dadurch soll sie nach dem erfolgreichen Rollout im neuen Absatzgebiet auch die alte Lösung im bestehenden Markt ablösen. Die neue Architektur erlaubt, dass so viel wie möglich über gemeinsam genutzte Bausteine abgedeckt werden kann und da wo es nötig ist oder da wo es wirklich auf eine Differenzierung ankommt, spezifische Lösungen zum Einsatz kommen.

Wie sieht sowas aus?

Unser technisches Setup sieht wie folgt aus:

• Als Hyperscaler kommt die Google Cloud Platform zum Einsatz. Sie liefert nicht nur das Frontend aus, sondern auch unsere kundenspezifischen Microservices (Custom Services) werden darauf betrieben. Zusätzlich sind noch weitere Dienste bzw. Produkte wie die Google Identity Platform oder Apigee etc. im Einsatz.
• In die Rolle der Headless Commerce Engine schlüpft commercetools.
• Die Vertretung für das Headless CMS übernimmt contentful.
• Die ganze Backend-Integration wird über Microsoft BizTalk realisiert.
• Natürlich sind noch viele weitere Systeme im Spiel, welche hier aber nicht weiter erläutert werden.

Was der Kunde sieht

Das Frontend ist modular im Atomic Design System aufgebaut und ist komplett losgelöst vom Backend. Dabei ist es wichtig, dass beide Ansätze von Client Side Rendering (CSR) und Server Side Rendering (SSR) je nach Bedarf unterstützt werden. Solche Anforderungen lassen sich heute sehr gut mit Frameworks wie next.js im React- oder nuxt.js im Vue-Umfeld umsetzen.
Weil gerade in diesem Bereich die Differenzierung passieren kann bzw. soll und daher sehr eigenständige Bausteine entstehen können, ist es wichtig, sich vorab Gedanken zu machen, wo es in die gleiche Richtung geht, um z.B. eine gemeinsam genutzte Komponentenbibliothek zu etablieren.

Der Klebstoff der alles zusammenhält

Das komplette Frontend läuft gegen einen API Gateway, in unserem Fall Apigee von Google. Dies hat mehrere Gründe:

• Der Kunde bekommt ein zentralisiertes System für die Orchestrierung und das Controlling bzw. Reporting. Was besonders bei heutigen MACH-Architekturen ein nicht zu unterschätzendes Thema ist.
• Wir können die Authentifizierung und Autorisierung im Zusammenspiel mit der Google Identity Platform sehr homogen lösen.
• Gerade im Umfeld von Legacy Systemen bietet Apigee die Möglichkeit z.B. eine XML Response in ein JSON Format zu transformieren und somit dem Frontend komfortabel zur Verfügung zu stellen. Zudem kann z.B. auch ein System, welches nicht auf hohe Zugriffszahlen ausgelegt ist, unkompliziert mit entsprechendem Caching ausgestattet werden.

Darf es sonst noch was sein?

Die Commerce Engine, in unserem Fall commercetools, kümmert sich um die Auslieferung der verkaufbaren Einheiten, den sogenannten SKUs (Stock Keeping Unit), gegenüber der Frontend Lösung. Die Aufbereitung der ganzen Produktdaten wie Bilder oder auch Produktbeschreibungen inkl. technischer Merkmale etc. geschieht vorzugsweise in den vorgelagerten Systemen wie Product Information Management (PIM) und Digital Asset Management (DAM). Ein sehr ausschlaggebender und arbeitsintensiver Punkt, welcher aber häufig unterschätzt wird. Auch der Verkaufspreis und der Lagerbestand werden in commercetools gehalten und dienen als erste Anlaufstelle. In diesem Bereich gibt es aber je nach Anwendungsfall noch Ausbaustufen, um beispielsweise den Lagerbestand direkt vom führenden System zu beziehen und den vorgehaltenen Bestand in der Commerce Engine als Fallback zu benutzen, sofern nicht in nützlicher Frist eine Antwort kommt.
Die eCommerce Lösung bietet von Haus aus eine Suchfunktionalität inkl. Facetten an, welche für eine klassische Suche eingesetzt werden kann. Steigen die Ansprüche evtl. hinsichtlich Product Recommendation, können in diesem Architekturansatz weitere Dienste wie beispielsweise die Google Retail API oder Produkte wie algolia und constructor.io eingesetzt werden, ohne die Lösung komplett zu verbiegen wie es bei den klassischen monolithischen Systemen der Fall ist.
Zu guter Letzt ist auch der transaktionale Prozess ein, wenn nicht der wichtigste Bestandteil der Lösung. D.h. von der Bereitstellung des Warenkorbs mit der entsprechenden Berechnung inkl. den Funktionalitäten welche für die Anreicherung der benötigten Informationen während des Checkout Prozesses benötigt werden, damit aus einem Warenkorb eine Bestellung resultiert.

Inhalte jeglicher Art

Um den CMS Teil zu bewerkstelligen, fiel die Wahl auf contentful. Hier besteht für Kunden, die sich an ein klassisches CMS gewöhnt sind, die grösste Umstellung. Nicht nur in der Bedienung, sondern auch in der Denkweise. Gerade was die Bedienung angeht, haben die heutigen Vertreter der Headless CMS Systeme den Anspruch der Benutzer erkannt und bieten den Anwendern unterdessen komfortable Editor-Lösungen wie es contentful z.B. mit ihrem Contenful Studio offeriert.
Durch die einfache Möglichkeit strukturierte Daten abzulegen, verwenden wir contentful nicht nur für die Ablage von klassischem Content für die Website bzw. den Shop, sondern auch Einstellungen und Konfigurationen für das Gesamtsystem können darin verwaltet werden.
Ein weiterer Anwendungsfall sind beispielsweise die Filialdaten mit Bilder, Öffnungszeiten etc. welche zentral organisiert werden können und unterschiedlichen Bezügern wie dem Storelocator auf der Shopseite oder aber auch der unabhängigen Website der Filiale zur Verfügung gestellt werden können. Eine kleine Anmerkung hier, eine Umkreissuche für die Filialen Suche lässt sich z.B. direkt auf der API von contentful realisieren.

Der Daten Highway

Als Integrations-Layer dient BizTalk von Microsoft, welches in unserem Beispiel schon länger beim Kunden im Einsatz ist und uns die Daten aus ERP, PIM etc. liefert. Gerade in unserem Fall macht eine Middleware Sinn, da Änderungen aus den genannten Systemen nur einmal verarbeitet werden müssen und dann unabhängig an die unterschiedlichen Konsumenten bzw. Shopsysteme ausgespielt werden können. Zudem kommen die Daten aus unterschiedlichen ERP-Systemen und können an diesem Punkt zusammengeführt und vereinheitlicht werden. Somit muss sich nicht jeder Bezüger mit einer eigenen Logik um die gleiche Thematik kümmern. Ein weiterer Punkt ist die Fehlerbehandlung, welche an diesem Punkt kanalisiert wird.

Fazit

• Das Konzept von Composable Commerce erlaubt ein iteratives und dadurch schlankes Vorgehen und richtet sich ganz nach dem Ansatz: Think big, start small, scale fast.
• Der richtige Aufbau und Auslegung des API und Integrations-Layers ist entscheidend, um mit möglichst geringem Aufwand bzw. Justierungen den iterativen Ablöseprozess über die Bühne zu bringen.
• Auch wenn die Architektur sehr flexibel ist und Kurskorrekturen einfacher gemacht werden können als bei einem monolithischen Ansatz, sollte man sich schon zu Beginn einige Gedanken zur Zielarchitektur gemacht haben und die Richtung klar deklarieren. Damit entsprechende Entscheidungen, die auf dem Weg getroffen werden müssen, zu einem besseren Ergebnis führen. Es muss aber definitiv nicht schon die Gesamtlösung in jedem Detail und für jede Eventualität durchspezifiziert sein, weil wie so oft bewahrheitet sich das Sprichwort: Erstens kommt es anders, und zweitens als man denkt.

Und wenn Sie jetzt auch denken, es sollte anders kommen als was heute mit Ihrem System möglich ist…melden Sie sich bei uns, wir helfen Ihnen gerne den Grundstein für eine nachhaltige und zukunftsfähige Lösung zu legen.