Nichts Passendes dabei? Stellen Sie ein, welche Inhalte Sie auf aleri.de sehen möchten:
Ein immer wiederkehrender Schmerz in Content-Management-Projekten tritt auf, wenn Dateneingabe, -holung und -aggregierung eng mit der Darstellung verwoben sind. Meistens liegt die Ursache des Schmerzes an der Mächtigkeit des Content-Management-Systems (CMS) und der Tatsache, dass ein klassisches CMS eine eigene Darstellungsschicht mitbringt, inklusive einer passgerechten Markup-Sprache für Produktfeatures. Ein Beispiel für diese Produktgattung ist der Adobe Experience Manager mit seiner Templating-Sprache HTL.
Eine Antwort der Cloud auf diesen Schmerz lautet headless CMS. Hier wird eine strikte Trennung von Content und Darstellung vorgegeben: das CMS hat schlicht keine Darstellungsschicht (Head), konzentriert sich auf den Content und dessen Struktur und passt sich dank seiner API in eine moderne Cloud-Service-Architektur ein. Das CMS unseres Partners contentful ist ein Beispiel für diese Produktgattung.
Das Headless-Konzept erfordert eine leicht veränderte Herangehensweise, was die Auswahl von Architektur und Software angeht. Es wird weniger Technologie durch das Produkt vorgegeben, und die Konzentration auf Kommunkation per API entspricht der modernen Cloud- bzw. (Micro-)Service-Architektur.
Es gibt für uns drei wesentliche Aspekte, die bedacht werden müssen: Architektur, Implementierung und die Redaktionsoberfläche.
Headless bedeutet: die Darstellung kann und muss frei entwickelt werden, das CMS liefert nur struktutierte Daten per API. Das ist ein Nachteil, denn fertige Blueprints und Vorlagensammlungen sind nicht verfügbar. Es ist ein Vorteil, denn die Frontends von großen Websites und Shops werden in der Regel mit großen Marketing-Budgets entwickelt. Somit sind Blueprints und vorgefertigte Templates hier irrelevant.
Die fehlende Darstellungsschicht bringt einen zusätzlichen Vorteil: das Team kann selber entscheiden, welche Technologien verwendet werden. Da außerdem nur eine API durch das CMS definiert wird, sind auch die Kommunkationsstrukturen, Services und Betriebsumgebungen frei wählbar. Damit steigt die Möglichkeit, moderne Technologien wie beispielsweise JAMStack oder Go-Microservices zu nutzen. Die Architektin hat die Verantwortung, die richtigen Dienste und Strukturen für das Projekt zu bestimmen und wird nicht von Produktvorgaben eingeschränkt. Vielmehr erleichtern die fehlenden Abhängigkeiten die Integration bestehender Services.
Ein großer Teil der Architektur-Arbeit entfallen auf die Informationsarchitektur und die Quellen von Informationen. Ein headless CMS ist API-getrieben und spielt seine Stärken naturgemäß in einem API-Kontext aus. Das bedeutet einerseits viel Arbeit in der Konzeption, andererseits sind dadurch die Verantwortlichkeiten und Kommunikationswege früh geklärt. Das Transaktions-Handling, z.B. für eingeloggte User eines Webshops, muss außerhalb des CMS behandelt werden; hier muss die Architektin sorgfältig arbeiten und strukturieren.
Denn genau hier liegt in Projekten häufig die Ursache für Komplexität und Wartungsprobleme. Ein mächtiges CMS mit vielen Funktionalitäten verschleiert die notwendigen Aufwände, besonders wenn Termine und Budget Druck auf das Projekt ausüben.
Für die Entwicklung bedeutet ein headless CMS die seit Jahrzehnten gewünschte Freiheit, Technologien und Frameworks selber zu definieren. Natürlich gibt es Einschränkungen, die durch die Architektur vorgegeben sind; das ist normal und richtig. Innerhalb dieser selbst gesetzten Leitplanken aber hat das Team die Hoheit über die Art der Umsetzung.
Praktisch bedeutet das, viele Detailaspekte des Content-Managements sind nicht durch das Produkt abgedeckt und müssen eigenständig bereitgestellt werden. Caching, einfaches Ansprechen von Funktionalitäten, Replikation, Routing, URL-Generierung sind eine Teilmenge dieser Aspekte, die vielfach komplexe Herausforderungen darstellen. Nicht umsonst beinhalten Enterprise-Systeme eine Vielzahl an Features.
Die glänzende Kehrseite dieser Medaille zeigt die Möglichkeit, sich von Ballast in Form nicht genutzter Features und unnötiger Komplexität zu trennen. Es braucht keine besondere Caching-Schicht mehr, wenn der Content Service cloudbasiert und auto-skalierend ist. Eine API zur Verwaltung von user-generated content, die in der Konfiguration eines Application Servers aktuell gehalten werden muss, wird in Projekten ohne diesen Content nicht benötigt. Fehlende Features erhöhen die Einfachheit, und sie müssen nicht beachtet werden.
Das wichtigste Merkmal des headless-Ansatzes allerdings liegt für mich in der freien Technologie-Auswahl. Die Teams können so die Dinge verwenden, in denen sie sich wohlfühlen oder mit denen sie bereits Services entwickelt haben. Damit fällt es auch leichter, eine unternehmensweite Ausrichtung hinsichtlich verwendeter Sprachen etc. zu befolgen, oder die Technologie zu nutzen, die die Entwickler beherrschen.
Ein headless CMS bringt natürlich die Möglichkeit mit, Content zu bearbeiten und zu publizieren. Allerdings entspricht diese Oberfläche nicht dem Design der Websites, die mit den gepflegten Inhalten befüllt werden. Stattdessen ist die Sicht eines Redakteurs entkoppelt von der Ausspielung. Diese Arbeitsweise passt viel besser zu einer Multi-Channel-Strategie, denn die Platzierung eines Inhalts ist abhängig vom Kanal. Die Tatsache, dass es dank Content Reuse oder automatisch auf Basis von Tags generierter Übersichtsseiten schon lange keine feste Seitenhierarchie für Content gibt, nehmen wir en passant mit.
Die abstrakte Sicht auf Content und die notwendige Modellierung erfordern, dass die Content-Verantwortlichen eingebunden werden. Damit steigt die Qualität des Gesamtprodukts, weil die User des Systems ihre Anforderungen zur Content-Arbeit frühzeitig artikulieren können - sie werden schlicht nicht vergessen.
Für mich sehr überraschend ist die Erfahrung, dass alle Redakteure, die mit einem Headless-CMS neu arbeiten, diese Abstraktion beinahe natürlich beherrschen und den Wechsel weg vom In-Page-Editing leicht vollziehen. Headless reduziert die Einarbeitungszeit in Enterprise-Produkte und bietet durch die Feature-Reduktion einen guten Migrationspfad in die Cloud. Content bleibt King, das Content-Management-System aber verliert an Bedeutung. Die Herausforderungen liegen in der Informationsstruktur, der API-Economy und dem richtigen Umgang mit User-Sessions und Transaktionen. Für diese bedarf es eines Ansatzes im Gesamtsystem und damit außerhalb des CMS.
Ich finde, headless ist ein frischer und konsequenter Ansatz, in einer modernen Service-Umgebung Content zu verwalten und zu nutzen. Die Einführung ist zwar aufwändig und verlangt eine intensive Betrachtung der bestehenden Service-Struktur. Dieser Aufwand zahlt sich aus, weil er für eine Reduktion nicht notwendiger Funktionalitäten sorgt. Wer also eine echte Cloud-Landschaft betreiben und entwickeln kann, erhält mit einem headless CMS die Flexibilität, die nötig ist.