Warum eine \u00c4nderung ansteht<\/h2>\n\n\n\n
Das heutige Shop System des Kunden ist eine All-In-One L\u00f6sung 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\u00fcr das Vorhaben des Kunden, eine neue Marke in einem neuen Markt zu etablieren, m\u00fcsste man eine Kopie ziehen und als zweites System daneben stellen. Der Copy&Paste Ansatz w\u00e4re 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\u00e4higkeit mit einer zus\u00e4tzlichen Marke und\/oder Markt.<\/p>\n\n\n\n
Wo soll die Reise hingehen?<\/h2>\n\n\n\n
Die neue L\u00f6sung 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\u00f6sung im bestehenden Markt abl\u00f6sen. Die neue Architektur erlaubt, dass so viel wie m\u00f6glich \u00fcber gemeinsam genutzte Bausteine abgedeckt werden kann und da wo es n\u00f6tig ist oder da wo es wirklich auf eine Differenzierung ankommt, spezifische L\u00f6sungen zum Einsatz kommen.<\/p>\n\n\n\n
Wie sieht sowas aus?<\/h2>\n\n\n\n
Unser technisches Setup sieht wie folgt aus:<\/p>\n\n\n\n Das Frontend ist modular im Atomic Design System aufgebaut und ist komplett losgel\u00f6st vom Backend. Dabei ist es wichtig, dass beide Ans\u00e4tze von Client Side Rendering (CSR) und Server Side Rendering (SSR) je nach Bedarf unterst\u00fctzt werden. Solche Anforderungen lassen sich heute sehr gut mit Frameworks wie next.js<\/a> im React<\/a>– oder nuxt.js<\/a> im Vue<\/a>-Umfeld umsetzen. Das komplette Frontend l\u00e4uft gegen einen API Gateway, in unserem Fall Apigee<\/a> von Google. Dies hat mehrere Gr\u00fcnde:<\/p>\n\n\n\n Die Commerce Engine, in unserem Fall commercetools<\/a>, k\u00fcmmert sich um die Auslieferung der verkaufbaren Einheiten, den sogenannten SKUs (Stock Keeping Unit), gegen\u00fcber der Frontend L\u00f6sung. Die Aufbereitung der ganzen Produktdaten wie Bilder oder auch Produktbeschreibungen inkl. technischer Merkmale etc. geschieht vorzugsweise in den vorgelagerten Systemen wie Product Information Management<\/a> (PIM) und Digital Asset Management<\/a> (DAM). Ein sehr ausschlaggebender und arbeitsintensiver Punkt, welcher aber h\u00e4ufig untersch\u00e4tzt wird. Auch der Verkaufspreis und der Lagerbestand werden in commercetools<\/a> gehalten und dienen als erste Anlaufstelle. In diesem Bereich gibt es aber je nach Anwendungsfall noch Ausbaustufen, um beispielsweise den Lagerbestand direkt vom f\u00fchrenden System zu beziehen und den vorgehaltenen Bestand in der Commerce Engine als Fallback zu benutzen, sofern nicht in n\u00fctzlicher Frist eine Antwort kommt. Um den CMS Teil zu bewerkstelligen, fiel die Wahl auf contentful<\/a>. Hier besteht f\u00fcr Kunden, die sich an ein klassisches CMS gew\u00f6hnt sind, die gr\u00f6sste 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\u00f6sungen wie es contentful<\/a> z.B. mit ihrem Contenful Studio<\/a> offeriert. Als Integrations-Layer dient BizTalk<\/a> von Microsoft, welches in unserem Beispiel schon l\u00e4nger beim Kunden im Einsatz ist und uns die Daten aus ERP<\/a>, PIM<\/a> etc. liefert. Gerade in unserem Fall macht eine Middleware Sinn, da \u00c4nderungen aus den genannten Systemen nur einmal verarbeitet werden m\u00fcssen und dann unabh\u00e4ngig an die unterschiedlichen Konsumenten bzw. Shopsysteme ausgespielt werden k\u00f6nnen. Zudem kommen die Daten aus unterschiedlichen ERP-<\/a>Systemen und k\u00f6nnen an diesem Punkt zusammengef\u00fchrt und vereinheitlicht werden. Somit muss sich nicht jeder Bez\u00fcger mit einer eigenen Logik um die gleiche Thematik k\u00fcmmern. Ein weiterer Punkt ist die Fehlerbehandlung, welche an diesem Punkt kanalisiert wird.<\/p>\n\n\n\n Und wenn Sie jetzt auch denken, es sollte anders kommen als was heute mit Ihrem System m\u00f6glich ist\u2026melden Sie sich bei uns, wir helfen Ihnen gerne den Grundstein f\u00fcr eine nachhaltige und zukunftsf\u00e4hige L\u00f6sung zu legen.<\/p>\n\n\n\n![\"architecture\"\/](\"https:\/\/i0.wp.com\/diselva.com\/wp-content\/uploads\/2025\/07\/architecture.png?w=1360&quality=78&ssl=1\")
<\/figure>\n\n\n\n\n
Was der Kunde sieht<\/h2>\n\n\n\n
Weil gerade in diesem Bereich die Differenzierung passieren kann bzw. soll und daher sehr eigenst\u00e4ndige Bausteine entstehen k\u00f6nnen, ist es wichtig, sich vorab Gedanken zu machen, wo es in die gleiche Richtung geht, um z.B. eine gemeinsam genutzte Komponentenbibliothek zu etablieren.<\/p>\n\n\n\nDer Klebstoff der alles zusammenh\u00e4lt<\/h2>\n\n\n\n
\n
Darf es sonst noch was sein?<\/h2>\n\n\n\n
Die eCommerce L\u00f6sung bietet von Haus aus eine Suchfunktionalit\u00e4t inkl. Facetten an, welche f\u00fcr eine klassische Suche eingesetzt werden kann. Steigen die Anspr\u00fcche evtl. hinsichtlich Product Recommendation, k\u00f6nnen in diesem Architekturansatz weitere Dienste wie beispielsweise die Google Retail API<\/a> oder Produkte wie algolia<\/a> und constructor.io<\/a> eingesetzt werden, ohne die L\u00f6sung 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\u00f6sung. D.h. von der Bereitstellung des Warenkorbs mit der entsprechenden Berechnung inkl. den Funktionalit\u00e4ten welche f\u00fcr die Anreicherung der ben\u00f6tigten Informationen w\u00e4hrend des Checkout Prozesses ben\u00f6tigt werden, damit aus einem Warenkorb eine Bestellung resultiert.<\/p>\n\n\n\nInhalte jeglicher Art<\/h2>\n\n\n\n
Durch die einfache M\u00f6glichkeit strukturierte Daten abzulegen, verwenden wir contentful<\/a> nicht nur f\u00fcr die Ablage von klassischem Content f\u00fcr die Website bzw. den Shop, sondern auch Einstellungen und Konfigurationen f\u00fcr das Gesamtsystem k\u00f6nnen darin verwaltet werden.
Ein weiterer Anwendungsfall sind beispielsweise die Filialdaten mit Bilder, \u00d6ffnungszeiten etc. welche zentral organisiert werden k\u00f6nnen und unterschiedlichen Bez\u00fcgern wie dem Storelocator auf der Shopseite oder aber auch der unabh\u00e4ngigen Website der Filiale zur Verf\u00fcgung gestellt werden k\u00f6nnen. Eine kleine Anmerkung hier, eine Umkreissuche f\u00fcr die Filialen Suche l\u00e4sst sich z.B. direkt auf der API von contentful<\/a> realisieren.<\/p>\n\n\n\nDer Daten Highway<\/h2>\n\n\n\n
Fazit<\/h2>\n\n\n\n
\n