Content needs to be accessible across multiple platforms today. The author writes the content once and it’s published everywhere. This is the principle of Content as a Service, decoupling the actual content from the medium in which it is presented.
Content as a Service provides raw content for other platforms to consume and make use of according to their particular needs. This happens usually on the cloud, with a centralized platform that can be globally accessible and provides a standard format for your content.
With Content as a Service, content is centralized into a single repository, where you can manage it, categorize it, make it available to others, search for it, or do whatever you wish with it.
Content is anything usable for information, including text, video, sound, spreadsheets, binary files, and the meta-data from the preceding elements qualifies as content.
A more formal and direct definition of what a Content as a Service platform could include:
There are many reasons why you’d want to go through the hurdles of either upgrading your current CMS into one that is based on serving content as a service, like a headless cms, or installing one where there was nothing before.
The key deciding factor at the end will be your current context. Here are three very obvious challenges you may be experiencing where Content as a Service would serve your content strategy well.
When your company is dealing with multiple sources of content daily, having to manage them all independently requires extra resources, added overhead and a waste of time.
You’re most likely dealing with one (probably more) of these situations:
A switch into a content-centric approach, content as a service would directly improve your performance. Having a content-first approach here would allow you to think differently about your clients or team and about what you’re trying to do every day for them.
If this is you, consider moving into a Content as a Service platform as soon as possible.
Extending content reach can be challenging due to the compatibility of your content with different formats however Content as a Service addresses all forms of content delivery and channels.
Many CMSs, such as Wordpress, assume the responsibility for presentation, ensuring that you don’t have to worry about it. This is perfect if you do not have the resources to build a cohesive look for all platforms for which your content exists, however, this also limits your coverage to only the devices that Wordpress’s representation of your content is compatible. And while it is true that their pages are quite compatible with both computer and mobile screens, there are many devices where your content is immediately rejected or just not pleasant to be consumed in.
For instance, have you ever considered how your Wordpress page would look like in a SmartWatch? What about a VR headset? You must ensure that you’re compatible with the future, especially when new technologies are being developed and released to the public every day. Content needs to be an abstract entity, and choosing the way it looks (or to keep it generic, the way it is consumed) needs to be the task of your clients.
For our Wordpress example, one solution may be to either use their REST API or migrate entirely to a headless CMS such as ButterCMS in order to fully gain their benefits. With both of these solutions, you’ll need developer resources.
There are different ways to tackle mobile development, and one great way to manage the content is with a mobile cms service. Content comes in many forms, and the most traditional CMSs available only provide web-compatible formats (such as HTML). In those cases, that format might not be the best fit for your app and would require you to work around that by adding extra support. There is a better solution!
Using a headless CMS or a Content as a Service approach can simplify your work. Here your options are quite straightforward: you transfer your presentation-less content to your clients’ applications and there, they can choose how to format it and display it to their users. You don’t need to worry about that part when authoring it and managing it.
The Content as a Service approach provides your team with the flexibility to use content to meet any use case requirement now and in the future.
If you have only a single use case for your data, switching to a Content as a Service approach would be the equivalent of using a shotgun to kill a fly. If you don’t need to worry about multiple channels or multiple representations of your data then Content as a Service is overkill.
If you need full control over how your content is supposed to look, but you don’t have the technical chops or resources to do so then a Content as a Service approach will be a poor fit. If this is a problem for you, likely a traditional CMS is your best bet. You don’t need to worry about building the presentation layer because that comes with the CMS, and you also have all the benefits of a centralized platform for content management.
Based on the above motivations to use a Content as a Service strategy for your projects, here are some classical use cases:
Mobile apps aren’t necessarily known for being really compatible with web content. Yes, they can render it using some particular components, but that content will visually jump out at you.
Also, if you think about it, having web content available, and not using it for web browsers makes little sense. In these cases where your content is only meant to be rendered in a mobile app, you would benefit greatly from splitting content and representation and allowing your own app to render your content the best possible way.
If instead, your problem is that you need your content to reach as many channels as possible, like going for Web, Mobile, SmartWatches, your SmartTV and (why not) your eventual SmartFridge, what you need is a way to distribute that content from a centralized location.
Solving these types of problems is one of the reasons why we have Content as a Service providers. As long as you’re working with one of them, there is nothing extra you should be doing. It’s up to your clients (or content consumers if you will) to decide how to use your content however best suits their needs.
Another use case is allowing your content consumers to customize your content’s presentation however they might want. By serving your content through an API and in a generic format, like JSON, where you have a predefined structure for it, your clients can pick and choose different parts from the content and use them however they need. In fact, this approach would actually allow different consumers to render the exact same piece of content in different ways.
In addition to providing different ways of presenting content and reaching other media, marketing platforms can analyze content to understand different things using machine learning and NLP (Natural Language Processing) techniques.
For example:
From a technical point of view, Content as a Service can be considered a pattern, a way of architecting your platform in order to obtain the benefits mentioned above. The actual implementation remains custom, as with any architectural pattern, but if you wanted to have a general overview of how a Content as a Service platform might work, here is a diagram:
The Content Management UI refers to a web application, one that centralizes all content authoring and content management of the platform. Here is where everything content-related happens.
Content is then centrally stored. The format for that and the technology used is not relevant at this point, anything that fulfills the intention of correctly storing data is good enough.
Lastly, the content is made available through a technology-agnostic API, meaning your platform shouldn’t care about the technology used to get the content. As long as they can speak with it, they’re fine. Normally, this is done with a REST API, as is usually the industry standard. But given the current trends, we should soon start seeing similar setups using GraphQL.
If you consider the box, “Content Provider” in the above diagram as a black box, you can think of solutions such as a ButterCMS or headless Wordpress as valid options. With these products, you’d be using their own platform to author the content whilst working on the presentation layer, comprising whatever set of applications you might need (maybe web apps, mobile apps and others). You could, as an alternative, also provide access to the public APIs of these platforms, allowing others to take care of building their own presentation layers and saving you the trouble of working on that.
It isn’t easy to find examples of sites or companies that advertise the use of these platforms since they are considered part of the base infrastructure or technical stack used to create them. A few who do are:
Hopefully, by this point, you have a pretty good idea of what Content as a Service means, how it works, and why, if at all, you should use such a strategy.
When it comes to content that has value to multiple audiences, content as a service allows systems to scale without impacting performance and also serves at a global level.
And to make things even easier, there are quite a few companies providing content as a service with bindings to all the common programming languages, making it even easier for you or your developers to integrate with them.
Let us know in the comments if you’ve ever used one of these systems and what your experience has been with them!
Do you want your product or marketing team to test Butter CMS? We can set up a live demo to walk your team through the fast, easy-to-use interface.
