Stolpersteine bei der CMS-Architektur

Ein Artikel von Susanne Koch, Senior Consultant bei Adesso SE im Bereich Insurance. | 06.07.2021 - 11:28

Digitaler Content ist Dreh- und Angelpunkt eines Versicherers. Umso wichtiger ist die Auswahl der Architektur, die insbesondere die Time-to-Market beeinflusst. Zum einen bestimmt die Architektur wie effizient Redakteure Inhalte bearbeiten und veröffentlichen können. Zum anderen wirkt die Architektur-Auswahl unmittelbar darauf ein, wie schnell neue Ausgabekanäle bespielt werden können und wie flexibel das CMS mit anderen Systemen interagiert. 

Daher umso wichtiger vor einem Launch oder Relaunch Prioritäten, im Sinne von kurz- und langfristigen Zielen, abzustecken. Denn Architektur tritt in der Regel erst zum Vorschein, wenn Grenzen erreicht werden – sei es im Falle von Performance-Problemen, wenn eine neue Lösung nicht integriert werden kann oder wenn Kosten zur Pflege von immer mehr Medien oder Kanälen explodieren.

Gekoppeltes CMS

Gekoppeltes CMS.JPG

Beispiel für ein gekoppeltes CMS. © Adesso SE

Ein gekoppeltes CMS besteht aus einem Backend und dem damit fest verbundenen Frontend. Das Backend muss verfügbar sein, damit Seiten ausgeliefert werden können. Jeglicher Content und digitale Dateien werden im Backend erstellt, gespeichert und gesteuert. Das Frontend zieht sich alle Inhalte aus dem Backend (Content, Bilder, Dokumente UND Designs) und stellt diese auf einer HTML-Seite zur Verfügung. 

Vorteile sind hier, dass ein solides Setup für den Start eines spezifischen Kanals (in der Regel für eine Website) möglich ist, dieser ohne hohen Integrationsaufwand schnell einsatzbereit ist und dass die Benutzerfreundlichkeit hier im Vordergrund steht. Nachteile sind, dass ein gekoppeltes CMS nur schwer skalierbar ist, da Backend und Frontend miteinander verbunden sind und nur zusammen skaliert werden können, wenn beispielsweise der Traffic zu hoch wird. Daher ist es auch nicht optimal für Mehrkanal-Szenarien geeignet da die Ausgabe (Inhalt und Design) nur im definierten Format (in der Regel der Website) erfolgt. 

Headless CMS

Headless CMS.JPG

Beispiel für ein Headless CMS. © Adesso SE

Ein Headless CMS besteht aus einem Backend, einer Datenbank und einem Application Programming Interface (API), das die Komponenten verbindet. Bei einem Headless CMS ist das Frontend komplett vom Backend getrennt. Der Redakteur arbeitet im Redaktionssystem und pusht Inhalte in eine Datenbank.

Damit werden die Seiten, und damit nur die Inhalte, in der Datenbank abgelegt und bereitgestellt. Das Frontend, auch Progressive Web App (PWA) oder Single Page Application (SPA) in diesem Fall genannt, ist eine eigene Applikation und pullt die Inhalte über eine API aus der Datenbank. In der Frontend-Applikation wird die gesamte User Experience definiert und erfolgt absolut getrennt von der Entwicklung des CMS-Backends. Wohingegen das CMS-Backend sich komplett auf die typischen Backend-Funktionalitäten konzentriert – ohne dabei die Präsentation (das Design) der Inhalte festzulegen. 

Vorteile sind hier, dass ein Headless CMS hoch flexibel ist, da Back- und Frontend komplett voneinander getrennt sind und Entwickler sich „nur“ um die UX im Frontend kümmern müssen. Durch die gute Skalierbarkeit ist ein Headless CMS bestens für Mehrkanal-Szenarien geeignet, so dass unendlich viele Frontend Applikationen angebunden werden können. Hierzu zählen beispielsweise jegliche Endgeräte der Kategorie Internet of Things (IoT). Diese Flexibilität macht jedoch Setup und Betrieb komplexer und bietet weniger Komfort für den Redakteur, da zum Beispiel eine Vorab-Ansicht nicht ohne weiteres möglich ist und auch Templates nicht zwingend zum Einsatz kommen.

Hybrides CMS

Hybrides CMS.JPG

Beispiel für ein hybrides CMS. © Adesso SE

Ein hybrides CMS kombiniert den gekoppelten mit dem Headless-Ansatz. Wie bei einem Headless CMS besteht auch ein hybrides CMS aus einem Backend, einer Datenbank und einer API, die die Komponenten verbindet. Die Auslieferung ist entkoppelt. Der wesentliche Unterschied zu einem Headless System besteht darin, dass das Backend ein Enterprise System ist und so der Redakteur alle benutzerfreundlichen Aspekte, wie z.B. Templates, Benutzerverwaltung und Vorab-Ansicht genießt. Parallel haben die Entwickler volle Freiheit in der Frontgestaltung. Wenn neue Ausgabekanäle angeschlossen werden, können alle Inhalte aus dem Backend genutzt werden und über Push und Pull auf die neue Frontend Applikation transferiert werden. Hier wird das Beste aus zwei Welten kombiniert. 

Fazit: Drum prüfe wer sich bindet

Susanne Koch.jpg

Autor: Susanne Koch ist Senior Consultant bei Adesso SE im Bereich Insurance. Sie verfügt über umfangreiche Kenntnisse der Versicherungsbranche und verantwortete im Speziellen als Projektleiterin den Relaunch eines Extranets eines großen deutschen Versicherers. 

Der Bedarf an digitaler Informations-Bereitstellung und Nutzung von Self-Services ist größer als je zuvor. Die Digitalisierung verschärft diesen Bedarf zunehmend: die Anzahl an Internet-Nutzern steigt und damit auch die Nachfrage, Informationen online abzurufen - jederzeit und überall, auf möglichst jedem erdenklichen Endgerät. Gut aufbereitete und verständliche Informationen, des oft komplexen und erklärungsbedürftigen Produktes Versicherung, sind hierbei geradezu obligatorisch. Denn auch wenn ein CMS nicht zu den Kernversicherungssystemen gehört, so ist es als erfolgskritisch einzustufen, da es erheblichen Einfluss auf Image und Umsatz eines Versicherers hat. 

Daneben sind die Anforderungen von Besuchern an die funktionale Bedienbarkeit des Frontends sowie die Anforderungen von Redakteuren und IT an die Benutzerfreundlichkeit des Tools extrem vielseitig und vielschichtig. Die Forderung einer kürzeren Time-to-Market, sei es von Redakteurs-oder Entwickler-Seite, potenziert den Bedarf zusätzlich. Umso wichtiger, vor einem Launch oder Relaunch, die Anforderungen der einzelnen Stakeholder detailliert zu erörtern und im Anschluss konkrete Ziele an ein CMS zu definieren. 

Erst dann sollte, gemäß dem Spruch „Drum prüfe wer sich bindet“, eine Entscheidung für eine Architekturform und für einen Produktanbieter eines Content-Management-Systems getroffen werden. Nur so lässt sich eine vollumfängliche Zufriedenheit aller Stakeholder erreichen.