Wie Headless E-Commerce zum Shop-Turbo wird

Headless E-Commerce Systems sind derzeit stark gefragt. Wegbereiter dieses Trends sind Anbieter wie CommerceTools    und Spryker  , die sich bei der Entwicklung ihrer Systeme von vornherein auf den Kern der ECommerce-Software konzentriert und das Konzept teilweise mit einem Microservice-Ansatz auf die Spitze getrieben haben. Der Clou eines Headless-Systems liegt in der vollständigen Trennung Frontend und Backend. Auf diese Weise lässt sich die Funktionalität des Shops deutlich einfacher umsetzen.

• Herkömmliche monolithische Systeme stellen den vollen Funktionsumfang eines Webshops bereit. Sie verwalten Produktdaten, Kundendaten und Informationen (wie Impressum, Bestellinformationen oder sonstigen Content), übernehmen die Bestell- und Bezahlfunktion (Ordermanagement) und stellen die fertigen HTML-Seiten in Form eines Web-Shops für den Kunden bereit (Frontend).
  
  
• Entkoppelte Headless Systeme sind dagegen in der Lage, diese Funktionalitäten zu trennen. Sie stellen im Kern das reine Ordermanagement bereit und bieten - wichtiger noch - ein leistungsfähiges Set an Schnittstellen (APIs), mit dem sich im Backend Systeme für Produktdaten (PIM), Kundendaten (CRM), Unternehmensdaten (ERP), Content (CMS) und Statistik (Analytics) anflanschen lassen. Auch das Frontend ist nicht mehr Teil der ECommerce-Software. Es wird als eigene Applikation entwickelt, die ebenfalls über die APIs mit der ECommerce-Engine kommuniziert.

Zuerst wurde der Ansatz in der Welt der Content Management Systeme (CMS) entwickelt (siehe iBusiness: API statt Apache - Warum Headless CMS das Content-Business umkrempelt). Dort wurden die Vorteile dieses Ansatzes offensichtlich, als das Internet begann, den Browser zu verlassen und in native Apps für Smartphones und Tablets wanderte, in IoT-Geräte wie Internet-Radios oder vernetzte Lautsprecher, Social-Media-Anwendungen, CSS-Reader, Intranet-Browser - kurz: Der Bedarf wuchs, Inhalte auf einer Vielzahl von Applikationen auszugeben und mittels Content-Syndication auszutauschen. Die HTML-Seite als höchste Form der Content-Aufbereitung hatte ausgedient, der Zugriff auf den reinen, unbehandelten Content wurde wichtiger.

Zeitgleich setzte eine ähnliche Entwicklung im ECommerce ein. Auch dort waren monolithische Systeme anfangs die Regel, die versuchten, eine Vielzahl von Funktionen in sich zu vereinen. Über diesen Ansatz stolperten zuerst große Unternehmen, die bereits eine gewachsene IT-Infrastruktur mitbrachten. Händler wie der Otto Versand   leisteten sich große und teure Enterprise-Shops - nur um diese im Anschluss mühselig zu entkernen und den nackten Rest mit den vorhandenen Systemen zu verheiraten.

Unternehmen wie Spryker und CommerceTools waren dann die ersten, die diesen Ansatz vollständig übernahmen und sich als "Betriebssystem für E-Commerce" (Spryker-Werbung) positionierten: Sowohl im Back- als auch im Frontend stellen diese Systeme lediglich das Ordermanagement und ein Schnittstellen-Set bereit, an das sich quasi beliebige Anwendungen anflanschen lassen.

Inzwischen unterstützen fast alle namhaften Hersteller von Enterprise-Systemen - ob Magento    (seit Version 2.0), Shopware    (seit Version 6.0), Oxid Esales   , SAP Commerce Cloud  , Salesforce Commerce Cloud   (ehemals Demandware), Intershop    oder Novomind   iShop - diesen Ansatz. "Headless-Systeme sind in unseren Augen ganz klar die Zukunft", meint etwa Simon Schröer , Senior Solution Engineer bei der Magento-Agentur Netz98   . "Die Vorteile sind so vielfältig, dass sich dieses Konzept auf lange Sicht sicher durchsetzen wird."

Die wichtigsten Anwendungsfelder:

