Blog

It’s when the fakes start emerging that you know a tech trend has started to get traction. Established vendors suddenly realize that customers have started asking for this new thing they don’t offer. In response, they give their products a buzzword-compliant makeover — but without fundamentally changing the underlying technology. We’ve seen it with SaaS and cloud computing, now we’re seeing it with headless CMS — and probably this will become a thing across other headless applications.

In case you’re not familiar with the term, a headless CMS (content management system) stores digital content in a way that allows it to be presented in any medium. The category is also known as a digital experience platform (DXP), with the ability to present a variety of different types of content to any client. This is a different proposition from a traditional web CMS, which, as the name implies, is designed specifically to show content within a website (a predetermined ‘head’).

The old type of CMS worked fine until mobile came along, where its limitations started to become evident. It is now proving increasingly inflexible as businesses seek agility across even more channels such as voice assistants, messaging clients and AR/VR. There is a growing variety of enterprise use cases, says Neha Sempat, CEO of Contentstack, one of a new generation of headless CMS vendors:

For example, we have a lot of retail customers that, of course, have been traditionally on the web for a while. From a mobile perspective, they’ve been trying to innovate, but there are ways in which they couldn’t innovate in the past, which now they can.

A lot of that is offer-based and specific to personalization — being able to bring information that you might experience in the mobile app or on the web, into your physical presence when you actually enter a store, and being able to transcend that experience. We see that also in other physical places like sports arenas, where you’re creating the most interesting digital fan experience in the world.

But also, [there are] general use cases where you may want to connect your entire support system or your entire employee base with content that may already exist on your intranet, but you want to be able to pull content from various places and expose it on mobile, on web, from various data sources.

Headless CMS in the enterprise mainstream

One example of those more general use cases is an organization that has brought its customer service knowledgebase into Contentstack, in order to surface the information both to customers and service agents. Another use case is to fuse commerce and web sites in a way that allows marketing teams to co-ordinate product information and customer experiences across multiple channels. A recent partnership with headless commerce vendor commercetools expands Contentstack’s offer here, as well as a longstanding relationship with SAP to provide a headless content platform for portals and ecommerce use cases.

This ability to bring in content from more traditional enterprise sources, such as content stored in digital asset libraries or transactional data from enterprise applications, plays to strengths founded on Contentstack’s heritage. The business grew out of Built.io, an API-centric platform taht connects multiple information sources and workflows into mobile, IoT and other applications. Sempat and co-founders Nishant Patel and Matt Baier sold Built.io to Software AG eighteen months ago so they could focus full-time on Contentstack. A $31.5 million funding round followed last October, fueling a new growth phase for the headless CMS business.

Rising demand has led to headless CMS becoming more mainstream. That in turn has brought an outbreak of vendors claiming to offer the model that previously had been dismissive, says co-founder and Contentstack CMO and COO Baier:

There has been a marked shift in rhetoric over the last year. Where a year ago there was definitely headless CMS technology and there were vendors that were talking about it, there were a lot of vendors who weren’t talking about it or who were dismissing it. Those same vendors are now claiming to have it or to have invented it.

So I think there’s there’s some healthy skepticism, that I would just encourage people to look a little bit behind the marketing terms. There is a difference in building a system API-first, and adding an API to a system. You make different choices, you expose things differently.

A system that grafts APIs onto an existing platform will have more limited capabilities than a true headless CMS, says Baier, reducing the speed and ease with which an IT team can deploy a new system. That is because there will be constraints built into the underlying architecture that can’t be fixed simply by adding an API.

How to spot a fake headless CMS

So what are the characteristics buyers should look for to ensure a headless CMS has the right pedigree? The first thing to do is to examine its origins, says Sonja Kotrotsos, Head of EMEA GTM & Alliances at ContentStack.

The easiest question is, are you older than five years? Have you had a monolithic, on-premise system? Unless you completely re-architected your stack, you are not API-first.

Another giveaway is to look at whether there are limitations on the frameworks and software environments the platform will work with. A true headless CMS lets you surface content in any medium, she explains.

A good indicator is to look at a vendor’s documentation — even as a business user, just go there and have a look how many software development kits do they have? If there is not a plethora of those for the different tools out there, [it’s] probably not really headless.

Looking at how existing customers are using the platform is another useful guide to whether this is a truly headless CMS, adds Baier:

Another good sniff test is case studies. If a vendor talks about having a headless solution, but then that headless solution is only being used for websites, there’s something amiss.

A true headless system is, by nature, neutral across channels. So ideally, you want to see a healthy mix of web and mobile and emerging channel use cases, across industries. The more broad their use cases are, the more likely you have a true headless system.

The ability to keep on evolving is also important, says Kotrotsos, which implies a cloud-first offering:

Why do customers employ a headless system? It’s because they want to have that digital dexterity to react to that goalpost of customer expectations. Having an API that gives you content alone is not enough for that. The system needs to be in the cloud, it needs to be software as a service.

As the vendor keeps innovating, the customer will have the right tools to evolve with the customer demand, which an on-premise solution or a cloud-hosted solution can never give. You’re always upgrading, always on the last version, the two-year-old version, and it doesn’t give you the speed to react to the market.

My take

At one point in our conversation, Sempat said to me, “the term headless is already part of the problem,” because it implies that simply dispensing with the ‘head’ and adding an API instead is all that’s needed. The real problem here is the tendency to seize on terminology without a full understanding of what it represents. Any shorthand term is bound to be an oversimplification, and too many people in the technology industry will take advantage of that to apply the term to products that don’t deliver the full story.

The history of cloud computing provides a well-documented case in point, where the market filled up with offerings that represented many different definitions, few of which achieved the full benefits of the canonical model. It’s taken twenty years for that model to have finally entered the mainstream, and even now some aspects are still not widely recognised.

My take is that a proper headless solution has to be powered by an underlying serverless infrastructure. That’s another shorthand term of course, which is also open to misinterpretation. What I mean is that the underlying layer can’t be a traditional monolithic platform, but rather a managed network of autonomous microservices from which the engagement layer can draw whatever functions and resources it needs.

This is true not just in the field of CMS, but across any application. The digital experience is increasingly going to have to be delivered independently of the underlying serverless infrastructure. So what we’re seeing emerge today in the field of headless CMS holds lessons of interest for the future of all enterprise applications.