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.
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.
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.
Unser technisches Setup sieht wie folgt aus:
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.
Das komplette Frontend läuft gegen einen API Gateway, in unserem Fall Apigee von Google. Dies hat mehrere Gründe:
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.
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.
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.
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.
Kontaktaufnahme