Navigation durch CMS-Architekturen über das Dreigespann aus Content, Frontend und Backend

27. Sept. 2023

Erfahren Sie, wie Content, Frontend und Backend eine zentrale Rolle beim Erstellen von Anwendungen mit Content-Management-Systemen (CMS) spielen

Beim Erstellen von Anwendungen mit Content-Management-Systemen (CMS) spielen drei wesentliche Bestandteile eine zentrale Rolle:

  • Content – Das sind die Inhalte, die Redakteure hinzufügen und anpassen – etwa Text, Bilder, Videos und mehr. 
  • Frontend – So erscheinen die Inhalte auf verschiedenen Kanälen, verwaltet von Frontend-Entwicklern mithilfe von Frameworks wie React oder Vue.  
  • Backend – Das ist die individuelle Funktionalität, die zum Erlebnis gehört und Dinge wie Bestellungen, Formularübermittlungen und Datenbankaktualisierungen verarbeitet, verwaltet von Backend-Entwicklern. 

Die drei Komponenten in einem gekoppelten CMS

In einer traditionellen gekoppelten CMS-Architektur sind diese Komponenten in der Regel zusammengebündelt. Der Content ist eng mit der Präsentationsschicht verknüpft, was es schwierig macht, denselben Content für andere Kanäle bereitzustellen.

Für Marketer ist dieser Ansatz für Websites attraktiv, weil das Frontend an den Content „gekoppelt“ ist, was das Bearbeiten von Webseiten einfach und schnell macht. Doch sobald der Bedarf entsteht, denselben Content auf anderen Kanälen auszuspielen, stoßen sie an eine Wand. Der Content, den sie die ganze Zeit bearbeitet haben, ist hinter den Kulissen mit HTML-Tags durchsetzt, die sich bei der Anzeige in mobilen Anwendungen nur schwer entfernen lassen.

Die drei Komponenten in einem entkoppelten CMS

Wichtig zu beachten ist, dass es einige Grade der Entkopplung gibt: eine, die zwischen den Komponenten einer Software entkoppelt, und eine andere, die zwischen völlig unterschiedlichen Systemen entkoppelt.

Hybrides CMS als entkoppeltes CMS

Sprechen wir zunächst über die erste Art der Entkopplung, die bei hybriden CMS verbreitet ist. Der Content ist zwar vom Frontend entkoppelt, aber beide befinden sich noch am selben Ort. Ermöglicht wird dies durch Softwarearchitekturen wie MVC (Model-View-Controller), die die Entkopplung von Komponenten innerhalb einer Anwendung unterstützen.  

Abbildung 1: Obwohl ein hybrides CMS Content, Frontend und Backend zusammenbündelt, sind sie nur lose gebündelt – ermöglicht durch Muster wie MVC –, damit Content von anderen Frontends und Microservices wiederverwendet werden kann 

Im obigen Architekturdiagramm befinden sich zwar alle Komponenten im CMS, doch die Integration ist lose, wodurch das Frontend optional wird und der Content für sich allein für die Darstellung in mehreren Modi verfügbar ist: Web (Standard), Mobile und Kiosk-Apps. Die Entkopplung erfolgt auf Softwareebene, nicht auf Lösungsebene, worauf wir als Nächstes näher eingehen. 

Was sind die Vorteile eines entkoppelten, hybriden CMS?

  • Einfachheit der Verwaltung – Auch wenn diese Sichtweise nicht auf jeden zutrifft, worauf wir später eingehen, bevorzugen manche Unternehmen, deren Kerngeschäft nicht Technologie oder Digitales ist, im digitalen Bereich tendenziell einen Ansatz mit einem einzigen Verantwortlichen. Sie behalten lieber schlanke Teams, die das Digitale verwalten können, und binden möglichst wenige Anbieter ein, die die größte Abdeckung bieten: Software, Infrastruktur und rund um die Uhr verwalteter Service mit SLA-Garantie. Sie wünschen sich Sorgenfreiheit ohne die Komplexität, es selbst zu verwalten.
  • Kosteneffizienz – Aufgrund des Ansatzes mit einem einzigen Verantwortlichen profitieren Organisationen oft von geringeren Gesamtbetriebskosten. Die Einbindung mehrerer Anbieter schafft nicht nur Komplexität in der täglichen Verwaltung des gesamten Stacks, sondern führt oft auch zu höheren Gesamtbetriebskosten, die Lizenzkosten mehrerer Anbieter, die Kosten für die Integration dieser Lösungen und die zusätzlichen Kosten für das Erlernen mehrerer Anbieter-Stacks umfassen. 
  • Benutzerfreundlichkeit für Marketer – Ein hybrides CMS bringt ein Frontend mit, allerdings in Form von Komponenten, die es Marketern ermöglichen, Erlebnisse per Drag-and-drop zu komponieren. Das ist wichtig hervorzuheben, weil dies bei Headless-CMS-Builds manchmal eingeschränkt oder den Marketern genommen wird, doch wir besprechen weiter unten Alternativen und Lösungen dafür.  

