The headless CMS space has gained traction in recent years, leading to the renewed excitement around a content management model that can help brands handle the relentless number of emerging devices and channels.
Old debates about the relevance of headless content management have reignited, leading to the invention of new acronyms and spin-off buzzwords that attempt to explain the storm in the CMS-teacup.
But with new jargon, comes new levels of confusion. So, let me break it all down for you.
Before we define headless content management, let’s first recap on how a ‘traditional’ CMS works.
With a traditional CMS like WordPress, Drupal or Joomla, users create and edit their content through tools like a WYSIWYG editor or an HTML editor and save it to the back-end database. The CMS then displays the content according to the front-end delivery layer built into the CMS.
In WordPress for example, that layer looks like a WordPress template, governed by cascading style sheets (CSS).
A traditional CMS is sometimes referred to as a ‘coupled’ CMS — we’ll discover the reason behind that later.
If a traditional CMS was a body, the “head” would be the front-end components like the front-end framework and templating system. If you chop that head off, and you’re left with a headless CMS.
A headless platform has no default front-end system to determine how the content is presented to the end user. Instead, it’s front-end agnostic, meaning that your content is raw and can be published anywhere, through any framework.
By getting rid of the front-end delivery layer, your CMS is suddenly a content-only data source. It produces content and then sits there. Waiting.
What’s it waiting for? Well, because there is no default “head”, front-end developers are free to build as many heads as they like, for however many channels they want to serve content to (think websites, apps, kiosks, billboards, smartwatches, etc). To retrieve the content for each channel, the headless CMS responds to API calls.
I consider headless content management to be a sub-set of decoupled content management. That’s because a decoupled CMS is headless, and then some.
With a decoupled CMS, your content is managed separately and is front-end agnostic, just like a headless CMS. Yet, it has front-end delivery tools in the box, like templates, if you want to use them.
The difference is that the back-end and front-end are not “coupled” to each other through a database like with a traditional CMS. Instead, the front-end and back-end communicate to each other through calls to an API.
So, remember when we chopped the “head” off a traditional CMS to make it headless? Well, imagine the same scenario here, except this time, we kept the head. It’s not attached to the main body as with a traditional CMS — but you aren’t totally left to your own devices when it comes to front-end delivery, like with a headless CMS, either.
It’s the best of both worlds, you might say.
Let’s dig a little deeper into what makes these two models so different.
With a headless CMS, you have modeling and editorial tools to create and edit content. But the concept of “publishing” content just means making it available via an API. It assumes that you and your nerdy front-end development team can handle the rest with whichever frameworks and tools you prefer.
A decoupled CMS, on the other hand, doesn’t assume anything. It does everything a headless CMS does, but it doesn’t stop there. It also says, “Hey, we’ve got some templating tools here so you aren’t working from scratch.”
That’s just good manners, right?
Blend Interactive CSO, Deane Barker, summed up the difference between decoupled and headless content management quite succinctly:
“A decoupled CMS is proactive — it prepares content for presentation and pushes it into a delivery environment. A headless CMS is reactive — it manages content, then just sits and waits for some process to ask for it.”
For marketers, this subtle difference can be a significant one. While the decoupled CMS uses the templates, WYSIWYG editing, and other tools are customarily seen with traditional CMS systems, many of those tools are not available in a headless CMS architecture. However, purely headless systems allow more control over how the content appears on each type of device. So, more fun for eager front-end developers, less fun for non-tech savvy marketers.
The headless content management model is growing in popularity — and we’ll explore why that is later. But before that, here are the benefits and drawbacks so you can evaluate the model for yourself.
Let’s circle back to the comment I made earlier about the headless CMS space gaining traction. The reason for the surge in the hype surrounding headless content management (and by definition, decoupled content management) is because multi-channel publishing is increasing in complexity.
Again, publishing on multiple channels is nothing new, and most traditional CMSs have allowed for this. Think of a responsive WordPress template, for example. You publish your content once, and the template is flexible enough to showcase it on desktop, tablet, and mobile. Boom, multi-channel baby!
But as we move deeper into the era of IoT, publishing to a handful of channels is no longer cutting the mustard. Large brands want the power to publish their content anywhere — because new channels and devices (such as smartwatches, VR headsets, and smart home assistants) are popping up faster than you can say Content-as-a-Service. Speaking of which…
Here’s another buzzword playing a role in the headless CMS realm.
Various headless CMS vendors are claiming that their model of content management can be described as ‘Content-as-a-Service’ (CaaS), a sub-set of ‘Software-as-a-Service’ (SaaS).
Software-as-a-Service isn’t about the technical inner-workings of a CMS. Instead, it’s the model used by vendors — and favored by brands — to sell their software.
Instead of building their own technology, or buying licensing fees from software vendors, many brands are turning towards cloud-based software that they can pay a monthly subscription for. The software is managed and hosted by the vendor, leaving the brand to “borrow” the technology to build and scale their digital presence. Hence, it’s a software, but in the form of a service.
As headless content management gained traction, so did the term Content-as-a-Service, because, you know, a headless CMS is all about the content, and nothing but the content.
It’s worth noting that the demand for SaaS products is growing exponentially, with IDC forecasting that by 2020, penetration of software as a service versus traditional software deployment will be over 25%.
So, if decoupled CMS gives you the best of both worlds (headlessness plus front-end goodies) when it comes to content management, and a cloud-based SaaS (or CaaS, if you want to be super specific) model is the best way to “borrow” that technology. I guess the ideal solution would be a Decoupled SaaS CMS. If only such a platform existed…
The future of CMS is quickly moving away from traditional, database-driven systems and toward API-driven headless or decoupled systems.
Consumers are making use of more devices and channels than ever before, and brands simply have to meet them there in order to provide quality omnichannel customer experiences. Going headless, whether that’s through a pure headless CMS or a decoupled CMS, is the simplest way to achieve that.