Headless CMS: Jetzt bloß nicht den Kopf verlieren!

Headless Content Management ist in aller Munde. Aber was bedeutet es? “Headless” ist die Entkopplung von Frontend und Backend. Sebastian Siemssens erklärt das in einem Artikel wie folgt, “Statt eine thematische Darstellung einer Webseite zu generieren, wird ein Interface geschaffen, dass pure, uniforme Daten, wie etwa JSON, extrahiert und dann unabhängig vom Backend transformiert und wiedergibt.”

Mark Polly schreibt, dass Technologien wie REST und Javascript Frameworks eine wichtige Rolle im Wachstum der Headless-Content-Bewegung spielen. Die mobile Revolution und insbesondere Apps treiben die Bewegung ebenfalls voran. Frontend-Entwickler, die sich der Frage stellen mussten, welches Backend sie nutzen sollen, haben sich mehr und mehr dafür entschieden, Data Stores zu nutzen – so können sie Content und Präsenz trennen.

%CAD2%

Pantheon und contentful schüren den Hype. contentful behauptet, dass Headless CMS die beste Wahl für diejenigen ist, die sich von den Frontend-Fähigkeiten eines klassischen CMS eingeschränkt fühlen. In diesem Artikel werde ich aufzeigen, dass es solche Grenzen in einem modernen Enterprise CMS nicht gibt.

Wie es zum Hype um Headless Content kam

Ein modernes CMS bietet meist eine große Anzahl an Funktionen. Damit geht Komplexität einher, und ein oftmals erheblicher Lernaufwand für Entwickler. Doch Zeit ist Geld, schnelles Time-to-market geschäftskritisch. Wenn sich ein neues Team in eine neue Software einarbeiten muss, und gleichzeitig ein Projekt unter Zeitdruck fertiggestellt werden soll, dann ist Komplexität das Letzte, was man braucht.

Aus der Sicht eines App- oder Frontend-Entwicklers sieht die Welt zudem anders aus als für eine “klassische” Website respektive dessen Entwicklung. Hier ist Agilität das A&O. Javascript auf dem Frontend heisst, dass vieles an interaktiver Funktionalität direkt auf dem Endgerät ausgeführt wird und es ausreicht, sich vom Backend nur die Rohdaten liefern zu lassen. Das spart Bandbreite und macht das Benutzererlebnis schneller, also besser.

Ein Headless CMS verspricht Freiheit von der Komplexität eines klassischen CMS. Entwickler setzen das oft mit mehr Agilität und Geschwindigkeit gleich. Frontend-Entwickler können damit Javascript-Frameworks wie Angular oder React verwenden, und lassen sich die benötigten Daten von einem relativ trivialen Backend per REST ausliefern. Damit ist die Lernkurve der Backendtechnologie minimal, allerdings auf Kosten der gelieferten Funktionalität. Dennoch: weniger lernen müssen heisst schneller loslegen können.

Und tatsächlich sind die Frontend-Fähigkeiten veralteter Content Management Systeme heutigen Anforderungen nicht mehr gewachsen. Entweder sind die Einschränkungen so gross, dass ein Arbeiten mit modernen Frontend-Technologien praktisch unmöglich ist, oder der Entwicklungsprozess ist so aufwändig, dass die Fertigstellung eines Projektes oder das Implementieren von Innovationen zu lange dauert. Das bedeutet zu wenig Flexibilität für Entwickler und Marketingabteilungen.

Viele sind also frustriert und denken, ein CMS ist das falsche Werkzeug, und die Suche nach Alternativen beginnt.

Nicht das Kind mit dem Bade ausschütten

Ein modernes CMS liefert jedoch hervorragende Lösungen. Es gibt mehr als ein CMS, dass Nutzern eine mehrsprachige, personalisierte, digitale Erfahrungen bietet und gleichzeitig Frontend-Entwicklern genug Freiraum gibt, um anstehende Integrationen und zukünftigen Änderungen agil zu meistern. Wir sollten also das Kind nicht mit dem Bade ausschütten.

Warum ist ein Headless CMS nicht immer die richtige Lösung?