• Crosschannel-Handel: Für Crosschannel-Händler ist es deutlich einfacher, ein Headless-System in die bestehende IT-Infrastruktur einzupassen. Datensilos lassen sich vermeiden, weil mit den passenden Connectoren Webshop, Katalog und POS mit den selben Daten beschickt werden können. Gerade komplexe Omnichannel-Herausforderungen lassen sich in einer nahtlos integrierten IT-Umgebung besser lösen.
  
• Marketing / User-Experience: Ein Headless-System erleichtert es, gemeinsam verwaltete Kundendaten zu nutzen. Da das Frontend frei gestaltet werden kann, lassen sich Verknüpfungen zu innovativen Personalisierungs- und Marketingfunktionen realisieren und die User-Experience (UX) deutlich verbessern.
  
• Conversational Commerce: Die Shopfunktionalität findet API-basiert statt, dadurch lassen sich neue ECommerce-Touchpoints leicht ansteuern: Chatbots können beispielsweise Transaktionen dialogbasiert durchführen, Social-Media-Kanäle wie Instagram oder Pinterest werden zur Storefront, Alexa-Skills zu VoiceCommerce-Agenten und In-Car-Entertainment-Systeme zu mobilen Verkaufsstellen. Solange sich über den neuen Kanal die ECommerce-API ansteuern lässt, kann er zum Shop-Frontend werden.
  
• Multistore-, Multibrand-Anwendungen: Ideal ist die Trennung von Funktion und Gestaltung selbstverständlich auch, wenn internationale Marken verschiedene nationale Vertriebsorganisationen, Marken oder Tochterunternehmen führen. Die Unabhängigkeit nationaler Teams bleibt unangetastet, trotzdem kann die Mutter zentrale Aufgaben übernehmen.

Moderner Ansatz - aber selten zwingend nötig

So einleuchtend diese Vorteile sind, um so sehr muss man aber auch auf dem Boden der Tatsachen bleiben: Die genannten Szenarien sind nicht für jeden Händler relevant, oft mehr Zukunftsmusik als umsatzrelevanter Vertriebskanal und häufig mit herkömmlichen Methoden zwar nicht so elegant, aber - getreu der 80:20-Regel - zumindest befriedigend zu lösen. Eine Headless E-Commerce-System ist in jedem Fall ein moderner Ansatz - aber eben in den seltensten Fällen zwingend nötig.

Zumal auch die Nachteile nicht übersehen werden dürfen: "Durch die Trennung von Front- und Backend entsteht mehr Entwicklungsaufwand, da gegebenenfalls nicht vorhandene Schnittstellen erst noch programmiert werden müssen", schränkt Schröer ein. ein. Es bieten sich zwar im Gegenzug auch mehr Individualisierungsmöglichkeiten, doch wenn diese nicht oder kaum genutzt werden, bleiben vor allem die höheren Kosten. "Für kleine Händler ist das durchaus eine Hürde."

Langfristig könnte sich diese Entwicklung aber umkehren. "Wenn Agenturen eine gewisse Anzahl von Implementationen geleistet haben, verfügen sie auch über mehr Standard-Komponenten. Dann sinken Aufwand und Kosten wieder", meint der Netz98-Entwickler. Schließlich lässt die hohe Flexibilität eines Headless-Systems grundsätzlich eine kürzere Time-to-Market zu. Und auf dem leergefegten Fachkräftemarkt profitieren Agenturen auch noch von einem anderen Effekt. "Für die Entwicklung eines Headless-Frontends müssen wir nicht nach den raren Spezialisten für ein bestimmtes Shopsystem suchen", erklärt Schröer. "Wir sind in der Wahl der Technologie und der Mitarbeiter sehr viel freier." Auch dies wird sich langfristig auf die Preisentwicklung niederschlagen.

Headless ist nicht gleich Headless

Trotzdem dürften viele Händler den Markt zunächst noch beobachten und bis zum nächsten turnusgemäßen System-Update warten. Bis dahin gibt es einiges abzuwägen. Denn: Headless ist nicht gleich Headless. Die verschiedenen Unternehmen nähern sich durchaus aus unterschiedlichen Richtungen. Die radikalsten Vertreter setzen auf einen API First-Ansatz und verbinden diesen vielleicht noch mit einer Microservice-Architektur, bei der jede einzelne Funktion von einer kleinen, überschaubaren App dargereicht wird (siehe iBusiness: Wie Microservices mehr Innovationsfähigkeit in Digitalunternehmen bringen).

