Deciding what kind of Content Management System to opt for is made much easier if you know the ups and downs of the headless and monolithic types.
Content Management Systems (CMS) are software systems or platforms that let you create, manage, and publish content to sites, apps, and other outlets.
So what’s a “headless” CMS? And why are they great for publishers and businesses doing lots of content?
In their most basic form, a website front-end and its CMS back-end are conjoined and effectively occupy the same piece of infrastructure. This would be termed a monolithic CMS, and you could just as easily say ‘a website that contains its own CMS’.
Such setups can be so closely coupled that to log into the CMS you might even use the public website domain, with a small variation in the URL for an admin or login page. And the conjoined CMS will not send content anywhere else than just its attached website: if you want to send content to apps or other sites, you need another CMS (or some hefty modification work). Annoyingly, if one side slows down or fails, it can bring the other side down with it.
Think of it like a small village bakery: the shop and the baking ovens and all the equipment are in the same place. If you grow and want another shop, you buy it all again. and if you need to up the bun output of the bakery, you build an extension for some bigger ovens, or go looking for a bigger shop. It's all bunched together, and if the buns catch fire the whole place gets shut.
For lots of small and relatively simple sites, these kind of self-contained 'site+CMS' setups were the norm and still quite acceptable. If you were new to the need to run a website, at first glance it probably seems the easiest solution: you have a website, and the content goes almost directly into the website - what could be easier?
But for serious enterprise users or publishers producing lots of content from lots of users, monolithic CMS will be so limiting that they would not be recommendable any more. The alternative will be what’s called a headless CMS.
Headless CMS completely separate the front-end and back-end systems and treat them as independent entities which are connected by APIs - simple and flexible connections that send information back and forth between separated systems.
With a headless CMS, you build your website as simple or powerful as you like, and tell it to look at an API connected to the CMS to get the content to go in each section and page. The site and CMS can be on completely different infrastructures, databases, and URLs, and if either is busy or under maintenance it should not effect the other at all - in fact you could in theory shut down one without effecting the other.
You can make countless changes to your sites without needing to make any change to the CMS, and vice versa. Most appealingly, one headless CMS can run countless outlets - not just a site or sites, but apps, newsletters, other CMS, syndication, social media, and so on. It is an enormous force magnifier.
Instead of our single bakery with its own ovens and equipment, think of a headless CMS as a separate baking plant that can supply an unlimited number of your shops, and other company's shops too if you branch out. To drum up local trade you can beautify each shop as much as you like without having to touch the baking facility each time, and if staff have new ideas for tasty treats you change the recipe just once - not time and again in each shop. No wonder headless CMS are as popular as hot cakes!
So what are the benefits of a headless CMS, especially for a publishing company or anyone doing lots of content and lots of updates?
Choosing a CMS is the easiest part of the project. Making it work properly and efficiently is the difficult bit.
The biggest win is gaining flexibility in your business objectives.
A monolithic CMS can double (or more) the development cost and time taken for each new feature or update to make it to production, because the different sides of the system are so closely linked you may find it impossible to make changes to one without making changes to the other, as well as all the extra testing necessary.
This becomes even more cumbersome with multiple front-end channels. Let's say you have one CMS for a site, one for an app, and one for newsletters, and your business wants to introduce a new user experience to all of them: all three CMS will potentially need updating and testing to introduce the new feature. Not only is that needlessly expensive, but you may wait three times as long for it all to be ready to launch. All of a sudden that simple idea has triple the cost and time attached to it.
A headless CMS and its channels are insulated from one other, so you can make significant changes to any without fear of breaking the rest, and test them much more nimbly. This speeds development enormously and if all your channels need an update, you only have one CMS to tweak (if it even needs it).
The things that grow your business are where you should focus your development muscle and budget. With front-end technologies changing so quickly, and increased demands from your audiences to be on their devices and platforms, it makes sense to commit your development strength to those revenue-generating channels and projects.
How does that square with the expertise required to build, manage, and maintain a Content Management System - especially one suited to big publishing operations? A monolithic setup means teams and projects often blur into one, slowing every aspect and demanding a skillset from your developers that is unreasonably wide, a nightmare to recruit for. Do you want your top cake-maker and decorator to also need to be an oven engineer and air-conditioning wizard too?
Headless CMS give independence of outcome. Your front-end teams go full bore on launches and new products that bring in revenue, while a separate CMS team manages everything on the content management side of things - which, to quote Liam Neeson, is a very particular set of skills. Launch pace and costs become a fraction of what they could be with old-style setups.
Remember we said that with old-style monolithic setups, if one side slows or fails it can bring the rest of the system down? How might that come about? Most frustratingly it's often at the exact worst moment - when you have a major traffic spike: just as a mass of users come to your site, the increased burden can cause a creaking CMS to collapse. In the worst case both sides go offline, dragged down like Captain Ahab roped to the whale.
With a headless setup, you can configure your site to scale in complete independence to the CMS, and vice versa - for example to downscale the power of your CMS stack on evenings and weekends when it might be unused, while at the same time giving your front-end super responsive flex to manage floods of traffic.
The peak of monolithic CMS inefficiency comes when editorial and content teams have to rekey or copy content across different CMS to send it to different channels. Or even just to different pages in the same site. It's like email before someone invented CC-ing.
Headless CMS mean you create content just once, and send it to multiple places and platforms as default. For some organisations, that includes print operations, going digital first for content creation and even being able to eliminate old print CMS too.
Because headless CMS work via APIs, it means they are geared towards the ways of working that the rest of the internet uses. So, external systems and tools such as ad platforms, paywalls, identity management, single sign-on services, Digital Asset Management systems and countless others should integrate far more easily than trying to hardwire them into an old-style CMS.
Splitting your audience channels and CMS can yield major improvements to your overall security, by removing an attack vector for bad actors. Monolithic CMS tend to be easy to spot just by scanning basic website code, and if a determined hacker has some knowledge of security vulnerabilities those platforms have, attacking your site just became much easier. WordPress, for example, makes its security updates publicly known, so it's easy to go scanning for sites that are lagging behind. Publishers are as vulnerable to this as any other business.