Frontend-Entwickler freuen sich zwar über Freiheit, aber ein Headless CMS liefert die Freiheit des “Ich kann machen was ich möchte” zum Preis von “Ich muss alle Funktionalität selber entwickeln, debuggen und verwalten”. Unweigerlich werden Funktionen im Projekt programmiert, die in einem “Full CMS” bereits vorhanden gewesen wären.

So manches Mal wird am Ende fast ein vollständiges CMS entwickelt. Mit der Agilität ist es dann schon lange vorbei. Wenn es erstmal so weit ist, dann liefert man aber nicht mehr ein Projekt ab, sondern man wartet ein Produkt. Und auch wenn der Unterschied nicht jedem klar ist (und genau darin liegt die Gefahr): als Softwarehersteller kann ich von den Unterschieden ein Lied singen. Den Sprung vom Projekt zum Produkt schaffen die wenigsten Unternehmen, die meisten scheitern daran.

Ein Enterprise-CMS enthält üblicherweise Funktionalitäten wie Asset Management, Navigation, Sicherheit, Workflow, Zugriffsrechte, Caching, Kategorisierung und Link Management, um nur einige zu nennen. Diese und viele andere sind bei einem Headless CMS nicht vorhanden.

Mit einem Headless CMS wird Sicherheit leicht zu einem Risiko. Es ist meist schwierig, Nutzerrechte zu bestimmen und somit besteht die Gefahr, dass vertrauliche Inhalte in falsche Hände geraten. Mehrsprachigkeit ist wenn überhaupt, dann nur mit viel  Entwicklungsaufwand zu realisieren. Auch die Redaktion kommt zu kurz. Jetzt wo Inhalte und Auslieferung getrennt behandelt werden, können Inhalte nicht vor der Veröffentlichung begutachtet werden.

Ein weiteres Problem mit Headless CMS ist die Personalisierung. Sobald Inhalte von der Auslieferung separiert sind, muss die gesamte Personalization-Content-Engine neu geschrieben werden. Oft sind auch Form Builders auf dem Server, so dass Integrationen mit Marketing Automation und anderen Werkzeugen, die es ohne CMS nicht gibt, verloren gehen. Das CMS kann Formulare nicht mehr dynamisch bauen.

Warum Lösungen von heute zu Problemen von morgen werden können

Es ist frustrierend, kaum Flexibilität zu haben, wenn es darum geht, Inhalte zu liefern. Aber Headless als Wundermittel anzusehen, ist sicherlich nicht zielführend. Es hat seinen Platz, aber eine sorgfältige Abschätzung des zukünftig benötigten Funktionsumfangs sollte schon passieren, bevor man sich gegen den Einsatz eines modernen CMS entscheidet, weil man meint, dadurch Zeit und Geld zu sparen.

Popularität ist nicht mit Nützlichkeit gleichzusetzen. Einfache Lösungen haben ihre Grenzen. Wenn eine Systemarchitektur nicht dafür gemacht ist, mit komplexen Anforderungen umzugehen, dann wird aus einem vermeintlich einfachen System schnell ein nicht wartbarer Albtraum. Oft bedeutet “Einfachheit”, dass andere Aspekte komplexer werden, da man versucht ein Problem zu lösen, für welches das Produkt nicht geschaffen wurde.

Headless Content Management funktioniert für bestimmte Aufgaben hervorragend. Aber  dies sind nicht CMS-Aufgaben, sondern die Ablage und der Abruf von einfachen, strukturierten Daten, die durch ein Formular eingepflegt werden können.

Moderne Content Management Systeme können problemlos mit strukturierten, semi-strukturierten und unstrukturierten Inhalten umgehen, liefern automatisch generierte Formulare für die Verwaltung von strukturierten Daten, und haben eine REST-Schnittstelle, um diese Daten mit Frontendtechnologien abzurufen. Sie stehen in dieser Hinsicht einem Headless CMS in nichts nach.

Wie immer sollte man für jede Aufgabe das geeignete Werkzeug verwenden. Es kann sogar Sinn machen, hybrid zu agieren. Also ein CMS zu benutzen, welches Daten aus einem Headless System abruft, und sich um alle anderen Aspekte einer wohl-kuratierten, mehrsprachigen Multi-Channel Auslieferung kümmert. Letztlich bestimmt der Anwendungszweck das Werkzeug. Ein gutes Werkzeug in der Hand eines Profis ist durch nichts zu ersetzen.