There’s been more than a little bit of discussion on content over the past few years (like here, here and here).
For many brands, content has moved past the ideation phase and into execution. Yet, this stage carries with it challenges of its own. Specifically, how do brands and organizations manage content that serves multiple functions for disparate audiences in a multi-device, multi-channel world?
Traditionally, this challenge has been solved with a CMS, like WordPress, Drupal, or other proprietary options. Then use-case specific products hit the market, like HubSpot for marketing or Confluence for documentation.
However, it’s become evident that these solutions can fail to address the broader problem for the enterprise – how to get useful content in front of the right audience at the right time. Customers don't stick to silos quite as much as organizations would like, and content that’s produced in one place is often going to be (or should be) used elsewhere.
Enter Content as a Service (CaaS). In this article, we explain what it is, why it matters, and the advantages it can offer over a standard CMS for businesses.
What is CaaS?
CaaS is basically a cloud-based solution that stores content in a nebulous form, and then pulls it out and loads it whenever or wherever it’s needed. There’s no structured format or specific shape that content comes in – it can be anything, and it can go anywhere.
Now it might be worth thinking a little about what we mean when we say content. Content is usually used to describe:
- Web articles or blog posts
- Whitepapers and case studies
- Videos and webinars
- Sales/marketing assets
But content is much broader than those categories. It could also be help documentation, app features or functionality, enriched experiences provided via ReactJS or some other language. It could be anything!
So, why use CaaS?
Because it decouples the content from the container. We’ll come back to the advantages of this in a minute, but let’s see how this works.
First, a content repository is hosted in the cloud. Think of this as a cloud-based library bookshelf.
Next, all of an organization’s content is stored there; tagged, catalogued, and organized.
Then, that bookshelf is connected to everything else via RESTful APIs. You can think of these as librarians who can come and get books for people from the bookshelf.
Next, there’s some form of front-end interface – website, mobile app, web app, kiosk, etc. This allows users (re: library card holders) to come and check out books. This will call the content usually as JSON format or some other dynamic, useful structure.
The front-end loads the right content based on those early categorizations and tags. Essentially, the content is pulled out from the repository in an unfinished format and is then formatted by tags embedded in the container.
Finally, this front end is littered with webhooks to call out to the library shelf and see if anything’s changed to keep all the content up to date.
So the process goes something like this:
- A content publisher writes a piece of content. They catalogue and tag it correctly, and file it with the library.
- The tags and cataloguing tell the piece of content where to go. For example, a blog post on a website.
- A user clicks on a link on Twitter to the blog post.
- The website calls out to the cloud as the page loads, requesting the content and loading it for the user. Note: the container (e.g. the web page) is empty UNTIL the content populates it from the library.
- The user reads the blog post.
That’s roughly how CaaS works. Now, let’s see how this is different, and why you should care.
How is it different from a CMS?
The fundamental difference here is around containers and display. CMSes like WordPress first started as a way for people to build websites quickly and easily.
From their inception, they were focused on building the container and populating it with content.
But with CaaS, this is no longer the case. The content is stored completely independently from the container.
This means content can be loaded, shaped, or reformed to perfectly fit the container that’s there.
For example, instead of having a single site with responsive design, you could have a non-responsive website and a mobile site.
Normally, this would require two sources of content. But with CaaS, you don’t need that. You can have a single source of truth and it just gets called via RESTful APIs to two different locations.
With webhooks, you can change the content and know that it will be changed everywhere, instantaneously.
Basically, it means that content can be produced to be completely user-centric, rather than produced to fit into a specific mold. Then, it can be quickly and easily updated whenever it needs to go.
Why use CaaS?
Now that we know what it is and how it’s different, let’s focus on the most important part – why bother with CaaS?
Recall that we previously said it decoupled the content from the container. That means there can be a single source of truth for all the content an organization produces. It’s easy to reuse, repurpose, and fit into specific settings or containers. When new experiences are needed (e.g. for new devices or platforms), they can be developed independently, with CaaS delivering the existing content library in a new format, without needing to re-think the existing platforms.
It also makes content more responsive and sensitive to the device it’s being viewed on. It can even mean that the content being displayed can be tailored to the user intent in that moment.
Second, it means content can be quickly and easily updated and maintained across many platforms and experiences. Changes can be made once in the repository and take effect immediately across all experiences. It’s truly a single source of truth.
Technology is fundamentally an evolving beast. Change happens slowly, and it usually happens through incremental improvements.
First, we had hard-coded HTML pages, then a CMS for easy content creation, then responsive design, so that content looked great everywhere. Now, we’re into CaaS, so the right content gets in front of the right people at the right time – always up to date, always fresh, and effortless to build and maintain.
Download our Guide to Planning Your Enterprise Website Project