Für wen und welche Anwendungsfälle eignet sich ein entkoppelter, hybrider CMS-Ansatz?

Kleinere Digitalteams, die in voneinander abhängiger Arbeit versiert sind, profitieren vom All-in-One-Ansatz. Er ist auch ideal für einfachere Projekte wie Marketing- und Broschüren-Anwendungen, deren Hauptaufgabe es ist, Content über mehrere Kanäle hinweg an Konsumenten auszuliefern. Wenn dies Ihr Anwendungsfall ist, achten Sie darauf, Ihren Tech-Stack nicht überzudimensionieren, da die Vorteile die zusätzliche Komplexität womöglich nicht rechtfertigen. Konzentrieren Sie sich stattdessen darauf, wie Sie Ihre Marketer befähigen können, schneller zu agieren, große Mengen an Content zu bewältigen und personalisierte Botschaften an Endnutzer auszuliefern.

Was sind die Nachteile einer entkoppelten, hybriden CMS-Architektur?

Ein All-in-One-Ansatz spricht keine Unternehmen an, die größere Teams und qualifizierte Ressourcen haben und bessere Kontrolle über ihren Tech-Stack wünschen. Hier sind die Nachteile: 

  • Technologische Einschränkungen bei Frontend und Backend – Trotz der besprochenen Entkopplung müssen Frontend und Backend letztlich weiterhin mit dem CMS bereitgestellt werden, was Grenzen innerhalb der beiden Komponenten schafft: 
  • Backend – Ihre Entwickler müssen die Backend-Programmiersprache verwenden, auf der Ihr CMS aufgebaut ist, etwa Java oder .NET. Die Programmiersprache und die passenden Ressourcen werden zu einem großen Faktor, wenn Sie sich für eine hybride CMS-Architektur entscheiden. 
  • Frontend – Sie haben zwar Flexibilität bei der Wahl des Frontend-Frameworks, doch es wird einige Einschränkungen rund um clientseitiges Rendering und Static-Site-Generierung geben, die das CMS möglicherweise nicht bieten kann. Klären Sie daher am besten mit Ihrem CMS-Anbieter, wo diese Grenzen liegen. 
  • CMS-Upgrades können schwierig, langwierig und kostspielig werden – Weil Frontend und Backend weiterhin mit dem CMS leben, schreiben Entwickler unter Umständen Code mit engen Abhängigkeiten von der CMS-Version. Entwickler müssen sicherstellen, dass sie die CMS-Entwicklungs-Erfolgsmethoden befolgen, um langwierige und kostspielige Arbeit bei Upgrades zu vermeiden. 

Wie Sie sehen werden, handelt es sich um Engineering-Probleme, die Welleneffekte in der Organisation auslösen können. Gibt es eine bessere Lösung? 

Entkoppeln Sie die drei Komponenten mithilfe einer Headless- und Microservices-Architektur.

Wie wir nun von oben verstehen, sind nicht alle entkoppelten CMS headless. Jedes Headless-CMS folgt jedoch einem entkoppelten Ansatz – einer Entkopplung auf höherer Ebene (zwischen Softwaresystemen) im Gegensatz zu einer Ebene innerhalb der Softwarearchitektur.

Um die Probleme einer hybriden CMS-Architektur zu lösen, begannen Entwickler, den Verantwortungsbereich des CMS zu reduzieren und letztlich Frontend und Backend vollständig aus dem CMS zu entfernen. Das verringert die Verantwortung des CMS-Anbieters und gibt Entwicklern volle Flexibilität bei Frontend und Backend, da diese beiden Komponenten nun extern verwaltet werden.  

