Some vendors are encouraging enterprises to federate their content silos. Find out why content federation – using multiple CMSs to publish content – can create more problems than it solves.
Published on May 29, 2023
Companies need to deliver precise information to customers. But as content grows in volume, it’s become harder to achieve this goal. A few vendors have proposed an approach known as content federation as a solution to the problem. Yet content federation exacerbates the complexity of managing large-scale content instead of resolving it.
Large enterprises can have dozens of CMSs, often from the same vendor. These CMSs, based on the same architecture that’s been in use for two decades, are showing their age. Their template-centric architecture doesn’t scale well and has trouble adapting to new requirements, such as integrating new services or delivering content to new touchpoints. But because these CMSs have become embedded within the enterprise’s fabric and are relied on to publish content, enterprises can be reluctant to “rip and replace” existing systems with a newer version of what they currently use.
Each separate CMS becomes a silo, operating independently and not supporting the needs of content teams using other CMSs.
Legacy CMSs have obvious drawbacks, such as their weak multichannel capabilities. But the vertical integration of these CMSs generates less noticed problems as well. Their monolithic architecture, which dictates how content is created, assembled, and delivered to the user interfaces that customers see, is rigid and difficult to customize, hindering the ability of enterprises to introduce new products and services online quickly.
Even though the chronic problems of CMS rigidity and sprawl are widely recognized, the right solution to these problems isn’t so apparent. One concept that has been suggested is to federate these different CMSs so that they no longer operate in isolation.
Federation is a long-established concept in IT. It’s possible to federate data from various sources, provided you label them accurately. It’s also common to federate documents: portals have done this for decades. Some IT professionals have argued that content should be federated as well since, when viewed from a technical perspective, the federation of all kinds of resources seems similar.
Several years ago, Deane Barker, the author of a book on website content management, suggested that “The Future Might be Distributed” and that content federation could become a trend. “What if a single, integrated web presence could be serviced by an array of systems, each working independently”, he asked. “What if your CMS didn’t originate any content”? He described this content federating mechanism as a “Content Provider Management System” that mediates between multiple CMSs that supply content “to generate a response that looks as if it came from a single entity.” Another term to describe this concept, suggested by a commenter, is “API gateway.” IT specialists now generally refer to the approach as content federation or, more broadly, as API federation.
In concept, the end-users of the content would never realize that the content they experienced was coming from separate CMSs that were “working independently.” The federation provider would not be responsible for deciding how the content is created. Its responsibility would be to make the content available for delivery. Other CMSs would be used to create the content.
Enterprises are being asked to adopt an untested idea. Since the concept of the content federation was first proposed several years ago, a few vendors have introduced content federation as part of their core value proposition. What was originally a speculative concept has become a product.
Content federation may be positioned as a tool or service, either as a special kind of CMS or as a middleware application. While not a well-defined product category, content federation is now marketed as a solution to the stubborn problem of content silos.
All large organizations struggle with islands of content managed by separate CMSs. Supposedly, federation will make these problems quickly disappear with a minimum of effort. Promoters of content federation make a range of claims:
It’s easy to see why these promises sound appealing. Most enterprises have fragmented content operations that hinder their ability to service customers and coordinate business operations. Content federation looks like an easy way to solve the problem of content silos.
Seemingly, content federation delivers change without any need for change management. Somehow you get the benefits of enjoying radically better efficiency while keeping the status quo.
If dramatic change without effort sounds unrealistic, that’s because many of these changes are cosmetic, surface-level ones that don’t change core operations.
A yawning gap exists between what content federation promises and the reality of how content needs to be developed to support customers.
Many claims about content federation are made by engineers who have little direct experience developing and publishing content. This becomes apparent when you hear vendors use the terms data and content interchangeably, as though they are the same. Watch out when vendors say “content is data” – that’s a strong signal they are selling an engineering solution rather than one that is geared to the needs of business users.
Some vendors may suggest you can “load your data” into their tool from “any backend,” and their tool will be able to take it from there, deciding where to send it to customers. The tool acts like a blender mixing a smoothie from ingredients pulled from different cupboards.
Content federation promises to provide a catalog of all the content stored in various CMSs. But in practice, federation doesn’t really tell you what’s there. It doesn’t provide visibility into what the content is and whether it’s the right content to present to users.
When engineers talk about mashing up content from different sources, they are encouraging the content to be blended into mush. They don’t acknowledge that content has texture: it is composed of unique pieces that play distinct roles. They fail to account for what those pieces are and how they work together.
A firehose of data won’t deliver a coherent experience for customers. A jumble of mismatched content isn’t going to deliver business value.
Enterprises haven’t adopted content federation for a host of practical reasons. Federating content is operationally dissimilar from federating data. Unlike simple data values, content has a meaning that depends on its context. Large organizations can’t mix content from different sources that was created by separate teams independently and expect it will be coherent. When content comes from different sources, each of those sources developed that content in isolation without consideration of how it would work with content developed elsewhere.
Content silos aren’t just an engineering problem that can be solved with APIs. They are a structural, organizational problem that requires transformation.
The messages and information contained in the content aren’t simple data that’s hidden in some backend system waiting to be fetched. It isn’t generated as the byproduct of transactions like data often is.
Authors create content to match the needs of readers in different contexts. They plan how details should fit together to deliver an experience. Pieces of content from different systems can’t be randomly mashed-up. These different pieces need a common content model so that they can be matched appropriately. But if they come from different CMSs, each of which is using a different content model, the pieces won’t be compatible.
Content federation is, in many ways, the opposite of headless content publishing. With federation, the presumption is that you need multiple CMSs to provide content to a single website. With a headless CMS, in contrast, a single CMS can support multiple websites.
Multiple CMSs create problems, but the solution is not to try to make all your CMSs serve a single website. Enterprises will always have multiple websites. What they don’t need is the number of CMSs they currently have.
Having many separate CMSs is a tell-tale sign of siloed content operations. If teams are using different CMSs to support a specific customer experience, then the process of creating that content is deeply fragmented.
When enterprises have numerous standalone CMSs that essentially do the same thing, that’s an indication that none of these CMSs can address the diverse needs of stakeholders. Tightly coupled monolithic CMSs make it difficult to support multiple touchpoints that present varied content using different UI designs. Each team or division feels they need their own dedicated CMS because they need to customize the CMS to meet their specific needs. Each CMS must be managed separately, creating headaches for the IT team. But the problem is deeper than IT admin.
Multiple content teams are working separately with no coordination. Each team is deciding for themselves what content to create for the specific website that their CMS supports. Connecting their CMSs won’t make the teams suddenly collaborate to produce coherent experiences for customers who are moving between different websites and channels. Various teams will still be working within their own siloed environments.
If enterprises connect dozens of problematic systems together, the problems won’t disappear. Instead, connecting them is going to amplify the existing problems.
Content silos are not solely a technical problem to overcome. Enterprises must change how they develop and manage content. Content federation does not solve the problem of fragmentation in content operations.
The core problem that enterprises face is that they lack control over all the content they are producing. They lack common processes, shared governance, and a unified content structure that’s followed by the whole enterprise. Different teams decide what they want to do with limited consideration of how their work needs to integrate with the rest of their organization.
If enterprises expect to get better at developing and delivering content, they can’t continue with fragmented content operations. When operations focus on individual websites or apps, their processes are not scalable. A decentralized process that’s managed by independent teams using separate CMSs will deliver an unintegrated customer experience and will fail to achieve operational efficiency.
Siloed content operations cause numerous problems:
Individual teams won’t improve their outcomes by following a go-it-alone approach.
Fragmented content operations pose a problem for everyone. For content leaders, they interfere with the governance of content. Various teams are doing their own thing, which means some of the content has a high risk of being:
For content producers, the situation is equally difficult. They can’t be faulted for the shortcomings of the content they create because they lack the ability to relate their work to broader enterprise concerns. They are expected to figure out on their own what content is needed and how best to do that because the CMS they use is isolated from the CMSs used by colleagues elsewhere in their organization. They need better support from the larger organization. They need their content and the processes they use to be connected to the rest of their organization.
Federating content debt doesn’t erase the debt. Content federation is an act of wishful thinking because it doesn’t fix the structural problems that fragment content operations:
The irony is that centralized, vertically integrated CMSs, because of their inherent inflexibility, spawn the decentralization of content creation because monolithic CMSs are unable to accommodate the needs of diverse content teams.
When relying on many uncoordinated CMSs, enterprises face multiple potential points of failure. The needed content may not be available because it was never anticipated and hence never created. Or else, different systems have the same kind of content, and it’s unclear which version is the right one to choose.
Silos not only hurt efficiency internally. They also hurt the customer experience. Customers don’t get relevant content when they need it. Content production is stovepiped, causing the delivery of that content to customers to be scattershot.
As enterprises aim to improve their orchestration of content – making the delivery of their content more relevant and timelier – they are finding that their content isn’t ready. They can’t personalize, customize, optimize, and localize their content easily because it is trapped in the vendor-provided templates that manage their content within monolithic CMSs.
The negative impact of multiple CMSs on the customer experience has grown as organizations have introduced more websites, apps, and other touchpoints. Customers visit a growing range of touchpoints but encounter content that hasn’t been produced to work together across channels.
Unfortunately, content federation will expose these problems even more if enterprises decide to mash up content from different CMSs that were never intended to appear on the same screen at once. Content federation not only won’t solve the company’s core problems, but it will also likely compound them.
Enterprises face formidable orchestration obstacles when drawing on content from multiple CMSs:
Content federation confuses the tactic of federation with the requirement of governance by implying that federation can bypass the need for governance. Federation without governance is reckless.
Enterprises do need the ability to combine their content with other kinds of data to deliver to customers. It can be useful to orchestrate content with other data or assets that are sourced from other systems and bring together different kinds of information, each of which might be managed by a dedicated source of record. For example, an enterprise may have product information stored in a separate system that serves as the source of record for that information.
For each distinct domain of data, there should be only one source of record. Otherwise, the enterprise risks providing the wrong data to customers. Enterprises shouldn’t have multiple sources for a specific kind of information or data. This principle applies to content even more; there must be a single source of truth for content. And the only viable way to have a single source of truth for content is for all enterprise content to be managed in a single platform that’s used by everyone.
While many CMSs have an API that allows external sources to feed content into them, this feature can be misused. What’s important is not just where the content is stored but where it was developed. All of the content should be developed according to common standards.
By continuing to rely on separately managed CMSs, enterprises find existing problems and inefficiencies become more entrenched. There’s no defined process to produce content correctly. Everyone is free to do things their own way. Each group might blame others for the problems that end-users encounter when experiencing a mishmash of incoherent content.
Content federation, in theory, is supposed to facilitate the orchestration of content. But in practice, the opposite is true. Content federation will expose the inconsistencies within siloed content.
Orchestration becomes risky and difficult when sourcing from multiple CMSs. Enterprises can’t deliver precise content when they rely on multiple CMSs. Each CMS relies on a different content model and will describe the pieces of content differently. The names of content types and their fields may be different, or else they may use the same name to refer to different things, making it hard to know what is being assembled. To compensate for this problem, federation approaches may rely on unique IDs to disambiguate the content pieces from different CMSs. But these IDs by themselves are meaningless. Those attempting to create a patchwork from the pieces will still need to examine them to understand what they refer to. That task is even more burdensome because the content items are scattered in different places and must be examined separately.
Centralized all-in-one monolithic CMSs, by imposing the structure of the content, its assembly, and its presentation, have managed to splinter enterprise content operations. Enterprises need an alternative solution that can coordinate the work of different content teams.
Enterprises need a unified content platform that all teams can use, regardless of what part of the organization they belong to, what their role is, or what kind of content they produce. Teams need a platform that gives them control to define their unique work and allows them to utilize resources developed by colleagues in other parts of their organization.
Headless CMSs make content API-ready and able to connect with other enterprise systems. But a good headless CMS is more than just another API endpoint. Content is too foundational to treat it as one more API call. Content is the beating heart of the enterprise’s communications with its customers.
When orchestrating content pieces created by different people, it’s important that they know how others are producing their content and what’s available. They should all be following a common process and set of standards. That’s only feasible if they use a common platform.
Enterprises need a unified content platform that enables them to gain complete control over their content. A headless CMS is a precondition to gaining control but alone is not sufficient. Enterprises with lots of diverse content need a platform that is both headless and can provide governance of large-scale content.
An enterprise content model provides coherence to all the content created across the enterprise. All teams use a common content model (schema) so that the meaning, purpose, and relationships of all content are clear.
Structured content can deliver precise details to customers that match their context. In some scenarios, it will be necessary to combine details from different content items to deliver them together to the customer’s screen. When the content is structured by a common content model that specifies the intent and relationships of different content details, combining details from different content items is possible through API queries. But such sophistication isn’t something that can be reliably executed when content items are defined and organized by different content models within different CMSs.
In addition to having a well-defined content model, a headless CMS should support the grouping of content into distinct collections whose access is tied to user permissions. This will ensure that specific kinds of content have undergone the correct workflow and approval review. It will ensure that the right content is provided for different scenarios.
A unified content platform allows different teams to share processes and follow common governance, ensuring that all the content produced meets quality standards and is ready for all channels. All teams use common capabilities, ensuring everyone can access the same tools and options.
Content federation is the wrong approach to the challenges of scale. It will highlight the scale of your problems.
Enterprises need to scale their content so that the correct content can be reused wherever it is needed.
They need to scale their content operations capabilities so that all teams can benefit from the best practices and features that have been adopted.
They need a platform that provides a solid foundation that enables them to orchestrate many rich details to provide relevant experiences to a diverse range of customers.
They shouldn’t compromise on these needs.
Listen to our new podcast for practical tips, tricks, and strategies to make your content shine. From AI’s magic touch to content management mastery and customer experience secrets, we’ll cover it all.
