In den letzten Jahren haben vor allem die neuen Headless CMS die Debatte um Contentmanagementsysteme dominiert. Doch die erste große Überraschung des Jahres 2020 kam aus einer ganz anderen Richtung: Der SPIEGEL hat mit seinem NextGen-Projekt einen großen Relaunch gewagt und dabei auf das weitgehend unbekannte CMS Statamic gesetzt [1].

Um die Tragweite dieser Entscheidung zu verstehen, muss man zurück in das Jahr 2012 gehen und nach Clifton Park reisen, einem kleinen Provinznest im hohen Norden von New York State. Dort hat der Designer und Entwickler Jack McDade das CMS Statamic als Nebenprojekt aus der Taufe gehoben. Durch den gemeinsamen ExpressionEngine-Hintergrund besteht eine gewisse Verwandtschaft zu dem etwas bekannteren CMS Craft. Statamic ist im Kern jedoch ein sogenanntes Flat File CMS und dadurch mit kleinen Systemen wie Kirby oder Grav verwandt. Ausgesprochen „flat“ ist bis heute auch die Personaldecke geblieben: Das Entwicklerteam hinter Statamic besteht aus drei Personen. Drei Personen, die das CMS hinter einer der reichweitenstärksten Webseiten in Deutschland entwickeln. Das klingt nicht unbedingt nach Enterprise. Doch genau hier trifft sich die Realität mit den Aussagen einiger Marktbeobachter, die eine Tendenz weg von komplexer Technologie und hin zu mehr Einfachheit erkennen.

Das Trendthema Headless CMS

Aspekte wie Vereinfachung, Reduktion und vor allem die Separation of Concerns gehören auch zu den Leitbildern der neuen Headless-Architektur. Und so wundert es nicht, dass auch der SPIEGEL diese Architektur bei seinem Relaunch aufgegriffen hat. Laut André Basse, dem Managing Director vom SPIEGEL Tech Lab, werden in einem selbst entwickelten Content-Store in der Cloud sämtliche Inhalte zentral im JSON-Format verwaltet und über einen Elastic-Index per REST API unter anderem an das CMS Statamic ausgeliefert. Das Beispiel zeigt, wie groß die Spielarten bei der Realisierung einer Headless-Architektur sind.

Wer die Mühen einer eigenen Headless-Architektur scheut, der kann auf ein breites Angebot an SaaS-Diensten zurückgreifen. Zu den Marktführern gehört das Berliner Start-up Contentful, das für seinen SaaS-Service gerne den Begriff „Content-Infrastructure“ nutzt. Wer dagegen die Hoheit über seine Contentinfrastruktur behalten möchte, der findet mit Directus (PHP), Strapi (Node) oder auch Gentics Mesh (Java) einige ausgereifte On-Premise-Lösungen auf dem Markt.

Die Idee der Headless CMS ist nicht neu. Mit ihr wird lediglich der Gedanke der Microservices auf den Contentbereich übertragen. Dazu bieten die Headless-Systeme eine Oberfläche für die Erstellung und Verwaltung von Inhalten und liefern diese Inhalte neutral über ein REST oder GraphQL API aus. Der Verzicht auf die Darstellung von Inhalten verringert nicht nur die Komplexität des Systems, sondern befreit die Frontend-Entwickler auch von lästigen Vorgaben. Mit einem Content-API sind Entwickler unabhängig von der serverseitigen Sprache des CMS, sie können beliebige Frontend Frameworks wie React, Vue, Angular und Svelte nutzen, oder sie können einen Static-Site-Generator als Ersatz für die fehlende Template-Engine anbinden und damit statische Webauftritte generieren. Kurz gesagt, Headless CMS sind im Backend der passende Gegenpart zum JAMstack-Trend (JavaScript, APIs, Markup) im Frontend.

Headless und der JAMstack

Der JAMstack und vor allem die Static-Site-Generatoren sind seit Jahren in der Entwicklerszene verbreitet und haben dort das klassische CMS mehr oder weniger abgelöst. Dass dieser Trend nun langsam auch im Mainstream und im Enterprise-Segment ankommt, zeigt das Beispiel Braun. Als Teil des Konzerns Procter & Gamble lief der Markenauftritt auf www.braun.de viele Jahre auf einem der großen Enterprise-CMS. Seit 2019 wird die Seite jedoch zumindest im Frontend mit Gatsby generiert, dem derzeit angesagtesten Kandidaten unter den Static-Site-Generatoren.

