Die CMS-Welt durchläuft alle paar Jahre die eine oder andere Revolution, während der sie sich selbst neu erfindet. 

Zur Zeit in Mode sind sogenannte “Headless” CMS, die die Verwaltung von Inhalten komplett von deren Darstellung trennen. 

Deshalb stellt sich den Betreibern und Entwicklern von Websites die Frage: Brauchen wir ein Headless CMS?

Headless CMS bieten gegenüber traditionellen CMS manche Vorteile, allerdings ist der Mehrwert auch stark vom Kontext, der Anzahl zu bedienender Kanäle, sowie der Inhaltsstrategie abhängig. 

In einem aktuellen Projekt haben wir den Headless-Ansatz verfolgt und einiges dabei gelernt. 

Heute würden wir gerne unsere Erfahrungen mit Ihnen teilen, und hoffentlich nützen sie Ihnen zu entscheiden, in welche Richtung Ihr nächstes Projekt gehen soll.

Was sind denn die Vorteile eines Headless CMS?

Ein Headless-CMS unterscheidet sich von einem traditionellen CMS, oftmals als «monolithisch» bezeichnet, vor allem dadurch, dass die Inhalts- und die Präsentationsschicht einer Website komplett getrennt werden, mehr noch, die Präsentation ausserhalb des Verantwortungsbereichs des CMS liegt und anderweitig implementiert werden muss.

Diese Headless-Strategie hat durchaus Vorteile: Das CMS kann sich ganz und gar nur im die Inhalte kümmern, und dessen Funktionalität kann so komplett auf Inhalte optimiert werden. 

Da die Inhalte keinerlei Informationen zu deren Darstellung enthalten, können die gleichen Inhalte für mehrere Ausgabekanäle verwendet werden – etwa die Website, eine App, Soziale Medien und allenfalls gar Printmedien. 

Im Gegensatz dazu kümmert sich ein monolithisches CMS sowohl um die Inhaltsbereitstellung und die Präsentation des Inhalts in “Seiten” und einer Seitenstruktur, die schliesslich der Navigation der Website entspricht. 

Je nach Architektur des CMS werden hierbei Inhalte fix auf Seiten platziert, was eine Wiederverwendung erschwert, oder es gibt eine gewisse logische Trennung zwischen Inhalten und deren Darstellung. 

Wie verwaltet Adobe Experience Manager Inhalte?

In Adobe Experience Manager (AEM), dem CMS innerhalb der Adobe Experience Cloud, werden Inhalte meist von den Autoren direkt zu Seiten zusammengefügt, die dann (mehr oder weniger) 1:1 den Webseiten entsprechen, auch wenn rein technisch die Inhaltsverwaltung und die Darstellung der Seiten getrennt sind. 

Weshalb wir Ihnen von AEM erzählen?

Ganz einfach.

Erstens ist One Inside zertifizierter Adobe-Partner und unsere Teams sind Experten in der Umsetzung von Projekten mit AEM.

Zweitens, weil AEM in diesem Projekt als CMS eingesetzt wurde – wie in den meisten unserer Projekte. 

Nun, sprechen wir über das Projekt. 

Das Projekt: Headless um jeden Preis

In unserem Projekt wollte der Kunde bereits auf der Website publizierte Inhalte auch auf einem digitalen Kiosk – einem Automaten bestehend aus PC und Touchscreen, auf dem ein Browser läuft – darstellen, so dass sich die Kunden selbständig über die angebotenen Produkte informieren können. 

Wir sind dabei relativ spät zum Projekt gestossen: Die Angular-Anwendung des Kiosks war schon halb fertig, und der Architektur-Entscheid, dass der Kiosk alle Daten lokal speichern sollte, war bereits gefallen. 

Es war also nicht möglich, von der in Adobe Experience Manager (AEM) erstellten Website direkt zu profitieren – sonst hätte man mit relativ wenig Aufwand eine auf den Kiosk angepasste Variante der Website erstellen können. 

So mussten REST-APIs geschaffen werden, welche die Inhalte dem Kiosk zur Verfügung stellen, und entsprechende JSON-Objekte für Inhalte und Konfiguration definiert werden.

Dank der Flexibilität und dem direkten Support von JSON und REST APIs in AEM konnte dies mit vertretbarem Aufwand umgesetzt werden.

Ist Headless immer die beste Lösung?

Im Projektverlauf zeigte sich einer der grossen Vorteile der Trennung von Inhalt und Präsentation: Das Backend und das Frontend-Team können sich voll und ganz auf ihren Bereich konzentrieren und müssen kaum Rücksicht auf die andere Partei nehmen. 

Das Backend-Team konnte in AEM die nötigen Anpassungen für die Verwaltung der Inhalte vornehmen, während das Frontend-Team die Angular-App zur Darstellung der Inhalte weiterentwickeln konnte. 

Beide Teams können sich so ganz auf Ihren Bereich konzentrieren, mit den gewohnten Frameworks und Technologien arbeiten und müssen dabei kaum Rücksicht auf das andere Team nehmen. 

