Marktübersicht Hybrid CMS

Kaum ein Trend hat den Markt der Content Management Systeme in den letzten Jahren so stark beeinflusst wie die Headless Architektur. Die darstellungsneutrale Verwaltung von Content und dessen Ausspielung über ein Application Programming Interface (API) ist bei Entwicklern ausgesprochen beliebt und kann einige praktisches Problem lösen. So ist es nicht verwunderlich, dass inzwischen sehr viele traditionelle Content Management Systeme auf den Zug aufgesprungen sind und eine Headless-Nutzung entweder als Feature, oder gleich als Produkt-Variante anbieten. Jenseits der Entwickler-Szene kommen Anwender bei den vielen Begriffen jedoch schnell durcheinander. Wo liegen also die Unterschiede und worauf sollte man achten?

#Decoupled CMS und Hybrid CMS

Die Idee hinter der Headless-Architektur ist nicht neu. Sie folgt Konzepten wie dem "Separation of Concerns" und dem generellen Trend hin zum Microservice. Dieser Trend hat andere Software-Bereiche bereits vor Jahren erreicht.

Da diese Konzepte weit verbreitet sind, war der Sprung auf den Headless-Zug für einige traditionelle Content Management Systeme auch nicht so groß wie man denken könnte. Denn einige Enterprise-CMS wie CoreMedia oder auch FirstSpirit haben die Systeme intern schon immer streng voneinander getrennt und über eine API-Architektur miteinander verbunden. Solche Content Management Systeme werden hin und wieder auch als decoupled CMS bezeichnet.

Die Anbieter solcher decoupled CMS konnten ihre APIs vergleichsweise schnell ausbauen oder gleich eine Headless-Lösung als Produkt-Variante anbieten. Für solche Produkte hat sich auch der Begriff des "Hybrid CMS" eingebürgert. Im Klartext: Mit einem Hybrid-CMS kann man sowohl ein fertiges Endprodukt wie eine Webseite erstellen. Man kann das System aber auch Headless nutzen und die Inhalte darstellungsneutral über eine API ausspielen.

#Verwirrende Vielfalt

Inzwischen haben viele weitere traditionellen Content Management Systeme nachgezogen und bieten mehr oder weniger ausgereifte APIs für die Headless-Nutzung an. All diese "traditionellen" Content Management Systeme könnte man als "Hybrid CMS" bezeichnen. Aufgrund der großen Konjunktur des Headless-Trends reklamieren jedoch viele dieser eher traditionellen Systeme den Begriff "Headless CMS" auch für sich. Umgekehrt stehen manche neue Anbieter wie beispielsweise Contentful dem Begriff "Headless CMS" eher kritisch gegenüber und bezeichnen ihr Angebot lieber als Content Infrastructure oder als Content Platform. Auch der Begriff des Content Service fällt in diesem Zusammenhang sehr oft.

Dieser "Kampf um Begrifflichkeiten" hat leider dazu geführt, dass Außenstehende die Angebote für sich kaum noch sinnvoll sondieren können. Darin kann jedoch auch eine Chance liegen, denn ob "Headless", "Hybrid", "Content Service" oder "Infrastructure" sollte bei der Auswahl eines CMS ohnehin keine zentrale Rolle spielen. Stattdessen sollte man die eigenen Anforderungen an das "Web Content Management" möglichst klar definieren und dann schauen, welche Architektur am besten passt.

#Problemfelder traditioneller CMS

Viele traditionelle Web Content Management Systeme sind immer noch sehr stark auf die Verwaltung von Webseiten ausgerichtet. Dabei haben zahlreiche CMS in den letzten Jahren Autoren-Features entwickelt, die eine visuelle Bearbeitung der Webseite ohne starke Abstraktionen ermöglichen. Ein gutes Beispiel ist WordPress. Mit dem Gutenberg-Editor und den Plänen für ein Full-Site-Editing (FSE) schlägt das beliebte CMS einen Weg ein, den Enterprise-Systeme wie der Adobe Experience Manager (AEM) schon vor Jahren abgeschlossen haben. Mit solchen Systemen lassen sich Webseiten relativ intuitiv und frei gestalten, ohne dass ein Entwickler eingeschaltet werden muss.

