The CMS world goes through a revolution during which it reinvents itself every few years. 

Currently, the latest trend is the so-called ‘headless’ CMS, which completely separates the management of content from its presentation. 

As a result, a question arises from website owners and web developers: do we need a headless CMS?

Headless CMS offer many advantages compared to traditional CMS, but the added value is also dependent on the context, the number of channels, and what you are trying to achieve with your content.

In one of our projects, we followed a headless approach and learned a lot from it. 

Today, we would like to share our learnings with you and hopefully, this will help you decide which direction is best for your future web project.

What are the advantages of a headless CMS?

A headless CMS differs from a traditional one, often described as ‘monolithic’ CMS. 

In a headless fashion, the content and presentation layer of the website are completely separated.

Moreover, the presentation is outside of the responsibility of the CMS and must be implemented elsewhere.

The headless strategy does have advantages: the CMS can only take care of the content, and its functionalities can be completely optimised for just that. 

As the content does not contain any information about how it is to be presented, the same content can be used for several output channels – such as the website, a mobile app, social media and even print media at best. 

In contrast, a monolithic CMS takes care of both the creation and the presentation of the content in ‘pages’. The page structure ultimately corresponds to the navigation of the website. 

Depending on the architecture of the CMS, content may be placed directly on pages, which makes content reuse difficult on other channels. In other architectures, there may exists a certain logical decoupling between content and design. 

How does Adobe Experience Manager manage content?

In Adobe Experience Manager (AEM), the CMS within the Adobe Experience Cloud, content is usually assembled directly by the authors into pages that then correspond (more or less) to the web pages 1:1, even if, technically speaking, the content management and the presentation of the pages are separated. 

Why am I telling you about AEM? Pretty simple.

Firstly, because One Inside is a certified Adobe Partner and our teams are experts in the implementation of AEM projects.

Secondly, because it was the CMS used for the project (as in almost all of our projects).

Now let’s talk about this project.

The project: going headless at any price

The goal of the project was to display content (already available on the website) in another channel: a digital kiosk.

A digital kiosk is a ‘vending machine’ consisting of a computer and a touch screen. The users of the digital kiosk can get informed about the products offered in a self-service way.

Our team joined the project relatively late, after the technical solution had already been designed.

The kiosk leveraged Angular to display information to its users.

The (front-end) application of the kiosk was already halfway implemented. The architectural decision had been taken as well: the kiosk should store all content locally, on the device. 

As the solution was designed, it was not possible to benefit directly from the main website created in AEM. Otherwise, it would have been possible to create a version of the website adapted to the kiosk with relatively little effort.

Instead, REST-APIs had to be used to provide content to the kiosk. A library of JSON objects had to be defined for the content and the configuration of the kiosk. Thanks to the openness of AEM and direct support of REST and JSON, this could be implemented with reasonable effort. 

Is headless always best?

During the project, another advantage of separating content and presentation was highlighted: the frontend team and the backend team could work independently from each other.

The backend team was in charge of managing the content in AEM while the frontend team took care of an Angular app for the content presentation.

Each team can 

• concentrate fully on their area of expertise, 
• work with their usual technologies and frameworks, 
• and hardly has to consider the other party.

A weekly coordination meeting plus an interface definition (properly documented) is sufficient for the team’s collaboration.

The architecture diagram above shows that the headless approach is justified for this use case: in the course of the project, other screens and devices will be connected, each device via its own interface. 

These can be implemented in a short time with little consultation between the teams – and new channels or devices can be added at any time. 

Welcome to the wonderful world of headless CMS!

Now all existing monolithic CMS can be replaced!

Or maybe not. 

With the first mentioned device, the kiosk, we could have saved a lot of time in our project if we had simply implemented a slimmed-down website directly in AEM. 

Headless was an overhead and introduced unnecessary complexity.

A lot of functionality had to be created using different technologies that would have been available already.

AEM’s CMS is powerful and offers the possibilities to create a light version of a website, for example based on Experience Fragments.

Too much effort for simple websites

Especially for websites or web-related channels, the headless approach might not be a better solution than a traditional approach. 

While backend for content repository is built (the CMS), the frontend is created completely independently (with Angular, React or a similar framework).

On the front-end side, everything has to be developed from scratch. Every component, every page template, including the entire navigation. 

This is an additional effort that should not be underestimated compared to design adaptations of the existing website with AEM and Core Components.

Think content first

What is overlooked is what I believe to be the biggest problem with the headless approach: how does content fit into the website, or rather how is a page structure defined?

On a highly structured site such as a news portal, where articles are assigned to categories (e.g. politics, sports) and displayed by topics, this can be done automatically, and similar solutions can be found for e-commerce.

In such cases, when the navigation can be automated, a headless approach might be appropriate. 

For an average corporate website where content is displayed in a semi-structured hierarchy, the frontend has to request the right content.

This can go as far as that the whole navigation has to be created in the frontend making it extremely difficult to support it via the backend. 

All functions for structuring content, which are taken for granted in a conventional content management system, must be created in the frontend with great effort, if at all possible. 

In our example with the kiosk, this problem had to be solved in such a way that the entire content structure per device is maintained in the CMS and then made available to the respective device as a JSON object.

The kiosk then procures the content itself and ensures the appropriate presentation. 

In the long run, the coordination between frontend and backend becomes problematic: even the smallest errors in the JSON configuration file lead to errors in the frontend. 

The advantages of a traditional CMS outweigh the headless approach in this case.

Hybrid CMS: the best of both worlds

Fortunately, Adobe has not stopped at the monolithic approach but has shown that Adobe Experience Manager is considered one of the most innovative products on the market for a good reason.

Content Services and related technologies such as Content Fragments and Experience Fragments allow content management and presentation to be separated. Plus, all content can also be retrieved as JSON objects via REST APIs. 

This approach, known as ‘hybrid CMS’, offers a headless CMS in addition to the traditional, page-based CMS optimised for websites. 

Content prepared for the website can be made available to other systems such as displays, kiosks, apps or the Internet of Things (IoT) via the corresponding APIs.

The question is no longer whether headless or not, but only: when do I go for headless and when for the traditional approach? 

Making the right choice can decide the success of a project. 

We are happy to help you choose the optimal content management strategy for your project and show you an efficient, cost-effective way to succeed. 

Talk to us.

Michael Grob

Senior Consultant Digital Marketing