Navigating the chaos of vendor categories when building your digital platform.
Organizations need to engage their customers in a myriad of channels including in-store experiences (including 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). Creating a unified omni-channel experience requires careful evaluation and comparison of technology vendors that should be considered when selecting the components of your digital platform.
Content is at the heart of the digital experience
If you are going to build a web application, regardless of the channel, the one thing it needs to do is serve content to your customers, employees, partners, patients, etc. The kind of content it serves depends on what kind of experience you are building. If you are building an eCommerce experience, you’ll have content such as product information, videos, images, promotions, offers, articles and blogs. If you are building a knowledge discovery web application, you may be serving documents, articles, blogs, cross-promotions, etc. So, let’s agree on the fact that the content layer is essential in building any digital experience.
With this behind us, there is still a lot of confusion about what makes up the overall digital experience tech stack and where exactly does a CMS fit. As a backdrop to this discussion, I want you to keep in mind that Gartner and Forrester are officially moving away from the Web CMS category altogether. Why? Well, this will become clear shortly.
The great ‘headless’ revolution
When it comes to the content layer, vendors typically belong in one of the two primary categories: Headless CMS and traditional Web CMS. They both claim, equally emphatically, that they provide the right technology stack for you to build your omni-channel digital experiences.
‘Headless CMS’ addresses the problem of creating and publishing channel agnostic content and decouples content from code. This is definitely a step in the right direction from an architectural perspective and for that reason, millennial developers love it! However, if you talk to the marketing and business-focused digital teams currently using headless CMSes, a large proportion of them express frustration about their lack of control over the end user customer experience. Marketing teams not only want to be able to control individual content items, 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.
Headless falls short of the hype
An experience is more than a simple list of content records — it is an orchestration of multiple content records that are 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 CMSes weren’t built to care about the where, when or how. That’s why it is called ‘headless’ in the first place.
On a side note, I have personally seen some implementations of headless CMSes where page templates and layouts are modelled as content types, essentially bastardizing the very reason why headless CMSes 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, once again these organizations are creating world in which content and layout are intertwined and this time, ever more rigidly than even the traditional CMSes did. It is hard to blame the digital teams that went down this path because what they were on a righteous path of decoupling their front-ends from back-ends. They just painted themselves in the corner and realized a bit too late that they business teams would not be happy losing complete control over the front-end experience.
Is the grass greener on the other side?
Let’s walk over to the other side and see if it really is the case. Frustrated and tired from the IT led projects that have taken control away from business, many marketing teams turn to the large incumbent digital experience platforms that offer them comfort with beautiful interfaces that seem to put marketing in full control of their destiny. While these decisions are being made, modern architects and developers yell and scream about vendor lock-in, closed architectures, huge implementation time lines, monumental costs, and so the eternal tussle between business and IT continues.
Are these complaints justified or is it a case of developers just wanting to build it themselves? The headless CMS movement has forced the incumbent leaders in the Web CMS space to re-package their existing product suites to match what the savvy buyers are 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 to have you believe this, 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.
WCM is out, DXP is in.
Let’s come back to the topic of why Gartner retired the WCM Magic Quadrant earlier this year. The research organization rationalized this decision by saying that the WCM market has reached maturity with little differentiation in vendor offerings. After all, as we have established, there is more to creating a customer experience than content authoring, publishing and delivery. From the downfall of WCM, a new category called DXP (Digital Experience Platform) has emerged. Gartner defines DXPs as ‘an integrated set of core technologies that support the composition, management, delivery and optimization of contextualized digital experiences.’ A huge focus is placed 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-Vendor vs. Best-of-Breed
The nice thing about having a DXP that has a strong integration foundation is that it allows you to pick the best-of-breed vendors for components such as customer analytics, A/B and multivariate testing, campaign management, 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”
The decision about which technology 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.
