Das Flughafen-Projekt setzt einen neuen Standard – sowohl in den gewählten Technologien als auch in der interdisziplinären Zusammenarbeit. Doch neuartige Technologien sowie unbekannte Ansätze bedeuten auch, dass vieles neu gedacht werden muss: Knifflige technische Herausforderungen verlangen nach kreativen, unkonventionellen Lösungen. Frontend und Backend müssen eine neue gemeinsame Sprache finden und viel enger miteinander zusammenarbeiten.
In meinem Erfahrungsbericht zeige ich Ihnen auf, wie wir für den Flughafen Zürich ein Instrument entwickelt haben, das viele Türen öffnet und neue Wege ermöglicht. Und ich gehe der Frage nach, wie entkoppelt Sitecore Headless wirklich ist.
Ein moderner Ansatz für ein komplexes Projekt
Alles begann mit der öffentlichen Ausschreibung des Flughafens Zürich für den Relaunch der Website – mit Sitecore als technischer Plattform sowie mit zahlreichen Anbindungen und Umsystemen. Wer mich kennt, weiss, dass solche Herausforderungen genau in mein Beuteschema passen: Seit über 20 Jahren bin ich im IT-Bereich tätig, und seit 10 Jahren beschäftige ich mich intensiv mit Sitecore. Sitecore ist daher eine Passion für mich – denn das System kann so viel mehr, als die meisten erwarten.
Wie der Flughafen Zürich zur Headless-Architektur kam
Wir wollten der Ausschreibung vom Flughafen Zürich mit einem modernen und technologisch hochstehenden Ansatz begegnen. Während wir das Projekt in der Offertphase genauer unter die Lupe nahmen, ist uns bewusst geworden, dass die neue Plattform zahlreichen unterschiedlichen Bedürfnissen gerecht werden und Inhalte für viele verschiedene Empfängerinnen und Empfängen bereitstellen muss. Sie sollte auch für zukünftige Anbindungen und Weiterentwicklungen stets eine zeitgemässe Antwort haben. Darum entschieden wir uns für eine stark vernetzte Multisite-Plattform, die auf einer Headless-Architektur basiert. Wir waren überzeugt: Nur eine Multisite-Plattform mit Headless kann all diesen Anforderungen gleichermassen entsprechen.
Welche Headless-Architektur ist die richtige?
Sitecore war als System gesetzt. Dieses bringt out of the box viele Funktionalitäten wie Personalisierung, A/B-Testing und mehr mit. Darauf wollten wir auch mit einer Headless-Architektur nicht verzichten. Darum war der Fall klar: Wir entschieden uns für Sitecore Javascript Services JSS. Sitecore JSS stellt eine Headless-Architektur zur Verfügung, die jedoch keinerlei Kompromisse bei den Standardfunktionalitäten von Sitecore nach sich zieht.
Der Flughafen Zürich sollte auch für zukünftige Anbindungen und Weiterentwicklungen stets eine zeitgemässe Antwort haben.
Besucher:innen am Flughafen benutzen das Smartphone
So weit, so gut. Die dem Projekt zugrundeliegende Architektur hatten wir definiert. Wie wir den Bedürfnissen im Bereich Mobile begegnen wollten, war nicht sofort klar: Sollten wir eine native App entwickeln oder nicht? Schnell mussten wir feststellen, dass eine native App dem Flughafen Zürich keinen grossen Vorteil brächte: Sie müsste auch nicht native verfügbare Funktionalitäten nutzen, was zu hohen Wartungsaufwänden führen würde. Verzichten auf ein «App-Feeling» wollten wir aber auch nicht. So kamen wir auf die Idee, auf eine Progressive Web Application, kurz PWA, zu setzen. Die PWA ist funktional nahe an einer nativen App mit deren Vorteilen und einer guten User Experience. Sie erlaubt ein konsistentes Nutzererlebnis über alle Geräte hinweg. Der Zugang läuft jedoch nicht über einen Store mit entsprechenden Freigaben, sondern über den Browser selber.
Die Passagier:innen wollen aktuelle Fluginformationen
Die Fluginformationen sind einer der wichtigsten Funktionalitäten der neuen Lösung. Sie sind für die Passagier:innen von zentraler Bedeutung: einerseits sind dies die Flugzeiten, das Gate, der Check-in und mehr, andererseits sind es auch Essens- oder Shopping-Möglichkeiten, die sich zum Beispiel während des Umsteigens anbieten. Die Fluggäste brauchen aktuelle und personalisierte Fluginformationen in ihrem jeweiligen Kontext. Die Ansprüche an den Service, welcher diese Fluginformationen zur Verfügung stellt, waren entsprechend hoch. Der bestehende Flugdatenservice konnte diesen Anforderungen aber nicht mehr gerecht werden.
Darum haben wir uns im Projektteam dafür entschieden, einen neuen Flugdatenservice basierend auf den Technologien .Net.Core und SignalR zu bauen. Für diese Implementierung haben wir uns also gänzlich von Sitecore gelöst. Dies gab uns die Gelegenheit, weitere technische Innovationen voranzutreiben. So haben wir vom sonst üblichen Pull-Mechanismus abgesehen und einen Push-Mechanismus eingerichtet: Neu verlangt nicht ein Endgerät neue Informationen (pull), sondern die Änderungen werden direkt an das Endgerät gesendet (push). Dies stellt sicher, dass die Passagier:innen immer die aktuellen Fluginformationen besitzen, ohne dass sie ein Neuladen der Seite veranlassen müssen.
Und das Hosting?
Das Hosting füllte einen grossen Teil unserer Arbeit aus. In der Ausschreibung war das Hosting in der Azure Cloud vorgegeben. Das umfangreiche Thema Azure kann ich aber im Rahmen dieses Artikels nicht abhandeln.
Die Fluginformationen sind für die Passagierinnen und Passagiere von zentraler Bedeutung.
Hohe Zukunftssicherheit des Systems – dank Headless
Sitecore steht als Content-Lieferant mit seinen Marketing-Automation- und Personalisierungs-Funktionen im Mittelpunkt der Content-Drehscheibe. Das hat zur Folge, dass wir schnell auf sich ändernde Bedürfnisse reagieren können. Dies führt zu einer hohen Zukunftssicherheit des gesamten Systems. Bereits während der Projektumsetzung zeigte sich, dass der Headless-Ansatz für den Flughafen Zürich grosse Vorteile mit sich bringt:
In technischer Hinsicht bietet die modulare Content-Architektur von Sitecore einen grossen Vorteil in einem Headless-Projekt: Es hat uns erlaubt, bereits die Content-Modellierung Endkanal-unabhängig zu gestalten.
Der architektonische Aufbau von Sitecore JSS machte es möglich, dass die Autorinnen und Autoren ihre gewohnte WYSIWYG-Umgebung trotz Headless behalten konnten. Zudem konnten viele Out-of-the-box-Funktionalitäten von Sitecore wie Personalisierungsfeatures problemlos übernommen werden.
Die CMS-Autor:innen können unkompliziert entscheiden, welcher Content über welchen Endkanal ausgeliefert werden soll: zum Beispiel Website, PWA, Indoor-Navigationskarte oder Stele-Displays vor Ort.
Sitecore JSS stellt zudem einen GraphQL-Endpunkt (eine Schnittstelle) zur Verfügung, welcher es uns erlaubte, spezifische Inhalte problemlos weiteren Applikationen zur Verfügung zu stellen: So können wir Integrationen, wie die der Wayfinding-Applikation, oder Diensten, wie dem Messenger Airport AI, strukturiert Content zur Verfügung stellen.
Frontend First oder Sitecore First oder beides?
Wie arbeiten Backend und Frontend auf einem Headless-Projekt zusammen? Sitecore kennt für die Headless-Entwicklung zwei Ansätze: entweder Frontend First oder Sitecore First. Aus unserer Projekterfahrung heraus wissen wir, dass die richtige Lösung meist in einer Mischung aus beiden Ansätzen liegt. JSS beitet mit dem connected Mode die Möglichkeit, die lokale Entwicklungsumgebung des Frontends mit einer laufenden Sitecore-Instanz zu verbinden. Dies hat dazu beigetragen, dass wir beide Ansätze verfolgen konnten.
Die gleiche Datenstruktur in Frontend und Backend sicherstellen
Dabei mussten wir sicherstellen, dass Frontend und Backend immer auf denselben Datenstrukturen und -definitionen, sogenannten Contracts, basierten. Dies mussten wir tun, damit nicht das eine oder das andere im agilen Entwicklungsprozess laufend angepasst werden musste. Contracts bedeuten: Die zu entwickelnden Module für Backend und Frontend basieren auf demselben «Vertrag» – in diesem Vertrag sind die Modulbestandteile definiert: Hat es einen Titel? Hat es Text? Wie ist das Verhalten (kann geöffnet/geschlossen werden)? Was ist optional, was zwingend? Darum haben wir einen «Contract Driven Development»-Ansatz aufgebaut. Dies ermöglichte uns, die benötigten Codeteile im Frontend sowie im Backend automatisch zu generieren. Sie waren so immer aktuell sowie auf dem gleichen Stand.
Automatisierte Vorschau: Immer den aktuellen Stand des Projektes sehen
Für die Umsetzung der Headless-Architektur haben wir nicht auf eine Sitecore-JSS-Vanilla-Installation gesetzt. Das heisst, wir gingen einen Schritt weiter: Wir nahmen nicht das «reine» Sitecore-JSS-System, sondern haben das Starter-Modul «Macaw» hinzugenommen. Damit können wir die Frontend-Artefakte direkt und automatisiert in ein sogenanntes Storybook, eine Frontend-Vorschau, einspeisen. Die Vorschau basiert automatisiert auf dem neusten Codestand. So können wir und die Kund:innen immer einsehen, wie das Frontend aktuell aussieht und wie es sich verhält – und dies ohne jeglichen Zusatzaufwand für die Frontend-Entwickler:innen.
Wir mussten umdenken. Immer wieder.
Umdenken & eine neue gemeinsame Sprache finden
Sehr viel Neues tat sich uns in diesem Projekt auf – viel Spannendes, viel Herausforderndes, aber auch viel Schwieriges. Als Consultant und ehemaliger Softwareentwickler hatte ich in diesem Projekt diverse Rollen inne. Ich «übersetzte» die UX- sowie die Businessanforderungen in die Sitecore-Sprache und definierte die Grundarchitektur der Sitecore-Lösung. Man könnte also sagen, dass ich als ein «Requirementsengineer-Businessanalyst-Solutionarchitekt» unterwegs gewesen bin. So hatte ich zwar alles im Blick, lief aber auch Gefahr, für alle Probleme eine Antwort bereit haben zu müssen. Was wir vor allem feststellten: Neue Technologien und neue Ansätze bedeuten auch, dass vieles neu gedacht werden muss. Auch müssen die Beteiligten entsprechend geschult werden.
Neuer Ansatz: Content First
Bereits in der Spezifikationsphase der einzelnen Funktionalitäten wurde uns klar, dass wir in der Entwicklung umdenken müssen: Wir mussten uns dem Content-First-Ansatz unserer UX-Spezialist:innen annähern. Denn die Konfiguration eines Inhaltes wie zum Beispiel die Bildplatzierung bedeutet je nach Kanal und jeweiligem Frontend etwas anderes. Darum erstellten wir das Content-Modell nach dem Inhalt und nicht nach dem Design – was übrigens auch bei Nicht-Headless-Projekten ein sinnvoller Weg ist. Diese neue Sichtweise brauchte ebenso ein Umdenken auf Kundenseite, denn oft wird mit dem Inhalt auch gleich das Design der Website diskutiert.
Umdenken im Entwicklungsprozess
Gegenüber anderen Projekten hat sich der Entwicklungsprozess ziemlich verändert. Dies stellte das gesamte Entwicklungsteam immer wieder vor neue Herausforderungen. Auch hier musste ein Umdenken geschehen. Wir mussten anfangen, in Content-Modellen zu denken, damit die Headless-Strukturen korrekt ausgeliefert und in den Frontends korrekt interpretiert wurden. Unsere Lösung mit dem «Contract Driven Development» (siehe oben) hat diesen neuen Ansatz technisch sehr gut unterstützt. Ohne das «Contract Driven Development» hätten wir vermutlich viele Module entweder im Backend oder im Frontend mehrfach entwickelt.
Eine gemeinsame Sprache von Frontend und Backend
Auch die Kommunikation wurde durch diesen Ansatz verändert: So haben Backend- und Frontend-Entwickler:innen eine gemeinsame Sprache festgelegt, welche auf den definierten Contracts basierte. Daraus entwickelte sich eine viel engere Zusammenarbeit der beiden Disziplinen. Diesen Wandel aus meiner Perspektive zu beobachten, war sehr spannend.
Herausforderungen mit Sitecore JSS
Die neuen Technologien haben uns vor diverse Herausforderungen gestellt. Gewisse Aspekte von Sitecore JSS sowie der anderen eingesetzten Technologien entpuppten sich teilweise als Stolpersteine. Unser üblicher Ansatz, ein Multisite/Multilanguage-Konstrukt mit Sitecore aufzubauen, funktionierte bei diesem Projekt beispielsweise nicht mehr. Sitecore JSS berücksichtigt es nicht, dass eine JSS-App mehrere Websites gleichzeitig bedient. Um dies bewerkstelligen zu können, mussten wir auch hier neue Wege finden und mehrmals im System eingreifen. Als Stichworte für diese Eingriffe seien hier Siteresolving oder Linkgenerierung genannt.
Wie «kopflos» ist Sitecore Headless tatsächlich?
Viele fragen sich bestimmt: Wie viel «Headless» steckt in Sitecore Headless wirklich drin? Ich persönlich glaube, dass dies eher eine philosophische Frage ist und je nach Blickwinkel unterschiedlich beantwortet werden kann. Ich selber spreche von «decoupled», da immer noch viele Einstellungen im Content zu einer Reaktion im Frontend führen. Sitecore bietet damit aber den Vorteil, dass in einem Headless-Konstrukt mit Sitecore JSS die WYSIWYG-Bearbeitung des Inhalts ermöglicht wird, aber trotzdem diverse Frontends Headless bespielt werden können. Zudem behält das Produkt seine Stärken, da die Out-of-the-box-Funktionalitäten voll und ganz unterstützt werden.
Ein neuer Standard für die Zukunft
Das Flughafen-Projekt setzt einen neuen Standard. Zwar haben die neuen Ansätze, die wir gewählt haben, uns stark gefordert und vieles verändert. Aber es hat uns auch weitergebracht. Ich bin der Meinung, dass wir auch künftig auf diese Weise Sitecore-Projekte realisieren sollten.
Achtung: Die Content-Verwaltung bleibt!
Auch in einem Headless-Projekt bleibt das Credo: Das Business Asset einer Website ist und bleibt der Content! Ohne gut gepflegten Content funktioniert auch die technisch innovativste Plattform nicht. Und bei einem Headless-Projekt verringert sich der Aufwand zur Content-Pflege nicht. Der Aufwand kann sich verschieben, aber er kann sich sogar erhöhen, da jetzt mehr Systeme zusätzlich Content von Sitecore beziehen. Die Autor:innen können aber für alle Systeme auf den bekannten Oberflächen und in den bekannten Strukturen ihren Content pflegen.
Durch die gewählte Architektur und den erstellten Baukasten hat der Flughafen Zürich ein Instrument in den Händen, welches viele Türen öffnet.
Und wie geht es weiter?
Wie es weitergeht, ist eine gute Frage. Durch die gewählte Architektur und den erstellten Baukasten hat der Flughafen Zürich ein Instrument in den Händen, welches viele Türen öffnet und neue Wege möglich macht. Sie können neue Frontends auf dieselbe Ausgabestruktur legen, wodurch sie neue Känale, wie die Stele-Displays vor Ort, bespielt können. Sie sind in der Lage, weitere Websites wie das Parking Booking oder den Business-&-Partner-Auftritt auf der gleichen Basis einfach und schnell zu erstellen. Bestehende Funktionalitäten können sie ohne grösseren Aufwand erweitern.
Zusammen mit dem Flughafen haben wir Pläne. Und es sind auch schon weitere Umsetzungen im Gange. Lassen Sie sich überraschen!
Noch mehr ins Thema Headless eintauchen? Lesen Sie unser Whitepaper
Wir sind da für Sie!
Sie möchten Ihr nächstes Projekt mit uns besprechen? Gerne tauschen wir uns mit Ihnen aus.
Kontakt für Ihre digitale Lösung mit Unic
Sie möchten Ihre digitalen Aufgaben mit uns besprechen? Gerne tauschen wir uns mit Ihnen aus.
