Mit dem neuen Auftritt für die Nürnberger Ingenieurgemeinschaft Dess + Falk ging vor Kurzem die erste Website live, die mit dem neuen CMS Acondo von Auctores umgesetzt wurde. Für Auctores ist das ein wichtiger Schritt: Das Content-Management-System auf Basis des Auctores-eigenen Entwicklungs-Frameworks Infinity Base bedeutet einen radikalen Systemwechsel weg vom klassischen CMS zum Headless CMS.
Der komplette Neuanfang mit Acondo beendet zum einen Legacy-Probleme des bisherigen Auctores-CMS: Das alte, Ende der 90er-Jahre entwickelte System wurde zwar stets angepasst und um neue Funktionen erweitert. Rückwärts-Kompatibilität war jedoch immer ein Thema – was auch bedeutete, dass die alte Codebasis ebenso wie die Komplexität von Programmierung und Bedienbarkeit zu immer größeren Hemmschuhen wurden.
Acondo bietet hier durch seinen neuen Ansatz massive Vorteile in puncto Sicherheit, Schnelligkeit und Nachhaltigkeit. Im Alltag ist die Fehleranfälligkeit aus einem weiteren Grund gering: Acondo ist auch im Backend individualisiert. Nicht alle Funktionen müssen für jeden Anwender und jeden Auftritt zur Verfügung stehen. Damit pflegen Anwender ihre Website einfach einfacher.
Bei der Entwicklung ging Auctores bewusst den Weg, das System so früh wie möglich produktiv einzusetzen. Nur so ließen sich Herausforderungen auf dem Weg zum neuen CMS unter realistischen Bedingungen testen und bewältigen. Mit Dess + Falk fand sich ein Unternehmen, das bereit war, sich auf das Abenteuer „Neue Website mit komplett neuem CMS“ einzulassen.
Der Relaunch für den Online-Auftritt eines mittelständischen Unternehmens war dabei das ideale Testgelände: Typische Elemente wie Service-Portfolio, Referenzen, Karrierebereich und News waren das erste Mal umzusetzen. Zugleich wurden nicht einfach ein Bestandsauftritt aufgehübscht, sondern Inhalte und Strukturen gründlich durchgeschüttelt, manches Überkommene über Bord geworfen und dafür Neues ebenso wie bisher ausgelagerte Bereiche integriert.
Im Wechselspiel zwischen Entwicklung, Erprobung und Kundenfeedback in Sachen Bedienung, Funktionsumfang und Darstellung entstand so ein Basisystem, das die Erwartungen des Entwicklungsteams deutlich übertroffen hat. Zugleich bestätigte sich für Auctores, dass der Schritt zum Headless-Ansatz für ein Content-Management-System der Richtige war.
Charakteristisch für ein Headless CMS ist die Trennung von Darstellung und Inhalt. Mancher mag denken: Ist das nicht schon typisch für herkömmliche Content-Management-Systeme spätestens seit der Jahrtausendwende? Hier lautet die Antwort: Nein, eine Website, die aus einem klassischen CMS kommt, trennt die Inhalte wie Texte und Bilder von der Art der Darstellung wie Seitenlayout, Farben, Schriftgrößen. Aber hier bilden das Backend für die Inhaltspflege und das Frontend, das die Inhalte anzeigt, eine technische Einheit.
Ein Headless CMS hingegen entkoppelt Pflege, Datenhaltung und Datenverwaltung vom Frontend, also dem, was ein Besucher der Website sieht. Kurz gesagt: Ein Headless CMS hat gar kein Frontend, sondern ist ein Speicher, in dem sich Inhalte pflegen, strukturieren und verwalten lassen. Das hat eine Reihe von Vorteilen.
Anders als ein herkömmliches CMS kann das Headless CMS über Schnittstellen Inhalte in unterschiedlichste digitale Kanäle ausspielen – die Website ist nur einer davon. Apps oder Social-Media-Plattformen lassen sich darüber ebenso beschicken. Damit müssen Inhalte nicht für jede Plattform und jeden Einsatzweck mehrfach vorgehalten werden.
Wie von selbst ergibt sich auf diese Weise ein großer Sicherheitsvorteil: Da die Anzeige von Inhalten, die sogenannte Präsentationsschicht, vom CMS entkoppelt ist, sind mögliche Sicherheitslücken schwieriger auszunutzen. Angreifer stehen vor einem zusätzlichen Bollwerk durch die zwischengeschalteten Authentifizierungs- und Autorisierungsmechanismen.
Diese Mechanismen spielen auch beim Verwalten der abgelegten Daten und der Arbeit damit eine wichtige Rolle: Inhalte lassen sich in einem Headless CMS besser strukturieren, Informationen kleinteiliger ablegen und bequemer auffinden. Die möglichen Suchfilter arbeiten mit spezifischen Zugriffsrechten, sodass jeder nur sieht, was er sehen darf. Dank Single Sign-On (SSO) lässt sich Acondo bruchlos in bestehende Unternehmensstrukturen integrieren. Das Andocken an vorhandene Software-Lösungen ist einfacher, da alle Inhalte über Schnittstellen ausgespielt oder empfangen werden.
Sind Backend und Frontend getrennt, bleibt die Website auch bei Wartungsarbeiten und Updates erreichbar. Da die einzelnen Webseiten nicht „just in time“ beim Abruf aus der Datenbank zusammengebaut werden, sondern aus dem Cache, dem Zwischenspeicher des Systems, kommen, bauen sich die Seiten sehr schnell auf. Für eingeloggte Nutzer lassen sich diese Caching-Daten mit internen Informationen anreichern, ohne dass sie auf die Geschwindigkeitsvorteile verzichten müssen.
Die flexible Skalierbarkeit des cloudbasierten Systems macht die Umsetzung ebenso wie den laufenden Betrieb unkomplizierter. Ein großer Vorteil der komplett medienunabhängigen Datenspeicherung ist die Zukunftssicherheit: Auch künftige Medienangebote und neue Trend-Plattformen lassen sich damit bespielen.
Mit der Einführung von Acondo wechselt Auctores weg von der Modulphilosophie eines herkömmlichen Content-Management-Systems hin zu Web Components. Dies beschleunigt nicht nur die Entwicklung von CMS-Erweiterungen, sondern stabilisiert auch das System, das somit über eine längere Lebensdauer hinweg weniger Updates benötigt. Zugleich lässt sich Barrierefreiheit im Frontend und Backend einfacher umsetzen.
Das World Wide Web Consortium (W3C) hat den Web-Components-Standard bereits 1994 entwickelt. Es hat jedoch Jahrzehnte gedauert, bis Webbrowser diesen unterstützten und die Technologie damit tauglich für den produktiven Einsatz machten. Web Components sind Code-Blöcke, in denen die Funktionalität und alle dafür nötigen Elemente wie HTML, CSS und JavaScript gekapselt sind. Sie funktionieren damit unabhängig von ihrer Umgebung und lassen sich beliebig in Websites und Apps nutzen – auch projektübergreifend. Entwickler müssen nicht jedes Mal Code neu schreiben, sondern können sich aus ihrer Bibliothek wiederverwendbarer Elemente bedienen.
Es ist nicht zu übersehen: Acondo hat ein tierisches Maskottchen – und noch dazu eines, das nicht unbedingt zu den typischen Kuscheltieren gehört. Warum ausgerechnet ein Oktopus? Das Tentakeltier tauchte erstmals auf, als es darum ging, einen Namen und ein Logo für das neue CMS zu finden. Die damit verbundenen Vorschläge setzten sich nicht durch. Aber der Oktopus gefiel allen Beteiligten, also durfte er bleiben. Und er hat durchaus Symbolcharakter: Seine vielen beweglichen Arme repräsentieren die Flexibilität von Acondo ebenso wie die Möglichkeit, auf unterschiedlichste Anwendungen zuzugreifen.