Hinweis: Dies ist Teil 1 unserer Serie von Beiträgen darüber, wie der futuristische Ansatz der Syndigo-Architektur unseren Kunden zugutekommt.
Primitive und monolithische Systeme für den digitalen Handel wurden für den einfachen Handel entwickelt.
In der Vergangenheit existierten Digital-Commerce-Systeme als isolierte Monolithen in der Systemlandschaft von Unternehmen, die Produkte oder Dienstleistungen verkaufen. In diesen Systemen waren nicht nur alle erforderlichen Daten vorhanden, sondern sie boten auch alle wesentlichen Funktionen - Preisberechnung, Rabatte, einige Funktionen zur Anreicherung Ihrer Produktdaten, einige kleinere Content Management System (CMS)-Funktionen und so weiter. Das Front-End (die kundenorientierte Schnittstelle) und das Back-End (Server, Datenbank und Geschäftslogik) des Systems waren eng miteinander verbunden.
Auch die Integration zwischen dem elektronischen Handel und anderen Systemen war rudimentär. Es gab keine Möglichkeit, die Genauigkeit und Konsistenz zu überprüfen - ob das System prüfte, ob der Bestand korrekt war oder ob der Preis in anderen Kanälen gleich war usw. Alle Kanäle arbeiteten unabhängig voneinander. Es handelte sich um eine echte Landschaft aus mehreren verschiedenen monolithischen Systemen, die mehr oder weniger nicht synchronisiert waren.
Die Entwicklung wurde durch Kundenpräferenzen vorangetrieben
Als die Verbraucher jedoch begannen, bessere Erfahrungen zu fordern, mussten sich die Anbieter anpassen. Die Verbraucher verlangten bessere Inhalte und Produktinformationen, aber vor allem auch bessere Anreize, um dem Unternehmen treu zu bleiben. Daraus ergab sich die Notwendigkeit, die Kommunikation zwischen den Systemen (und Kanälen) zu verbessern. So wurde beispielsweise ein einziges System erforderlich, um den kundenspezifischen Preis zu berechnen - und zwar für alle Kanäle! Es wurde notwendig, die genaue Anzahl der vorrätigen Artikel zu ermitteln, bevor die Bestellung aufgegeben wird. Es wurde notwendig, die Bestellung sofort im zugrundeliegenden Auftragsverwaltungssystem (OMS) zu verarbeiten, unabhängig davon, ob es sich dabei um ein großes monolithisches ERP-System oder ein separates OMS-System handelt.
Mit der Weiterentwicklung der Webtechnologien setzten sich APIs (Application Programming Interfaces) immer mehr durch. APIs ermöglichten einen besseren Datenaustausch und eine bessere Integration zwischen verschiedenen Systemen. eCommerce-Plattformen begannen, APIs anzubieten, die es Entwicklern von Drittanbietern ermöglichten, benutzerdefinierte Front-Ends zu erstellen oder in andere Systeme zu integrieren.
Dies war ein echter Schritt nach vorne und ein echter Treiber für die nächste Veränderung im eCommerce - von Cross-Channel oder Multi-Channel hin zu Omnichannel. Es war ein wichtiger Meilenstein auf dem Weg zur Schaffung eines über alle Kanäle verbundenen Kundenerlebnisses. Der andere, noch wichtigere Treiber für die Entwicklung war jedoch der schiere Umfang, die Größe und die Geschwindigkeit der Daten. Die alten Systeme waren einfach nicht in der Lage, Anfragen in der heutigen Größenordnung zu verarbeiten. Es gab eine wachsende Nachfrage nach flexibleren und individuell anpassbaren eCommerce-Erlebnissen.
Headless commerce war der nächste Schritt in dieser Entwicklung des digitalen Handels.
Eine kurze Analogie zur Beschreibung einer headless Architektur
Eine einfache Möglichkeit, sich Headless vorzustellen, ist ein Szenario, in dem Sie sich Lebensmittel liefern lassen. Wahrscheinlich haben Sie eine App, mit der Sie ein paar Artikel auswählen können, und ein paar Minuten später stehen sie vor Ihrer Haustür. Aber was passiert, wenn Sie auf die Schaltfläche klicken? Es müssen zwei Dinge passieren - jemand muss durch den Laden gehen und Ihre Lebensmittel einkaufen, und jemand muss vom Laden zu Ihnen nach Hause fahren und sie liefern.
Sie können sich eine Version dieses Prozesses vorstellen, bei der sowohl der Käufer als auch der Fahrer ein und dieselbe Person sind.
Aber stellen Sie sich vor, sie wären es nicht. Sie könnten den besten Einkäufer für die Einkäufe und den besten Fahrer für die Fahrten einsetzen. Wenn Ihr Fahrer umziehen oder kündigen müsste, könnten Sie ihn ersetzen und die Einkäufe nahtlos an den neuen Fahrer weitergeben.
Der Begriff Headless Architecture bezeichnet einen modernen Ansatz für die eCommerce-Architektur, bei dem das Front-End (die kundenorientierte Schnittstelle) und das Back-End (Datenbank, Geschäftslogik und Logistik) eines Online-Shops lose gekoppelt oder getrennt sind. Diese Entkopplung ermöglicht eine größere Flexibilität, Skalierbarkeit und Anpassbarkeit bei der Bereitstellung von digitalen Einkaufserlebnissen.
Diese Trennung wurde mit Hilfe von APIs erreicht, die die Entwicklung benutzerdefinierter Frontends unter Verwendung verschiedener Technologien wie JavaScript-Frameworks (z. B. React, Vue.js) oder mobiler Anwendungen ermöglichten und die Kommunikation und den Datenaustausch zwischen den Frontend- und Backend-Komponenten erleichterten.
Wie Syndigo PIM die headless Architektur umsetzt
In jedem PIM-System werden einige Schlüsselfunktionen erwartet.
- Das System muss in der Lage sein, die Art der Daten (das Schema) zu definieren.
- Es muss in der Lage sein, die Daten zu erfassen und zu speichern.
- Der Nutzer sollte die Möglichkeit haben, eine Suche in den Daten durchzuführen.
- Das System sollte in der Lage sein, die Daten zu validieren, d. h. sie auf Vollständigkeit und Genauigkeit zu prüfen.
- Anreicherung der Inhalte, wenn möglich durch Automatisierung
- Syndikation?
Die herkömmliche Methode, diese Funktionen anzubieten, besteht darin, sie alle in einer einzigen App zu vereinen, die den gesamten Bedarf des Nutzers abdeckt. Auf den ersten Blick scheint diese Methode zu genügen. Da jedoch neue Technologien und Prozesse entwickelt werden, würde jede Aktualisierung der App eine massive, teure Überarbeitung erfordern. Die gesamte Anwendung müsste neu geschrieben werden, nur um die Suchfunktion zu verbessern. Und später noch einmal, wenn es eine bessere Möglichkeit zur Anreicherung von Inhalten gibt. Und dann noch einmal, wenn es eine weitere Verbesserung der Suchfunktion gibt.
Stattdessen besteht Syndigos Ansatz für PIM darin, diese Dienste als Module anzubieten, die über APIs verbunden sind. Auf diese Weise muss nur das Modul aktualisiert werden, wenn der Bedarf oder Wunsch besteht, die Art und Weise der Ausführung einer Suchfunktion zu verbessern. Der Rest der Anwendung bleibt unangetastet. Auf diese Weise wird dem Nutzer immer die bestmögliche Konfiguration der Anwendung angeboten.
Even outside of the PIM itself, the customer benefits from the flexibility to configure their e-commerce landscape as a whole due to the loose coupling with the PIM. Updates to the data models in the PIM can flow upstream or downstream through model change interfaces. Changes to the e-commerce pricing engine or web interface can be done without worrying about changes to the entire tech stack like you would have to with a monolithic vendor. Syndigo’s approach delivers our customers a best-in-breed PIM for their commerce needs and ensures that they are able to adjust and improve their technology as needed with minimal disruptions. Contact us to learn more about how Syndigo’s headless approach to PIM can help you not only streamline your PIM functionalities but also empower you to adapt and thrive in an ever-evolving digital marketplace
