Why headless CMS?

Perhaps you have heard of the headless (or “decoupled”) CMS. What’s all the fuzz? Why, and – perhaps most importantly – when, is a headless CMS relevant? Is it time to part from your traditional CMS?

If we are to address the value of a headless CMS we need to see the context – or the current state – of digital and where we’re headed. In the last years, we’ve been witnessing a shift in how the primary focus of digital platforms has moved away from supporting existing business models to instead disrupting them.

Innovation, often in the form of startups, disrupt markets. Innovation shakes the very foundation of established players. And, in the innovation process, a great advantage is to reach the customer with new services at speed – relentlessly experimenting and adapting. Delivering content and capabilities in different and new channels – utilizing the full potential of both native and web applications.

Just as startups are finding their specialized niche they can take advantage of, we also see a rise in specialized components in favour of monolithic applications. This; delivering new capabilities at speed in the innovation process, disrupting markets and adapting, is why the headless CMS is becoming more and more relevant.

So, what’s a headless CMS?

The traditional CMS is often a one-stop shop application. Packaged with data storage, back-end, front-end and other plugins which ultimately delivers a single application – what we commonly refer to as a monolith. These applications grow to contain more functionality, more components, more stuff.

A traditional CMS is often a web-first application. It naturally assumes that the content will be delivered via the HTTP protocol and serve content in the format of HTML. Should we create a smartphone or smartwatch application then we would most likely need to extend or modify the CMS. It usually wouldn’t be natural for it to deliver content through other protocols or channels.

This is because the traditional CMS is commonly built with back-end and front-end bundled into a single application that is web-first. One web component assumes the presence of the other.

The headless CMS is only back-end. The content is delivered through an API that doesn’t care about the front-end. Therefore, it’s referred to as headless ­– there is no head (front-end) with which to deliver the content.

The content from a headless CMS could be consumed with a completely different programming language than the back-end. The consuming device could be a TV, smartphone or smartwatch that doesn’t know the first thing about web, HTTP or HTML. Perhaps a smart toothbrush or smart mower – not only humans enjoy great content!

We must also ask ourselves: is there a value in a lasting front-end? When the development team wants to upgrade a framework, library or other of the front-end,must the CMS follow suit? When we have delivered the website – are we done? Do we only do incremental upgrades until we, once more, start over?

I believe that the value lies in the content. Then the question begs the answer of how fast we can add new delivery channels, new formats, new programming languages or new devices with which the content reaches its intended audience and adds value.

Let’s drop our current CMS!

No! The traditional CMS is still fantastic and we love it. If the context – and requirements – of our audience and content still favors the traditional CMS in its web-first approach then there is no reason to change – at least not right now. If we are building a new application that is app-first or should deliver content across multiple devices, formats and protocols, then the headless CMS should be considered.