Wie ein Unternehmen vorgehen sollte, wenn es seine Systeme in die Richtung eines Headless-Ansatzes bewegen möchte und ob das überhaupt für jedes Unternehmen sinnig ist, erläutert uns Oliver Goerke, CEO bei unserem ECC CLUB Mitglied piazza blu², im Interview.
Kannst du uns einen kurzen Überblick darüber geben, was der Headless-Ansatz ist und wie er sich insbesondere von traditionellen coupled Shopsystemen unterscheidet?
Headless Ansatz meint, dass ein Shopsystem kein technisch integriertes Frontend mehr enthält, sondern nur eine API bereitstellt. Das Frontend (oder mehrere Frontends, wie z. B. eine App) laufen getrennt als eigene Komponenten. Man entkoppelt also Frontend und Backend. Der „Head“ steht als Synonym für das Frontend.
Ich versuche es mal anschaulich mit einem Beispiel. Im Grunde ist ein „traditionelles coupled Shopsystem“ wie eine Jukebox für Musik. Die Jukebox hat 30 Knöpfe, du wirfst eine Münze rein, drückst einen Knopf und bekommst Musik. Wenn man in diesem Bild bleibt, wäre ein Headless-Shopsystem sowas wie ein Klavier. Hat viele Knöpfe (sogar schwarze und weiße), und wenn man einen Knopf drückt, kommt nur ein einzelner Ton raus. Das erklärt gut, worüber wir sprechen.
Was ist also der Unterschied zwischen einer Jukebox und einem Klavier? Und was ist jetzt besser? Ich denke, die ehrliche Antwort muss lauten: „Es ist etwas anderes, macht am Ende aber auch Musik.“ Beides hat seinen Platz. Und eigentlich ist es auch nicht ganz richtig das eine als „traditionell“ und das andere als „modern“ zu bezeichnen. Die All-in-One Systeme gibt es nach wie vor und das ist auch gut so.
Das MACH-Prinzip spielt eine zentrale Rolle im Headless-Ansatz. Erläutere doch bitte einmal, wofür MACH steht und warum es für moderne E-Commerce-Lösungen so relevant ist?
MACH steht für die folgenden, sehr technisch orientierten Begriffe
- (M)icroservices
- (A)PI
- (C)loud
- (H)eadless
Wenn wir es wieder auf unser Beispiel Jukebox/Klavier beziehen, wäre es etwas wie das Notensystem oder eine Partitur. Zwischen Noten und Tasten besteht ein Zusammenhang. Hier geht es vor allem um die Frage, auf welche Standards man sich einigt, damit man wie in einem Orchester zusammenspielen kann.
Du hast in deiner ersten Frage die „traditionellen coupled“ Systeme benannt. Die MACH basierten Architekturen „decouplen“, also entkoppeln die Teile eines Commerce Systems, sie sind „headless“, trennen also das Frontend (oder mehrere Frontends) vom Backend. Wir nutzen mittlerweile häufig beispielsweise eine getrennte „Suche“ oder ein getrenntes „Headless-CMS“. Mit einem solchen Auseinanderziehen und Entkoppeln gewinnen wir die gewünschte Flexibilität. Gleichzeitig benötigt eine solche Struktur aber eben Standards, damit getrennte Einheiten miteinander integriert werden können. Denn sie sind ja nicht völlig entkoppelt.
Entscheidend ist hier also, dass alle Akteure in einer solchen Welt (Softwarehersteller, Integratoren, Agenturen) diesem Prinzip folgen und es anwenden. Es gibt sogar die MACH Alliance (www.machalliance.org) die diesen Standard definiert und die Hersteller und Agenturen zertifiziert.
Wie sehen die ersten Schritte für Unternehmen aus, um erfolgreich von einem gekoppelten System zu einem Headless-Ansatz zu wechseln?
Vorab ist die Frage zu klären, ob es Sinn macht, die Jukebox auf den Müll zu werfen und dafür ein Klavier anzuschaffen. Das Ziel sollte sein, dass nach wie vor schöne Musik erklingt. Und wenn jetzt ein potenzieller Kunde vor mir steht und im übertragenen Sinne sagt: „Wir haben jetzt schon ewig diese Jukebox, damit kommen wir nicht weiter, wir wollen effizienter und besser werden, mehr Umsatz online machen und wir brauchen was Moderneres.“ Verkauf ich dem jetzt ein Klavier?
Ein Headless-Ansatz, also ein Auseinanderziehen, ein Entkoppeln macht nur Sinn, wenn ich diese Flexibilität wirklich brauche. Das erkennt man meist daran, dass solche Szenarien an der mangelnden Anpassbarkeit bestehender coupled Systeme wirklich leiden. Indikatoren sind hohe Kosten für das Betreiben oder Migrieren stark angepasster Systeme.
Wenn man erfolgreiche Replatforming-Projekte anschaut, die sich von einer solchen Situation hin zu einem Headless Ansatz bewegt haben, ist sehr oft der erste Schritt, das Frontend vom Backend zu lösen. Dann folgen erfahrungsgemäß solche Themen wie ein Headless-CMS, ein getrenntes OMS (Order Management System) oder die getrennte Suche.
Mit welchen Herausforderungen müssen Unternehmen bei der Umstellung auf ein Headless-Shopsystem rechnen und wie können diese bewältigt werden?
Erst mal bedeutet es eine Investition, finanziell und organisatorisch. Und es erfordert vor allem ein Umdenken und Umstrukturieren. Oft geschieht ein solcher Schritt im Rahmen eines Replatformings einer Commerce Plattform. Wir nehmen oft wahr, dass bei Kund:innen, die eine solche Umstellung machen, viele Herausforderungen auftauchen und die Vorteile einer solchen Architektur erst nach einiger Zeit zum Tragen kommen. Es ist oft nicht nur die Technik, die Herausforderungen bereithält, sondern auch die Organisation selbst und deren Struktur, die eine solche Veränderung umsetzt.
Welche Mehrwerte siehst du langfristig für Unternehmen, die den Wechsel zu einem Headless-System vollziehen und warum lohnt es sich, diese Transformation anzugehen?
Dieser Trend hin zum Decoupling und Cloud basierten Modularisieren ist ja etwas größer und nicht nur in der Commerce Branche zu beobachten. Aber interessant ist, dass ein großer Marktteilnehmer im Cloudbusiness (die AWS-Cloud) seine Wurzeln im Commerce hat und den Ansatz aus der eigenen Commerce Architektur zum Produkt gemacht hat.
Der größte Mehrwert ist die Flexibilität und damit verbundene Reaktionsfähigkeit. Sie befähigt eine Organisation iterativ und inkrementell zu agieren in der Welt, in der sich alles ändert.