two people standing in front of a wall with multiple arrows circling
PHOTO: Charles

Content is at the heart of the digital experience.

The one thing any digital property needs to do, regardless of channel, is to serve content. The kind of content it serves depends on what kind of experience you are building. If you are building an ecommerce experience, you’ll serve product content along with related videos, images, promotions, offers, articles and blogs. If you are building a knowledge base for your employees, you’ll need content such as documents, articles, blogs, etc.

So, let’s agree that the content layer is essential in building any digital experience.

But confusion enters the picture when we try to determine where content fits in the digital tech stack. Does it belong in a CMS? A DXP? A content services platform or content collaboration platform?

The easiest way to differentiate between these is to look at the use cases they support. For our purposes, we are interested in powering multi-channel, personalized digital experiences to end users and customers through a centralized content infrastructure. 

Which Content Platform Do You Need? Process of Elimination

Let’s use the process of elimination to rule out some of the vendor categories. We’ll start with content collaboration platforms. Content collaboration platforms allow thousands of users to collaborate on the creation, editing, annotation and sharing of content (primarily files). They are best suited to  enterprise-level use cases such as governance, business process automation, workflow management, and more.  Therefore, we can eliminate content collaboration platforms.

Next up,  content services platforms. These help organizations  tackle content sprawl and silos and modernize content processes. For example, think of digitizing the entire insurance claim process so both employees and customers can securely collaborate on this content through sophisticated workflows. Most of the use cases for content services platforms are focused on challenges within the walls of the enterprise and therefore won’t help us.

Which leaves us with content management systems and digital experience platforms. You would think that CMS is the obvious solution, but Gartner and Forrester are officially abandoning the web CMS category altogether. Why?

Related Article: How to Categorize the Web CMS Marketplace

Goodbye Web CMS?

Web content management came into its own (arguably) in 1995, making it 25 years old, which is ancient in technology years. So when Gartner retired the WCM Magic Quadrant earlier this year it rationalized the decision by stating that the WCM market had reached maturity with little differentiation in vendor offerings. But I suspect a few other factors were behind the demise of web content management.

The Omnichannel Reality and the Great Headless Revolution

The days of customers only interacting via a brand’s website are long gone — although that’s still an important piece of the puzzle. Customers now interact with companies through myriad channels, including in-store experiences such as kiosks, magic mirrors and endless aisles, social platforms, native apps, digital marketplaces and affiliate networks, conversational interfaces such as phones, chatbots and digital home devices, IoT (including wearables, smart homes and vehicles), and immersive experiences via augmented reality (AR) and virtual reality (VR). 

The need to create multi-channel experiences while staying agnostic in the presentation layer gave birth to the headless CMS. Headless CMSs address the problem of creating and publishing channel-agnostic content by decoupling content from code. This is definitely a step in the right direction from an architectural perspective and for that reason, modern developers love it!

Related Article: Why We Need a New Grand Compromise in Content Management Systems

Headless Fell Short of the Hype

An experience is more than a simple list of content records: It is an orchestration of multiple content records, assembled into a layout or a template based on logic (or artificial intelligence) that ideally provides relevant and contextual content to every user. Where, when and how the content appears on the page matters just as much as what the content consists of. Headless CMSs weren’t built to care about the where, when or how. It’s why they’re called ‘headless’ in the first place.

Talk to the marketing and business-focused digital teams currently using headless CMSs, a large proportion of them will express frustration about their lack of control over the end user customer experience. Marketing teams not only want the ability to edit and publish individual content records such as blog posts or promotional banners, they also want control over where and how this content visually appears within the page template, as well as who sees this content at what time.

On a side note, I have seen implementations of headless CMSs where page templates and layouts are modeled as content types, essentially bastardizing the very reason why headless CMSs were created in the first place. In these implementations, you will see a presentation framework tightly coupled with the content layer (even if it is built on modern javascript frameworks). So, these organizations are once again creating a world in which content and layout are intertwined and this time, ever more rigidly than even the traditional CMSs did. It is hard to blame the digital teams that went down this path. They were likely on a righteous path of decoupling their front-ends from back-ends and painted themselves in the corner,realizing a bit too late that the business teams would not be happy losing complete control over the front-end experience.

