This blog post is by Dennis Shiao, Founder of Attention Retention.
I attended an interesting webinar presented by Deane Barker, Global Director of Content Management at Optimizely. The webinar was hosted by Content Marketing Institute (CMI). You can register to view it on-demand.
The title of Deane’s webinar was “Single Sourcing Content: A Path Forward.” In a previous job I developed an interest in single sourcing content when we added such capabilities to our Content Management System (CMS).
In this post I’ll summarize Deane’s presentation.
What Does “Single Sourcing Content” Mean?
With single sourcing content you have a central repository that publishes content to multiple channels. This repository is at the heart of multi-channel publishing.
An essential principle of single sourcing content is the separation of content from presentation. Content is stored in a repository with no details on how it is formatted or rendered. Decisions on rendering are made at the channel, independent of how that content is stored.
While the industry has been talking about this for a long time, we weren’t practicing what we were preaching. “We talked about separating content from presentation, but for many companies it was theoretical. They were publishing to one channel, so they didn’t really need to separate content from presentation,” says Deane.
NPR Digital: Pioneers In Single Sourcing Content
In a 2009 South by Southwest® (SXSW®) presentation, Zach Brand and Daniel Jacobson of NPR Digital presented a concept they called “COPE”:
Create Once Publish Everywhere
Single sourcing content had been a theoretical construct, but the NPR Digital team made it tangible. Deane calls it “a bit of a watershed in the content management industry.” He continues, “People hadn’t really done it as much as they talked about it. It was one of those benefits of content management that was promised, but never really manifested.”
In a 2009 article at NPR titled “Clean Content = Portable Content,” Jacobson lists the key principles of COPE:
- Develop Content Management Tools, not Web Publishing Tools
- Separate Content from Display
- Eliminate markup from content
Deane showed the user interface (UI) of NPR’s content repository. Here’s the metadata for a story about Winnie The Pooh:
This content repository is the “Create Once” side of things. Deane showed examples of NPR’s “Publish Everywhere”:
- Main NPR website
- An iPhone app
- An Internet radio station
- An NPR affiliate website (WBUR)
- In iTunes
- In iGoogle
Each channel used elements from the content repository, but there were also some elements that a channel chose not to use, since it wasn’t relevant to that channel. The look and feel of one channel was completely different than another one, even though the underlying content came from a single source.
Four Challenges of Single Sourcing Content
Deane notes that single sourcing content is not new, but it’s still so hard. He identified four challenges of single sourcing content. For each challenge, he explained why the challenge exists and provided ways to address or mitigate that challenge.
Challenge #1: Repository Models Are Not Content Models
While we understand the need to separate content from presentation, Deane notes that our thinking can intertwine the two. In other words, we model content so we can store it, but we think that those models transition perfectly to all of our different channels.
Deane uses the analogy of a musician. The channel is the stage, whereas the repository is back stage. Musicians act differently when they’re back stage versus on stage. Similarly, Deane says that the way we store content in a repository is not the way we present that content.
“When we take content from a repository and push it into multiple channels, we are going to need to transform and flex that model. We’re going to need to change it on the way over.
We need to be prepared to change the models as they’re transmitted to different categories,” says Deane.
Deane gave these examples of sample model transformations:
- Combined properties: first-name and last-name need to become full-name
- Logical transforms: If hire date is in the future, set publish flag to “Draft”
- Negated properties: Show Sidebar doesn’t apply to a tweet
- Pre-templating: Channel X expects HTML, not Markdown
Deane’s path forward:
Be Prepared to Flex Your Models
Data will need to transform in-transit; take this into account when building content models.
Challenge #2: Consider The Impacts on Governance and Process
Single channel publishing is easy, but things get hairy with multi-channel publishing. Deane shared an example, which I’ll call Deane’s Law of Splitting:
Splitting a process over two systems will ALWAYS result in complications.
Let’s look at complications that surface when content in the repository is updated.
Where do approvals happen? In some organizations, different channels are managed by different teams. When you change content in the repository and you’re publishing out to many different channels, Deane says that maybe half of those channels will want to approve the change in the channel, while the other half will trust that the change makes it out to the channel and is rendered as expected.
Deane says that these are governance and operations questions that you’re going to have to resolve and approvals can be tricky.
Deane’s path forward:
Don’t Assume Governance and Process
Adding more systems will distribute governance; most organizations have a hard enough time with ONE system.
Challenge #3: Content Orchestration Is Too Often Just Assumed
Deane defines content orchestration as “everything that needs to take place to get content from repository to channel.”
The challenge is that content editors are like Mickey Mouse in Fantasia, says Deane. They want to be able to flick their fingers and part the oceans and do amazing things. They want to press one button in the repository and have three dozen channels across the world update at once.
The problem is that Mickey Mouse is a fictional character and the magic of Fantasia doesn’t exist in the real world. There’s real work (i.e., orchestration) that needs to be performed. According to Deane, example orchestration tasks include:
- Static file generation
- File and data movement
- Cache manipulation
- Service notifications
Why is content orchestration too often assumed? Because we’re used to coupled Content Management Systems (CMS), where content editors and content consumers (e.g., website visitors) talked to the same system. Deane says that with a coupled CMS, “Fundamentally there is no orchestration. Orchestration is flipping a bit in the database, saying that this content is now published.”
Here, Deane’s slide shows a coupled CMS:
Deane notes that content orchestration needs to develop into a discipline all its own.
Let’s take the example of social media. Publishing into social media requires some amount of domain knowledge of each social platform (e.g., LinkedIn, TikTok, Twitter/X, Threads, etc.). Deane says that the person responsible for getting content into social media needs to take charge of the content orchestration process — how content gets from one side to the other.
He mentioned some third-party technologies that can help with orchestration, including consumer-grade tools Zapier and IFTTT, and enterprise tools like Cyclr, Tray.io and Prismatic. Deane calls this latter set integrated Platform as a Service (PaaS) companies. These tools can help you orchestrate content from your repository into WordPress, for example.
Deane’s path forward:
Treat Orchestration As Its Own Discipline
If you can, have an orchestration team separate from your repository teams; it will likely need to grow out of the channel side.
Challenge #4: Single Sourcing Can Turn Into Multi-Sourcing
It turns out the NPR Digital team evolved their COPE model into CAPE:
Create Anywhere Publish Everywhere
Here’s how it looks:
NPR took content in from more than one source, concentrated it at the repository, then pushed it out to multiple channels. They were able to take content from more than one source, then combine it in the repository to create information products. These products didn’t actually exist in any one source. They combined information from multiple different sources to come up with unique, new content and publish that out to channels.
Deane came up with the name “Content Warehouse” to denote this bowtie-shaped content architecture. He noted that the core of Optimizely’s platform delivers on this Content Warehouse concept.
Deane’s path forward:
Think Bowtie, Not Bullhorn
Don’t consider your repository as the single source; rather think of it as the single collection point.
My Take
Our content needs to go wherever our users and customers are: mobile apps, social media platforms, custom applications, physical kiosks, chatbots and more. We can all agree that single sourcing content is the right model to support our multi-channel publishing needs.
But here’s the rub:
If you’re using a content platform that supports single sourcing (e.g., Optimizely), that’s good. But what if you’re using a coupled CMS? I recommend these two steps:
- Inquire with your CMS vendor on whether their product roadmap includes plans to go decoupled or hybrid. In my previous job at a CMS vendor, we did just that — we took a coupled CMS and made it hybrid.
- Form a skunkworks project to experiment with a headless CMS. This system serves as the “content repository” I referenced throughout this post. There are free and open source options. Build a content repository and render content on a test channel. This exercise should be helpful in your move towards single sourcing.