Die 4 wichtigsten Anwendungsfälle für den Einsatz von Headless

Mit 64 % der Unternehmen, die derzeit einen Headless-Ansatz verwenden, und 90 %, die eine Evaluierung planen, ist die steigende Popularität der Headless-Architektur unbestreitbar. Ja, der Hype um Headless ist echt und bringt klare Vorteile für das Entwicklungsteam mit sich. Wie bei jeder technischen Investition ist es jedoch wichtig, einen Schritt zurückzutreten und wirklich zu verstehen, welche Probleme Ihr Unternehmen zu lösen versucht und warum ein Headless-Ansatz mit diesen Anwendungsfällen übereinstimmt.

Was wollen Sie also erreichen? Wenn eine der folgenden Geschäftsanforderungen auf Sie zutrifft, könnte ein Headless Content Management System die ideale Lösung sein.

Geschäftsanforderung Nr. 1: Zukunftsfähigkeit, Vermeidung von Herstellerabhängigkeit
"Wir wollen zukunftssicher sein und uns problemlos an veränderte Anforderungen anpassen können.

Für Unternehmen, die Anpassungsfähigkeit und die Möglichkeit zum mühelosen Austausch von Komponenten suchen, könnte ein Headless CMS eine gute Wahl sein. Die Einführung einer Headless-Architektur zwingt Teams dazu, das CMS vom Frontend (oder der Präsentationsschicht) sowie von der Backend-Logik zu entkoppeln, und zwar in Form von Microservices, die außerhalb des CMS gehostet werden. Dies gibt Ihnen eine enorme Freiheit im Front-End und Back-End. Sie können verschiedene Frontend-Frameworks wie Vue, React oder Angular oder Backend-Programmiersprachen wie .NET oder Java nutzen, die als Microservices auf Ihrer bevorzugten Cloud-Plattform gehostet werden. Die flexible Natur einer Headless-Architektur stellt sicher, dass Sie eine lose Kopplung zwischen den Schlüsselkomponenten beibehalten, so dass, wenn Sie beispielsweise Ihr Headless-CMS ersetzen müssen, Ihr Frontend und Backend erhalten bleiben können, was Ihnen die Mühe erspart, einen Monolithen zu dekonstruieren, falls dies überhaupt möglich ist.

Fragen Sie sich selbst: Welche Komponenten meines Stacks, die sich wahrscheinlich ändern werden, kann ich vom Rest des Stacks abkoppeln?

Geschäftsanforderung Nr. 2: Ein einziger Content-Hub für mehrere Kanäle
"Wir brauchen eine zentralisierte Content-Management-Lösung für unsere verschiedenen digitalen Eigenschaften".

Wenn Ihr Unternehmen über mehrere Websites oder Kanäle wie mobile Apps, Kioske oder digitale Speisekarten verfügt, ermöglicht Ihnen die Konsolidierung in einem einzigen Content-Hub die Verwaltung aller Inhalte an einem Ort. Die National Rugby League zum Beispiel nutzt Optimizely, um Inhalte für 19 Websites, eine mobile App, digitale Displays und vier weitere digitale Objekte zu verwalten. Ebenso nutzt Electrolux das CMS von Optimizely seit über einem Jahrzehnt, um Inhalte für mehrere Marken zu verwalten. Wenn Ihre Geschäftsanforderung wirklich darin besteht, ein einziges Content-Repository zu haben, kann ein Headless CMS Ihnen diese zentralisierte Lösung für ein rationalisiertes Content-Management bieten. Das bedeutet nicht, dass ein All-in-One-CMS Sie nicht bei der Verwaltung von Inhalten für mehrere Kanäle unterstützen kann. Allerdings sind Marketer, die ein Headless CMS verwenden, gezwungen, Inhalte strukturiert zu betrachten und sich auf die Wiederverwendung von Inhalten und die Bereitstellung für mehrere digitale Kanäle vorzubereiten.

Geschäftsanforderung Nr. 3: Entkoppeltes Frontend und Backend
"Wir wollen React als Frontend-Framework einsetzen."

Die Entkopplung von Frontend und Backend ist nicht unbedingt eine geschäftliche Anforderung, sondern eher eine technische Lösung, die entweder durch architektonische Präferenzen oder durch die Struktur Ihrer internen Entwicklungsteams bestimmt wird. Mit getrennten Front-End- und Back-End-Entwicklerteams kann jedes Team "in seiner eigenen Spur bleiben" und sich auf seine jeweiligen Fachgebiete konzentrieren. Dadurch werden unnötige Abhängigkeiten beseitigt, die Arbeitsmoral der Mitarbeiter verbessert und das Unternehmen kann schneller auf den Markt kommen. Die Entscheidung für eine Headless-Lösung ermöglicht die Unterstützung vieler verschiedener Architekturmuster. Daher müssen Entwicklungsteams, die sich für eine Headless-Architektur entscheiden, bei der Strukturierung und Pflege ihres Codes disziplinierter vorgehen, um zu verhindern, dass aus dem Code, der für die Verbindung von Headless-Lösungen erforderlich ist, ein Monolith entsteht.

Geschäftsanforderung Nr. 4: Anwendungen mit hoher Interaktivität
"Wir haben eine eCommerce-Website" oder "Unsere Kunden tätigen ihre Transaktionen hauptsächlich über unsere mobile App".

