< zur Übersicht

Headless (dt. “Kopflos”) heißt nicht, dass man kopflos durch Projekte steuert bzw. im Falle von Headless Commerce, sich ohne Gedanken darüber zu machen, was, an wen, in welcher Form oder über welchen Kanal verkauft werden soll.
 
Headless bedeutet lediglich, dass ein IT-System kein User Interface bietet, d.h. den “Head” zur Darstellung und Interaktion mit dem User nicht eingebaut hat. Es handelt sich also um ein Systemarchitekturmuster zur Trennung der Darstellung von der Businesslogik.

Daraus resultieren vermutlich mehrere Fragen: 

1. Wie interagiert mein IT-System mit dem User, wenn es kein User Interface hat?

Dass ein IT-System kein User Interface hat, bedeutet nicht, dass es keine Kommunikationskanäle bietet. Im Grunde ist das Gegenteil der Fall: Ein Headless-Shop definiert höchst präzise, welche Kommandos bzw. Aufträge man ihm schicken kann (z.B. “Gib mir alle Produkt-Kategorien für Shop xy”) und wie er antwortet, sodass man die Antwort klar weiterverarbeiten kann. Die Weiterverarbeitung, der durch die Backend API gesendeten Antworten, erfolgt durch User Interfaces in spezifischen “Head-Applikationen”, beispielsweise einer Mobile-App. Dieses User Interface - als eigenständige Anwendung - entwickelt man entweder selbst oder nutzt dafür ebenfalls eine Standardlösung.
Je nachdem, wie man sich entscheidet, gibt es natürlich wieder Chancen und Risiken sowie Freiheitsgrade oder Einschränkungen. 

2. Warum macht man so etwas und wofür brauche ich es? 

Der Hauptgrund für einen Headless-Ansatz ist die Trennung von hochgradig autarken, in sich kompakten IT-Komponenten. Diese sind in diesem Fall User Interface bzw. Frontend und Backend. 
Die Herausforderungen monolithischer Ansätze, vor allem von großen Standardlösungen ist, dass man sich über Jahre hinweg für eine Technologie entscheidet, denn die Kosten für die Einführung sind zumeist recht hoch.
Auch wenn die Businesslogik immer noch aktuell ist und weiterverwendet werden kann, so ist die Webentwicklung viel schnelllebiger. Dadurch kann es vorkommen, dass man an ein veraltetes Frontend gebunden ist, in welchem eventuell nicht alle Möglichkeiten für eine moderne Webanwendung gegeben sind. Weiterhin ist man natürlich an die Anpassbarkeit der Lösung gebunden.
Beim Headless-Ansatz wird, die Präsentationsschicht von der Businesslogik entkoppelt. Dies bietet den Vorteil, dass man auf Änderungen, die das User Interface betreffen, schneller reagieren und diese implementieren kann.
Aber auch hier gilt natürlich, wenn man mit vorgefertigten Lösungen arbeitet, ist man an die Möglichkeiten des Systems gebunden.

Chancen, die genutzt werden können:  

Herausforderungen, die es zu beachten gilt: 

• Aufbau eines "Technologiezoo's" – gegebenenfalls Bedarf vieler spezieller Technologien und jeweiliger Spezialisten 

• Entwicklung bedarfsgerechter und performanter APIs  

• Erhöhung der Komplexität des Gesamtsystems: Durch eine Entkopplung von Systemen sowie evtl. weiterer Trennungen z.B. von Entwicklungsteams, Projektmanagement, Product Ownern, etc. kann sowohl die technische als auch die organisatorische Komplexität steigen. 

• Bei Eigenentwicklung können zwar Kosten für Entwicklung "geschätzt" werden, aber die Betriebskosten z.B. durch nutzungsabhängige Kostenmodelle sind zu Beginn schwer zu prognostizieren 

• Monitoring und Test der einzelnen Teilsysteme auch unabhängig voneinander

---

Abbildung 1: Vergleich von traditioneller und Headless Architektur.

---

3. Kann ich dann alles frei austauschen, wie es mir beliebt? 

Wie im vorhergehenden Abschnitt beschrieben wurde im Sinne des Headless-Ansatzes das User-Interface oder gar Frontend vom Backend getrennt. Hier stellt sich die Frage, ob eines der beiden dann relativ schnell ausgetauscht werden kann.Generell würde man diese Frage wohl mit “nein” beantworten.
Im Vergleich zu einem monolithischen System, ist es einfacher einzelne Komponenten austauschen bzw. neu entwickeln und dann ältere abschalten. Man kann aber nicht das komplette Backend ohne größeren Aufwand wechseln. Auch das Frontend basiert auf einer bestehenden API. 

