Buzzword Bingo –
Headless Software Architektur

Nicht mehr topaktuell, allerdings immer noch sehr stark im täglichen Tech-Buzzword-Bingo vertreten, wenn es um den Aufbau neuer Plattformen geht: „Headless“ oder besser „Headless Software“. Nachdem zuerst „kopflose“ Content Management Systeme die Bühne betreten haben, wird mittlerweile auch das Thema „Headless Commerce“ immer heißer. Dieser Artikel bezieht sich primär auf den Bereich der Content Management Systeme und möchte aufklären, was sich hinter all dem Zauber verbirgt und versuchen eine erste Entscheidungshilfe für die Auswahl eines passenden CMS zu geben.

Um die unterschiedlichen Technologieansätze vergleichen zu können, kommen wir allerdings an einer kurzen Einführung in das Thema Softwarearchitektur nicht vorbei:

Denn wenn man nun das Backend des CMS als Body und das Frontend als Head identifiziert, wird klar, worin der ganze „Zauber“ eines „Headless“ CMS liegt: Ihm wurde der Kopf entfernt.

Damit ein System wirklich „Headless“ betrieben werden kann, müssen alle notwendigen Content-APIs vollständig definiert und architektonisch auch dementsprechend gebaut worden sein. Dadurch wird sichergestellt, dass jede Art von Frontend bzw. Darstellungsoption an das System angebunden werden kann.

Änderungen des Frontend-Layouts an einem klassischen, monolithischen CMS (einem System mit einem vollständig verbundenen Front- und Backend) erfordern normalerweise Änderungen am gesamten System. Das liegt daran, dass Frontend und Backend eng miteinander verflochten sind.

Headless-Systeme lösen dieses Problem, indem Frontend und Backend separat geändert, verwaltet und sogar gehostet werden können. Diese Systeme eignen sich auch perfekt für den Start von Omnichannel-Kampagnen, da jeder Frontend Kanal separat mit dem Backend verbunden werden kann.

Sie sind auch meist auf Skalierbarkeit ausgelegt, da das System bei Bedarf in dem betroffenen Bereich (Tier) inkrementell erweitert werden kann, um einer höheren Nachfrage gerecht zu werden.

Man erreicht also eine maximale Flexibilität, die bei den heutigen technologischen Anforderungen auch nötig ist. Diese Flexibilität hat allerdings auch ihren Preis: Jeder Frontend Kanal muss eigens konzipiert und gebaut werden, sofern er nicht schon vorhanden ist.

Wenn nun aber der Hauptnutzen des CMS primär zum Ausspielen von Content als responsive Website für Desktop, Tablet und Smartphone gedacht ist, gibt es aber auch die Möglichkeit, nicht komplett kopflos zu agieren. Hier hat die Praxis gezeigt, dass hybride bzw. decoupled Systeme eine oft effektivere Wahl darstellen.

Diese Systeme bieten meist ebenfalls den flexiblen, modularen Aufbau und die umfangreiche API des Headless-Ansatzes. Allerdings sind hier bereits Frontend Frameworks, Module und Templates enthalten. Dies ermöglicht es, auch im Bereich der Präsentationschicht möglichst schnell zu einem Ergebnis zu kommen, ohne das Rad immer neu erfinden zu müssen. Meist ist der Aufwand, die bereits vorhandenen Features nach eignen Bedürfnissen bzw. UI/UX Vorgaben anzupassen, um einiges geringer, als alle Funktionen neu zu bauen.

Die Kernfrage, die es zu klären gilt, ist meist nicht „Headless: ja oder nein“, sondern vielmehr „Stellt das System genug Funktionen bereit, alle benötigten Kanäle anzubinden“. Es lohnt sich also bereits im Vorfeld detailliert zu analysieren, welche Schnittstellen benötigt werden und ob diese gegeben falls möglichst einfach erweitert werden können, um während der Umsetzungsphase nicht auf unlösbare Probleme oder zu hohe Hürden zu stoßen.