Headless CMS: Effiziente Entwicklungsprozesse dank Fokus auf die Inhalte

Olaf Kaiser-OttoJuni 2020

Headless Content-Management-Systeme rütteln die klassische CMS-Landschaft auf. Dabei ist Headless vielmehr als einfach ein neuer Technologie-Ansatz. Ganz im Sinne von Content First sorgt Headless dafür, dass im Projekt der Fokus von Anfang an auf Inhalten und Funktionen und damit auf dem Mehrwert für den User liegt. Der Entwicklungsprozess wird völlig neu orchestriert: Inhaltserfassung und technische Entwicklung laufen parallel. Dies steigert die Effizienz im Projekt  und senkt die Entwicklungskosten. Dieser Artikel entstand in Zusammenarbeit zwischen Unic und Daniel Takai, Silberrücken AG.

Personalkosten treiben die Entwicklungskosten

Es sind vor allem Personalkosten, die den Preis für die Entwicklung einer Website in die Höhe treiben. Aber auch die für den Betrieb benötigten Systeme können eine Stange Geld kosten. Besonders dann, wenn ältere, selbst betriebene Systeme zum Einsatz kommen. Für ihre Konfiguration und Wartung braucht es Spezial-Wissen.Websysteme verändern sich schneller als andere Softwaresysteme. Die Personalkosten sind entsprechend noch höher. Der Entwicklungsaufwand wächst mit der Veränderungsrate. Websysteme sind nie fertig entwickelt. Man stellt eine Website nicht als Version 1.0 live und arbeitet danach nie wieder daran. Die Webentwicklung erstreckt sich über den gesamten Lebenszyklus des Produkts – bis zu seiner Abschaltung.Diese Kosten für die Entwicklung sind ein Fass ohne Boden. Besonders wenn die Technologien in die Jahre gekommen sind und die Agentur bzw. der Dienstleister keine ausreichende Maturität im Software Engineering hat. (Wie man den Ausweg aus dieser Kostenfalle findet, würde den Rahmen dieses Artikels sprengen. Gerne verweisen wir Sie an dieser Stelle auf das Buch von Daniel Takai.

Daniel Takai, Agile Coach/Facilitator, Silberrücken AG

Die effektiven Kosten einer CMS-Lösungen sind dabei nur oberflächlich von den initialen Lizenz- oder Abonnementskosten getrieben. Tatsächlich sind die Auswirkungen der Lösungswahl auf die Lösungsqualitäten und die (Entwicklungs-)Prozesse die wesentlichen Kostentreiber.

Die verschiedenen Rollen im Entwicklungsprozess

Um die Personalkosten in klassischen CMS- mit Headless CMS-Projekten zu vergleichen, müssen wir die Rollen innerhalb des Entwicklungsprozesses genauer betrachten. Den Arbeitsprozess, den wir verwenden, ist abstrahiert und teilweise idealisiert. Wir beschränken uns auf die Rollen PO, Redaktor, UX, Frontend, Backend und Betrieb.

PO: Die Rolle des Product Owner steht für das Business der Zielorganisation. Die Person mit dieser Rolle vertritt die fachliche Perspektive im jeweiligen Kontext.
Redaktion: Redaktorinnen und Redaktoren produzieren Inhalte – beispielsweise Texte, Bilder oder Videos.
UX: User Experience Designerinnen und Designer erstellen Modelle der Benutzerführung und des Inhalts. So entstehen Konzepte für Benutzeroberflächen und Ausgabekanäle, die zu den Zielgruppen passen. Das wichtigste Qualitätsmerkmal für das User Experience Design ist die Bedienbarkeit.
Frontend: Unter Frontend-Entwicklung versteht man die technische Umsetzung der Konzepte des User Experience Design. Oft werden zusätzlich Vorgaben der Corporate Identity und des Corporate Design berücksichtigt. Frontend-Entwicklerinnen und -Entwickler schreiben in den Computersprachen HTML, CSS und JavaScript Software, die der Benutzer später im Browser ausführt. Dabei werden sie mit stetig verändernden Standards, Browsern und einer grossen Anzahl von Endgeräten mit unterschiedlichen Eingabetools und Bildschirmgrössen konfrontiert. Für die Frontend-Entwicklung sind die Veränderbarkeit und die Performance besonders wichtig: Niemand mag langsame Benutzeroberflächen.
Backend: Backend-Entwicklerinnen und -Entwickler schreiben hinter den Kulissen die Quelltexte, die im CMS laufen. Sie sind dafür verantwortlich, dass die richtigen Seiten «gebacken» werden (wie man im Jargon sagt). Auf dieser Ebene wird die Entwicklung durch die Programmiersprache des CMS bestimmt (AEM ist Java, TYPO3 oder Neos sind PHP, Sitcore ist .NET). Besonders herausfordernd sind Mischsysteme, die zum Beispiel mit Java und .NET funktionieren. Dass es schwierig ist, eine Entwicklerin oder einen Entwickler zu finden, die bzw. der beide Programmiersprachen beherrscht, liegt auf der Hand.
Betrieb: Last but not least widmen wir uns der Rolle des Betriebs. Er stellt Laufzeiteinheiten bereit. Eine einzelne Person oder eine Gruppe sorgen dafür, dass die angefertigte Software korrekt konfiguriert wird und auf den richtigen Maschinen läuft.

Klassische CMS sind Monolithen. Darstellung und Redaktion sind durch (systemeigene) Templates eng miteinander verbunden. Um eine Darstellung zu ändern, müssen Backend-Entwicklerinnen und -Entwickler die Templates anpassen oder Inhalte programmatisch in die richtige Form konvertieren. Personen, die eine hohe Kompetenz im Frontend haben und ähnlich gut in der jeweiligen Backend-Sprache programmieren können, sind selten. Also gestaltet sich der Prozess an dieser Stelle wie folgt:

Abbildung 1: Schematischer Ablauf des klassischen Entwicklungsprozesses.

Der Entwicklungsprozess mit klassischem CMS

Ein Kernteam – bestehend aus PO, UX, Frontend und Redaktion – bespricht gemeinsam die Konzeption der Website (1). Das Ergebnis ist ein HTML-Prototyp: eine im Browser lauffähige Webanwendungen, die das gewünschte Verhalten aufzeigt. Wir nennen diesen Schritt in der Entwicklung die Spezifikation.

In einem zweiten Schritt «übersetzen» Backend-Entwicklerinnen und -Entwickler den Prototypen (2): Sie portionieren ihn in Häppchen und kopieren Templates und Komponenten ins CMS. Eine zeitaufwändige Arbeit mit viel Potential für Fehler. Deshalb müssen sie alle Komponenten und Templates prüfen und testen. Entdecken sie eine Fehlfunktion, müssen sie den Fehler gemeinsam mit dem Frontend-Entwicklern suchen. Es folgt Abstimmungsrunde auf Abstimmungsrunde. Die Rechnung wird immer höher. Diese Arbeitsprozesse sind hochgradig redundant, geprägt von Missverständnissen und Fehlern. Die Übergabeprozesse sind vor allem bei verteilten Teams oft ineffizient.

Hat der Backend-Entwickler seine Arbeit abgeschlossen, reicht er sie als Softwarepaket an den Betrieb weiter. Dieser spielt das Paket auf den entsprechenden Maschinen aus und konfiguriert sie. Auch der Betrieb braucht CMS-Wissen, um allfällige Fehler diagnostizieren zu können. Das führt in der Praxis oft zu einer unscharfen Abgrenzungen der Verantwortlichkeiten zwischen Betriebssystem und Applikation. Es kommt zu ähnlichen Missverständnissen und Fehlern, wie bei der Abstimmung zwischen Backend und Frontend.Am Ende dieses Prozesses steht die fertige Website. Erst jetzt kann die Redaktion mit der Inhaltserfassung (3) beginnen. Und erst danach erfolgt der GoLive (4) und das Produkt wirkt am Markt.

Abbildung 2: Sequenzieller Prozess von Entwicklung und Inhaltserfassung mit klassischem CMS.

Der Entwicklungsprozess mit einem Headless CMS

Bei einem HCMS sieht der Entwicklungsprozess anders aus (Abbildung 3): Auch hier beginnt der Prozess mit einer ersten Spezifikation (1). Hier wird jedoch nicht über Templates und Komponenten gesprochen, sondern über ein Inhaltsmodell. Anstatt über die Präsentation und deren Funktionsweise zu sprechen, dreht sich alles um die eigentlichen Inhalte. Auf dieser Basis ist es einfacher, die Essenz der Kommunikation und die geschäftliche Aufgabe zu definieren.

Das mehrdeutige und nicht-normalisierte Inhaltsmodell, das auch als Domänenmodell wahrgenommen werden kann, wird unmittelbar im ausgewählten HCMS konfiguriert. Es braucht dafür keine Backend-Entwickler. Wenn das Team eine Verbesserungsmöglichkeit erkennt, kann es das Modell selber anpassen. Die ersten Inhalte entstehen bereits bei der gemeinsamen Ausgestaltung des Inhaltsmodells. Es gibt einen intensiven Austausch zwischen den Domänen. Werden die Entwicklerinnen und Entwickler jetzt beigezogen, startet der Lernprozess zu einem frühen Zeitpunkt. Hier lohnt sich ein HCMS im SaaS-Modell, bei dem neue Benutzer flexibel hinzugefügt werden können.

Ist das Modell adäquat und einigermassen stabil, kann die Entwicklung (2) beginnen. Und zwar im Tandem mit der Inhaltserfassung/-pflege (3). Unter Dialog und Kollaboration werden zeitgleich Inhalte produziert und Präsentationsschichten erstellt. Probleme und neue Möglichkeiten in Modell und Anwendung werden gemeinsam entdeckt. Der verständnisvolle Austausch führt zu einer kollaborativen Lernerfahrung. Eine gute Vorbeugemassnahme gegen Missverständnisse und teure Fehler in Entwicklung und Betrieb.

Ein paar Worte zur Implementierung (2): HCMS verfügen nicht über einen systemeigenen Templating-Mechanismus sondern eine standardisierte API. Darüber können Inhalte strukturiert bezogen werden. Über die API erreichen die Ausgabekanäle die Inhalte direkt und brauchen dazu keine individuelle, selbst erstellte Lösung. Weil es hier um Content Management geht, klammern wir die Integration anderer Services in diesem Artikel aus. Wichtig ist an dieser Stelle, dass Concerns und die damit verbundenen Abhängigkeiten für die Inhaltspflege bei HCMS entfallen. Flexibilität und Geschwindigkeit des Innovationsvorhabens nehmen Fahrt auf.

Sind die Präsentationsschicht entwickelt und Inhalte produziert, erfolgt der GoLive (4). Bei modernen Organisationen erfolgt dieser Schritt ohne Personal aus dem Betrieb; er würde unnötig viele Ressourcen binden und Abhängigkeiten schaffen.

Abbildung 3: Paralleler Prozess von Entwicklung und Inhaltserfassung mit HCMS

Was ist das Fazit?

Der Vergleich der Entwicklungsprozesse zeigt, dass mit HCMS die Rolle der Backend-Entwicklung entfällt. Dadurch spart man die Personalkosten von mindestens einer Person. In einem Team von fünf Personen reduzieren sich die Kosten so um circa 40 %. Zur Kostenindikation ziehen wir in der Softwareentwicklung die Anzahl der Kommunikationswege bei, denn sie ist wissensbasiert. Bei einer Reduktion von fünf auf vier Personen sinkt die Anzahl von zehn auf sechs Wege.Mit einem HCMS sparen Sie aber noch mehr als die oben erwähnten Personalressourcen: Die frühzeitige Diskussion des Inhaltsmodells sorgt für eine hohe Maturität der Inhalte und reduziert den Änderungsbedarf im späteren Projektverlauf. Die schnelle Verfügbarkeit der Inhalte über eine standardisierte Schnittstelle und die parallele Erstellung von Ausgabekanälen und Inhalten steigern die Effizienz und senken ebenfalls die Kosten.