So gut wie alle Headless-Anbieter unterstützen die Verwendung von Static-Site-Generatoren mit Erweiterungen und Tutorials. Das Aufsetzen der erforderlichen Deployment- und Build-Prozesse war bislang allerdings mit relativ viel Handarbeit verbunden. Doch auch in diesem Bereich wächst das Ökosystem Schritt für Schritt: Im Dezember 2019 hat Gatsby seinen Service Gatsby Cloud vorgestellt, der eine einfache Anbindung von Contentmanagementsystemen wie Contentful und GraphCMS, aber auch von WordPress und Drupal ermöglicht. Die ergänzende Build und Deployment Pipeline folgte wenig später mit Gatsby Builds. Damit dürfte Gatsby dem neuen Stack weiteren Vorschub leisten.

Hybrid, DXP und die Cloud

Trends wie Headless CMS, Static-Site-Generatoren und der JAMstack sind in der Unternehmenswelt längst angekommen und werden dort vor allem in den IT-Abteilungen intensiv diskutiert. Und natürlich haben auch die traditionellen Contentmanagementsysteme frühzeitig auf die neuen Entwicklungen reagiert. Vom einfachen Content-API über separate Headless-Distributionen bis hin zu Hybridsystemen bietet inzwischen fast jedes relevante CMS eine Lösung an, die der eigenen Gewichtsklasse entspricht. Was mit den originären Headless-Anbietern als eigenständige Produktkategorie begann, entwickelt sich bei den traditionellen CMS mehr und mehr zum Feature oder zur Produktvariation.

Gleichzeitig zeichnet sich eine weitere Spreizung des Markts ab. Denn während die Headless-CMS eher eine Verringerung der Komplexität anstreben und gut zu einer Best-of-Breed-Strategie passen, fügen die Headless-Features bei vielen Enterprise-WCMS eher einen weiteren Layer zur bestehenden Komplexität hinzu. Und Komplexität bleibt zumindest im Enterprise-Segment weiter im Trend. So sehr, dass der Analyst Gartner Ende 2019 die Kategorie der reinen Webcontentmanagementsysteme fallen gelassen hat und künftig nur noch den Markt der Digital Experience Platforms (DXP) beobachten will. Bei den DXP wiederum ist das WCMS nur noch ein Baustein unter mehreren Softwareprodukten, mit denen komplexe Produktlebenszyklen begleitet und der Fokus auf das Management von Kundenerlebnissen gelenkt werden soll. Da bei reinen Headless-Systemen alle Anforderungen jenseits der Contentverwaltung separat gelöst werden müssen, können Lösungen out of the box ein entscheidender Vorteil bei komplexen Szenarien sein.

Komplexität sollte jedoch nicht nur beherrschbar, sondern im besten Fall auch kalkulierbar sein. Und die Kalkulierbarkeit ist eines der schlagenden Argumente für SaaS- und Cloud-Angebote. Dieses Argument machen sich wiederum die Headless-Anbieter zu eigen, indem sie zum großen Teil als reine SaaS-Dienste auf dem Markt auftreten. Doch auch die Enterprise-Anbieter haben die kalkulatorischen Sorgen ihrer Zielgruppe erkannt: Vom Adobe Experience Manager (AEM) über CoreMedia bis hin zu Magnolia und FirstSpirit bieten inzwischen fast alle bekannten Namen ihre Produkte auch als SaaS- oder Cloud-Services an.

Die Grenzen des Hypes

Wenn es um die technischen Anforderungen im Unternehmensumfeld oder um die Ansprache einer jungen Generation von Frontend-Entwicklern geht, dann haben Themen wie Headless, APIs und die Cloud ein großes Gewicht. Blickt man jedoch auf die Anforderungen des Marketings oder der Contentredakteure, herrscht in der Praxis viel Verwirrung in der Frage, in welchen Situationen die neuen Ansätze einen echten Mehrwert bieten. Denn wie jede Technologie bringen auch die Headless CMS und die Static-Site-Generatoren ihre eigenen Fallstricke mit.

