Was ist ein Headless-CMS?

Bei einer Headless-CMS-Architektur sind Backend-Content-Funktionen (wie Erstellung, Verwaltung und Speicherung) von Frontend-Funktionen (wie Präsentation und Bereitstellung) getrennt.

Jetzt wollen wir es aber wissen: Was ist ein Headless-CMS?

Was bedeutet das? Warum ist eine Headless-Architektur wichtig für die Zukunft digitaler Erlebnisse?

Headless-Architektur ist teilweise das Ergebnis der Art und Weise, wie sich Web-Content im Laufe der Zeit entwickelt hat. Lange Zeit wurden die meisten Webinhalte über einen Browser, oftmals in Form von Webseiten, bereitgestellt. Es kommen aber laufend neue vernetzte Geräte hinzu.

Heute wird Content über neue Oberflächen mit unterschiedlichsten Formfaktoren konsumiert – wie Smartphones, Wearables, KI-fähige Sprachassistenten und VR-Headsets.

Eine Headless-CMS-Architektur ist grundlegend für die Bewältigung dieser neuen Content-Herausforderungen. Das bedeutet, dass viel mehr Inhalte einfach erstellt und verwaltet und an viel mehr Stellen bereitgestellt werden können.

Bevor wir aber zu technisch werden, beginnen wir mit den Grundlagen.

Eine Headless-CMS-Architektur ist grundlegend für die Bewältigung dieser neuen Content-Herausforderungen. Das bedeutet, dass viel mehr Inhalte einfach erstellt und verwaltet und an viel mehr Stellen bereitgestellt werden können.

Bevor wir aber zu technisch werden, beginnen wir mit den Grundlagen.

Wir stellen hier zwei grundlegende architekturbezogene Entscheidungen vor und schauen uns an, welchen Einfluss diese auf die Art und Weise haben, wie Content erstellt, gespeichert, verwaltet, bereitgestellt und personalisiert wird.

Welchen Einfluss hat eine CMS-Architektur darauf, wie Content auf einer Seite präsentiert wird?

Wir wollen herausfinden, was die Unterschiede zwischen seitenbasierter und objektbasierter Architektur sind, und befassen uns mit der Frage, warum Ihr KI-fähiger Sprachassistent nicht ansatzweise so smart ist wie er sich anhört.

Welchen Einfluss hat eine CMS-Architektur darauf, wie (und wo) Content den Nutzern präsentiert wird?

Erfahren Sie, welche Unterschiede es zwischen einer Headless- und einer herkömmlichen Architektur gibt und wie Sie vermeiden können, dass Personalisierung und Analysen durch die Entscheidung für eine Headless-Strategie beeinträchtigt werden.

CMS: Frontend und Backend

Ein traditionelles CMS besteht aus zwei Hälften: dem Frontend und dem Backend.

Helt overordnet handler back-end-delen af et CMS-system om, hvordan indhold bliver administreret, og front-end-delen handler om, hvordan det bliver præsenteret. Tænk på det som et butiksvindue.

Allgemein gesprochen: Das Backend eines CMS hat damit zu tun, wie Content verwaltet wird, und das Frontend damit, wie er präsentiert wird. Das kann man sich wie eine Schaufensterauslage in einem Geschäft vorstellen.

Zu Frontend-Aufgaben gehört alles, was Sie sehen würden, wenn Sie von der Straße in das Fenster schauen: Auswahl und Anordnung der Produkte sowie der zugehörigen Schilder.

Backend-Aufgaben beinhalten die Logistik – Erstellen der Schilder, Lagerung der Produkte und Verwaltung der Warenbewegungen im Geschäft.

Bei einer einfachen Website könnte das Backend Folgendes beinhalten:

• Eine einfache Oberfläche, um Content zu erstellen
• Eine Datenbank zur Speicherung digitaler Assets
• Eine Anwendungsebene zur Erstellung und Anwendung von Design-Frameworks

Das Frontend würde dann auf Content, gespeicherte Assets und Designs zugreifen und diese auf einer HTML-Seite veröffentlichen.

Was ist ein „Decoupled CMS“?

TTraditionell waren das Frontend und Backend bei einem CMS eng verzahnt. Die Benutzer konnten Content auf einer zentralen Oberfläche erstellen, speichern, verwalten und veröffentlichen.

Für technisch nicht ganz so versierte Benutzer, die einfachen Content veröffentlichen wollten – wie z. B. einen Blog – war das eine tolle Sache.

Aber im Zuge der Entwicklung digitaler Erlebnisse mussten die Entwickler sehr viel Zeit für die Entwicklung benutzerspezifischer Behelfslösungen aufwenden, um optimierten Content für ein immer breiteres Spektrum an Geräten bereitzustellen.

Decoupled CMS sind in Backend- und Frontend-Aufgaben unterteilt. In der Praxis bedeutet dies, dass die Entwickler Frontend-Erlebnisse in der von ihnen bevorzugten Sprache schnell programmieren und entwickeln können, ohne durch restriktive Backend-Technologien ausgebremst zu werden. Stattdessen können sie Application Programming Interfaces (API) nutzen, um die Backend-Funktionen – wie Content-Speicherung und -Verwaltung – mit einer beliebigen Frontend-Bereitstellungsumgebung zu verknüpfen.

Was ist ein „API-first CMS“?

Auch wenn bei Decoupled CMS die Backend- und Frontend-Funktionen getrennt sind, beinhalten sie oftmals Frontend-Bereitstellungstools wie Seitenvorlagen oder Modulintegrationen.

