Content as a Service

Content as a Service (CaaS) means that you make information available on request. The traditional publishing model is to package and format information into print, PDF, or websites, and make those collections available to the consumer. But with CaaS, consumers decide what information they want and in what format they want it.

CaaS: giving control to the content consumer

In a traditional publishing workflow, the content owner is in control until they distribute the content. After distribution, consumers take control. (A wiki is an outlier approach in which consumers can participate in content creation. From a content lifecycle perspective, a wiki expands the universe of content owners.)

In a CaaS environment, you transfer content ownership earlier in the process. The content owner writes and releases content, but the released content is not packaged or formatted. Instead, the raw content is made available to the consumers. Consumers can then decide which content they want, how to format it, and finally consume it.

If, as a content owner, CaaS makes you uncomfortable, it’s probably because of this shift. In the content world, we are accustomed to having control over content until the last possible moment.

With CaaS, you turn over decisions about filtering, delivery, and formatting to others—a content-on-demand model. The content owner is no longer the publisher. Instead, the content consumer controls delivery; the content owner’s responsibility ends when the content is made available to content consumers.

CaaS: the content consumer might be a machine

In a CaaS environment, the content consumer is not necessarily a person. A CaaS environment could also supply content to a machine.

Your content consumer is likely to be software—another system in your content supply chain. 

CaaS: Troubleshooting information

For example, consider a machine that you control via an on-device screen. An error occurs on the machine:

Error: 2785 battery low

Correcting the error requires troubleshooting. In the past, the troubleshooting content was loaded directly onto the machine, or perhaps a service technician might carry a tablet with troubleshooting instructions. Most machines have limited storage, so it may not be possible to load all content on them, especially if content is needed in multiple languages.

In a CaaS approach, a repository stores the troubleshooting content. When the error occurs, the machine sends the error code to the content repository along with the current language/locale setting, and the repository returns specific troubleshooting instructions.

The obvious disadvantage to this approach is that it only works when your machine is connected to the content repository. 

The advantages are:

• Less storage required on-device.
• Content is stored and updated centrally. No need to “push” information onto every device when there is an update.
• You can deliver troubleshooting information for that exact error code, in the appropriate language, when the machine requests it.

CaaS and chatbots

CaaS is also potentially useful for chatbots. Consider a chatbot that provides step-by-step instructions for a procedure. Instead of loading up the chatbot with huge amounts of content, you connect the chatbot to your CaaS content repository, so it delivers the procedural steps one at a time as the user goes through the procedure. Again, this approach lets you separate the chatbot’s logic and processing from the text.

CaaS for content integration

The proliferation of multiple incompatible content repositories is a huge problem in many large organizations. There’s a content management system for technical content, a learning content management system for learning/training content, a knowledge base for technical support, and so on. 

The primary end user experience is generally controlled by a web CMS, and the other organizations find themselves trying to duplicate the appearance and behavior of the main website for subsites like docs.example.com or kb.example.com.

In a CaaS environment, you solve the content integration problem by making all content available to the delivery layer through content Application Programming Interfaces (APIs). Authors create content in the various specialized systems, but delivery is managed by a single system.

One important caveat: This approach requires systems that can communicate via APIs.

Content integration via CaaS provides a way to build out enterprise content strategy without forcing every author into the same authoring system.

Component-based system architecture with CaaS

In addition to providing for content integration, a CaaS strategy could decouple the components of the content lifecycle from the content management system. Many CMSs offer authoring and publishing, along with editing, terminology, metadata, workflows, review, and personalization.

You might consider a CaaS approach to separate out some of those pieces. For example, you could:

• Build sophisticated visualizations of content status for authors
• Connect with an enterprise metadata system to manage taxonomy
• Connect with an enterprise terminology system to manage metadata
• Connect the rendering system with a personalization engine

There are endless possibilities when you think about each component in the content lifecycle independently.

Getting started with CaaS

The CaaS approach opens up some fascinating possibilities and offers enormous flexibility, but it’s going to be pricey to configure. You have to set up a CaaS repository and then the content consumer needs to set up CaaS requestor systems. Contrast this with traditional publishing tools or frameworks (like DITA). If the features inside a traditional publishing tool meet your requirements, then licensing that tool is going to be the least expensive alternative. You can move up to frameworks if you need more flexibility, and up again to CaaS for maximum power, but each of these steps increases the configuration effort required.

Take a look at the fundamentals of your content. To make content snippets available through a repository, you need granular, reusable content with consistent markup. Structured content offers one way to meet those requirements.

Rethinking content operations at your organization? Contact Scriptorium to discuss how we can help.