So haben Contentmanagementsysteme mit einer dynamischen Seitenauslieferung gegenüber den Static-Site-Generatoren zwar unzweifelhaft ihre Nachteile, wenn es um Aspekte wie den Ressourcenverbrauch, die Performance oder die Sicherheit geht. Jedoch genießen die wenigen noch existierenden Contentmanagementsysteme mit einer statischen Seitenauslieferung in Redaktionen einen eher zwiespältigen Ruf, da die Seitengenerierung im Zweifelsfall viel Zeit in Anspruch nimmt. Nächtliche Deployments bei einer Änderung im Footer gehören dabei zu den gängigen Aufregerthemen.

Auch die Idee hinter der Headless-Architektur klingt erst einmal bestechend, kommt in der Praxis jedoch nicht ohne Einschränkungen aus. So gehörten in den letzten Jahren eine hohe Flexibilität bei der Seitengestaltung, ein möglichst visuelles Arbeiten mit Inhalten sowie die eigenständige Erstellung von Microsites zu den Kernanforderungen aus dem Marketing. Durch solche Anforderungen hat sich ein regelrechter Wettlauf um die größte Flexibilität, die beste Author Experience und das ausgefeilteste Content-Editing etabliert. Entsprechend wirken Enterprise-WCMS wie AEM heute mehr oder weniger wie selbst gehostete Website-Builder. Zwar ist auch bei den Headless-Systemen in aller Regel die Einrichtung einer Seitenvorschau durch einen Entwickler möglich, doch Konzepte wie Content-Editing sind den Headless CMS durch die fehlende Darstellungslogik fremd. So müssen sich Redakteure wohl oder übel wieder mit vordefinierten Formularoberflächen und einem vergleichsweise abstrakten Arbeiten anfreunden. Entsprechend hat der Director of Research and Innovation von Acquia, Preston So, darauf hingewiesen, dass Marketingverantwortliche die Umstellung auf eine Headless-Architektur zumindest mit Blick auf die Pflege von Webauftritten oft weniger positiv bewerten als die IT [2].

Ob die Umstellung auf ein Headless CMS Sinn ergibt, hängt also nicht nur von der Perspektive der IT ab, sondern auch ganz wesentlich von den Anforderungen und dem Mindset der Redakteure. Eine Content-First-Strategie, bei der Gestaltungsfragen eine untergeordnete Rolle spielen, dürfte den Umstieg auf eine Headless-Architektur wesentlich erleichtern. Starke Argumente liefern natürlich auch PWAs oder die Bespielung mehrerer Seiten aus einem zentralen Repository. Geht es jedoch im Kern um einen einzelnen klassischen Webauftritt, dann ist es wenig sinnvoll, die gewonnene Gestaltungsfreiheit der Redakteure durch neue Technologien wieder einzuschränken.

Contentmanagement und Smart Devices

Ein weiteres Argument für die darstellungsneutrale Auslieferung und Verwaltung von Inhalten liefert der boomende Markt der Smart Devices. Voice Assistants, Smartwatches und andere Geräte werden die Anforderungen an das Contentmanagement nachhaltig verändern. Doch wie relevant wird welcher Kanal für welches Unternehmen in Zukunft werden? Und noch wichtiger: Welche Anforderungen stellen die Nutzer dann an die kanalspezifischen Inhalte? Wie genau soll beispielsweise eine Landingpage für eine Sprachinteraktion gestaltet werden und wie müssen Inhalte generell aufbereitet werden, damit sie wirklich sprechbar sind? Gerade beim Trendthema Voice ist die Frage der Contentaufbereitung bis heute noch recht nebulös.

Eine Verwaltung und Auslieferung von Inhalten unabhängig von ihrer Darstellung mag ein erster Schritt zu einer Lösung sein. Damit hat man jedoch noch keine zufriedenstellende Antwort auf die Frage gefunden, wie Inhalte innerhalb eines Contentmanagementsystems für alle relevanten Kanäle sinnvoll aufbereitet und organisiert werden können und welche Rolle dabei die Redakteure auf der einen Seite und die Entwickler auf der anderen Seite spielen sollen. Preston So hat die Herausforderung an moderne Contentmanagementsysteme sinngemäß damit beschrieben, dass das Verhältnis zwischen den Entwicklern und den Redakteuren auch in Zeiten unzähliger neuer Touchpoints ähnlich gut ausbalanciert werden muss, wie in der Web-only-Ära.

