The web content management landscape has been steadily shifting over the last few years. The introduction of headless (or to be more specific, API-first) content management systems has moved the goalposts. Headless CMS is nothing new – most have been around for a few years – but the last two years have seen a spike in interest and adoption.
Looking for statistics on adoption rates, it is fair to say that these statistics are thin on the ground so it is great to see this report from Kentico which provides some interesting insights into the trends and views in the market. With that in mind, I wanted to add to this overview with our own MMT Digital view on the rise of the headless from the perspective of a digital agency operating on the front lines. I’ve pulled out some of the key headlines and included some advice and recommendations along the way.
Coupled, hybrid and headless
A good starting point is to get our language straight. There are lots of terms bouncing around, from coupled through to headless. To help frame this post, let’s quickly summarise the three key terms.
By “coupled” we are talking about the traditional and arguably monolithic, content management systems that tie the front end to the content, taking control or at least heavily influencing the presentation layer.
By “hybrid” we are talking about those approaches, typically driven from the traditional content management systems, where management functionality is separated out from the presentation layer and served up through stateless APIs (or other methods) to multiple channels. You can achieve this with many of the traditional content management systems out there.
And, by “headless”, we are talking about the API-first content management systems, effectively content repositories that provide APIs to allow content to be delivered to any channel.
Competition in the market
Over the past few years, we’ve seen an ever-increasing number of API-first content management systems emerging onto the market. These range from cloud-based, SaaS offerings such as Kentico Cloud through to self-hosted, open source offerings, typically developed by agencies and one-man bands.
The next few years will be interesting as the various vendor’s jockey for position in this space. We can expect to see a number fall by the wayside, most likely due to low adoption rates, lack of investment or poor positioning. Many of the API-first platforms are all doing the same thing which is a different ball game to the traditional CMS where the competition often lay in the rich feature sets and added extras (e.g. Digital Experience Management or Digital Marketing). The winners will be those with the robust roadmaps, strong positioning and cleanest implementations of features and APIs.
However, the traditional CMS can’t be overlooked. It’s easy to think that they will simply fall at the feet of this new generation but for many of these traditional CMS, they have been plotting their own route into this space. Some, such as Kentico and its Kentico Cloud product, have moved into space with a separate headless offering while others, such as Sitecore, Episerver and Drupal, are adapting their own platforms to move into this space. Arguably, the latter is headless solutions as the presentation layer is separated out allowing you to distribute to multiple channels but, since they are to a degree still the monolithic solutions of old (lots of features for all kinds of jobs), it is easier to think of these as simply hybrid.
It will be interesting to see how these solutions fare over the coming years – particularly as their current licence models aren’t necessarily geared towards modern architectures in the same way as API-first solutions.
CMS Selection
CMS selection is an interesting one. Reviewing Requests for Information and Requests for Proposal from the past three years, there have been plenty containing feature matrices of such magnitude that even Everest seems a trifle in comparison. For traditional CMSs, this is often fine. These CMSs are crammed full of features. However, when you move to API-first, that feature matrix becomes a little redundant. These systems aren’t crammed full of features since they serve a specific purpose – to curate and serve content.
As a result, we have started to see a change when it comes to those clients embarking on the CMS selection journey. Those matrices will occasionally pop up but, more often than not, these matrices are moving aside as businesses start to grasp the capabilities of headless CMS and the accompanying microservices-based architecture.
Feature matrices aside, another aspect to CMS selection is that of cost. Arguably, the initial investment in traditional CMS is lower as you are typically investing in one platform to rule them all. With the headless CMS approach, there is not only the subscription but also the cost of the infrastructure, service layer and additional systems required to deliver certain functionality. However, this is a short-term view. To truly consider cost, we need to take a long-term view and factor in upgrades, maintenance, patches. It is at this point that the headless CMS and its accompanying eco-system comes into its own offering a more competitive longer-term cost.
The headless approach is a shift in mindset and not necessarily an easy shift. Traditional content management is ingrained in the market and full education on headless takes time. But, over the coming years, I’d expect the figures in the Kentico report to creep up when it comes to both knowledge and adoption.
MMT’s recommendation is to think through your CMS selection criteria. Do you really need a long list of features? Based on experience, I would argue that this is probably not necessary. To allow for the inclusion of headless/API-first CMS, take a different approach and think about practical, everyday usage scenarios, e.g. common tasks, potential scenarios. And think through the long-term investment into the platform. You will need to factor in initial investment, infrastructure, upgrades, maintenance and ongoing fees.
Client-side adoption
Moving further downstream from CMS selection towards the practical application of headless, businesses are already moving in that direction – some faster than others. It’s important to note that this isn’t simply a lift and shift. Businesses often have lots of systems built on a particular infrastructure (or infrastructures) that may be tightly coupled. Shifting all of them requires careful planning.
The key ingredient here is the service layer. Elements need to be separated out and the service layer is used to power all manner of digital experiences and channels. It can be tricky to get right and we have seen good and bad implementations. It’s not cheap by any means but if implemented correctly, can give you big rewards further down the line – flexible architecture, access to the latest technology, improved performance and speed to market.
As a result, what we have started to see is an increase in experimentation. Businesses are using headless CMS to power microsites and campaign sites to enable them to understand the architecture they require and to start creating earlier versions of their service layers to aid them in forecasting expenditure and effort.
Whether you opt for a hybrid CMS or a headless CMS, this is arguably one of the most important elements to get right. Get this right and you provide a solid foundation for the future. Get it wrong and you could be inviting further rework. Be incremental in creating your service layer, adding to it piece by piece as you uncover the elements you need.
Developers
Developers, on the whole, love headless. And why wouldn’t they? The separation of concerns and the flexibility that headless offers give them free rein to embrace modern front-end frameworks and patterns to deliver more sophisticated and engaging experiences across a range of channels. They have full control over the presentation layer so, client budget permitting, the sky is really the limit.
It’s no surprise that this is reflected in the report and we’re seeing similar trends here in the market. Increasing numbers of developers are diving into the API-first world which in turn has a knock-on effect for recruitment and retention within businesses – both agency and client-side.
For agencies, this is a tricky one to manage as they need to ensure they have developers with the right skillsets. The signs are pointing to the headless and hybrid approaches as the future (for now at least) but coupled CMSs are not going away just yet. There’s a balancing act to maintain here while we strive towards that future.
Unfortunately, there’s no magic wand to wave here. This hinges on business decisions made on future architectures and development approaches plus, for agencies, new business and marketing activities. Start the conversation now – how could a microservices architecture benefit the business (or the client if you’re an agency), what impact does this have on current business operations and what effort/budget is required.
Editors
While developers welcome and embrace the move to headless, the same can’t be said for content editors.
The traditional CMS encouraged editors to think of content as content that would be pushed out onto a website and, as a result, all the text and media was architected in the form of pages. The move to hybrid and headless CMS steps away from that notion (in general as there are situations where you may use either of these approaches to deliver simply a website) towards thinking of content as essentially raw text blocks. The content you are creating is material that could be used on a website, an app, a smartwatch, through voice, through VR, etc.
Some editors are taking to this like a duck to water – especially those who already have experience of solutions such as GatherContent where content is treated as content with no ties to a particular channel. For others, it is a step into the unknown – much like it was in the early days of web content management.
If you are moving to headless CMS, don’t underestimate the time needed to train and support editors during this transition. Headless CMS removes in-page editing (and in some cases the WYSIWYG editor) which can be a daunting scenario for editors. With carefully structured processes and frameworks which they can follow as a guide, the transition can be made as painless as possible.
Summary
The perception of headless on the whole has been very positive from all quarters and the benefits that an approach like this yields, when implemented properly, are clear to see – speed to market, ability to innovate with fewer constraints, flexible architecture, ability to engage with the latest technology, ability to reach different channels and access to a larger developer pool.
If you are considering a move to this approach, I would urge you to take heed of the areas I have highlighted. To get this right, the move should be careful and considered so you can make the most of the opportunity.