Was sind die Vorteile eines Headless-CMS-Ansatzes?

  • Maximale Flexibilität für Entwickler – Wenn die Frontend- und Backend-Komponenten aus dem CMS herausgelöst werden, sind dem im Grunde keine Grenzen mehr gesetzt. Entwickler haben völlige Wahlfreiheit bei Frontend-Frameworks, Backend-Programmiersprache, DevOps und dem Hosting clientseitiger Anwendungen.
  • Kürzere Einarbeitungszeit für neue Entwickler – Weil das wichtigste Integrationsmuster über standardisierte APIs läuft, ist die Einstiegshürde niedriger, und daher haben neu ins Team aufgenommene Entwickler eine kürzere Einarbeitungszeit.
  • Engineering kann schneller auf den Markt gehen – Mit einer vollständigen Trennung von Frontend und Backend vom CMS können Frontend-Entwickler unabhängig von Backend-Entwicklern arbeiten, was Welleneffekte im Engineering auslöst. Das Team kann schneller auf den Markt gehen, Upgrades werden schneller und Entwickler sind weniger vom CMS-Anbieter abhängig.

Für wen und welche Anwendungsfälle eignet sich ein Headless-CMS-Ansatz?

Größere Engineering-Teams, die bessere Kontrolle und Verwaltung ihres Tech-Stacks bevorzugen, würden diesen Ansatz vorziehen. Anwendungen, die komplexe Frontend-Funktionalität oder bidirektionale Interaktivität erfordern, etwa E-Commerce- oder transaktionsintensive Anwendungen, profitieren von diesem Ansatz. Die zusätzliche Komplexität der Verwaltung mehrerer Komponenten wird durch die zusätzliche Kontrolle und Flexibilität gerechtfertigt, die Ingenieure aus einer Headless- und Microservices-Architektur gewinnen. 

Was sind die Nachteile eines Headless-CMS-Ansatzes?

  • Erhöhte Komplexität und Verantwortung für das Engineering – Weil Frontend und Backend nicht mehr im CMS leben, müssen Engineering-Teams nun neue Infrastruktur bereitstellen und verwalten, um diese Komponenten zu hosten, Integrationen erstellen und DevOps verwalten, um diese Komponenten zu verbinden, und sicherstellen, dass SLAs weiterhin gelten – einschließlich der zusätzlichen Anbieter im Mix. Für die oben besprochenen einfacheren Anwendungsfälle kann ein überdimensionierter Tech-Stack Sie sogar ausbremsen. Wenn Ihr Anwendungsfall jedoch erhebliche Entwicklungsarbeit erfordert und Sie über die richtigen Engineering-Ressourcen verfügen, ist die erhöhte Komplexität für bessere Kontrolle gerechtfertigt. 
  • Höhere Gesamtbetriebskosten (TCO) – Aufgrund der zusätzlichen Komponenten, die von anderen Anbietern lizenziert werden müssen, etwa zusätzliche Hosting-Lizenz und SLA, sowie der Kosten für deren Integration, wird ein Anstieg der Gesamtbetriebskosten erwartet. Die zusätzlichen TCO können jedoch ausgeglichen werden, wenn dies Effizienzen innerhalb der Engineering-Abteilung erzeugt. 
  • Die WYSIWYG-Erfahrung der Marketer kann eingeschränkt werden – Headless-CMS-Anbieter ermöglichen es Redakteuren zwar, Content zu verwalten, doch reine Headless-CMS-Anbieter lösen designbedingt nicht die Fähigkeit, das Erlebnis zusammenzustellen. Entwickler müssen diese Fähigkeit einbauen oder mit anderen Softwareanbietern integrieren, um WYSIWYG-Fähigkeiten zurückzubringen und sicherzustellen, dass das Marketing-Erlebnis nicht beeinträchtigt wird. 
Fazit ...

Wie bei allem Technologiebezogenen gibt es kein Einheitsmodell, das für alle passt. Die Wahl der richtigen CMS-Architektur hängt von der Projektkomplexität, der Teamgröße und den Kompetenzen sowie dem gewünschten Gleichgewicht zwischen Einfachheit, Kosten und Kontrolle ab. Die Entscheidung muss letztlich mehrere Stakeholder berücksichtigen: das Engineering für den Build, das Marketing für die Content-Authoring-Erfahrung und das Business für die Gesamtbetriebskosten.

Optimizely CMS unterstützt beide Entkopplungsmethoden: hybrid oder rein headless. In meinem nächsten Artikel werde ich über das neu eingeführte Optimizely Graph-Angebot schreiben, das unser API-Angebot erweitert, um Effizienzen in der Softwareentwicklung zu schaffen – bleiben Sie also dran.