For the past few years, there's been a lot of talk about about headless content management systems. We've been hearing it popping up in a lot of conversations around web technology, and the maturity of the products in the market built on the concept has improved dramatically. But where did it first come from, and why would we want a headless CMS? Before we dive into the technical aspects, let's put it in context.
Content management and how it's developed
Think about how your web experience has changed over the years. It started with a desktop computer, probably with bigger screens as the years went by and then a new channel emerged next to it: mobile. Then the tablets appeared followed by smart watches, smart home speakers and so on. More and more channels are appearing making digital interactions possible in many different forms. Even in this list we can see that the old-fashioned browser-related experience is not the only way to digitally interact, the journey is also changing. For example, it’s completely normal now for a user to start a purchase on a desktop, then pick it up and complete it over mobile later on.
The question then becomes, how do you manage all these experiences on different channels and devices, and how do we keep them consistent? This is where the headless CMS comes in.
Getting to grips with what it means to be "headless"
Traditional CMS usually allow authors to change the content and play around with front-end options. This makes it a very suitable tool for marketeers, or authors, who don't want to rely on IT too much. Marketeers nowadays need to create more content and faster than ever before (more on this later).
For example in a traditional workflow, marketeers get to play with WYSIWYG editors to make their pages and content look exactly how they want.
The challenge with this type of CMS is the number of channels and devices. There are so many options out there today and it becomes very complex for IT and marketeers to deliver the same content over all these channels and keep their message and experience consistent.
With a CMS that is intertwined with the frontend delivery and presentation layer of the content, it is nearly impossible to manage everything flexibly. Inevitably, marketers have to make compromises on how content is presented across all their channels.
The approach with a headless CMS tries to address this problem.
Essentially, the headless CMS is a repository for your content which does not have options or a system for the frontend presentation. All your content is purely stored in its raw form. So to continue with the ‘headless’ terminology, we can place as many heads on this CMS as we want. We do this with an API which pulls content data from the CMS and distributes it to as many channels (heads) as you want.
The frontend is not the only area that’s simplified by headless CMS. Think about all the content systems your channels derive information from. These could include PIM, CRM and shop info, stored in a range of different systems or databases. As the diagram below shows, integrating all those systems with each other can make for a complex web of connections which is very hard to maintain.
By connecting all the systems to one API, the infrastructure can be a lot less complex and easier to maintain. Data suggest that the average enterprise uses 91 marketing tools, which makes a strong case for a headless solution as something worth looking into.
Has it all been resolved now then? Headless for everything?
You may start to think, ‘wow this is fantastic, why aren’t all CMS’s headless’? There can be a downside. Marketeers are limited with their author options; they can manage the content and distribute it to many channels but managing its presentation becomes more complicated. The front-end work is disconnected, making it easier for IT to do change requests. But now it seems marketeers must go through IT for every front-end change they need. This makes it harder to respond to user behaviour changes and to adapt messages.
The hybrid (or decoupled) CMS came along because the pure headless CMS resolves a few problems but creates others. For marketeers it’s not always the ideal solution. Remember that the marketeer needs to create more content than ever before? That’s down to two main reasons: one, the number of channels that need to be services, and two, the fact that user journeys are not linear anymore. Today’s users browse from their mobile, over to their desktop and interact with your company in many different forms. To keep the journey consistent and relevant (different topic but equally important) the marketeer is forced to create more content.
The hybrid CMS combines both requirements, making it easier for IT to do integrations via an API and marketeers still get to enjoy frontend options to play around with.
A hybrid CMS is often also called a decoupled CMS. The image below shows what the fundamental difference is. It basically comes down to having both the options of the traditional CMS with all its front-end options, but also the decoupled option for other data to deliver to devices/channels via an API.
In conclusion we can say that the headless CMS is not the complete solution, it’s just another tool in your toolbox. It really depends on the situation whether the headless CMS is the appropriate solution. The same applies to the hybrid (or decoupled) CMS. Here are a few examples where the options discussed in the article are probably appropriate:
Publishing non-web content: In this example one can think of several mobile apps which need some content. A complete CMS might be too advanced and over the top where as a headless solution might be the right fit.
Segmentation of content: In this example it might be that the website has two types of content, one is normal web content, the other is very technical data. In this situation it might be useful to have a traditional CMS for the marketeers to manage the web content and a lightweight headless CMS for the technical data. In this scenario, another option could be the hybrid / decoupled CMS.
Clearly there are many other scenarios one can think of but the essence of making a choice between all these options really depends on the functional requirements.
Wherever you are in your CMS choice, we’re here to help. Whether you’d like some fresh thinking or a complete solution built around your unique needs, just get in touch.