Alle Welt spricht von „Headless Commerce“, auch wenn es technologisch gesehen keine Innovation ist. Was verbirgt sich hinter dem Wort „headless“? Ist diese Software-Architektur erfolgsversprechender als herkömmliche Shopsysteme?
Was ist „Headless Commerce“?
Wie auf viele Fragen, gibt es auch auf diese mehrere Antworten. Die einfachste ist wohl die: Die strikte technologische Trennung des Frontends vom Backend. Das bedeutet, dass das Backend als Commerce Engine fungiert und die Darstellung der Produkte mit dem dazugehörigen Content über performante Schnittstellen (API) erfolgt.
Ob eine Software-Architektur von Grund auf so gebaut ist, dass sie beispielsweise kein Shop-Frontend anbietet oder ob sie „im Nachhinein“ so modular umgebaut wurde, dass es egal ist, ob die Commerce Daten in das eigene Frontend oder andere gepumpt werden, spielt zunächst keine Rolle.
Welche Vorteile bietet eine „Headless“ Architektur?
Je komplexer die Anzahl der Shopping-Kanäle, Geräte und Bedienkonzepte und die damit einhergehenden technischen Anforderungen werden, desto größer ist der Bedarf an eine Software, die die Vielfalt an Kanälen schnell und kostengünstig bedienen kann. Und zwar so, dass das Kundenerlebnis am besten perfekt ist. Schnell, weil die ersten, die Instagram-Shopping umsetzen, ganz andere Reichweiten erzielen können als die, die später in den Markt eintreten. Kostengünstig, weil die Lebenszyklen der Frontends deutlich kürzer sind als die der Backends. Investitionen müssen sich also schneller amortisieren.
Wenn es keinen großen Aufwand bedeutet, neue Frontends anzudocken, dann können Unternehmen Ideen ungehindert ausprobieren. Anstelle einer aufwändigen Programmierung einer Erweiterung oder Schnittstelle sind „headless“ Systeme genau darauf vorbereitet, mit wenigen Klicks und ein paar Zeilen Code neue Commerce Apps anzubinden.
Headless Commerce verspricht also Flexibilität und die Freiheit, seine Vertriebskanäle schnell den Marktbedingungen anzupassen und Kunden zielgenau ansprechen. Denn am Ende geht es darum, die Customer Journey möglichst nahtlos zu begleiten und den Kunden über egal welchen Touchpoint zu erreichen, ob es die Smartwatch, die VR-Brille oder der smarte Kühlschrank ist.
Welche Nachteile bringt „Headless Commerce“?
Fakt ist, dass Handel nicht kopflos sein kann. Gekauft wird eben nur über Voice Commerce, eBay, Preisvergleiche, im Laden, am Instore Display oder eben im eigenen Shop. Die Frage ist nur, wer stellt die überzeugenden Inhalte für die Köpfe zur Verfügung und unterfüttert eine zusammhängende Customer Journey?
In Folge dessen, müssen natürlich alle „Frontend-Köpfe“ angeschlossen werden. Je nach Komplexitätsgrad der Produkte und Bestellstrecken, kann etwas sein zwischen ein paar Klicks und ein paar Monaten.
Für wen ist es eine geeignete Software-Architektur?
Wenn es um die Wahl einer Commerce Software geht, stellt sich schnell die Frage: wofür wird es gebraucht? Es gibt nach wie vor genügend Geschäftsmodelle, für die ein einfacher Shop, der den grundlegenden Verkaufsprozess abwickelt, ausreicht.
Je komplexer die Produkte, Märkte und Verkaufskanäle werden, desto sinnvoller ist eine flexible Architektur mit standardisierten Schnittstellen und Microservices. Damit ist gemeint, den Commerce Prozess in kleine Einheiten zu zerlegen, dessen Aufgaben und Funktionen durch Microservices abgedeckt werden. Ändern sich die Marktanforderungen, dann muss nicht die gesamte Commerce Software angepasst werden, sondern nur der jeweilige Micorservice.
Inzwischen hat sich „Headless Commerce“ als zukunftsfähige Software-Architektur durchgesetzt. Und trotzdem sollte man genauer hinsehen und verstehen, was am Ende wirklich nötig ist, um sein Commerce Modell umzusetzen.
Worauf kommt es an?
- Wie gut sind die Schnittstellen?
- Wer orchestriert die Microservices?
- Welche Systeme sind datenführend?
- Wie anpassungsfähig sind überall die Datenstrukturen?
Auf die Schnittstellen kommt es an
Headless Systeme sind nur so gut, wie ihre Schnittstellen sind. Auch wenn eine flexible Architektur im long run günstiger ist, so müssen anfangs für jedes System, mit dem kommuniziert wird, Schnittstellen konfiguriert oder programmiert werden. Entwickler freuen sich, wenn sie mit möglichst wenig Zeilen Code auskommen bzw. die Schnittstellen einheitlich und gut strukturiert sind, sich gut parametrisieren und debuggen lassen. Darüber hinaus bieten vorintegrierte Schnittstellen zu Standard-Systemen den Vorteil, dass ein Datenaustausch direkt erfolgen kann.
Wer behält den Überblick über alle Microservices?
So attraktiv eine granulare Aufteilung in Microservices erscheint, so herausfordernd kann deren Orchestrierung werden, wenn die Geschäftsprozesse immer komplexer werden. Soll beispielsweise die Lagerverwaltung und der Versand dezentralisiert werden, Produkte auch als Private Label verkauft werden oder Geschäftskunden mit individuellen Angeboten bedient werden, dann wird der Standardprozess erweitert. Wer triggert dann welche Aufgabe zu welchem Zeitpunkt?
Middleware oder All-in-one
Will man Headless Commerce Systeme als reine Middleware nutzen, die darauf ausgelegt ist, möglichst einfach und performant mit anderen Systemen zu sprechen und die Daten aus anderen Systemen zu verknüpfen? Also das Produkt x aus dem PIM mit dem individuellen Preis y aus dem ERP für einen Geschäftskunden z aus dem CRM? Dieses Szenario bietet sich dann an, wenn eine bestehende Systemlandschaft nicht verändert werden soll und erste Datenwiederverwendbarkeit hergestellt werden soll.
Headless Architekturen sind dank ihrer flexiblen Einsatzweise bestens für die Zukunft gerüstet. Es wäre zu kurz gedacht, es würde ausreichen, sich zwischen einem monolithischem System und einer Headless Architektur zu entscheiden. Viel wichtiger sind folgende Fragen: Wie baue ich meine Datenstrukturen auf? Welche Bausteine will ich miteinander verdrahten? Wieviel Aufwand muss ich in die Integration der Microservices stecken?
Jeder Händler muss sich so oder so Gedanken machen, wo und wie er Produkte, Preise, Kunden, Aufträge, Faktura und Versand verwalten will. Am wenigsten Aufwand ist es, alle Daten sind in einer orchestrierenden
Hand. Erst dann können Personalisierung, automatisierte Prozesse, Analysen und das direkte Umsetzen der Erkenntnisse in Marketing-Aktionen garantiert stattfinden.
