Schmutzige Geheimnisse des Headless Commerce: Was einige Anbieter absichtlich nicht sagen

Die schmutzigen Geheimnisse von Headless-Commerce-Lösungen: Was einige Anbieter Ihnen (absichtlich) nicht sagen, kann Sie viel Geld kosten.

Headless Commerce – oder einfach „headless“ – ist derzeit der Liebling der B2C-Welt. Laut Google Trends sind die Suchanfragen für Headless Commerce seit Anfang 2020 exponentiell gestiegen. Aus E-Commerce-Sicht ist es leicht zu verstehen, warum.

Die Verbraucher waren während der Pandemie ans Haus gebunden und an ihre Social-Media-Feeds gebunden. Direct-to-Consumer-Marken können Medien wie Instagram, TikTok oder Facebook nutzen und ihre Waren direkt an ihre Zielgruppe bringen. Headless-Commerce-Lösungen sind ein Kinderspiel.

Headless-Architekturen bieten eine große Flexibilität. Aufgrund der Entkopplung von Frontend und Backend (und der Verfügbarkeit von APIs) ist es für Organisationen, die Handel auf neuen Kanälen bereitstellen möchten, viel einfacher, dies mit einer Plattform zu tun, die Headless unterstützt.

Headless-Commerce-Lösungen bieten auch eine größere Agilität, da Frontend und Backend separat bereitgestellt werden. Da Agilität zu einem enormen Unterscheidungsmerkmal für Unternehmen geworden ist, steigt das Interesse an Headless.

Headless-Commerce-Lösungen: Den Hype durchbrechen

Aber was genau ist Headless Commerce? Wie so oft in der Welt der Technik und des Marketings besteht die Tendenz, sich an das neueste glänzende Schlagwort zu klammern – denken Sie an Big Data oder künstliche Intelligenz/maschinelles Lernen vor ein paar Jahren zurück – und es in so viele Gespräche wie möglich einfließen zu lassen .

Wenn Menschen jedoch nicht wirklich definieren können, was ein Ding ist, neigen die Gewässer um dieses Ding herum dazu, ziemlich trübe zu werden. Genau das passiert beim Headless Commerce.

Wir können Marketingfachleuten gegenüber nicht zu hart sein; Sie sind nicht die einzigen, die das Wasser trüben. Viele Anbieter fügen dem Mix absichtlich oder unabsichtlich hinzu, indem sie Headless, Cloud, APIs und Microservices zusammenführen. Sie haben ihre Pläne, also ist es zu ihrem Vorteil, die Grenzen zwischen diesen Dingen zu verwischen. Und um es klar zu sagen, keiner von ihnen ist gleich.

Einfach ausgedrückt bedeutet Headless Commerce:

1. Das Frontend/Storefront/Glas ist von der Commerce-Engine (dh dem Backend) entkoppelt.
2. Da es entkoppelt ist, verbraucht es Backend-Funktionen wie Preise und Werbeaktionen über API-Aufrufe.
3. Damit eine Handelsplattform Headless-Bereitstellungen unterstützen kann, benötigt sie per Definition daher eine API-Abdeckung der Handels-Backend-Funktionalität.

Lassen Sie uns einsteigen und einen genaueren Blick darauf werfen, was Headless genau ist (und was es nicht ist), woher es kommt und für wen es ist.

Headless Commerce ist nichts Neues

Während der Begriff selbst vielleicht erst in den letzten Jahren an Fahrt gewonnen hat, ist das Konzept von Headless nicht im Entferntesten neu. Wie oben erwähnt, handelt es sich um einen API-First-Ansatz, bei dem Frontend/Präsentationsschicht/Glas vom Kern entkoppelt wird (unter Verwendung der APIs).

Beispielsweise ermöglichen wir bei SAP (und ehemals Hybris) seit über einem Jahrzehnt Handelsfunktionen über unsere Restful-API-Schicht (Omni-Commerce Connect). Etwa die Hälfte der über 3500 Kunden, die SAP Commerce (lokal und in der Cloud) betreiben, tun dies Headless mit einem Drittanbieter-CMS oder einer maßgeschneiderten, entkoppelten Storefront.

Der Punkt ist, lassen Sie sich nicht von der Begeisterung täuschen; Headless ist nicht einfach auf der Bildfläche aufgetaucht.

Reine Headless-Commerce-Lösungen sind nicht jedermanns Sache

Headless ist, wie alles andere auch, nicht jedermanns Sache. Es ist komplex, für den Anfang. Entwickler müssen über umfassende und umfassende Kenntnisse in mehreren Codebasen verfügen.

Aber das ist nicht alles. Sie erfordern IT-Reife und Entwicklungskapazitäten, da eine maßgeschneiderte Präsentationsschicht/Storefront vollständig von Grund auf neu erstellt werden muss, wobei Front-End-Frameworks und -Bibliotheken (wie Angular/React/Vue) oder zumindest über eine Partnerlösung verwendet werden müssen. Diese benutzerdefinierten Frontends werden im Allgemeinen nicht vom Anbieter unterstützt.

Darüber hinaus schränken maßgeschneiderte Frontends in der Regel die Fähigkeit von Geschäftspraktikern ein, das Frontend ohne die Hilfe der IT zu entwerfen und zu aktualisieren. Wenn dies eine wichtige Überlegung für Ihr Unternehmen ist, dann sind Headless-only-Commerce-Lösungen möglicherweise nicht gut für Sie geeignet.

