At first sight the title might sound a bit spooky, especially in the middle of the Halloween season but “headless” is actually a technical term and simply refers to the presentation layer of your Content Management System.
To further increase the confusion, in reality, the goal of going headless is to enable having multiple heads and serve them from the same source. So, let’s take a step back, examine how traditional or so-called monolithic CMS systems work and discover the advantages of the new approach.
If at any point you feel that the terminology gets a bit overwhelming or hard to follow, we prepared a software technology cheat sheet with quick descriptions that you can easily check for help at any time.
Traditional CMS systems
The traditional CMS approach is to put everything in one big bucket: content, images, HTML, CSS…etc. If you think about a classic WordPress, Drupal or SiteCore based page, in essence they are built up of 4 different parts:
- There is a Content Creation layer, essentially your Admin page where you or your content creators can log in and upload their creations. Blog posts, pictures, edits..etc.
- This content then gets stored in the Content DB as data.
- In order to display the content these systems are usually built using Templates, so there is a nice design and look assigned.
- As an end result, there is a webpage or blog..etc. that visitors can check and start consuming your content.
If you look at these stages, you see that they create a coherent and integrated (coupled) system and workflow and it might seem that removing elements from it would actually take away from its functionality and make it “less” usable.
However, decoupling 1.- 2. so the “body” from the frontend or “head”, so separating them from 3.- 4. actually allows you to deliver the same content to multiple outputs and have an omni-channel solution. As an example, the same content can be displayed on a website, in a mobile app, on an airport screen or even through an Alexa like voice interface.
Content-as-a-service
A headless CMS heavily relies on using Application Programming Interfaces or APIs in short. This creates the connection or integration points and the output is raw data most likely in JSON format which allows it to be connected to IoT devices, even your new fridge, or your Apple TV or an EV making new and creative uses available. Headless is starting to dominate the market because it brings many advantages, it is most often cloud-based and available as SaaS (software as a service) solution.
As a response to the growing popularity of headless CMSes, some of the traditional CMS vendors started to add APIs on top of their systems and market them as “decoupled”. In theory, this decoupled approach promises both website rendering capabilities and the flexibility of headless in the same package. However, in reality, the decoupled CMS APIs are heavily influenced by a model built for a single website (or output) which at the end still means a form of coupling, introduces limitations and restricts the amount of contexts that your content can reasonably be applied to.
There are many terms in use to describe what a Headless CMS is like Content Hub, Content Infrastructure, and Managed Content as a Service.. etc. These all describe the idea fairly well since Headless CMS essentially offers a repository for storing content that is ready to be delivered somewhere.
Headless CMS hosts all the content that teams need to produce for all digital entities – text, images, videos, files, etc. – and stores them as structured content within the CMS so development teams are able to query this content via API, distribute them to any digital frontend from a single source whilst working with modern and preferred technologies. In the long run, the main advantage of this approach is that it creates a more scalable architecture and removes content silos.
Pros vs Cons
A headless CMS is usually:
- Faster, Easier and more Flexible to develop on
- More future proof for your content
- Has a better omni channel architecture
- Much more scalable and secure
- No versioning and it leads to better software architecture
- All content in one place, reusable content, only authorize once
If you think about the classic approach, building a new site is a big decision, probably a steeper learning curve and a bigger effort to configure. Once everything is set up, you need to keep up with software versions and as content gets bigger and the system is getting more and more complex things get slower and more difficult to alter. Usually, after a few years, this gets to a point where you decide to redo the whole thing and almost start from scratch again.
By separating the data and the presentation layer, headless CMS solutions not only allow you to use the same content on multiple platforms but also allow you to reuse the same content when rebuilding your site or adding a new display type.
The headless approach has many pros and the only real thing that could be considered as a con is that it can require more development time especially when first setting things up. This is natural as you are essentially building a more well-integrated and interlinked system that quickly returns the initial investment.
Taking the idea a step further
To provide a real-life example that can hopefully spark some new ideas, I would like to mention one of our bigger projects for one of the largest sports teams in Central Europe. There are many different surfaces for the fans to consume content on about their favorite team, website, mobile app, projectors in the stadium, TV displays..etc. and in order to provide the highest quality experience, the CMS needs to be linked to many other internal systems. The ticketing system, the gates, merch stores..etc. all need to be orchestrated so fans can have a hyper-personalized experience.
This requires constant training for the team, continuous development efforts to keep all systems in sync and usually really detailed planning before adding anything to the existing complexity of the setup. So when the team a year ago decided to introduce a new food and beverage ordering solution for the stadium that lets fans place and pay for their orders from within their fan mobile app they wanted to keep everything under one hood and manage catering setups and menu items from their existing backend.
Luckily OrderStride can be really well integrated and it also has a really detailed API so it allowed us to place it as part of the existing admin interface, under a new menu item, saving some valuable time in both learning and logging in and out of a new system. As the ordering also has many different outputs, there are TV screens at the buffets for displaying the status of the in-progress orders, tablets on the caterer side so they can track and manage the orders and also in-app notifications and confirmation emails, it made perfect sense to handle them under the same pre-existing CMS.
If you would like to tip your toe into a new system integration project or you are thinking about how you could switch to the headless approach, please reach out to us for a discussion as we might have some valuable tricks and tips for you.