WordPress und das Indie-Web

Der allgegenwärtige Wandel ist groß. Allerdings sind die Auswirkungen nicht überall gleichermaßen spürbar. Der Modernisierungsdruck entsteht derzeit vor allem bei den großen Enterprisesystemen und wird absehbar auch beim Mittelstand und damit für die klassischen Agentursysteme wie Drupal oder TYPO3 stärker werden.

Etwas anders sieht die Situation bei der breiten Masse der kleineren Webauftritte und dem immer noch omnipräsenten WordPress aus. Zwar wird auch im WordPress-Umfeld fleißig mit neuen technischen Ansätzen experimentiert, allerdings lösen Trends wie die Headless-Architektur oder die Static-Site-Generatoren zumindest aus der Perspektive der WordPress-Anwender kaum ein wirklich relevantes Problem. Schon die schwierige Umstellung auf den Gutenberg-Editor hat gezeigt, dass sogar sinnvolle bzw. technisch notwendige Änderungen wie die Modernisierung der Frontend-Technologien und die Einführung einer flexiblen Contentmodellierung durch einen Blockeditor nicht uneingeschränkt auf Gegenliebe bei den Anwendern stoßen. Warum sollten gerade diese Anwender nun ihre gewohnte Eigenständigkeit gegen technisch herausfordernde Workflows oder SaaS-Angebote wie Gatsby Cloud eintauschen?

Das Erfolgsrezept von WordPress lag schon immer im Empowerment des normalen Anwenders und des technikaffinen Laien. Mit vergleichsweise einfachem Handling und Wandelbarkeit dank des riesigen Ökosystem bleibt WordPress für diese Nutzergruppe auch heute noch ohne Konkurrenz. WordPress mag zwar in mancher Hinsicht seinen Zenit überschritten haben und für viele Entwickler im Vergleich zu jungen Alternativen an Attraktivität zu verlieren, doch wie schwer es ist, WordPress trotz aller Mängel vom Thron zu stoßen, hat vor mehreren Jahren bereits das Node CMS Ghost erfahren. Einst als reines Blogsystem und gefeierte WordPress-Alternative gestartet, verabschiedet sich Ghost inzwischen vom reinen Blogkonzept und transformiert sich stattdessen zu einem Spezialanbieter für Journalisten und professionelle Publisher. Ähnlich sieht es mit den anderen Newcomern aus: Systeme wie Craft oder eben auch Statamic bieten neben modernster Technik und einer hohen Flexibilität auch einen Schaulauf für eine hervorragende Author Experience. Dennoch adressieren beide Systeme als primäre Zielgruppe erst einmal die Entwickler und bieten kaum bzw. gar keine fertigen Themes für den Eigengebrauch an. Vorhersagen sind in Zeiten des Wandels ein riskantes Unterfangen, doch es ist eher fraglich, ob sich diese Situation für die beschriebenen Nutzergruppen in fünf Jahren wirklich grundlegend gewandelt haben wird.

Zeit für Experimente

Für Entwickler ist es eine aufregende Zeit: Neue Ansätze wie die Headless-Architektur oder der JAMstack bringen Glamour und Experimentierlust zurück ins Spiel und junge Systeme präsentieren sich mit modernem Code und allem erdenklichen Komfort für die anspruchsvolle Entwicklung. Unternehmen stehen jedoch vor einer schwierigen Aufgabe: Sie müssen in einem unübersichtlichen und sehr dynamischen Umfeld Entscheidungen treffen, die sie voraussichtlich mehrere Jahre lang an eine Technologie bindet. Wie so oft dürfte die Rechnung bei radikalen Brüchen nur in den seltensten Fällen aufgehen. Besser ist es, im Rahmen kleinerer Projekte eigene Erfahrungen zu sammeln und mit den neuen Konzepten zu experimentieren. Auch hier kann die Vorgehensweise des SPIEGEL als Blaupause dienen: Das Medienhaus hatte zunächst mit Bento und SPIEGEL+ kleinere Webauftritte auf Statamic umgestellt und den Umstieg des zentralen Auftritts erst mit den gewonnenen Erfahrungen gewagt.