Headless-Commerce ist kein Selbstzweck

In den vergangenen zwei Jahren wurde (neben KI) wohl kaum ein Begriff so inflationär gebraucht, wie „Headless Commerce”. Ganz viele aktuelle Probleme im Handel sollen sich damit wie von selbst lösen. Nur leider ist das kein Selbstläufer.

Es klingt ja zu schön, um wahr zu sein. Dank „Headless-Architekturen” und „Mikro-Services” werden die IT-Systeme von Händlern schneller und viel flexibler. Dazu müsse man sich nur von seinen starren Systemen verabschieden und (schrittweise) alles umstellen. Es gibt da aber doch noch die eine oder andere Kleinigkeit zu bedenken.

Die offensichtlichen Vorteile des Ansatzes

„Headless” kommt wie so vieles aus der IT-Welt. Da bezeichnet es meist Installationen und Anwendungen, die ohne eine klassische Benutzeroberfläche auskommen. Wer etwa einen Server auf Basis von Linux aufsetzt, kann oft eine „Headless”-Variante wählen. Die bietet alle Funktionen, schleppt aber nicht den Ballast der grafischen Oberfläche mit.

Dieses Prinzip wird im Bereich E-Commerce auf die notwendigen Programme übertragen. Klassischerweise entscheidet sich ein Händler für eine Shoplösung. Die bietet einen definierten Funktionsumfang, neue Funktionen kommen dann in einer neuen Version zu Einsatz. Dabei liegen Programmcode, Oberfläche für die Bedienung und die Funktionen ein einem geschlossenen Gebilde vor.

Zum Problem können diese monolithischen Systeme in zweierlei Hinsicht werden:

1. Zum einen gibt es nicht mehr nur den einen Kanal, über den die Kundschaft einkaufen will. Sie nutzt Apps, mobile Webseiten, einen Marktplatz oder eben den Shop. Obwohl die gleichen Funktionen, etwa Warenkorb, Payment etc. benötigt werden, kann ein Onlineshop nicht einfach so zu einer App werden. Und nicht jedes Shopsystem bietet hier die technischen Voraussetzungen, um dies schnell und kostengünstig zu realisieren.
2. Die Funktionen sind tief im Programmcode des Systems verborgen und teilweise miteinander verwoben. So bleibt dann häufig nichts anderes übrig, als diese in einer anderen Anwendung nachzubauen, um so mittels Schnittstellen die Daten in sein führendes System zu integrieren.

Jetzt kommen der Headless-Ansatz und die Mikroservices ins Spiel. Denn diese splitten (ebenfalls stark vereinfacht) die Funktionen auf. Und zwar so, dass diese dann über eine definierte Schnittstelle in einer anderen Software oder Umgebung genutzt werden können. Wem das zu abstrakt ist: Gibt es in einem Shop eine Suche nach Standorten eines Filialisten, ist das eine Funktion, die beispielsweise sehr gut in einer mobilen App genutzt werden kann. Die Standortsuche wird zu einem Mikroservice. Ob Shop, App oder etwa eine Sprachsuche: Über die API werden die Standorte abgefragt. Die Logik arbeitet zentral im Hintergrund und wird über die Cloud zur Verfügung gestellt.

Da über die API nur Daten abgefragt werden, kann das gesamte System schneller arbeiten und wird auch schlanker. Die Einbindung der API in eine App verbraucht weniger Speicherplatz als die Implementierung einer vollständigen Suche.

Basiert das E-Commerce-System vollständig auf Mikroservices und APIs, sind auch Erweiterungen viel einfacher, wenn die API eines externen Anbieters integriert wird.

Headless ist nicht kopflos, kann es aber werden

Die Kombination aus APIs und Mikroservices kann somit Entwicklungen und Anpassungen beschleunigen. Und durch das Schöpfen aus einem Fundus aus Services können auch neue Anwendungen flexibler entwickelt werden. Immer unter der Prämisse, dass die Basis bereits nach diesem Ansatz funktioniert.

Ob die Entwicklungszeit tatsächlich kürzer wird, hängt von den realen Bedingungen ab. Verglichen mit konventioneller Entwicklung sollte das aber der Fall sein. Und in der vollen Aufbaustufe nur noch Daten zwischen APIs bewegt werden, wird das System schneller.

Leider fallen bei der arg technikgetriebenen Diskussion verschiedene Aspekte regelmäßig unter den Tisch.

• Daten sind hier das Schlüsselwort. Es besteht nämlich die Gefahr, sich hier kopflos in ein Abenteuer zu stürzen, das viel Geld kostet, am Ende des Tages aber keinen Mehrwert bringt. So erinnert die Vorteilsargumentation zu Headless an Menschen, die sich für 50 Quadratmeter Rasenfläche einen Aufsitzmäher kaufen. Toll, so stark motorisiert zu sein, löst aber nicht die Kernprobleme. Und die liegen bei vielen Händler in der Datenqualität. Ob es nun korrekte Anschriften, Anreden oder Geschlechtszuweisungen sind: Ein kritischer Blick in den eigenen Posteingang wird Ihnen sicherlich zahllose kleinere Fehler selbst bei den Großen der Branche offerieren. Und das ist oft nur die berühmte Spitze eines Eisberges. Die Einführung von Headless ist kein Selbstläufer, der schlechte Datenqualität optimiert.
• Daten werden zwischen den Schnittstellen in Windeseile übertragen. Damit stellt sich aber auch die Frage nach der Datensicherheit. Denn am sichersten vor Angriffen und Hackingversuchen sind die Daten, die sich möglichst kaum bewegen, sondern geschützt in einem sicheren Speicher aufbewahrt werden. Wenn sie denn transportiert werden müssen, gebietet schon allein die Compliance, dass die Daten auf ihrem Weg verschlüsselt werden müssen (Transportverschlüsselung).
• Im Marketing kommt es heute darauf an, möglichst viele Daten miteinander zu verbinden, um daraus individuelle Kundenerlebnisse zu schaffen und neue Erkenntnisse zu gewinnen. Nicht jeder Marketingfachmann ist Entwickler (und wird es aller Voraussicht nach auch nie werden). Das Niederreißen von Oberflächen macht es genau dieser Expertengruppe deutlich schwerer, mit den Daten zu arbeiten und überhaupt die Möglichkeiten zu erkennen, die zur Verfügung gestellte APIs denn bieten.

Headless-Commerce und Mikroservices sind aus meiner Sicht durchaus eine adäquate Antwort auf die weitere (wenig vorhersagbare) Zukunft im E-Commerce. Aber bevor sich Unternehmen auf diesen Pfad begeben, sollten sie kritisch hinterfragen, wo genau diese Architektur ihnen in Zukunft weiterhelfen wird und ob sie ihre eigenen Hausaufgaben auch erledigt haben.