Is the Grass Greener on the DXP Side?

A new category emerged from the downfall of WCM: digital experience platforms (DXP). Gartner defines a DXPs as “‘an integrated set of core technologies that support the composition, management, delivery and optimization of contextualized digital experiences.”’

DXPs place a big focus on integration capabilities, with adjacent technologies including digital commerce platforms, analytics, third-party search (or insight engines), customer data platforms, social media platforms, marketing automation platforms and more. The trend is towards platforms that act as the foundation or a ‘connective tissue’ for all adjacent technologies to be integrated, providing an experience gateway (not just content APIs), ideally through headless APIs.

One too many IT-led projects pushed many marketing teams into the arms of DXPs, with their beautiful user interfaces that seemed to put them in full control of their destiny. This choice caused modern architects and developers to yell and scream about vendor lock-in, closed architectures, huge implementation timelines and monumental costs. And so the eternal tussle between business and IT continued.

Are these complaints justified or is it a case of developers just wanting to build it themselves?

The headless CMS movement forced the incumbent leaders in the Web CMS space to repackage their existing product suites to match what savvy buyers were looking for. Every monolithic web CMS vendor is now using the term “‘headless”’ when describing the nature of their underlying content repositories. As much as they’d like you to believe it, exposing a content repository with a set of APIs does not make it headless. Yes, they are delivering something with APIs, but the underlying content structure is very much tied to their own presentation layers. This is why you will not often hear about an Adobe CMS powering a front-end built on ReactJS unless it is a carefully crafted set of javascript libraries that follow a design pattern prescribed by these vendors.

Related Article: Why Did Gartner Kill the Web Content Management Quadrant?

One-Vendor vs. Best-of-Breed

The benefit of a DXP that has a strong integration foundation is it allows you to pick the best-of-breed vendors for components, such as customer analytics, A/B and multivariate testing, persona modeling, commerce engine, customer data platform, DMP, marketing automation, social platforms, AI-powered propensity modelling and customer journey mapping.

The incumbent traditional DXPs have expanded their boundaries by acquiring products that touch every one of these capabilities. According to Forrester, native solutions win easily in DXPs as “products joined by mergers and acquisitions frustrate customers because they have to force-fit the product integrations.” These monolithic product suites try to piece together all the parts under one roof and have amassed overlapping capability from many products, which has resulted in undue complexity and high cost of ownership.

The Ideal DXP Is Lean and Mean

So at this point it should be pretty clear that there is only one vendor category worth considering: the DXP. The decision about which DXP should serve contextual content experiences to your presentation layer should be based on its ability to act as the connective tissue for your digital platform, while allowing your digital teams to easily control the overall experience in an intuitive interface.

Content authoring, publishing, delivery, experience management, search and personalization/ contextualization of content are very much related and interdependent components of the digital platform. I am all for best-of-breed approach and integration, but I would strongly argue that these specific functions need to stay together. If you separate content authoring and publishing from experience management, you will be in a situation where your marketing teams will be switching back and forth between different admin interfaces, creating a fragmented experience. Or, worse yet, your marketing team will lose control over the who, what, where and when of your content delivery. I would also argue that the experience management interface should not only allow digital teams to orchestrate the delivery of content that resides within the DXP, but also content that resides in external repositories, PIMs and databases.

The DXP must have a strong integration foundation that allows for product information from ecommerce platforms and content managed in other repositories to ‘flow’ through this layer, allowing digital teams to connect the various content silos through dynamic relationships and packaging it together into organized content blocks.

The ideal DXP should be able to integrate with systems of insight such as CDP, DXP and analytics platforms to pull the customer’s behavioural attributes and real-time context and be able to respond with relevant content based on logic and rules set by the marketing team, thereby providing the right content to the right person at the right time.

This contextual content assembled into front-end agnostic templates should be delivered to the front-end via a headless experience gateway that is not prescriptive in any way about how you write your front-end code or which technologies you use.