Wenn man das Backend austauschen will, muss das Neue entweder so angepasst werden, dass die gleichen – vom Frontend angefragten – Schnittstellen bedient werden können, oder man muss ebenfalls ins Frontend investieren.
Jedoch sollte es mittels Headless-Ansatzes leichter sein, z.B. das Frontend durch eine neue Technologie zu ersetzen, im Vergleich zu einem All-In-One IT-System.
Möchte man im Backend eine höhere Austauschbarkeit erreichen, können Fachlichkeiten der Geschäftslogik voneinander getrennt werden. Die dafür prädestinierten Ansätze wären Microservices bzw. Serverless-Functions, welche primär aber nichts mit dem Headless Ansatz zu tun haben.  

4. Ist es besser oder schlechter als ein monolithischer All-In-One Ansatz? 

It Depends! Wichtig ist, dass das Team aus Entwicklern, Architekten und Fachverantwortlichen die Anforderungen verstehen, analysieren und bewerten, um eine Entscheidungsvorlage für die richtige Lösung des Kundenproblems zu finden.
Wenn die monolithische Lösung genau das bietet, was benötigt (sowie weiterentwickelt und gewartet) wird, spricht grundsätzlich nichts dagegen, sich für solch eine Lösung zu entscheiden. 

Im Softwaredesign bedeutet monolithisch, dass die Komponenten des Systems voneinander abhängig sind. Doch es spricht nichts dagegen, dass ein Monolith ebenfalls eine API anbieten darf. Wenn dies der Fall ist (bzw. der Monolith um eine API erweitert werden kann), kann auch dieser als Headless- Backend agieren. Dies wäre auch ein Ansatz potenzieller Migrationspfade. 

5. Welche Rolle spielen "Microservices" oder "Serverless Functions" beim Headless-Ansatz?

Generell ist der Headless-Ansatz nicht an Technologien oder weitere Architekturmuster gekoppelt, und es gibt viele Muster, die die Implementierung unterstützen, wie zum Beispiel “Backend for Frontend”, Serverless, Gateways oder Microservices. 

Wenn die Möglichkeit besteht, auf einer “grünen Wiese” zu beginnen und man sich die Teilsysteme herauspicken bzw. selbst entwickeln kann, die auch wirklich zur Umsetzung der Lösung benötigt werden, würde man im moderneren “Best-of-Breed"-Ansatz eher in Richtung fachlich voneinander getrennte Systeme hinarbeiten – also Microservices. Dies erleichtert die Austauschbarkeit einzelner IT-Komponenten. Jedoch ist dies keine zwingende Voraussetzung und man sollte die dadurch entstehende Komplexität genau abwägen. 

Fazit 

So wie in den letzten Jahren damit geworben wird, könnte man es als Hype bezeichnen, jedoch ist es lediglich ein Systemarchitekturmuster, welches auch schon länger existiert.
Prinzipiell lautet auch hier, wie bei allen IT-Entscheidungen, die Antwort auf die Frage, ob es der richtige Ansatz für die Lösung ist: It depends!
Man sollte vor der Entscheidung abwägen, wie viel Komplexität und Flexibilität die Lösung bieten soll und ob es wirklich der richtige Ansatz für die gewünschte Lösung ist. Manchmal gibt es auch kein richtig oder falsch, sondern nur ein Abwägen von Vor- und Nachteilen sowie Kosten und Komplexität.
Wenn man sich für eine monolithische Lösung entscheidet, bekommt man alles aus einer Hand. Mit dem richtigen Implementierungspartner, welcher Spezialisten für die Lösung einsetzt, können sicherlich die meisten Wünsche im Rahmen der Möglichkeiten des Systems/der Technologie und der Größe des Geldbeutels erfüllt werden.
Entscheidet man sich für einen Headless-Ansatz, gewinnt man mehr Flexibilität, aber diese kann zu Kosten der Komplexität gehen. Wer beispielsweise vor hat, seine Backend-Landschaft nach und nach umzugestalten, fährt mit so einem Ansatz vielleicht gar nicht so schlecht.  

Jetzt zur E-Commerce-Lösung beraten lassen!

< zur Übersicht