CX & CMS Teil 1/3 - Einführung in erfolgreiche CMS-Konzepte

ARITHNEA hat Mitte vergangenen Jahres im Rahmen einer großangelegten Studie gemeinsam mit dem Markforschungsinstitut Splendid ermittelt „Was Online-Kunden wünschen“. Und hier kamen unter anderen folgende Ergebnisse zustande: 75% der über 1.000 Befragten gaben an, sich vor allem auf der Produkt-Website beziehungsweise dem Online-Store selbst inspirieren zu lassen. 65% tun dies mit Hilfe von Amazon und nur 18% sagten aus, sich bezüglich neuer Produkte auf Online-Magazinen bzw. unabhängigen Portalen inspirieren zu lassen.

Schlussfolgerung: Nichts ist für das Onlinegeschäft so förderlich wie gute, erlebnisreiche Produktinformationen – und zwar direkt auf den eigenen Shop- und Webseiten.

Einführung in aktuell sehr erfolgreiche CMS-Konzepte

Googelt man heute nach modernen CMS-Ansätzen, kommt man an „Headless” nicht mehr vorbei. Auch die Begriffe „Decoupled“ und „Hybrid CMS“ werden häufig diskutiert. Die Auseinandersetzung mit dem Thema Headless und Co. ist dabei eher technisch und architekturgetrieben. Ich möchte im Folgenden die wichtigsten CMS-Alternativen und ihre Vor- und Nachteile erläutern, aber vorab noch einen kleinen Denkanstoß geben. Oder besser gesagt drei Argumente liefern, warum sich auch Marketer und Content-Spezialisten mit dem Thema auseinandersetzen und vor der Entscheidung für ein CMS die richtigen Fragen stellen sollten.

Denn die CMS-Architektur beeinflusst weit mehr als nur die IT-Infrastruktur eines Unternehmens:

1. Effizienz und Performance der Marketingabteilung

Mit welchen Systemen können und wollen wir arbeiten? Wie setzen wir sie sinnvoll ein und vor allem, wie vernetzen wir sie gewinnbringend?

2. Kosten und Geschwindigkeit von Innovationen

„Quick wins” oder zukunftssicheres Fundament? Was können wir kurzfristig erreichen? Was wollen wir langfristig erreichen, um zum Beispiel neue Touchpoints für bessere Experiences schnell hinzuzunehmen?

3. Agilität des gesamten Unternehmens

Ist unsere IT-Infrastruktur nur Cost-Center oder auch Process-Center, welches ermöglicht, Mensch und IT effektiv und agil zusammenarbeiten zu lassen?

Architektur fällt immer dann auf, wenn sie nicht (mehr) funktioniert. 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 Varianten an: Welche Ansätze gibt es? Was sind die Stärken und Schwächen und wann ist welche Architektur passend?

Varainte 1: 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, aber sind 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:

• in einziges Produkt „out-of-the-box” mit solidem Funktionsumfang
• Ist schnell einsatzbereit und 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)

Variante 2: Decoupled CMS

Moderne, entkoppelte CMS-Architekturen funktionieren auf den ersten Blick ähnlich, jedoch agieren hier Backend und Frontend deutlich unabhängiger. Das Grundgerüst bilden 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, das heißt hier werden Seiten oder Inhaltsfragmente zum Beispiel 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 Inhalteund 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. Developer 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 bringt seine Stärken genau bei den Schwächen des zuvor beschriebenen Konzeptes ein. 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 das auch immer 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 sich 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:

Zum Einsatz kommt ein Headless CMS vor allem dann, wenn man mehrere Kanäle bespielen will, beispielsweise 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 zum Beispiel integriertes Bearbeiten im Kontext der Live-Seite
• Reine Headless-Architektur schließt Tiefenintegration aus, das heißt zentrale Features von zum Beispiel Shopsystemen bleiben womöglich ungenutzt

Variante 3: 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 und einem reinen Headless CMS wählen muss. Man erhält mit einem hybriden Ansatz eine 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 nicht zuletzt eine Experimentierkultur im Unternehmen, mit der sich das Beste aus den unterschiedlichen Features, Daten und Inhalten herausholen lässt.

Im zweiten Teil der Serie erfahrt ihr, wie ihr mit e-Spirit und SAP Spartacus in Rekordgeschwindigkeit zur Experience gelangt.

Die Serie im Überblick

• Teil 1: Content in der Umsetzung - Einführung in aktuell sehr erfolgreiche CMS-Konzepte
• Teil 2: Wertvolle Synergieeffekte: Die Verbindung von e-Spirit mit SAP Spartakus
• Teil 3: Mehr Profitabilität im E-Commerce mit KI-gesteuerter Personalisierung