Headless E-Commerce Systems sind derzeit stark in aller Munde. Mehrere Anbieter treiben das Modell offen nach vorne, beispielsweise CommerceTools, Intershop, Magento oder Sylius. Den Anfang haben headless CMS-Systeme gemacht. Commerce Systems ziehen nun nach. Der Grund für eine Headless-Architektur ist einfach: Flexibilität und die Anbindung multipler Touchpoints. In diesem Artikel will ich die Geschichte von headless skizzieren, seine Vor- und Nachteile besprechen sowie die Fragen beantworten, für wen es sich eigentlich lohnt und was man bei der Wahl beachten sollte.
Was ist Headless?
Konventionelle Software verfügt über ein Front- und Backend sowie eine Applikationsebene, das die Logiken und Funktionalitäten enthält. Fast immer ist es notwendig, Drittsysteme an die Software anzubinden, bspw. ein Produktinformationssystem oder ein ERP. Dafür werden Konnektoren benötigt, die den Datenaustausch zwischen beiden Systemen formalisieren und umsetzen. Um diesen Prozess voranzutreiben, werden APIs eingesetzt. Das sind standardisierte Programmierschnittstellen. Mehr über die Funktion von APIs könnt Ihr hier nachlesen. Verfügt ein System über solche Schnittstellen, kann es in der Regel headless betrieben werden. Es reicht dabei nicht aus, einfach die UI/UX-Ebene vom System zu entkoppeln. Damit ein System wirklich headless betrieben werden kann, müssen einerseits die APIs reif sein, also lesen und schreiben können, sowie auf das System ausgerichtet und andererseits architektonisch auch so gebaut worden sein.
Warum hat sich der Headless-Ansatz entwickelt?
Die erste große Headless-Welle Gab es durch Content-Management-Systeme. Damit Inhalte auf die unterschiedlichen Medien effektiv verwaltet und ausgespielt werden können, müssen sie standardisiert vorliegen. Das andere System kann sowohl eine mobile App, ein JavaScript-Framework, wie React, Angular und Konsorten, oder eine Website sein, die mithilfe eines Static Site Generators kreiert wird. Das hat hier den Hintergrund, dass man eine bestimmte Technologie mit bestimmten Fähigkeiten nutzen möchte, um das Frontend auszuspielen.
Es liegen unterschiedliche Entwicklungsgeschwindigkeiten hinsichtlich der Systeme und Bereiche vor. Frontend, UI/UX-Themen, sind für gewöhnlich schneller als Backend-Systeme. Durch eine Abkopplung können neue Technologien wesentlich schneller im Frontend eingesetzt werden. Bei starren Systemen wäre die Entwicklungszeit länger.
Hinzu kommt, dass sich weitere Services entwickeln, die integriert werden können / müssen, im Kontext einer ›best-of-breed world‹. Bestes Beispiel: Payment Service Provider. Darüber hinaus wandeln sich Webseiten. Sie fühlen sich weniger wie Content-Seiten an, sondern mehr wie Applikationen. Diese Apps basieren auf verschiedenen Technologien.
Für wen ist Headless Commerce geeignet?
Mit einem Headless Commerce System entkoppeln Sie also das Frontend vom Commerce-Kern. Dadurch können Sie eine beliebige Anzahl an unterschiedlichen Frontends anschließen. Die benötigten Funktionalitäten für die jeweiligen Frontends holen sie sich aus dem System. Die Qualität der APIs sind der Schlüssel hierzu.
Die entscheidenden Fragen sind: Aus wie vielen Quellen kommt Ihr Traffic, und: Mit wie vielen Systemen müssen sie sich integrieren? Darüber hinaus ist mit einem Headless Commerce System Omnichannel und Customer Centricity überhaupt erst wirksam umsetzbar.
Die aktuellen Entwicklungen der Customer Journey zeigen, dass User mehr als nur einen digitalen Touchpoint nutzen. Laut Google starten 85% der Nutzer ihren Einkauf an einem Endpunkt und beenden es an einem anderen.
Ein Tipp am Rande: Headless beschreibt nur die Methode der Auslieferung von Inhalt und Funktionalitäten. Achten Sie bei der Wahl Ihres Headless Systems auf die Reife und den Umfang der Funktionalitäten sowie auf die Performance des eigentlichen Systems. Sind diese Eigenschaften schwach ausgeprägt, nützt Ihnen der gesamte Headless-Ansatz nichts.
Worin liegen die Vorteile eines Headless-Systems?
Strategisch gesehen sind Headless Systems notwendig für Omnichannel-Lösungen und Customer-Centricity-Konzepte. Sie steigern die Wettbewerbsfähigkeit durch Entwicklungsgeschwindigkeit und Flexibilität in der Technologiewahl. Damit das funktioniert, ist aber eine IT-Abteilung notwendig. Kleines Beispiel: Konventionelle Commerce-Plattformen haben Release-Zyklen von Wochen bis Jahren. Amazon hat einen durchschnittlichen Zyklus von 11.7 Sekunden. Mit Headless Systems sind Front- und Backend voneinander entkoppelt. Die Innovationszyklen von Frontend-Technologien ist wesentlich höher, als die von Backend-Systemen. Stichwort: Fuzzy Frontend. Ein weiterer Vorteil ist die steigende Flexibilität. Unternehmen können neue Technologien und Touchpoints schnell anschließen.
Was sind die Nachteile?
Die Total Cost of Ownership eines Headless Commerce Systems sind wesentlich höher. Neben den eigentlichen Lizenzgebühren und den Projektkosten für die Anpassung des Systems kommen noch die Kosten für jedes Frontend hinzu. Je mehr Technologien Sie einsetzen und verwenden, desto höher werden die Kosten. Das betrifft nicht nur Lizenzkosten, sondern vor allem Projektkosten für die Erstellung der Konnektoren. Diese Kosten entstehen dann vor allem langfristig, da Sie höhere Wartungskosten haben und IT-Ressourcen vorhalten müssen. Zwar können Sie diese Kosten durch Open-Source-Technologien reduzieren, allerdings steigt dadurch die technologische Komplexität weiter an. Inhaltsersteller und Marketers werden von Entwicklern abhängig. Problematisch sind Personalisierungen, konfigurierbare Workflows und Authentifizierungen.
Fazit
Der Kunde und die Kosten entscheiden am Ende immer. Amazon, Wish, Zalando und Co. treiben die Convenience-Spirale immer weiter nach oben. Diese Erwartungshaltung brennt sich in den Kunden ein und wird von ihm automatisch erwartet. Erfüllt man diese nicht, wird es vom Kunden negativ wahrgenommen. Headless Systems bieten wettbewerbsrelevante Vorteile, erhöhen aber im Gegenzug die technologische Komplexität und die Kosten. Ohne eigene IT-Ressourcen sind diese Systeme nicht umzusetzen.
Unter dem Pseudonym Marian Haller analysiert unser Gastautor vor allem Shopsysteme und –technologien. Dies ist auch sein berufliches Hauptbetätigungsfeld im E-Commerce. Er gilt als ausgesprochener Experte auf diesem Gebiet.
Hier gibt es alle Beiträge von Marian Haller zum Nachlesen. |
Bildquelle: Khakimullin @ Bigstockphoto
Roman Zenner meint
Ich habe das Gefühl, hier werden einige Dinge durcheinandergeworfen. Weder Intershop und Magento noch viele andere wie Spryker, die sich diesen Begriff mittlerweile auf die Fahnen und ins Marketing-Material schreiben, sind echte „headless“-Systeme, Was diese quasi-headless macht: In Implementierungsprojekten mit viel Aufwand die ursprüngliche, Template-basierte Logik entfernen, um dann eigene GUIs zu bauen. Womit wir direkt beim TCO wären, der unter anderem durch diesen Entkernungsaufwand mitnichten niedriger ist als bei echten Headless-Systemen. Würde das aber gerne im Detail diskutieren liebe(r) Herr/Frau Haller 🙂
Marian Haller meint
Hallo Herr Zenner,
Sie werfen interessante Fragen auf: Was sind die Kriterien für Headless überhaupt und welche Eigenschaften muss eine Software erfüllen um Kopflos zu sein? Welchen Reifegrad und welche Eigenschaften müssen die API aufweisen? Welche Eigenschaften sollte das System mitbringen? Wir haben ja im Markt mitunter wilde Beschreibungen und Vorstellungen – coupled, decoupled, headless, hybrid headless, usw. Das Bingo ist inzwischen groß geworden.
Für meinen Teil habe ich mich auf die Definition von Wikipedia von „Headless Software“ gestützt: „However in a headless installation the front-end is a stand-alone piece of software, which through API communicates with a back-end. Both parts operate separately from each other, and can even be placed on separate servers, creating a minimum version of a multi-server architecture.“ Forrester erweitert diese „einfache“ Referenzierung auf den API-Layer, um diverse Kriterien: Cloud Hosting, Stateless API, Pure Data Format, usw.
Bei den genannten Herstellern finde ich viele Indizien, die für eine Headless Architektur sprechen und außerhalb vom Marketing-Bla-Bla liegen:
– Eigene, losgelöste Frontend-Technologien
– Offen zugängliche API-Dokumentationen
– Produktive Microservices.
Sicher sind das alles nur Hinweise und um es wirklich beurteilen zu können, müsste ich in den Projekten „Live“ dabei sein oder zumindest die Core-Architektur kennen. Insofern finde ich Ihre Behauptung mutig, dass die Hersteller eben dies nicht sind, da es nahelegt Sie kennen diese.. Ich stecke in keinem Projekt drin und kann mich erst einmal nur auf die Aussagen von Dritten, frei zugänglichen Informationen und Analysten verlassen. Darüber hinaus kann ich Sie von Ihrem Standpunkt aus völlig nachvollziehen, wird es doch als ein Alleinstellungsmerkmal genannt. Und das führt mich zu zwei Fragen, bei denen mich Ihre Ansicht interessieren würde:
1. Was sind für Sie die klaren und festen Kriterien, ab wann eine Software Headless ist? Was müssen die API´s dafür können? Wie sollte die Architektur aufgebaut sein? Wie sollten Daten vorliegen und wie die Prozesse strukturiert sein?
2. Ist Headless für Sie noch ein Alleinstellungsmerkmal oder inzwischen „nur“ noch ein Feature, wenn Sie sich den Markt ansehen?
Hinsichtlich der TCO fahren Sie mit einem Headless System immer höhere OPEX und CAPEX als mit einer All-in-One Solution. Sie haben bei Headless Systemen zwei Projekte – Customization und Frontend. Dadurch schlimmstenfalls auch zwei Organisationen, die Geld von Ihnen haben wollen. Darüber hinaus haben Sie höhere OPEX – allein in Form von IT-Ressourcen – um den Betrieb und die Vorteile einer Headless Lösung nutzen zu können. Von nachgelagerten Herausforderungen in den Operations einmal abgesehen. Wenn Sie konkrete Zahlen haben würde ich mich dafür sehr interessieren.
VG MH