Headless CMS: the pros and cons

Headless certainly isn't a new trend in the Content Management landscape, but Headless CMS's have been growing stronger and stronger for the last couple of years. Many traditional CMS vendors have jumped the train and started offering a headless implementation option in one form or another. But should you invest in this solution? We'll talk about the pros and cons in this article. 

Headless CMS?

A Headless CMS is a new solution with a strong focus on providing content to anyone, anywhere, anytime. It's an implementation approach, that can and should be considered in many cases. Let's compare a headless CMS to a traditional CMS, which is still dominant at this point in time. 

In a traditional CMS, when a visitor requests the homepage, that request is sent to the CMS, that CMS will look up the content in the database, and return a HTML document. The HTML, after parsing by your browser, can then be understood by the visitor. When looking at a headless CMS, a specific page can still be requested, but the return will not consist of "easy to understand" HTML, but of a format that is meant to be understood by another software layer. And this layer will then return a HTML document.

The HTML, after parsing by your browser, can then be understood by the visitor. It basically boils down to this: when using a headless CMS, an extra layer is added between the CMS and the website visitor. Let's talk about why we would want to add an extra layer (and complexity). 

Headless CMS: the pros

There are a couple of reasons why a headless CMS could be beneficial. It is often considered as more complex and expensive without any real benefit, but we'd like to argue the opposite. 

Simplification

The added complexity actually simplifies the architecture. When the CMS fetches the content from the database, it returns an HTML document that already passed through a data access layer, business logic layer and presentation layer. 

The only difference is the presentation layer, which is spilt into the right responsibilities: a general presentation layer which converts the content to a comprehensive set of content, and a channel specific presentation layer, which ensures the right conversion between the content and used channel. 

Independence & omnichannel

This extra layer does not only simplifies the architecture, it also ensures a level of independence between the website and the CMS. The CMS doesn't give an HTML output for the web channel, but it outputs content in a format that is understandable, and can be transformed to the web. The Headless CMS has no first class citizens anymore: the web isn't the only channel that matters today. It can provide content for websites, mobile apps, newsletters, point of sale systems, internal communication screens, directly to external stakeholders and so on. The WCM, or web content management, is dead - an omnichannel approach should be the standard going forward, for all the content that you write, store and deliver. 

Made to experiment

We have a decoupled CMS and an extra layer that ensures that each piece of content matches its channel. Those different layers all have their own responsibilities. And within those responsibilities (eg. showing the content on the website) experimentation can be pushed even further. Every channel only affects its own. This means that the presentation on the website for example, can only affect the presentation on the website. And it can not impact the presentation of the content on your mobile app in any way.

Cost

The answer that everyone is waiting on... does it cost more to implement a headless CMS? Yes and no. It could be more expensive when you are planning to deliver content on multiple channels; each channel will have its own development cost. But, when you are comparing a headless CMS to a normal one for one channel, there is no extra cost. On the contrary, there is an improvement of the experience and an increased separation between front-end and back-end, which allows for a more stable platform that is easier to extend. 

Which option to choose?

Should you create everything in a headless architecture? Yes, if you have the opportunity, you should not hesitate. Your website might be your only CMS channel today, but keep in mind that we live in an omni-channel world. Does your visitor only interact with your company on the website? No, your visitor has multiple digital touch points across the world and across a multitude of channels. So why would you develop a platform only for one single channel? Next to that it is important to know that we can only guess what the future might bring. In the end building something future proof does not mean that you need to develop features that you don't need now, but might in the future. It only means that you should build what you need, and keep the future in mind. The extra flexibility you get with a Headless architecture, can only help you later.

Think before you create

Headless certainly is a good trend in the Content Management Landscape: it simplifies the architecture by ensuring a better separation of the responsibilities. It allows for easier experimentation and has no increased development cost.

But, as always, there is no one-size-fits-all solution. For every pro, we could probably come up with a con. It's important to think about which solution would fit your organization best. Think before you create, to allow ultimate acceleration of your platform.  Are you still unsure whether to implement a headless CMS or to go a different route? We are happy to help. Let's discuss which solution fits your business best.