Wenn solche Systeme nun auch Headless-Features anbieten, dann liegt das Problem oft weniger in der Technik, sondern vielmehr im Mindset der Anwender. Denn wer es gewohnt ist, visuell zu arbeiten und Webseiten weitesgehend selbst zu gestalten, der wird sich schwer damit tun, diese visuelle Repräsentation aufzugeben und stattdessen die Inhalte strukturiert und darstellungsneutral über Formulare zu erfassen. Doch genau darum geht es bei dem Headless-Ansatz: Man erstellt die inhalte nicht für eine bestimmte Webseite, sondern neutral für die Verwendung in den unterschiedlichsten Szenarien.

Abgesehen von möglichen technischen und konzeptionellen Unzulänglichkeiten mancher nachträglich integrierter "Headless"-APIs kann man das Problem traditioneller CMS mit Headless-Architektur auf folgende Regel herunterbrechen können: Je stärker sich Redakteure an ein visuelles Arbeiten gewöhnt haben und je stärker ihre Spielräume in Bezug auf die Gestaltung eines Endprodukts sind, desto größer ist der Bruch beim Umstieg auf eine Headless-Architektur.

#Problemfelder von Headless Systemen

Bei den reinen Headless-Systemen sieht es genau umgekehrt aus. Mit ihnen lassen sich die Inhalte nahezu beliebig strukturieren und organisieren. Und aufgrund des jüngeren Alters sind die Systeme in der regel leichtgewichtig, ohne historischen Ballast und technisch sauber aufgestellt. Per Definition fehlt jedoch bei den meisten Headless-CMS die visuelle Präsentation der Inhalte. Zwar lässt sich in der Regel eine Seitenvorschau konfigurieren. Ein Block-Editing, andere Formen des visuellen Arbeitens oder auch die eigenständige Erstellung von Microsites sind jedoch nur bei den wenigsten Headless Systemen möglich.

Hinzu kommen weitere bekannte Einschränkungen. Beispielsweise sind Headless-CMS auf die reine Content-Verwaltung spezialisiert. Für alle anderen Funktionen wie zum Beispiel für die Realsierung von Shops müssen Dritt-Systeme genutzt werden. Das ist im Sinne der Headless-Architektur natürlich kein Nachteil. Die Konsequenz einer stärkeren Abhängigkeit von Entwicklern und IT-Abteilungen muss bei der Auswahl jedoch bewusst sein.

#Headless-Angebote traditioneller CMS

Die traditionellen Content Management Systeme haben sehr unterschiedlich auf den Headless-Trend reagiert. Drupal ist das Headless-Thema beispielsweise sehr offensiv angegangen und bietet verschiedene Headless-Distributionen an. Dagegen hat Joomla! erst mit Version 4 im August 2021 eine umfangreiche REST-API vorgestellt. Der Umfang und die Art der APIs ist ebenfalls sehr variabel: Manche Systeme bieten neben der REST-Api auch eine ausgereifte GraphQL-API an. Andere beschränken sich auf einfache Read-Only-APIs. Die gleiche Vielfalt herrscht bei den angebotenen Authentifizierungsmethoden, die von klassichen API-Keys über modernere Web-Tokens bis hin zu einer einfachen Basic-Authentication reichen. Die folgende Liste soll einen ersten Überblick bieten. Im Anschluss werden ausgewählte Angebote noch einmal mit weiterführenden Links kurz charakterisiert.

Hier gibt es bald mehr spannende Inhalte für unsere Premium-Leser.

© by Sebastian Schürmanns, 2017 - 2022. All Rights Reserved. Built with Typemill.