Traditional content platform architectures leverage a coupled management and delivery model, in which the same product and application both manages content via a CMS interface and delivers the end experience though web page templates in the CMS. The focus is often web as the primary channel of use since that was the predominant channel of the past.

More recently, there has been a big push toward omnichannel content management with the proliferation of many different devices and channels — web, native mobile apps, social media, voice apps, chatbots, email — you name it. This omnichannel need has resulted in many pure play headless CMS platforms emerging, or traditional products providing headless APIs (which is called Hybrid CMS and a whole topic for another time).

The decoupling of the delivery-side of these products from the CMS admin has enabled many consumer applications to reuse the same content though these headless APIs — thus consistent content across channels to enable a truly omnichannel experience.

What a Content Hub Looks Like

If you can imagine a content platform as your centralized content hub that is pushing content out from a single source to many channels, you will see a 1-to-many relationship like this:

content hub

Great. We have a product capable of managing content for multiple channels with headless APIs to give you the freedom to consume the content how you wish. This is the promise of headless architecture, and this is what we need, right? It provides a centralized content hub with the opportunity to serve as an omnichannel content delivery platform.

Related Article: Content Teams: Beware the Headless CMS

Content Silos Are Speed Bumps to a Consistent User Experience

But what's wrong with this picture? In concept this makes sense, but does it match reality?

This isn't how content management often works. Is it possible that content can come from many other sources throughout an organization, not just a centralized source?

Perhaps different brands, business units or departments have their own processes and tools to mange their specific content? According to Netskope’s August 2019 Cloud Report, at the time the average enterprise had 120 cloud services in use for marketing purposes. Just imagine even a small percentage of those systems being used to store and manage content and data.

Learning Opportunities

This presents a bit of a problem by creating content silos that may hinder the reuse and consistency of content. This is where the concept of content unification comes in, allowing for multiple sources to your centralized content hub in a many-to-1 relationship:

unification orchestration

Content Unification as Traffic Control in the Content Supply Chain

Content unification allows you to aggregate and compose content together in your centralized content hub that is sourced from upstream systems in your digital content supply chain. If one business unit manages all of their content in a pureplay headless CMS just for them, how does that content get reused outside of that product for the larger organization? What about a department-specific DAM subscription? Does it need to get rolled out to the entire org in order to see broader benefits?

Content unification solves this problem by allowing your centralized content hub to be a consumer of other content sources. This lets you focus on using the content hub to orchestrate the specific compositions of content you need for the experiences you are providing:

content hub unifcation orchestration

Related Article: Why Modern Marketing Teams Should Consider Going Headless

Content Unification in Real Life

Content unification is manifesting in different ways across similar but different product types:

  • Hygraph, a pure play headless CMS, recently introduced Content Federation though the addition of Remote Sources, a way to configure and define external APIs that combine with Hygraph content into their content delivery API.
  • Conscia offers their DX Graph, a unified Content API that synchronizes and aggregates data from external sources, even systems that don't offer modern APIs to consume content. This enables legacy systems without modern APIs to still deliver content as part of the content supply chain.
  • We're also seeing content federation and aggregation though experience orchestration products. Uniform, which offers a composable DXP, is not a CMS or DXP itself, but rather a framework to integrate and unify your martech components to compose your own custom-tailored DXP. I like to think about it as an integration factory. It helps with the integration of upstream martech products and the orchestration of them together so you can compose the user experience you want with the content and data you need.
  • Similarly, Sitecore's XM Cloud — its new SaaS CMS — offers the new Sitecore Pages authoring interface. Sitecore Pages introduces the capability for data connectors to expose content from external systems in the CMS so you can orchestrate experiences with content from many different systems. You can imagine a use case where you may not manage much content in Sitecore at all, but you can leverage Sitecore Pages to assemble it from many systems prior to delivering the user experience. This is also a good use case if you are slowly migrating away from a pureplay CMS as you can start to consume the content externally before migrating.

What's Ahead for Content Unification?

As organizations adopt modern headless content platforms to provide consistent omnichannel experiences, they can leverage content unification capabilities to compose and orchestrate the right content they need, regardless of source, to provide the best possible customer experience. I expect to see this capability emerging more in the future across various content platforms and martech products.

fa-solid fa-hand-paper Learn how you can join our contributor community.