Wenn die Kanäle, für die Sie Inhalte verwalten möchten, viele Transaktionen von Ihren Kunden akzeptieren, wie z. B. eCommerce oder eine mobile App, ist die Wahrscheinlichkeit groß, dass eine hohe Interaktivität in beide Richtungen stattfindet. Die Wahl einer Headless-Lösung für Anwendungen mit hohen Interaktivitätsanforderungen wäre eine ausgezeichnete Wahl, da sowohl im Frontend als auch im Backend ein deutlich höherer technischer Aufwand erforderlich sein wird. Die Ausgliederung beider Komponenten aus dem Headless CMS, wie in den vorangegangenen Punkten beschrieben, ermöglicht eine effiziente Softwareentwicklung. Besteht Ihr digitales Eigentum jedoch aus Marketing-Websites oder mobilen Anwendungen, die nur Informationen anzeigen, dann kann die Wahl eines Headless CMS zu viel des Guten sein. Die Entscheidung für eine Headless-Lösung anstelle eines All-in-One-CMS für einen einfachen Anwendungsfall zwingt die Teams dazu, die Komponenten unnötig zu entkoppeln. Sie müssen nicht nur die Frontend- und Backend-Logik pflegen, sondern auch das Hosting für beide und zusätzliche Elemente wie Suchfunktionen, Vorschaufunktionen, Personalisierung, Formulare zur Lead-Generierung, CDNs, statische Website-Generierung und vieles mehr bereitstellen. Als Unternehmen müssen Sie mehrere Anbieter, Verträge und unterschiedliche SLAs verwalten und diese Lösungen in Ihren Kopf integrieren.

Fragen Sie sich selbst: Rechtfertigt mein Anwendungsfall die zusätzliche Verantwortung für die Zusammenarbeit mit vielen Anbietern, das Unterzeichnen und Aushandeln mehrerer Verträge, die Arbeit mit unterschiedlichen SLAs und die Pflege von internem Glue-Code?

Vergessen SieIhr Marketingteam nicht.

Entwickler drängen oft auf Headless, weil sie dadurch eine enorme Flexibilität erhalten. Auf der anderen Seite benötigen Vermarkter, Content-Ersteller und Content-Redakteure ein CMS, das sich problemlos in ihren Content-Erstellungsprozess einfügen lässt. Sie werden feststellen, dass ein Headless CMS ihnen zwar bei der Strukturierung von Inhalten ohne Präsentationsschicht hilft, dass aber der Aufbau der Seiten/Erlebnisse nun entweder von der Technik durch Code oder durch eine andere Software gesteuert wird. Headless CMS, wie der Name schon sagt, bieten in der Regel keine Funktionen für die Erstellung von Erlebnissen und Seiten. Und wenn doch, sind sie nicht rein headless. Wenn Sie sich also für ein Headless CMS entscheiden, stellen Sie sicher, dass auch Ihre Vermarkter auf ihre Kosten kommen, indem Sie ihnen eine Lösung anbieten, die Erfahrung/Seitenerstellung ermöglicht, damit auch die Vermarkter schnell arbeiten können.

Kann Optimizely als Headless CMS eingesetzt werden?

Absolut - Optimizely CMS hat schon immer den Inhalt von der Präsentationsschicht entkoppelt. Der Inhalt befindet sich in der Optimizely-Datenbank und die Präsentationsschicht im Code, unabhängig davon, ob dieser in oder außerhalb von Optimizely gehostet wird. Dies ermöglicht es Unternehmen wie Dolby, der National Rugby League und Moco Food Services, Inhalte über mehrere Websites und verschiedene andere digitale Eigenschaften, wie mobile Apps und digitale Displays, wiederzuverwenden.

Mit der Einführung von Content Graph haben wir unser Headless-Angebot gestärkt und bieten Ingenieuren mehr Optionen für die Bereitstellung von Inhalten, entweder über .NET SDKs, RESTful APIs oder GraphQL.

Das Besondere an Optimizely ist, dass es auch eine optionale Page-Builder-Funktion hat, die sicherstellt, dass Vermarkter immer noch eine umfassende Kontrolle über die Erfahrung/Seitenkomposition für Websites haben. Anstatt diese Verantwortung Ingenieuren zu überlassen oder eine andere Software zu beschaffen, um diese Lücke zu füllen, die andere reine Headless-Player hinterlassen, kann Optimizely Ihnen helfen, dieses Problem zu lösen, indem es, falls gewünscht, On-Page-Editing-Funktionen aktiviert.

Fazit

1. Die Entscheidung für ein Headless CMS gibt Ihren Entwicklern enorme Freiheiten. So können Sie schneller auf den Markt gehen. Zu viel Flexibilität kann jedoch zu einer Belastung werden. Stellen Sie daher sicher, dass eine Unternehmensarchitektur und eine strenge Entwicklungspraxis vorhanden sind, um zu vermeiden, dass Sie in einem Monolithen aus benutzerdefiniertem Code enden.
2. Headless CMS bietet, wie der Name schon sagt, Lösungen für die Verwaltung von Inhalten, aber nicht für die Verwaltung der Präsentationsschicht. Wenn Sie sich für ein Headless CMS entscheiden, stellen Sie sicher, dass Sie auch eine Lösung für den Erfahrungsaustausch/Seitenerstellung für die Vermarkter bereitstellen, damit diese ein hohes Maß an Selbstständigkeit haben und nicht mehr von den Ingenieuren für ihre tägliche Arbeit abhängig sind.
3. Die Entscheidung für ein Headless CMS schafft die Voraussetzungen für ein kompatibles digitales Ökosystem, das die Flexibilität des Unternehmens erhöht. Ein Ökosystem mit mehreren Softwareanbietern führt jedoch zu mehreren Verträgen, unterschiedlichen SLAs und möglicherweise zu Klebstoffcode für die Integration all dieser Anbieter. Treten Sie einen Schritt zurück und überlegen Sie, ob Ihre geschäftlichen Anwendungsfälle die zusätzliche Verantwortung für die Verwaltung mehrerer Anbieter, unterschiedliche SLAs und die Pflege von internem Glue-Code rechtfertigen.