Ist Hybrid oder Headless das CMS der nächsten Generation?

Der CMS-Markt ist im stetigen Wandel. Aktuell bestimmt das Thema „Headless CMS“ die Diskussionen. Auch die Begriffe Decoupled und Hybrid CMS fallen immer häufiger, wenn es um modern Ansätze für Content Management in allen Kanälen geht. Doch worum geht es dabei eigentlich und warum sind Headless, Hybrid und Decoupled nicht nur Techie-Themen, sondern insbesondere auch für Marketer und Content-Spezialisten wichtig?

Die CMS-Architektur ist Basis des Marketing-Erfolgs

Die Auswahl von Marketing-Systemen und -Tools wird schon länger federführend vom Marketing gelenkt. Es ist kein reines IT-Thema mehr. Neu hinzugekommen sind aber Fragen, die die Architektur bzw. die Betriebsart der Wunschsysteme betreffen. Ob das CMS klassisch oder als Headless oder als Mischform und/oder in der Cloud betrieben werden soll, ist eine Frage, die das Marketing direkt betrifft. Die Auswahl und Architektur sind immerhin Motor der Effizienz und Performance der Marketingabteilung. Sie beeinflussen, wie gut und nahtlos andere Systeme vernetzt, wie leicht die Kommunikationskanäle aus einem Content Pool heraus bespielt werden und wie schnell Ziele erreicht werden können. Und letztlich bestimmt die System- und die Architekturwahl auch die kurz- und langfristigen Kosten. Muss die Software immer wieder mit viel Programmieraufwand an neue Anforderungen angepasst werden, ist das nicht nur teuer und aufwendig, sondern bedeutet auch enge Grenzen in Bezug auf die Umsetzbarkeit neuer Ideen und die Anpassung an verändertes Kundenverhalten. Eine unflexible Architektur kann die digitale Transformation eines Unternehmens bremsen und neue Geschäftsmodelle behindern.

Architektur fällt immer dann auf, wenn man mit ihr an Grenzen stößt. Wenn es beispielsweise Performanceprobleme gibt, eine wichtige neue Lösung nicht integriert werden kann oder wenn die Aufwände zur Pflege von immer mehr Medien und Kanälen explodiert. Es ist also sinnvoll, sich vorab Gedanken darüber zu machen, welche Ziele man kurz- und langfristig erreichen will. Denn davon hängt die Wahl des passenden CMS-Konzeptes ab.
Schauen wir uns also die verschiedenen Alternativen an: Welche Ansätze gibt es? Was sind die Stärken und Schwächen und wann ist welche Architektur passend?

Traditionelles CMS

Der Klassiker in aller Kürze: Es gibt zwei Komponenten, das Backend und das Frontend. Beide sind fest miteinander verbunden, liegen auf verschiedenen Servern, sind aber im Grunde ein zusammenhängendes Software-Produkt. Im Backend arbeiten die Redakteure und erstellen Content; auf dem Frontend („Head” oder „Delivery Tier”) greifen die Endnutzer, zumeist Webseitenbesucher, auf die Inhalte zu.

Vorteile:
- Ein einziges Produkt „out-of-the-box” mit solidem Funktionsumfang
- Ist schnell einsatzbereit ohne nennenswerten Integrationsaufwand

Nachteile:
- Inhalte, Design und Nutzererlebnisse (UX) sind fest miteinander verbunden, dadurch unflexibel und nur mit erheblichem Aufwand skalierbar
- Keine Wahlmöglichkeit bei der Präsentationsebene (Delivery Tier)
- Ausgelegt auf nur einen spezifischen Kanal, zumeist die Webseite
- Anpassungen im Frontend ziehen immer auch Anpassungen im Backend nach sich (hoher Kosten- und Ressourcenaufwand)

Decoupled CMS

Moderne, entkoppelte CMS-Architekturen funktionieren auf den ersten Blick ähnlich, jedoch agieren hier Backend und Frontend deutlich unabhängiger. Das Grundgerüst bildet eine getrennte Architektur zwischen CMS-Backend und Frontend sowie ein optionaler Head.

Das CMS kann – ähnlich wie beim traditionellen Ansatz – mit einer herstellereigenen Auslieferungsschicht betrieben werden, auf der serverseitige Aufgaben wie Formularvalidierung oder Personalisierung als Live-Anwendungen ausgeführt werden. Der Austausch zwischen den Schichten erfolgt über „Push”-Mechanismen, d. h. hier werden Seiten oder Inhaltsfragmente z. B. im HTML- oder JSP-Format ausgeliefert. Das Frontend kann aber auch ein beliebiger Web- oder App-Server oder eine Cloud-Auslieferungsinfrastruktur sein.