API-first CMS sind von der Funktion her mit Headless CMS vergleichbar, weil auch sie kein Standard-Frontend besitzen. Entwickler haben die Möglichkeit, so viele Bereitstellungsebenen wie benötigt zu erstellen (in der von ihnen bevorzugten Sprache), um Content in beliebigen neuen Kanälen bereitzustellen.

API-first CMS sind eine tolle Sache, wenn Sie bereits ein Team erfahrener Entwickler haben – das CMS verwaltet einfach nur Content und wartet auf API-Aufrufe von einer vom Entwicklerteam angelegten Frontend-Bereitstellungsebene.

Decoupled CMS hingegen sind für Unternehmen geeignet, die Wert auf die Flexibilität eines separaten Frontend und Backend legen, aber Unterstützung bei der Veröffentlichung benötigen.

Headless-CMS sind sicherlich die Zukunft des Content-Managements, und das aus zwei wichtigen Gründen.

Zunächst einmal wird digitaler Content immer komplexer und die Erwartungen der Nutzer werden immer größer. Um sich vom Wettbewerb abzuheben, müssen Sie ansprechenden, bedürfnisgerechten und interaktiven Content erstellen – und das möglichst schnell.

Zum anderen kommen laufend neue Kanäle und Nutzergeräte hinzu. Es reicht längst nicht mehr, nur tollen Content zu produzieren – Sie müssen auch sicherstellen, dass er so effizient wie möglich und überall bereitgestellt wird. Headless-CMS bedeutet, dass Marketer und Entwickler heute wirkungsvollen Content entwickeln und – das ist das Entscheidende – ihre Content-Prozesse zukunftssicher machen können, um durchgängig überall ansprechenden Content bereitzustellen.

Das ist eine feine Sache für Marketer, Entwickler und Benutzer.

Das ist hervorragend für Marketer, weil ...

… sie Content nur einmal erstellen müssen und die Entwickler diesen dann überall veröffentlichen können. Das bedeutet, dass weniger Zeit für die Administration aufgewendet werden muss und mehr Zeit für wirkungsvolle, konsistente Erlebnisse zur Verfügung steht.

Das ist hervorragend für Nutzer, weil …

… das Benutzererlebnis schnell, konsistent und bedürfnisgerecht ist. Das liegt daran, dass die Client-Seite nicht mit dem Backend-System kommunizieren muss – sie muss den Content lediglich wiedergeben.

Das ist hervorragend für Entwickler, weil …

… sie am Backend nicht mehr an Programmiersprachen gebunden sind, mit denen sie keine Erfahrung haben. Stattdessen können sie Benutzererlebnisse vom Look & Feel und von der Funktionalität her mit Tools entwickeln, die sie kennen und mit denen sie gerne arbeiten (z. B. JavaScript-Bibliotheken und -Frameworks), und den Content dann mithilfe der neuesten APIs überall veröffentlichen.

Standard-Headless-CMS sind kein Wundermittel für alle Ihre Content-Herausforderungen. Es gibt zwei große Nachteile, die bedacht werden müssen.

Auf der einen Seite gewinnen Sie Flexibilität, auf der anderen Seite leidet die Zugänglichkeit. Da die Präsentation Sache der Entwickler ist, die mit JavaScript arbeiten, können nicht-technische Marketer nicht WYSIWYG (What You See Is What You Get)-Authoring oder -Bearbeitung nutzen.

Der zweite Nachteil ist schwerwiegender:

Wenn das CMS seines „Kopfes“ beraubt wird, passiert etwas Drastisches – es gibt keine Möglichkeit mehr, Kundeninteraktionsdaten zwischen Frontend und Backend in Echtzeit auszutauschen.

Das bedeutet, dass keine Erlebnisse personalisiert oder Content-Analysen durchgeführt werden können.

Personalisierung ist aber von einem „Nice-to-have“ zu einem erfolgskritischen Erfordernis geworden. Amazon, Netflix, Spotify und andere machen schließlich vor, wie Personalisierung geht.

Wenn Sie nicht ein ähnliches Erlebnis bereitstellen können, werden die Kunden vermutlich abwandern – und zwar sehr schnell. Wie soll man darauf reagieren?

Eine ideale CMS-Architektur kombiniert die Flexibilität und Erweiterbarkeit eines Headless-CMS mit den Personalisierungs- und Content-Analysefunktionen herkömmlicher gekoppelter CMS.

Genau das leistet die Headless-Bereitstellungsoption von Sitecore.

Mehrere Headless-Optionen unterstützen die Frontend-Entwickler beim Bau von Lösungen und Apps, die Inhalte auf alle Geräte und Browser zuschneiden. Die Entwickler können ganz einfach auswählen, was sie brauchen, gleich ob sie JavaScript-Bibliotheken wie Vue.js, React.js und Angular.js verwenden oder die neue ASP.NET Core SDK und Headless-Rendering-Hostarchitektur nutzen.

Diese Optionen sind außerdem mit einer API ausgestattet, die eine Anbindung an den Sitecore Delivery Server für kontextabhängigen Content ermöglicht. Verwendet werden Informationen aus der Sitecore Experience Database™, damit Geräte und Browser Content- und Personalisierungsregeln in Echtzeit interpretieren können. Jeder Benutzer sieht also anderen Content, weil sich dieser nach Profildaten, dem Interaktionsverlauf und anderen Merkmalen richtet.