Ein wöchentliches Abstimmungsmeeting sowie eine klare Schnittstellendefinition (natürlich sauber dokumentiert) reicht zur Koordination der Teams aus.

Obenstehendes Architekturdiagramm zeigt, dass der Headless-Ansatz durchaus seine Berechtigungen hat: Im Laufe des Projektes mussten noch andere Screens und Geräte angeschlossen werden, jeder Gerätetyp über eine eigene Schnittstelle mit eigens aufbereiteten Daten. 

Diese konnten in kurzer Zeit mit wenig Absprache zwischen den Teams umgesetzt werden – und es kommen immer wieder neue dazu. 

Somit sollen jetzt alle bestehenden monolithischen CMS durch die schöne neue kopflose Welt ersetzt werden?

Lieber nicht. 

Beim erstgenannten Gerät, dem Kiosk, hätten wir in unserem Projekt einiges an Zeit und Geld sparen können, wenn wir dafür einfach eine abgespeckte Website direkt in AEM hätten implementieren können. 

AEM bietet hierfür die Möglichkeiten, beispielsweise durch die Verwendung von Experience Fragments.

Mehraufwand bei reinen Websites

Dabei zeigt sich: Insbesondere für Websites oder für Web-Technologien allgemein macht der reine Headless-Ansatz nur begrenzt Sinn. Auf der einen Seite wird ein Backend für die Inhaltspflege gebaut (mittels CMS), auf der anderen Seite wird das Frontend komplett unabhängig davon erstellt (mit Angular, React oder einem ähnlichen Framework). 

Dabei muss alles von Grund auf entwickelt werden: Jede Komponente, jedes Seitentemplate, die gesamte Navigation.

Das ist ein nicht zu unterschätzender Mehraufwand im Vergleich zu Design-Anpassungen der bestehenden Website in AEM.  

Inhalte zuerst!

Übersehen wird hierbei das meiner Meinung nach grösste Problem mit dem Headless-Ansatz: Wie werden die Inhalte in die Website abgefüllt, beziehungsweise eine Seitenstruktur definiert?

Bei einer stark durchstrukturierten Site wie einem Newsportal, wo Artikel Kategorien (Politik, Sport, … ) zugewiesen werden und nach Aktualität sortiert angezeigt werden, kann dies ja noch automatisch geschehen, und auch für Webshops finden sich ähnliche Lösungen. 

Für eine durchschnittliche Corporate Website aber, deren Inhalte auf den ersten Blick in einer willkürlichen Hierarchie abgebildet werden, muss die ganze Navigation im Frontend erstellt werden.

Da ist es äusserst schwierig, dies vom Backend her zu unterstützen.

Alle Funktionen zur Strukturierung von Inhalten, die in einem herkömmlichen Content Management System als selbstverständlich gelten, müssen mit grossem Aufwand, wenn überhaupt möglich, im Frontend erstellt werden. 

In unserem Beispiel mit dem Kiosk musste dieses Problem so gelöst werden, dass pro Gerät die gesamte Inhaltsstruktur im CMS gepflegt wird, und dann als JSON-Objekt dem jeweiligen Gerät zur Verfügung gestellt wird. Der Kiosk beschafft sich anschliessend die Inhalte selber und sorgt für die entsprechende Darstellung. 

Problematisch hierbei wird längerfristig die Abstimmung zwischen Frontend und Backend: Auch kleinste Fehler im JSON-Konfigurationsfile führen zu Fehlern im Frontend. 

In diesem Falle überwiegen die Vorteile eines traditionellen, «monolithischen» CMS gegenüber dem modernernen Headless-Ansatz.

Hybrid CMS: Das Beste beider Welten

Zum Glück ist Adobe nicht beim “monolithischen” Ansatz stehengeblieben, sondern hat gezeigt, dass Adobe Experience Manager nicht zu Unrecht als eines der innovativsten Produkte am Markt gilt. 

Mittels Content Services und verwandten Technologien wie Content Fragments und Experience Fragments lassen sich Inhaltsverwaltung und Darstellung trennen, und alle Inhalte auch auf einfache Weise als JSON-Objekte über REST-APIs abrufen. 

Dieser als «Hybrid-CMS» bekannte Ansatz bietet neben dem herkömmlichen, seitenbasierten, auf Websites optimierten CMS zusätzliche Headless-Funktionalität. 

Für die Website aufbereitete Inhalte können so über die entsprechenden APIs auch anderen Systemen wie Displays, Kiosks, Apps oder dem Internet of Things (IoT) zur Verfügung gestellt werden – es stellt sich also nicht mehr die Frage, ob Headless oder nicht, sondern nur noch: Wann setze ich auf Headless, und wann auf den traditionellen Ansatz? 

Bei dieser Frage die richtige Wahl zu treffen, kann entscheidend für den Projekterfolg sein. 

Wir helfen Ihnen gern, die Frage zur optimalen CMs-Strategie für Ihr Projekt zu beantworten, und zeigen Ihnen einen effizienten, kostengünstigen Weg zum Erfolg auf.

Sprechen Sie mit uns.

Michael Grob

Senior Consultant Digital Marketing