The airport project is setting a new standard – in terms of technologies selected, but also in terms of collaboration across disciplines. However, novel technologies and unfamiliar approaches also require us to carve new paths at times: Tricky technical challenges require creative and unconventional solutions. Frontend and backend have to develop a new common language and collaborate much more closely than before.
In this article I would like to share our experience and illustrate how we developed a tool for Zurich Airport that opens many doors and new avenues. Plus, I will try to shed light on the question of how decoupled headless Sitecore really is.
A Modern Approach for a Complex Project
It all started with a call for tenders by Zurich Airport for the relaunch of their website – with Sitecore as a platform and numerous integrations and peripheral systems. If you know me, you’ll know that a challenge like that is right up my alley: I’ve been working in IT for more than 20 years, and for 10 years now, I have been focusing on the intricacies of Sitecore. Over time, Sitecore has become a passion of mine – especially as the system is much more powerful than most people realise.
Why Zurich Airport Chose a Headless Architecture
We wanted to respond to Zurich Airport’s call for tender with a state-of-the-art, technologically sophisticated approach. During the tendering stage, we familiarised ourselves with the project and realised that the platform will have to meet a number of varied needs and provide content for a variety of recipients. It also needed to be able to keep up to with future integrations and further development. That is why we decided to create a highly interconnected multi-site platform based on a headless architecture. We were convinced that only a headless multi-site platform would be able to live up to all these expectations.
What is the Right Headless Architecture?
Sitecore was the system that had been preselected. Out of the box, it offers a lot of features such as customisation, A/B testing and much more. We did not want to sacrifice any of this for a headless architecture. That made the choice very easy: We decided on Sitecore JavaScript Services JSS. Sitecore JSS provides a headless architecture without requiring you to compromise on the standard Sitecore features.
Zurich Airport needed to be able to keep up to with future integrations and further development.
Visitors at the Airport Use Smartphones
So far, so good. We had defined the basic architecture of the project. Initially, we were unsure how to meet the needs in terms of mobile devices: Should we develop a native app or not? We figured out pretty quickly that a native app would offer no added benefit to Zurich Airport. It would also have to use non-native functions, which would mean a lot of maintenance. But we didn’t want to give up that “app feeling” either. That gave us the idea of using a progressive web application, or PWA. The PWA works almost like a native app with all the same advantages and a sleek user experience. It provides for a consistent user experience across all devices. However, it is not accessed via a store with all the necessary permissions, but via the browser.
Passengers Want Real-time Flight Information
Flight information is one of the key features of the new solution. This is crucial to passengers: As well as their departure time, gate, check-in desk and more, they also look for opportunities to eat or shop while in transit. Passengers require current and personalised flight information for their specific context. The demands on the service providing the flight information were accordingly high. However, the current flight data service could no longer meet these demands.
That is why the project team decided to build a new flight data service based on the .NET Core and SignalR technologies. So, for this implementation, we moved away from Sitecore completely. This created an opportunity for us to drive further technical innovation. We did away with the usual pull mechanism and implemented a push mechanism instead: No longer does a device request current information (pull), but instead, changes are sent to the device (push). This way, passengers will always be looking at the current flight information without having to refresh the page.
And What About Hosting?
Hosting makes up a large part of our work. The call for tender stipulated hosting in Azure Cloud. This is a major topic in itself and exceeds the scope of this article. Read more about Azure here. You will soon learn more about this in another article.
Flight information is crucial to passengers.
A Highly Future-proof System – Thanks to Headless
Sitecore as a content provider with all its marketing automation and personalisation features is at the heart of content distribution. This allows us to quickly respond to changing demands and makes the entire system highly future-proof. Even during the implementation, it became clear that the headless approach comes with great advantages for Zurich Airport:
From a technical point of view, the modular content architecture of Sitecore comes with a huge benefit to a headless project. It allowed us to create a
channel-agnostic content model.
The architectural setup of Sitecore JSS made it possible for authors to keep their familiar WYSIWYG environment despite headless. Also, we were able to use many Sitecore features such as personalisation out of the box.
It is easy for authors working in the CMS to decide which content is to be delivered through which channel: Website, PWA, indoor navigation map or signage display on site, for instance.
In addition, Sitecore JSS generates a GraphQL endpoint (an interface), which allowed us to seamlessly make specific content available for additional applications: We can provide structured content to integrations such as the wayfinding application or services such as the Messenger Airport AI.
Frontend First, Sitecore First or Both?
How can the backend and frontend collaborate in a headless project? Sitecore has two approaches for headless development: frontend first or Sitecore first. We’ve learned from experience that a mixture of the two approaches is usually the right solution. With the connected mode, JSS provides a possibility to hook up the local development environment of the frontend with a running Sitecore instance. This allows us to pursue both approaches.
Ensuring a Consistent Data Structure in Frontend and Backend
While doing that, we had to ensure that frontend and backend are always based on the same data structure and definitions, which are called contracts. We had to do that to avoid constantly needing to adapt one or the other throughout the agile development process. Now what is a contract? The modules to be developed for backend and frontend are based on the same “contract”, which defined the module components: Does it have a title? Does it have text? How does it behave (can it be opened/closed)? What is optional, what is compulsory? This is why we set up a contract-driven development approach. It allowed us to automatically generate the required code segments in the frontend and backend. This kept them current and aligned.
Automated Preview: and What Does It Look Like Now?
For the implementation of the headless architecture, we did not use a vanilla installation of Sitecore JSS. We took it a step further: Instead of using a “blank” Sitecore JSS system, we added the “Macaw“ starter module. This lets us feed the frontend artefacts directly and automatically into what is known as a storybook – a frontend preview. The preview is automatically based on the most recent version of the code. This way, the customer and project team can check at any time to see what the frontend looks like now and how it behaves – without any additional work required by frontend developers.
We had to rethink. Again and again.
Carving New Paths & Creating a New Common Language
We were confronted with plenty of new things in this project – exciting things, challenging things, but also many difficult things. As a consultant and former software developer, I had multiple roles in the project. It was my job to “translate” the UX and business requirements into Sitecore language and to define the fundamental architecture of the Sitecore solution. You could call my role that of a “requirements engineering business analysing solution architect”. I had a comprehensive overview of everything, but was also at risk of having to find solutions for all problems. One thing we learned for sure: Novel technologies and new approaches also require you to carve new paths at times, and the people involved require training.
New Approach: Content First
Even when specifying the initial features, we realised we would have to rethink development. We would have to shift towards our UX specialists’ content-first approach, because the configuration of content such as the image alignment would be completely different depending on the channel and the frontend. That is why we generated the content model based on the content and not based on the design – which, incidentally, is also a wise approach in non-headless projects. This new perspective also required our customer to change their way of thinking, because discussions about the content frequently also trigger conversations about the website design.
Rethinking the Development Process
Compared to other projects, the development process has changed considerably. The development team kept running into new challenges. They also had to carve new paths for themselves. We had to start thinking in content models to ensure correct rendering of the headless structures and a correct interpretation in the frontends. Our contract-driven development (see above) supported this new approach really well. Without contract-driven development, we would probably have frequently redeveloped modules either in the backend or frontend.
A Common Language for Frontend and Backend
This approach also changed the communication: Backend and frontend developers agreed on a common language based on the defined contracts. This brought about much closer collaboration between the two disciplines. Observing this shift from my point of view was really fascinating.
Sitecore JSS Challenges
The new technologies also came with various challenges. Some aspects of Sitecore JSS and the other technologies used turned out to be stumbling blocks. Our usual approach of setting up a multi-site/multi-language construct with Sitecore no longer worked in this project. Sitecore JSS does not factor in one JSS app serving several websites at a time. To make this happen, we also had to carve new paths and adapt the system several times. Site resolving and link generation are just two aspects I would like to mention here.
How “headless” is Headless Sitecore Really?
Many of you may be asking yourselves: How much “headless” is there in headless Sitecore? Personally, I think this is more of a philosophical question that can be answered in different ways, depending on the perspective. I always speak of “decoupled”, since many content settings still trigger a reaction in the frontend. However, this comes with the advantage that in a headless construct with Sitecore JSS, you can edit the content with a WYSIWYG editor while still delivering headless content to several frontends. Sitecore’s strong points are not affected by this, since the out-of-the-box features are fully supported.
A New Standard for the Future
The airport project sets a new standard. There is no denying that the new approaches we selected came with some significant challenges and changes. But they also made us evolve. In my opinion, we should continue to realise Sitecore projects this way in the future.
Beware: Content Management is Here to Stay!
Even a headless project comes with a familiar motto: A website’s key asset still is and will always be its content! Without well-maintained content, even the most innovative platform will flounder. A headless project does not reduce the amount of content management required. There may be shifts, but content management may even require more time now because more systems get their content from Sitecore. However, authors can still use familiar interfaces and structures to edit their content.
The chosen architecture and the building blocks created provide Zurich Airport with a tool that opens many doors.
What’s Next?
That is a brilliant question. The chosen architecture and the building blocks created provide Zurich Airport with a tool that opens many doors and new avenues. They can create new frontends for the same output structure, allowing them to serve new channels such as the display boards on site. They can easily and swiftly generate additional websites for booking parking or for business and partners on the same basis. Existing functionalities can be enhanced with minimal work required.
We have made more plans with the airport, and the implementation is already underway. Keep an eye out for what’s coming!
Contact for your Digital Solution
Book an appointmentAre you keen to talk about your next project? We will be happy exchange ideas with you.
Contact for your Digital Solution with Unic
Book an appointmentAre you keen too discuss your digital tasks with us? We would be happy to exchange ideas with you.