API-First beschreibt dabei die Idee, die gesamte Software rund um die Schnittstellen zu bauen. Soll eine neue Funktion realisiert werden, wird zuerst die Schnittstelle definiert und beschrieben. Sicherheits- und Performancefragen müssen zuerst geklärt werden. Dieses Vorgehen stellt sicher, dass jede Funktion über APIs gesteuert werden kann.

Bohrt der Hersteller hingegen seine Software nachträglich um ein Schnittstellenset auf, ergeben sich häufig Schwierigkeiten, die eine umfängliche Steuerung verhindern. Der Hersteller ist dann gezwungen, seine Core Software vollständig neu zu entwickeln - so wie dies Shopware jüngst mit Version 6 seiner Anwendung getan hat - oder Workarounds anzubieten.

Häufig werden REST-APIs für die Schnittstellen verwendet. Solche APIs sollen allumfassend sein und wie aus einem Guss wirken. Einheitliche Formate, Verlinkungen und Dokumentationen vereinfachen den Umgang und sollen Dopplungen von Begriffen mit jeweils unterschiedlichen Bedeutungen in verschiedenen Kontexten vermeiden. Eine gute REST-API ist die Basis für eine weitere erfolgreiche Entwicklungsarbeit.

Allerdings gibt es mit GraphQL auch einen alternativen Ansatz, den etwa Oxid Esales in seinem Core implementiert hat. Genau genommen handelt es sich dabei um eine 2015 erstmals veröffentlichte Anfragesprache (Query Language). Sie versucht, einige Probleme starrer Schnittstellen zu umgehen. Diese liefern einen standardisierten Datensatz in einem festgelegten Format. Für den gewünschten Zweck können das zu viele Daten (etwa, wenn nur der Vorname des Users benötigt wird, aber die kompletten Kontaktdaten geliefert werden) oder zu wenige Daten sein (was zu einer weiteren Abfrage und damit Prozessorlast führt). Außerdem muss die REST-API über eine Versionierung erneuert werden, wenn die neuen Features eingeführt werden oder eine Überarbeitung der Datenschicht notwendig ist.

GraphQL bündelt dagegen Requests und kann selbst Datenabhängigkeiten in einer einzigen Abfrage auflösen. Außerdem legt die Sprache schon bei der Abfrage fest, wie und in welchem Format das Ergebnis zurückgegeben werden soll. Dies reduziert einerseits die Menge der zu verarbeitenden Daten und erlaubt es andererseits, die Schnittstelle zu erweitern, ohne eine Versionierung durchzuführen oder das Frontend anzupassen.

Headless: Für jeden und niemanden

Zuletzt machen einige Hersteller den Aufstieg ins Headless-Lager einfacher, indem sie ihre Software immer noch mit einem eigenen Frontend ausstatten. Magento 2.0 und das gerade erst runderneuerte Shopware 6 gehen diesen Weg. Trotz konsequentem API-First-Ansatz ist in der neuesten Shopware-Version nach wie vor ein eigenes Frontend integriert. "Für uns ist ganz wesentlich, dass Händler mit Shopware wachsen können", erklärt Niklas Dzösch, Developer Evangelist bei Shopware den Ansatz. "Deshalb konzentrieren wir uns nach wie vor ganz stark auf KMU, obwohl wir auch ein eigenes Enterprise-Team beschäftigen."

In der Software hat diese Philosophie Spuren hinterlassen: So kann ein kleinerer Händler nach wie vor das mitgelieferte Frontend verwenden und den Standardshop mit geringem Aufwand nutzen. Will er erweitern, stehen ihm trotzdem alle Vorteile des API-Ansatzes zur Verfügung.

"Letztlich", gibt Dzösch zu bedenken, "ist Heeadless ein Thema, das jeder und niemand braucht." Kein Händler verkauft auch nur ein Stück mehr, weil sein Shopsystem Headless arbeitet. Insofern kann dem Händler und dem Kunden das Thema zunächst völlig egal sein. Aber: "Richtig eingesetzt ist Headless ein Turbo für den ECommerce", sagt der Evangelist. Nämlich dann, wenn der Händler durch die schnellere Entwicklungsarbeit, schlankere Systeme und neue Features profitieren kann.

Insofern: Headless ist kein Wert an sich. Es geht vielmehr darum, im richtigen Moment Headless zu werden.