Headless certainly isn't a new trend in the Content Management landscape but Headless CMSs have been growing stronger and stronger the last couple of years. Many traditional CMS vendors have jumped the wave and started offering a headless implementation option in one form or another. But should you invest in this old "trend"?
##Headless CMS? A Headless CMS is a new type of solution, it has a strong focus on providing content to anyone, anywhere on any channel. It's an implementation approach, that can be considered in many use cases. Let us take a moment to compare a headless CMS to the traditional CMSs, which rule the landscape for now.
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.
So if you boil it down to the simplified basics, in a headless CMS an "extra" layer is added in between the CMS, and the visitor. So why would one choose to add that extra layer? And adding the complexity...
##Advantages Well there are a couple of reasons why adding this extra layer can be beneficial. Headless is often considered as a more complex approach. A trend that doesn't add any real benefit but can only become that unexpected extra cost.
###Simplification So that added complexity, it simplifies the architecture in fact. When the CMS fetches the content from the database and returns a HTML document, it is already passed through a data access layer, a business logic layer, and a presentation layer.
The only difference now is that the presentation layer is split into the right responsibilities: a general presentation layer, that converts the content to a comprehensive set of content. And a channel specific presentation layer, to ensure that the content is converted to something that matches the current channel.
###Independence & omnichannel Next to that this extra layer ensures a certain level of independence between the website and the CMS. The CMS does not simply output HTML for the web channel, it outputs an understandable content format that can be transformed to the web. The CMS has no first class citizens anymore, web simply isn't the only channel that matters today. Your CMS can provide content for: websites, mobile apps, newsletters, reception screens, point of sale systems, directly to external stakeholders, and many more. The WCM is dead, and omnichannel should be taken into consideration for all content that you write, store, and deliver.
###Easier Experimentation So we have a decoupled CMS and an extra layer that ensures the content matches the 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 Is there an extra cost when using the headless approach? Well it could be, if you are planning on delivering your content to more channels than the website. Then yes the development of these extra channels will have a cost. Also the headless offering of some vendors comes at a higher cost. But the development cost does not increase. On the contrary there is an improvement of the developer experience and the increased separation of concerns that allow for a more stable platform that is easier to extend.
##Should you? So should you create everything in a headless architecture? Well 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 touch points across the world and across a multitude of channels. So why would you develop a platform only for that single touchpoint, that 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 So 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 silver bullet, everything that can be said to always use a headless approach can also be said to not use it. For every problem there is a solution that fits your need, but there are many more that simply do not fit. It's important to think before you create to allow for ultimate acceleration.