Navigating the New Approaches to CMS — Part 2: Headless CMS & the Digital Experience Stack
In Part 1 we looked at the Digital Experience Platform (DXP): the big, all-in-one platform from a single software vendor that manages all aspects of the digital experience—including content management — and renders websites that use that content.
In Part 2 of the series we’re going to look at an alternative approach to the DXP. This approach brings together multiple platforms from different vendors and is sometimes called a Digital Experience Stack.
Unlike the DXP that can come with a bunch of features you might not use, the DX stack is yours to define, and can contain whatever services you need today. You’re free to swap platforms and services in and out as those needs change—without bringing the whole house down.
The DX stack in the diagram combines a few Software-as-a-Service (SaaS) platforms. SaaS isn’t the only thing you can add. The platforms in your stack could be a mix of on-premise software, software installed in the cloud, and SaaS. The trend, though, is very much with SaaS.
So where does content management fit into this world of multiple platforms and services? As you’ve likely already guessed, this is where we’ll find our next approach to content: the Headless CMS.
What it is
Comparing Headless CMS to the familiar world of more traditional CMS helps to explain the approach. Here’s the skinny.
Where’s the Head?
A traditional CMS renders the website (the head). Browse to the website and the application spitting out that page is the traditional CMS. Headless CMS provides an Application Programming Interface (API) so consumers from multiple channels (websites, apps, etc.) can get at the content they need. The Headless CMS has absolutely nothing to do with rendering the web page shown in the browser.
Just the content, please
Much like the DXP they evolved into, a traditional CMS typically does a bunch of other stuff, like digital marketing, search, forms, etc. Headless CMS just does one thing: content.
If you need to add functionality like digital marketing, or a way to manage customer data, then add these platforms to your stack.
If a traditional CMS is written in a programming language like PHP, then chances are you’ll have to code your website, and any CMS extensions, in the very same programming language.
Because websites, apps, etc. get to the content in a Headless CMS via its API, you’re free to use whichever programming language you want. This provides a lot of flexibility. The choice could be whichever language works best for your organization in terms of existing skillset and productivity.
Let the software vendor look after the platform
A traditional CMS needs to be installed somewhere and then looked after (upgrades and updates). Most Headless CMS platforms are SaaS, which reduces the overhead of having to look after the actual CMS platform.
Content is more reusable
A traditional CMS typically mashes up some of your content with how it’s presented. Headless CMS takes a more content-first approach. It’s not web-centric. You start by designing and modelling your content structure, and then extend that model to meet the needs of the channels consuming your content—which may or may not be a website.
Designing a good content model will help make your content reusable and reduce issues such as content duplication. If you’re interested in finding out more about content modelling, then check out my other series on content modelling with Kentico Kontent.
Content should outlive the website
When you combine the above features, then a couple of other perks come with using a Headless CMS:
- Want to redesign your site? Do that without redesigning how all your content is structured. A staff bio, information about an event, company services, products etc.—all this core content will be the same on the new site as it is on the old one.
- Want to rebuild your site in an entirely new programming language? Content separation, combined with the fact that Headless CMS platforms are technology agnostic, means you can do that rebuild without forking out for an expensive content migration initiative. Why? Because your content is staying exactly where it is: in your content repository (you’ll also sometimes read the term content hub).
Why it is
Businesses finally got serious about content
The content that a business creates is a significant asset:
- It serves internal needs
- It serves external audiences
- It drives conversions and revenue
Content should outlive the current iteration of your website, app, etc. For that matter, having valuable content siloed in a website building tool like a traditional CMS, with authors having to duplicate it when it’s required on other platforms, causes chaos.
The content-first approach fundamental to Headless CMS puts the focus where it should always have been: on the content. Start there, then factor in personalization and channel-specific concerns.
The API-first approach fundamental to Headless CMS eliminates the overhead of managing duplicated content. Rather, content is centralized on the Headless CMS and available to any channel.
Being specialized works for software users
As a software user, there’s more choice and flexibility when combining specialized SaaS than when using a DXP from a single provider that may be strong in some areas but weaker in others.
Moving away from a DXP is a significant endeavour for any organization. If you start with a more micro-services approach then you just replace underperforming services when better options arrive on the market. No, this isn’t effort free, but it is significantly less effort than pulling out your DXP.
Being specialized works for software vendors
As a software vendor, you don’t just enter the DXP market. Most DXPs have evolved from very mature web content management systems. These platforms are huge monoliths and take years to build up all the features and functionality expected from a DXP.
Improvements in cloud technology helped to reduce the effort in building SaaS. New standards for APIs and growing developer expectations made integrating your platform with others a must-have rather than a nice-to-have. It’s OK if your software doesn’t do everything. Just excel at what you are doing.
There’s been an explosion in Headless CMS platforms available as SaaS. Companies new to CMS, such as Contentful, ContentStack, and StoryBlok. Also CMS veterans like Kentico Kontent* and Umbraco Heartcore.
Where There Can be Confusion in the Marketing Babble
I’ve only got a single website, so I guess Headless isn’t for me.
Headless CMS marketing talks a lot about multi-channel. For all the benefits described in this post, Headless CMS is great for a single channel, too. Even if your primary channel is web and 100% of your content is going to one website.
Headless CMS is also getting better and better for the web channel. A few enterprise platforms, aware that web is typically the primary channel for many of their customers, are focusing in on making the lives of web editors even easier.
Kentico Kontent is an excellent example of this. They’ve created an optional extension to their Headless CMS called Web Spotlight. Web Spotlight “combines in-context website management with the flexibility and multi-channel support of a headless CMS.”
How does it provide website management? Well, it doesn’t add the head back in to control how things are rendered. Instead, it provides developers an API to make the site they build smart enough to know when it is being loaded into Web Spotlight for editing. The site can then show and interact with that editing tool.
We use Kentico Kontent and Web Spotlight for our agency’s website.
Hassle-free out-of-the-box integrations with everything!
Today, when it comes to integrating your Headless CMS to other platforms in your stack, we’ve thankfully got standardized approaches like webhooks and APIs. Modern platforms and SaaS both offer these integration approaches to a greater or lesser extent.
Does this standardization make integration simpler? Absolutely. Does it reduce the effort to almost nothing (as suggested in many marketing campaigns)? No.
Out-of-the-box integrations tend to be pretty skinny when it comes to features and functionality. Quite often they’re there to prove that two platforms can communicate — and to provide attractive marketing collateral for the platform vendors (too cynical?).
Custom applications can be developed to make use of the webhooks and APIs. These applications broker the communication between two platforms. If you throw in something like serverless functions, then creating these types of integrations can be relatively quick and, given they live in the cloud, scalable as well.
In 2021, everything is-a-Service, including this integration “glue” that brokers communication between platforms (referred to as Integration Platform-as-a-Service; e.g., MuleSoft). This approach is worthwhile for large enterprise stacks.
No more upgrades or updates!
If you’re considering a Headless CMS in the cloud (most are SaaS), then you’ll likely have come across marketing claims that you don’t have to manage upgrades and updates. These claims are true. Hooray!
The fact that the software is fully managed by the software vendor is indeed fantastic. In the scenario where you’re using a Headless CMS for your website, there is, however, another piece of the puzzle that your company or digital agency will need to manage: that’s the website itself.
In other words, a solution using a Headless CMS still needs someone to look after the head. You’ll still need to host that somewhere. If you want to use new features provided through the API, then you’ll need to manage updates to your website to use the new API.
What it’s good for
- You’ve already started to use, and see, the benefits of having multiple platforms in your company for things like digital marketing, e-commerce, etc. If you’re looking for a centralized home for your content, then a Headless CMS is the right fit. A DXP in this case will be overkill.
- You’re working on a proof-of-concept and looking to move fast with as little overhead as possible. Go sign up for a Headless CMS that has a free subscription, and get building.
- You’re looking for a solution to content challenges that your business or organization is experiencing
- You have a history of spending significant portions of your digital budget on content migrations each and every time you move to a new platform. You’d like to get your content into something where it can live and evolve independently.
When to avoid
- Moving a team who are used to a mature DXP to a stack of disparate SaaS platforms is a lot to take on. You might want to use a Headless CMS on a standalone digital initiative to find your feet, and then evaluate if this is the way forward for your organization.
- Your RFP reads like a DXP marketing brochure. If you’re really in the market for that much functionality being delivered in a single digital initiative, then a DXP is likely the right approach.
Remember I said this market was exploding? This is just the tip of the iceberg.
Upper end of the market
A favourite with developers
An on-premise option
Looking to find out more about Headless CMS? Check out this category over at g2.com.
Enabling marketers and editors to get work done without needing to bug developers has always been a goal for CMS. In Part 3, we’ll look into the world of Low-Code and No-Code. Two approaches with a similar theme: creating digital products with as little development as possible.