Paradedisziplin für entkoppelte CMS ist die Shop-Integration: Hierbei steckt im Shop ein kleines Stück CMS-Integration, das aus CMS-Content native Objekte erzeugt. Nativ deshalb, weil sie sich nicht von den Objekten unterscheiden, die im Shop selbst erstellt wurden. Als Gegenstück gibt es im CMS-Backend eine Shop-Integration, die beispielsweise den Produktkatalog zugänglich macht und die redaktionelle Vorschau erzeugt.

Um auch hochdynamische Experiences ausliefern zu können, gibt es eine weitere Komponente, die herstellerübergreifend häufig Content-as-a-Service (CaaS) genannt wird. Der CaaS ist eine REST-basierte Content-Schnittstelle, die jegliche Inhalte, auch einzelne Fragmente, zum Abruf bereitstellt. Nach dem Pull-Prinzip werden die Inhalte vom Server oder direkt vom Client herangezogen und in Echtzeit für dynamische Experiences zusammengesetzt.

Vorteile:
- Sehr solides Konzept, um State-of-the-Art-Webseiten, auch in großen Enterprise-Szenarien zu betreiben
- Sehr flexible, skalierbare und performante Architektur
- Im Shop-Kontext ermöglicht eine tiefe Integration komplexe Features wie die Shop-native Personalisierung und das Maximum aus den Shop-eigenen Auslieferungsfunktionen

Nachteile:
- Inhalte, Design und Nutzererlebnisse am Frontend sind relativ fest miteinander verbunden. Entwickler brauchen domänen-übergreifendes Know-how, um die User Experience weiterzuentwickeln
- Keine ideale Lösung für Multichannel-Szenarien. Für jegliche neue Kanäle oder Touchpoints müssen neue Integrationen gebaut werden
- Investitionen in die User Experiences und Entwicklungen im Frontend sind durch die hohe technische Abhängigkeit zwischen CMS und Shop/Portal wenig zukunftssicher

Headless CMS

Ein Headless CMS spielt seine Stärken genau an den Schwächen der zuvor beschriebenen Konzepte aus. Neben der mangelnden Zukunftssicherheit von Innovationen und Investitionen am Frontend zählen dazu vor allem die geringe Freiheit bei der Auswahl der Frontend-Applikationen und damit die fehlende Flexibilität bei der Gestaltung und Optimierung der Nutzererlebnisse. Was kann ein Headless CMS also besser?

Das einfache Grundprinzip: Es gibt ein CMS-Backend und dazu einen Content-as-a-Service als alleinige Auslieferungsschicht, die jeglichen Content bereitstellt. Die Frontend-Applikation, welche auch immer das sein mag, ist komplett vom Backend getrennt und greift ausschließlich über einen Pull-Mechanismus auf die Schnittstelle zu. Der Austausch zwischen den Komponenten erfolgt typischerweise über JSON, einem standardisierten Format für den Austausch von Daten zwischen Maschinen. Bei diesem Ansatz lebt die gesamte User Experience in der Frontend-Applikation und ist vollkommen getrennt von der CMS-Entwicklung.

Das CMS-Backend fokussiert komplett auf die typischen Backend-Funktionalitäten wie Authoring, Workflow, Versionierung oder Kollaboration. Die Frage nach der Präsentation der Inhalte, also wie sie der End-User erlebt, wird beim Headless-Konzept im Backend nicht definiert. Kombiniert man die Features eines Decoupled CMS mit einer REST-API, erhält man also die Definition einer Headless-Architektur. Der Vollständigkeit halber hier auch der Verweis auf eine gängige Definition:

„A headless content management system, or headless CMS, is a back-end only content management system (CMS) built from the ground up as a content repository that makes content accessible via a RESTful API for display on any device.” (Wikipedia)

Zum Einsatz kommt ein Headless CMS vor allem dann, wenn man mehrere Kanäle bespielen will, bspw. Web und Mobile Apps, Shops, Digital Signage und Voice Assistants. Die Anzahl der Touchpoints lässt sich beliebig erweitern, alle greifen dabei auf denselben Content-Pool zurück.

Vorteile:
- Ein einheitlicher Weg, um Content an jeden beliebigen Touchpoint zu bringen (maximale Skalierbarkeit)
- Klare Trennung zwischen Back- und Frontend: Das Frontend lässt sich vollkommen unabhängig vom CMS weiterentwickeln
- Große Vorteile bei der personellen Besetzung von Webprojekten, weil Backend-Entwickler keine Frontend-Kenntnisse benötigen und umgekehrt
Sichere und nachhaltige Investitionen in die UX

