EIN SYSTEM, ZWEI KOMPONENTEN!? Headless
CMS und Pagebuilder
In diesem Whitepaper beleuchten wir speziell die Rolle des Headless CMS und des Pagebuilders in einer modernen Composable Architektur.
HEADLESS CMS UND PAGEBUILDER
Headless, API-driven und Composable
Commerce
In der modernen Webentwicklung sind die Themen „Headless“ und „API-driven“ allgegenwärtig, meist vereint unter der Überschrift „Composable Commerce“ oder „MACH“ (Microservices, API-first, Cloud-based, Headless). Hinter diesen Buzzwords verbirgt sich das vertraute Best-of-Breed-Konzept, bei dem Software-Komponenten verschiedener Anbieter zu einer optimalen Content-&-Commerce-Lösung zusammengeführt (composed) werden. Im Composable-Commerce-Konzept werden kleinere funktionale Module wie Suche, Facettenfilter, Warenkorb, Checkout miteinander kombiniert. Diese Module nennt man „PBC“ (Packaged Business Capabilities), sie werden technisch als Microservices auf Basis ihrer APIs miteinander verbunden. Da als API Webstandards verwendet werden, können die einzelnen Services in unterschiedlichen Umgebungen laufen, auch in der Cloud des Anbieters selbst („SaaS“ - Software as a Service). Dabei haben die einzelnen Microservices selbst kein Frontend, sie sind somit „Headless“.
Vorteile des Composable Commerce mit Headless und API-driven
Wie bei allen modularen Konzepten ergeben sich die Vorteile des „Composable Commerce“ einerseits im Gegensatz zu „monolithischen“ Lösungen und andererseits zu kompletten Individuallösungen. Monolithen, also All-in-one-Standard-Lösungen zu überschaubaren „Listenpreisen“ sind leicht konfigurierbar aber schlecht individualisierbar; Individuallösungen bieten dagegen alle Freiheiten, sind aber sehr aufwendig zu implementieren und zu pflegen. Modulare Lösungen liegen in der Mitte: die Integration der Module ist aufwendiger als die Konfiguration einer Komplettlösung aber einfacher als eine Individualentwicklung. Zudem bietet die Modularität den Vorteil der Flexibilität, da einzelne Module austauschbar sind, so dass nicht für alle Module bereits zum Start die maximale Variante vorliegen muss.
In der Realität nähern sich Monolithen und Composable/HeadlessLösungen pragmatisch an. Kaum jemand wählt für jedes einzelne Modul einen eigenen Anbieter aus, sondern wählt Systemkomplexe, die man auch als Monolithen kennt, wie ein Content Management System. Dabei stellt das Headless-System anders als der Monolith die Funktionen seiner Module per API zur Verfügung, so dass man Module verschiedener Systeme auf der API-Ebene miteinander verbinden kann. Diese Entwicklung in der Softwarebranche findet von zwei Seiten statt: einerseits werden bekannte monolithische System zunehmend auch API-driven angeboten, andererseits bieten Hersteller von ursprünglichen API-driven-Systemen immer mehr bereits zueinander passende Module an, die zusammen den Umfang eines monolithischen Systems bieten.
Daher stellt sich bei der Systemauswahl die Frage, ob und wieweit sich die Anforderungen stärker in Richtung Flexibilität und Individualisierbarkeit bewegen. Da beim Composable-Commerce durchweg APIdriven Module ausgewählt werden, stellt sich diese Frage auch mit Blick auf diese: sind diese Module ausreichend anpassbar und mächtig und damit flexibil und individualisierbar oder sind sie eher Teil eines weniger mächtigen und weniger flexiblen Baukastens?
Diese Fragestellung soll in diesem Whitepaper anhand der Komponenten CMS und Pagebuilder diskutiert werden.
HEADLESS CMS UND PAGEBUILDER
Exkurs: SaaS und Cloud
In diesem Zusammenhang soll auch das Thema Open-Source vs. Closed-Source, Hosting und SaaS kurz angerissen werden. Selbstgehostete Open-Source-Module - in der Cloud oder on premise - sind in Funktionen und Schnittstellen frei anpassbar und bieten so den höchsten Individualisierungsgrad, während Closed-Source-Lösungen wie auch SaaS-Module, die vom Hersteller in dessen Cloud gehostet werden, unabänderlich „as is“ nur die Funktionen und Schnittstellen bieten, die der Hersteller vorgesehen hat. SaaS-Lösungen sind jedoch umfassend getestet, Mängel die bei einem Kunden erkannt werden, werden sofort für alle behoben. Die Kosten für SaaS-Systeme sind dabei tendenziell hoch und meist nur gerechtfertigt, wenn alle enthaltenen Komponenten auch genutzt werden. Dass dies nicht immer sinnvoll ist, wird im Folgenden aufgezeigt.
Ein Vorteil auf der SaaS-Seite liegt auch bei der Vollverantwortung des Herstellers für Betrieb und Wartung, während flexiblere Lösungen selbst oder durch Dritte gehostet und gewartet werden müssen (was auch dritte Cloudanbieter wie AWS, Azure, Google etc. einschließt). Risiken bei SaaS liegen jedoch bei der Performance, es gibt keine Garantie, dass eine SaaS-Lösung, welche via Schnittstellen angebunden ist immer ausreichend „performt“. Insbesondere kann die Behebung von derartigen Engpässen mangels eigenem DevOps-Ansprechpartner langwierig sein. Hier kann ein unabhängiger Betrieb - ob on premise oder in der eigenen Cloud, auch einer gemieteten, von Vorteil sein, da hier je nach Service-Level auf der DevOps-Ebene schnell und pragmatisch agiert werden kann.
Zudem wird bei SaaS jedes Release mitgenommen, Änderungen z.B. an Schnittstellen werden daher sofort wirksam ohne dass Testing oder ein Rollback nach eigenem Ermessen im Problemfall möglich sind. Die flexibelste Kombination stellt Open-Source in einer Cloud mit schnell verfügbarem DevOps dar. Ob diese Kombination für alle Komponenten optimal ist, wird im Folgenden behandelt. Vorab sei schon die Tendenz erwähnt, dass für Standard-Komponenten zum Datenmanagement wie CMS, PIM, MAM Closed-Source und SaaS-Lösungen weniger probematisch sind, während bei Integrationskomponenten tendenziell Flexibilität und Anpassbarkeit im Vordergrund stehen.
HEADLESS CMS UND PAGEBUILDER
Headless CMS: Content-Repository mit redaktionellem
Backend
Der Begriff „Headless“ scheint zuerst ein negativer: die so bezeichnten Systeme und Module haben keinen „Head“, das heißt die entsprechenden Module stellen nur ihre Funktionen und Content über ihre API zur Verfügung. Wie die Inhalte und Funktionen dem Nutzer zur Verfügung gestellt werden, bleibt einem gesonderten Frontend-Layer überlassen. Ein Headless-CMS bringt somit alle Module mit, die zur Erstellung und Management redaktionellen Contents erforderlich sind, einschließlich eines Backends für Redakteure - jedoch keine Möglichkeit, die Inhalte zusammenzufügen, mit anderen Inhalten zu mischen, zu strukturieren und im gewünschten Design darzustellen, Rollen und Rechte für Nutzer festzulegen etc.
Ein Headless-CMS trennt somit das Backend, in dem Inhalte erstellt und verwaltet werden, vom Frontend, wo diese Inhalte angezeigt werden. Diese Trennung ermöglicht es Entwicklern, Inhalte über APIs bereitzustellen und auf verschiedenen Plattformen und Geräten zu nutzen, wie Websites, mobile Apps und IoT-Geräte. Die Hauptvorteile eines Headless-CMS sind:
• Ausgabeneutralität: Inhalte können problemlos auf verschiedenen Plattformen und Geräten angezeigt werden.
• Kombinierbarkeit: die redaktionellen Inhalte können mit anderen Inhalten (wie Produktinformationen) im Frontend kombiniert werden (auch mehreren verschiedenen Frontends wie Online-Katalog, Website, Shop, Sales App oder Web2Print).
• Technologieoffenheit: Entwickler können das Frontend unabhängig vom CMS mit beliebigen Technologien gestalten, auch mehreren für verschiedene Frontends.
• Skalierbarkeit: Infrastruktur-Skalierung ist einfacher möglich und besser an die Gegebenheiten anpassbar, z.B. mehrere CMS/ Frontend-Instanzen bei hohen Lasten/Zugriffen.
• Unabhängigkeit: Das Backend ist nicht an ein bestimmtes Frontend gebunden, was die Anpassung und Erweiterung erleichtert. Server und Infrastruktur können für Frontend und CMS unabhängig voneinander optimiert werden. Bspw. Frontend auf Performance & Skalierbarkeit, CMS auf Benutzerfreundlichkeit & Sicherheit.
Ein scheinbarer Nachteil ist die Notwendigkeit, den Content „API-fähig“ zu gestalten. Da die Formatierung erst im Frontend erfolgt, entspricht eine Formatierung im Backend nicht zwingend der Darstellung im Frontend, wie die Inhalte dann „wirklich“ aussehen, entscheidet erst das Frontend.
Dieser scheinbare Nachteil wird jedoch dadurch ausgeglichen, dass das separate Frontend wieder in das Backend „zurückintegriert“ wird und so in Realtime die erstellten Inhalte formatiert anzeigt, so dass mit der Realtime-Preview sofort das Ergebnis der Datenpflege kontrollierbar ist.
Technische Details zu Headless CMS
• API-First Ansatz: Ein Headless-CMS verwendet APIs (RESTful oder GraphQL), um Inhalte bereitzustellen. Dies ermöglicht eine einfache Integration mit verschiedenen Frontend-Technologien wie React, Vue. js oder Angular.
• Microservices-Architektur: Viele Headless-CMS sind zudem als Microservices aufgebaut, was eine bessere Skalierbarkeit und Wartbarkeit ermöglicht.
• Wartung und Pflege: Diese ist bei solcherart entkoppelter Systeme bedeutend einfacher und pflegeleichter. Updates (Major/Minor) lassen sich z.B. viel besser einspielen, da kaum Abhängigkeiten bestehen und somit wenig bis gar kein Individualcode migriert werden muss.
• Content Modeling: Benutzer können komplexe Inhaltsmodelle erstellen, die genau auf ihre Bedürfnisse zugeschnitten sind. Dies umfasst die Definition von Inhaltstypen, Feldern und Beziehungen zwischen Inhalten.
• Sicherheit: Headless-CMS bieten oft erweiterte Sicherheitsfunktionen wie rollenbasierte Zugriffskontrolle, Zwei-Faktor-Authentifizierung und regelmäßige Sicherheitsupdates.
• Performance: Headless CMS-Websites haben aufgrund der State-of-Art-Technologien in der Regel sehr kurze Ladezeiten und ermöglichen durch den Einsatz entsprechender Frontend Technologien verbesserte User Experience (UX) sowie Suchmaschinen-Ranking.
HEADLESS CMS UND PAGEBUILDER
Page- und Sitebuilder: Der benutzerfreundliche Website-Baukasten
Funktionen des Page- und Sitebuilders
Da ein Headless-System keine Komponenten dafür bietet, die Inhalte zusammenzufügen, mit anderen Inhalten zu mischen, zu strukturieren und im gewünschten Design darzustellen, Rollen und Rechte für Nutzer festzulegen etc., muss dies durch andere Systeme erfolgen. Für den Redakteur ist die wichtigste Komponente hierfür der Page- und Sitebuilder.
Ein Page- und Sitebuilder ist ein Tool, das es ermöglicht, Pages und Websites ohne Programmierkenntnisse aus Content verschiedener Quellen zu erstellen - insbesondere aus Content von HeadlessSystemen via API (die Hersteller verwenden meist nur einen der Begriffe für ihr Produkt, „Pagebuilder“ oder „Sitebuilder“, auch „Visual Editor“ u.ä.). Mit der Drag-and-Drop-Oberfläche und vorgefertigten Templates des Page- und Sitebuilders können Redakteure schnell und einfach Websites gestalten: einzelne Seiten mit redaktionellen Inhalten, Seitentypen für automatisch generierte Inhalte wie Produktseiten, kombinierte Pages mit CMS- und Drittinhalten - wie Produktdaten. Dabei können auch funktionale Elemente platziert werden, wie Suchfelder, Filterelemente, Warenkorbfunktionen, Navigationselemente etc. Wo nötig können auch direkt Inhalte im Builder ergänzt werden. Ebenso wird die hierarchische Struktur der Website mit dem Page- und Sitebuilder gemanagt. Weiterhin können Metadaten ergänzt werden, um z.B. zu steuern, welche Userrollen Zugriff auf die Inhalte und Funktionen haben. Auch ist hier ein Realtime-Previewing möglich, um die erstellten Pages bei der Bearbeitung zu sehen, bevor diese live gehen, ergänzt um ein entsprechendes Staging für die gesteuerte Liveschaltung von Pages etc.
Der Frontend-Layer greift dann auf die Inhalte, Strukturen und Funktionen zu, die im Page- und Sitebuilder zusammengestellt wurden und erzeugt mit HTML, CSS und Javascript die gewünschten formatierten Darstellungen und Funktionen der Website für die Besucher. Hinsichtlich der Vorteile ist der Page- und Sitebuilder komplementär zum Headless-CMS, er verbindet Content zu Strukturen und gibt sie an das Frontend weiter.
Page- und Sitebuilder mit Atomic Design Aus dieser Architektur ergibt sich, dass die Inhalte im CMS erzeugt, im Page- und Sitebuilder zusammengestellt und im Frontend-Layer formatiert werden. Diese „Schichten“ tauschen sich über ihre APIs aus. Daraus ergibt sich die Notwendigkeit, die verschiedenen Schichten strukturell so zu konfiguieren, dass sie miteinander nahtlos funktionieren. Ein Element, das im CMS vorhanden ist, aber dem Page- und Sitebuilder und dem Frontend-Layer unbekannt ist, wird nicht oder nicht wie gewünscht dargestellt. Dies gilt umso mehr, desto komplexer oder funktionsreicher dieses Element ist. Um diese konsistente Konfiguration zu ermöglichen, stehen entsprechende konzeptionelle und technologische Methoden zur Verfügung. Diese ist vor allem die AtomicDesign-Methode, die von der fachlichen Konzeption, der grafischen Gestaltung bis zur technischen Umsetzung greift: der konsistente Aufbau aller Elemente auf einer gemeinsamen Basis vom kleinsten „Atom“ bis zum komplexen „Organismus“ .
HEADLESS CMS UND PAGEBUILDER
Page- und Sitebuilder:
Der benutzerfreundliche Website-Baukasten
CMS-spezifische vs. autarke Page- und Sitebuilder Um diese konsistente Implementierung zu vereinfachen, bringen große Headless-CMS-Systeme teils ihre eigenen Page- und Sitebuilder samt Frontend SDK mit. Diese sind spezifisch auf die API des CMS, typische reaktionelle Content-Elemente und CMS-Funktionen ausgerichtet. Dabei wird die spezifische Integration teils soweit getrieben, dass der Page- und Sitebuilder auch die Funktion des Frontend-Editings („Visual Builder/Editor“) ermöglicht, d. h. man kann den Content direkt im Frontend-Layout bearbeiten und formatieren. Diese spezifischen Page- und Sitebuilder sind dann sinnvoll, wenn das CMS und der redaktionelle Content im Mittelpunkt stehen, aber Inhalte, Daten und Funktionen aus Drittsystemen wie PIM, MAM/DAM oder Webshop nur punktuell und mit überschaubarer Komplexität eingemischt werden. Hierbei wird in der Regel der Content dritter Systeme über das CMS zum Page- und Sitebuilder „durchgeschleift“ und kann in diesem positioniert werden, oder es wird mit Platzhaltern gearbeitet, indem im CMS auf dritte Content-Elemente referenziert wird, die erst vom FrontendLayer abgerufen werden.
Sobald Inhalte aus weiteren Systemen gleichberechtigt in der Website verwendet werden sollen, kommen CMS-spezifische Page- und Sitebuilder an ihre Grenzen. Die besonderen Funktionen, die sie bieten, sind nur für redaktionellen Content aus dem CMS verfügbar, während sie nur eingeschränkte Gestaltungsmöglichkeiten für komplexe Inhalte oder gar funktionelle Komponenten aus anderen Systemen bieten. Daraus ergibt sich eine inkonsistente Usability, suboptimale Darstellung und stark eingeschränkte Funktionalität. Dies gilt insbesondere, wenn redaktionelle Inhalte mit Drittinhalten wie dynamisch abgerufenen Produktinformationen und Drittfunktionen wie „In den Warenkorb“, Filtern oder gar Konfiguratoren kombiniert werden sollen.
Ist also die beabsichtigte Breite und Tiefe der Integration groß - wie bei Architekturen mit PIM-Systemen oder B2B-E-Commerce mit vielen Funktionen, Märkten, Sprachen, Rollen und Rechten - , sollte für Komponenten mit integrativen Funktionen auf flexible und individualisierbare autarke Lösungen gesetzt werden. Um mit Content, Metadaten, Funktionen und Strukturen aus verschiedenen Systemen samt darüberliegender Steuerungsschichten wie Rollen- und Rechtemanagement oder systemübergreifende Suche adäquat umgehen zu können, müssen integrative Komponenten wie Page- und Sitebuilder oder FrontendLayer an mehrere Systeme gleichermaßen anpassbar sein, bis hin zur funktionalen Erweiterung. Auch die Auswechselbarkeit von Komponenten nur wird durch mächtige autarke Integrationskomponenten gewährleistet: Ein Austausch einer datenliefernden Komponente - z.B. eines SaaS-CMS - darf nicht den Austausch von Integrationskomponenten erzwingen. Dies würde die Nachteile von monolithischen Lösungen wieder in die Composable-Welt übertragen. Nicht zuletzt wird durch autarke Page- und Sitebuilder auch eine übergreifende und einheitliche Usability für Content aus allen Quellen ermöglicht.
HEADLESS CMS UND PAGEBUILDER
Fazit: Flexibilität und Individualisierbarkeit vs. systemspezifischer Komponenten
An diesem Beispiel wird deutlich, dass die Frage ob und wieweit sich die Anforderungen stärker in Richtung Flexibilität und Individualisierbarkeit oder systemspezifischer Komponenten bewegen, nicht für alle Komponenten pauschal beantworten lässt. Während die Nutzung eines Headless-CMS als Content-Repository in Form einer SaaS-Lösung eher unproblematisch ist, da dieses „nur“ den redaktionellen Content zur Verfügung stellt, kommt es bei Komponenten mit integrativen Funktionen wie Page- und Sitebuilder und Frontend-Layer auf die Breite und Tiefe der Integration der Gesamtarchitektur an: ist sie gering, spielen systemsspezifische Integrationskomponenten ihre Stärken aus, ist sie hoch, sollten individualisierbare und mächtige autarke Integrationslösungen zum Einsatz kommen.
FRAGEN? DANN SPRECHEN SIE MICH AN.
ALEXANDER PIRCHER
Geschäftsführer infolox GmbH, Bregenzer Str. 101, 88131 Lindau am Bodensee alexander.pircher@infolox.de +49 8382 / 27 58 94 - 3