Die gute Nachricht: Anbieter bieten „headless and frontal“-Funktionen mit 100 % API-Abdeckung und einer entkoppelten Storefront, ohne dass diese von Grund auf neu aufgebaut werden muss. Dieser Ansatz beschleunigt die Frontend-Entwicklung und die gesamte Projektlaufzeit.

Headless ist nicht gleich Microservices

Wie wir eingangs erwähnt haben, trüben einige Anbieter absichtlich das Wasser, indem sie Headless mit Microservices verschmelzen. Lassen Sie uns den Rekord klarstellen.

Nein, Microservices sind NICHT gleichbedeutend mit APIs. Und nein (ich werde hier meine Stimme von „außen“ verwenden), EINE MICROSERVICE-BASIERTE ARCHITEKTUR IST KEINE VORAUSSETZUNG FÜR HEADLESS (APIs hingegen schon).

Laut Martin Fowler „ist der Microservice-Architekturstil ein Ansatz zur Entwicklung einer einzelnen Anwendung als eine Suite kleiner Dienste, die jeweils in einem eigenen Prozess ausgeführt werden und mit leichtgewichtigen Mechanismen, häufig einer HTTP-Ressourcen-API, kommunizieren.“

Sie haben richtig gelesen – Microservices legen ihre Fähigkeiten über APIs offen und sind als solche komplementäre, nicht austauschbare Konzepte. Vergleichen Sie eine Microservice-basierte Architektur mit einer monolithischen Architektur, bei der die gesamte Anwendung aus „einem Stück“ Code besteht. In der realen Welt basieren nur wenige Anwendungen entweder vollständig auf Microservices oder sind vollständig monolithisch. Sie fallen normalerweise irgendwo in die Mitte.

Während Microservices viele Dinge tun können, sind sie auch kostspielig (viel Overhead) und keinesfalls eine Wunderwaffe für Agilität. Ohne auf die Vor- und Nachteile der einzelnen Architekturmuster einzugehen, ist es erwähnenswert, dass der Hauptvorteil einer auf Microservices basierenden Architektur die Geschwindigkeit und Agilität ist, mit der große Entwicklungsorganisationen Software erstellen können. Der Overhead ist gering im Vergleich zu der Zeit, um Code in einer monolithischen Architektur zu entwickeln.

Es ist also ziemlich wertvoll für einen Anbieter von Handelsplattformen wie Amazon, an dem normalerweise Hunderte von Entwicklern arbeiten. Diese Art von Architektur würde jedoch nicht für alle gut funktionieren. Es eignet sich besonders schlecht für Unternehmen, die nicht über die IT-Kapazitäten und die entsprechenden Ressourcen für die Handelsentwicklung verfügen, um davon zu profitieren.

Es ist besser, darüber nachzudenken, was Gartner die zusammensetzbare Geschäftsarchitektur nennt. Dieses Modell aus austauschbaren Bausteinen ermöglicht es einem Unternehmen, je nach Bedarf umzugestalten, abhängig von Faktoren wie einer Verschiebung der Kundenwerte oder plötzlichen Änderungen in der Lieferkette oder den Materialien. Diese Bausteine ​​oder Module können Mikro-, aber auch Makrodienste sein.

Laut Gartner bietet diese Architektur: Geschwindigkeit durch Erkennung, größere Agilität durch Modularität, bessere Führung durch Orchestrierung und Ausfallsicherheit durch Autonomie. Dies hätte nicht wichtiger sein können als während der Pandemie, als Unternehmen ihre Geschäftsmodelle innerhalb weniger Tage komplett überdenken und umstellen mussten oder riskierten, bankrott zu gehen.

Wenn Sie sich jetzt fragen, warum einige Anbieter Headless mit Microservices verwechseln, ist die Antwort so alt wie der Markt für Unternehmenssoftware selbst. Durch die Betonung einer neuen glänzenden Fähigkeit ermöglicht es aufstrebenden Anbietern, den Fokus von Fähigkeiten abzulenken, bei denen sie zu kurz kommen, wie z. B. Plattform- und Funktionsrobustheit.

Und obwohl eine moderne Architektur definitiv ein wichtiger Aspekt bei der Auswahl einer Handelsplattform ist, darf dies nicht zu Lasten des Funktionsreichtums oder der Fähigkeit gehen, Geschäftsanwendern mehr Möglichkeiten zu geben.

Headless ist gekommen, um zu bleiben

Da die Zahl der Berührungspunkte weiter zunimmt, wird Headless Commerce nirgendwohin führen. Berücksichtigen Sie bei der Auswahl einer Plattform alle funktionalen und nicht funktionalen Anforderungen, die für Ihr Unternehmen gelten, nicht nur heute, sondern auch morgen.

Die Auswahl einer Plattform, die heute vielleicht funktioniert, aber Ihr späteres Wachstum nicht unterstützt ( z. B. internationale Lokalisierung ) , ist kurzsichtig und wird nur dazu führen, dass Sie die sprichwörtliche Dose aufgeben.

Schließlich bedeutet die Tatsache, dass einige Anbieter möchten, dass Sie sich das helle, glänzende Objekt ansehen, nicht, dass die anderen Anforderungen plötzlich keine Rolle mehr spielen. Produktinformationsmanagement, Web-Content-Management, Auftragsmanagement, B2B-Fähigkeiten, B2C-Fähigkeiten und Personalisierung sind unerlässlich.

Tappen Sie nicht in die Falle, robuste Funktionalität mit veralteter Architektur zu verschmelzen, ungeachtet dessen, was einige Anbieter sagen.