Headless - wer wird denn gleich den Kopf verlieren?

"Headless" ist seit geraumer Zeit ein Begriff, der die Welt der Content Management Systeme dominiert. Während einige ganz neue CMS aufgepoppt sind, die sich gleich vollständig dem Headless-Ansatz verschreiben, setzen auch etablierte Hersteller alles daran, ihrem Image einen neuen Schub zu verpassen und zumindest eine Headless-Komponente mit ins Angebot zu legen. Headless ist hip!

Ursprünglich wurde der Begriff für Hardware verwendet, also für Computersysteme, die über keinerlei grafische Ausgabe verfügen, sondern ausschließlich zur reinen Datenverarbeitung bzw. Kommunikation mit anderen Systemen oder Netzwerken dienen. Kein Monitor, keine Tastatur, keine Maus - hier kann man sich sehr anschaulich vorstellen, dass dem System der Kopf fehlt, der dem Benutzer sonst gegenüber sitzt.

Übertragen auf die Software bedeutet "headless", dass ebenfalls eine strikte Trennung zwischen Datenerfassung bzw. -verarbeitung (Backend) und grafischer Darstellung (Frontend) passiert. Letztere liegt nicht mehr im Verantwortungsbereich des CMS, wodurch dieses dann sozusagen den Kopf verliert.

Das System stellt die Dateneingabe bereit, die Datenspeicherung und die Ausgabe in einer strukturierten Rohform wie z.B. JSON. Alles was danach mit den Daten passiert, ist dem jeweils ausliefernden System überlassen und kann ganz unterschiedlich aussehen und unterschiedlichen Zwecken dienen. Genaugenommen kann es hier sogar mehrere Köpfe - im Sinne von Darstellungsvarianten - geben. Diese sind aber losgelöst, das CMS selbst gibt die Präsentation nicht mehr vor.

Noch vor wenigen Jahren hat man ein CMS hauptsächlich zur Erstellung von Webseiten verwendet (WCMS) und meistens wurde der Content nur für diesen Zweck angelegt und ausgespielt. Dieses Prinzip hat sich grundlegend gewandelt. Verschiedenste mobile Endgeräte müssen heutzutage bedient werden, wobei nicht nur die Darstellungsform variiert, sondern auch die Inhalte für den Nutzer unterwegs anders aufbereitet werden müssen, um gut zu funktionieren.

Weiterhin kann der Content für komplett andere Zwecke verwendet bzw. wiederverwendet werden. Man denke an smarte Armbanduhren und Wearables, VR-Brillen oder KI-Assistenten, aber auch Anzeigen im Auto oder auf Maschinen. Beispielsweise können Bedienungsanleitungen auf Fabrikmaschinen über das Internet bereitgestellt werden oder Kochrezepte auf modernen Küchengeräten direkt im Display abgerufen werden. All das kann im Idealfall aus derselben Content-Quelle kommen wie die Webseite.

Will man also eine Vielzahl an Ausgabekanälen für Nutzer in verschiedenen Situationen bereitstellen (Omnichannel), ist eine Headless-Lösung die beste Wahl.

Der frontendseitige Zugriff auf die Daten geschieht über eine einheitliche Programmierschnittstelle bzw. Application Programming Interface (API) wie z.B. RESTful. Das ist zwar nichts grundlegend Neues, aber anstatt wie bisher die Schnittstelle dem Verwendungszweck anzupassen, kommt nun der "API-First"Ansatz ins Spiel.

Dabei steht im Vordergrund, nicht nur eine Auswahl von Funktionen bereitzustellen, sondern alle Daten so generisch wie möglich abrufen zu können, um sie für den jeweiligen Einsatz optimiert verarbeiten zu können. API-First bedeutet also, dass zunächst die Schnittstelle durchdacht und entwickelt werden sollte, damit beliebige Datenabfragen möglichst flexibel von unterschiedlichsten Endpoints ermöglicht werden, ohne die Schnittstelle immer wieder anpassen zu müssen.

Die Vorteile liegen auf der Hand:

• Das Frontend ist entkoppelt vom Backend und umgekehrt
• Beides kann unabhängig voneinander komplett ausgetauscht werden, so lange die Schnittstelle bestehen bleibt
• Die Entwicklung wird flexibler und schneller, da getrennte Teams für Frontend/Backend unabhängig voneinander arbeiten können
• Die Technologie ist nicht mehr starr vorgegeben und dadurch zukunftsfähiger
• Keine redundante Datenhaltung
• Redakteure arbeiten nur in einem System und behalten den Überblick
• Content kann flexibel in verschiedene Kanäle geleitet werden
• Endnutzer bekommen qualitativ hochwertigen Content in der jeweiligen Situation sinnvoll aufbereitet
• Neue Touchpoints können leicht hinzugefügt werden, ohne die Schnittstelle erweitern zu müssen
• Headless-Content lässt sich leichter in andere Systeme integrieren, z.B. Webshops oder Portale

Ein paar Nachteile gibt es aber auch, deshalb sollte man abwägen, was langfristig sinnvoll und kostengünstiger ist. Man muss nicht zwingend auf Headless umstellen, wenn es keine Vorteile bringt. Mögliche Gesichtspunkte, die dagegen sprechen sind:

• Ein direkter Datenaustausch zwischen Frontend und Backend wird durch die Trennung erschwert
• Eine WYSIWYG Echtzeit-Vorschau der Daten im Backend erfordert zusätzlichen Aufwand
• Eine Vorschau der Endausgaben in allen Ausprägungen bereitzustellen ist aufwändig bis unmöglich
• Es ist ein gewisses Umdenken sowohl für Entwickler als auch für Redakteure und Marketer erforderlich
• Braucht man überhaupt eine Omnichannel Verwertung der Daten? Oder genügt auch weiterhin das bewährte WCMS?