Nachteile:
- Höhere Komplexität von Setup und Betrieb als bei einer standardisierten Web-CMS-Anwendung
- „Pureplay” Headless-CMS Anbietern fehlen oftmals Features, die bei etablierten Anbietern vorausgesetzt werden, wie z. B. integriertes Bearbeiten im Kontext der Live-Seite
- Reine Headless-Architektur schließt Tiefenintegration aus, d. h. zentrale Features von zum Beispiel Shopsystemen bleiben womöglich ungenutzt

Hybrides CMS

Ein hybrider Architektur-Ansatz ergänzt die Stärken eines hochflexiblen Headless CMS, indem es die tiefe Integration von Drittsystemen wie z. B. Shops ermöglicht. Wie bei einem Headless CMS existiert das separate Backend und die REST-API, die vorhandene Touchpoints anbindet. Zusätzlich gibt es aber eine Tiefenintegration zwischen Shop und CMS-Backend, mit der man die Vorteile beider Welten ausspielen kann.

Ein entscheidender Punkt ist hierbei, dass man nicht zwischen dem klassischen CMS und einem reinen Headless CMS wählen muss. Man erhält mit einem hybriden Ansatz hohe Flexibilität, risikoarm neue Wege für eine bessere Digital Experiences zu gehen, mit Content und Kanälen zu variieren, zu testen und zu optimieren. Damit etabliert man eine Experimentierkultur im Unternehmen, mit der sich das Beste aus den unterschiedlichen Features, Daten und Inhalten herausholen lässt. Sie können Headless z.B. einsetzen, um im ersten Schritt besonders dynamische Content-Bereiche der Website, also Bereiche, auf denen sich häufig Inhalte ändern, die auch in anderen Kanälen geändert werden sollen, „kopflos“ zu gestalten, während selten geänderte Seitenbestandteile „klassisch” ausgespielt werden. Gleichzeitig stehen sämtliche Content-Elemente “out of the box” ohne aufwändige Integrationsprojekte für beliebige neue Kanäle oder Touchpoints zur Verfügung - auf Basis der standardisierten Content-API können agil arbeitende Teams neue Nutzererlebnisse schaffen, ohne dabei getrennte Content-Silos aufbauen zu müssen.

Fazit: Headless ist neu und gut – Hybrid ist besser, denn es vereint neu und alt

Mit einem Hybrid CMS, wie FirstSpirit, vereinen Sie die headless Content-Verteilungstechnologie der neuen Welt mit den enterprise-class CMS Features und dem Komfort aus der gewohnten Welt:
- Gewohnte Effizienz, Übersicht und Sicherheit mit Rechte & Rollen, Workflows, Versionierung etc.
Komplexe Multi-Brand- und Multi-Site-Szenarien sicher umsetzen.
- Ihre Marketer und Redakteure können gewohnt-intuitiv Inhalte pflegen.
- Inhalte aus angrenzenden internen und externen Systemen lassen sich leicht integrieren.
- Sie erhalten erfolgssteigernde Zusatzfunktionalitäten wie KI-basierte Personalisierung, Automated Content Creation, Kampagnen-Management, Shoppable Video und vieles mehr.

Wenn Sie oder Ihre Kollegen / Vorgesetzten das Thema interessiert, laden wir Sie herzlich zu unserem vertiefenden Webinar ein. Dort können Sie noch ausführlicher, und an Schaubildern und Beispielen erklärt, einsteigen. Es ist jederzeit abrufbar. In dem Webinar zeigen wir auch, welche Unternehmen bereits herausragende digitale Erlebnisse mit FirstSpirit als hybridem CMS umgesetzt haben.
https://www.e-spirit.com/de/events/headless-cms-als-entscheidender-faktor-wettbewerb-um-beste-digital-experience.jsp


Mit der FirstSpirit Digital Experience Platform von e-Spirit, erhältlich als SaaS oder klassisches On-Premises-Modell, können sich Unternehmen durch maßgeschneiderte Kundenerlebnisse von Wettbewerbern differenzieren, die Kundenbindung und Konversion optimieren und Geschäftsumsätze steigern - anytime, anywhere. Die FirstSpirit-Platform ermöglicht mit dem hybriden (headless+) CMS, KI-gestützter Personalisierung und Omnichannel-Marketing-Funktionalitäten, personalisierte Inhalte in Echtzeit kontextspezifisch über alle Kanäle und Touchpoints zu verbreiten und Kunden zu begeistern.