Tools are only good if users want to use them. If your writers and editors don’t want to use a tool, your content velocity will halt, and your business will suffer.
While it’s easy to dictate a monolithic approach to building your CMS strategy, managing a diverse team with diverse needs in their content generation processes is not always easy. Rarely will one data entry process be the correct one for all those individuals.
It's important to note that while allowing your writers and editors to choose their tools can increase content velocity, it's also important to maintain some standardization of data structures and APIs. Without that standardization, your developer velocity will suffer.
What is distributed content management?
Distributed content management is a pattern where your content is spread amongst the systems that work with that content type the best. Your marketing copy lives in a headless CMS; your product information in your PIM; your inventory in your WMS; your customers in your CRM. Each system handles its own data type better than a monolithic approach could.
Each data type also has its own specific group of editors. These editors are most comfortable in the systems they’re trained to deal with. Forcing an eCommerce expert into a headless CMS or a marketing expert into a PIM just for the sake of having a singular tool doesn’t make sense and will often stifle the teams needed to continue refining and producing content.
The distributed CMS pattern means each editor type can use the system that works best for their data. The data is then all brought together via a federation pattern — here at Hygraph, we’re believers in Content Federation, but any data combination pattern will work depending on your needs.
Why should you care about content velocity?
Among many teams, content reigns supreme. Strong content published regularly is crucial for long-tail leads, thought leadership, and brand growth.
Regularly creating fresh, new content can help keep your audience engaged and growing. While a single strong piece of content can provide high value, each new content piece is a chance to find a bigger, more engaged audience.
Creating a steady stream of new content pieces also allows for a stronger sense of experimentation. In the realm of content, what works one week may not work the next. Trying new perspectives, content types, and tones is important. Experimentation increases the chance of hitting the right tone and perspective to generate high engagement. Not every piece will succeed, which is why it’s so important to be able to create and experiment at a high velocity.
The importance of content standardization
Content velocity might increase, but there are potential pitfalls to a distributed CMS approach that centers on the idea of standardization.
Unified Content Strategy
When you lose a centralized tool, it’s easy to let strategic concerns slip in favor of “getting the work done.” Any content plan needs a solid strategy as its base. While that can be covered up by a strong centralized tool, holes in internal workflows and strategies become more apparent when decentralized.
When crafting a decentralized solution, it’s important to start with a set of standards for how all aspects will be crafted. This goes from things like tags on blog posts and articles to how products are referenced. A strong plan for this content will align everyone in your organization around how these elements should be written, edited, and used regardless of the system they use. A strong plan will also help create a stronger sense of technological standardization.
Technological standardization
While allowing your writers and editors to choose their tools is important, it's equally important to maintain some standardization in your data structures and APIs. This will ensure that your developer velocity doesn't suffer and that your content can be easily integrated into your CMS.
Given three content teams with three separate CMSs, chances are good that your development team will struggle with creating consistent, efficient, and performant applications and sites. Each CMS brings its own data structures, its own API endpoints, and its own content strategy. Those can’t be standardized in their individual applications; a central system must standardize them. Without a standardization mechanism, site and application development will be more prone to bugs, developer frustrations, and blockers.
How a distributed system can help with standards
Each system may be separate, but each can help enforce the standards of the others.
For example, Dr. Oetker, a global food and beverage wholesaler, has multiple systems that need to converge to make their various localized websites, customer data needs, product information, and recipe database.
While all of these systems could theoretically exist within one massive, monolithic structure, each system is better at maintaining the individual standards of its own content than could happen in a singular system.
Dr. Oetker’s product information lives within their PIM. The PIM provides product data for the recipe database and editorial CMS. Customer data is housed in Force.com. Page data and content structure are built in Hygraph, where editors also work. All this is bundled and built with Next.js for 40 localized websites.
A recipe editor won’t be editing the product information. Since that lives in the PIM, it’s completely safe and standardized. Same for building editorial content or pages. All the product information is usable and standardized without having to worry about the individual teams knowing exactly the right information.
We leave room for error or interpretation if we depend on an overall strategy and the humans implementing them in separate systems. However, if the information is pulled directly from the PIM or WMS systems for use in the others, then the standards set by the PIM or WMS team are automatically enforced for all other teams.
Case study: Dr. Oetker harmonizes platform infrastructure with HygraphRecommended Reading
Reduced training time and costs
When you dictate the tools that your writers and editors use, you must provide training and support for those tools. This can be time-consuming and expensive, especially if you have a large team. Instead, if you work with your teams and allow them to collaborate and help craft the editing experience, including the tools, you can gain buy-in and drastically reduce training time and costs. When drafting a content architecture and strategy, involving your editors as early as possible can help save on inconsistencies later.
Since your team is already familiar with those tools, they won't require as much training, and you won't need to spend as much on support. This can free up more time and resources for other critical tasks, such as content strategy and distribution.
Setting up a distributed CMS
While a multi-CMS approach may feel like it adds a lot of overhead or orchestration, it’s possible to set this up in a real-world approach with relatively little effort.
In the past, this would have required custom orchestration layers. Whether those were hosted middleware functions, content hub approaches, or an incredibly bloated frontend, it often felt insurmountable. We can easily overcome these deficiencies with recent improvements in the federation world. While tools like Apollo made the development of orchestration layers easier, concepts like Content Federation allow for ease of use for developers and non-technical users to create orchestration layers.
With Content Federation, we can craft a system where multiple data sources come together in a low-code or no-code system and allow for data to be remixed in various ways.
An eCommerce experience
Let's look at an eCommerce store as an example of real-world distributed content management. To create an eCommerce experience, we need product information, blog posts, page content, user reviews, and more. No single CMS provides the ideal solution for all these types of data.
Product information is often best housed in your product information management (PIM) solution — Shopify, BigCommerce, Magento, etc. These PIMs are great for eCommerce data but are notoriously bad for marketing content and are often not fully featured enough for complex inventory management, where a warehouse management solution (WMS) would be a better tool.
When crafting marketing pages, you’ll want a CMS with a solid foundation of both data and content and the ability to combine those in some form of page-building system. We may be biased, but Hygraph is a great solution here.
Finally, your content team may already have a blog in a system like WordPress. Say what you will about WordPress, but it’s still a solid blogging experience. Its page-building experience is weak, as is its PIM experience.
Each of these platforms offers specific perks and deficiencies. Combining all of them together can create a great experience for all editors involved. Let’s make sure it’s also a great experience for developers by combining all of the necessary data into one API.
Using Hygraph’s Remote Sources functionality, we can pull all the data from our PIM for product details, inventory levels from our WMS, and all the blog posts from WordPress and combine them with marketing data and campaigns stored in Hygraph to create a full API of all the data needed to build experiences across multiple channels.
On top of that, any data can be augmented and constructed in new ways. Products can be added to campaign pages. Specific reviews and blog posts can be built into the homepage (and changed by editors). All of this is unlocked when you use a CMS as your middleware.
Conclusion
Content velocity, content experimentation, standardized data, and flexible site building are cornerstones to crafting a strong brand image and a strong business. If any one of those pillars is weak, the entire system can crumble. You can gain standardized data by forcing your team into a monolithic approach, but content velocity and experimentation will suffer.
By allowing your team to work in the space they’re most comfortable or where the data is best served, you open up a higher level of velocity and experimentation. With the advent of Content Federation, you don’t suffer from bad data or problematic site-building. One standardized API from customized, efficient, flexible sources.
Top comments (1)
What do you think? Is it possible that with a little bit of extra complexity, we can simplify, standardize, and unify our content across multiple systems?