In 2018, content is still “king” – and we need more of it than ever before.
We now have a proliferation of channels that brands can use to reach their customers, from websites and apps to social media, email, push notifications, chatbots, voice assistants, and more.
On top of this, we have more devices than ever that consumers can use to access brand content – desktops, laptops, smartphones and smart watches, each with their own specifications and restrictions – with yet more looming on the horizon.
How can brands and marketers create bespoke content for each one of these formats and channels, all while making sure that this content is future-proofed for any new media that might develop in the future? Creating dedicated pieces of content for each individual medium becomes labour-intensive to the point of being unworkable.
One piece of content, many methods of delivery.
In order for marketers to be able to continue to reach consumers using the latest technology and channels, all while incorporating cutting-edge developments like dynamic personalisation, content itself needs to operate in a whole new way. Enter Content as a Service.
The concept of Content as a Service (CaaS) has evolved in response to the dilemma posed by our modern digital ecosystem and its incredibly high demand for new and different types of content. However, it’s also an evolving concept which isn’t always clearly-defined – making it difficult to pin down exactly what it entails, and how brands can implement it.
We reached out to some experts to find out how this new method of managing content works, its benefits, and how brands can get started.
Content as a Service is typically mentioned in conjunction with “headless” or “decoupled” content management systems. What is the relationship between CaaS and a headless or decoupled CMS?
Richard Jones, CTO at Inviqa:
Content as a Service (CaaS) is really just marketing speak for a headless CMS that’s sold as a Software as a Service (SaaS) platform.
It describes a headless CMS that’s hosted and allows you to set up content for consumption by different applications – from frontend web applications, to chatbots, voice user interfaces (VUI), and so on. With CaaS, activities relating to scaling and performance become the responsibility of the platform provider.
Rick Madigan, Digital Marketing Strategist at MMT Digital:
“Headless” is a tricky term, as it’s often a misnomer. It has come to be used in the last couple of years to describe the new wave of content management systems that are lightweight and focused specifically on management and delivery of content.
However, headless is in effect the separation of the administration backend and presentation layers. With that in mind, many of the traditional CMSes – often referred to as monoliths because they cram a lot of functionality for content management, ecommerce, online marketing, analytics, etc. into one product – could be utilised in a headless fashion to pull out content and display through a separate presentation layer.
For instance, a platform like Sitecore could be run in “headless mode”, but that could not be defined as “Content as a Service” because you’re still utilising a monolithic web CMS (WCMS) to provide a broad range of features, and it may or may not be cloud-hosted.
It is easier to think of headless as the overarching term. Content as a Service is simply a category within this, describing the types of content management system – such as Contentful or Prismic – that are hosted, managed and upgraded by the vendors, and which focus on the creation, management and delivery of content.
What’s the difference between a headless and a decoupled CMS?
Richard Jones, CTO at Inviqa:
With a headless CMS, you have no capability to generate front-end code, so it’s purely a content service without a display layer. Headless is reactive because it assumes that another system will request content as and when it needs it. So, if you add content to a headless CMS, what you get out is the same content in the form of an API request.
With decoupled CMS you do have front-end capability, but content-consuming devices and platforms access your content via the CMS API, rather than directly from the database (as with a traditional coupled CMS).
Decoupled CMS is more proactive because it pushes content to template engines that convert the content into a layout suitable for a particular platform or device (i.e. HTML + CSS). In other words, you expose content to other frontend systems, rather than using the theming and presentation layers you would normally use with a coupled CMS.
Typically, a template engine will inject the content from the CMS into a template of HTML and CSS to produce a page that’s ready for a web browser to interpret. A decoupled CMS also gives you the option of delivering your content in pure API form, in the same way as a headless CMS.
What are the benefits of using a headless, or decoupled, CMS to deliver content?
Rick Madigan, Digital Marketing Strategist at MMT Digital:
A headless CMS is usually one component within a modern microservices-based architecture, something that many businesses are moving towards. Therefore, it’s important to move the conversation to that of the benefits of a microservices approach, rather than just talking about the benefits of a headless CMS.
With that in mind, there are several benefits that I would identify. First, flexibility and speed to market: free from the constraints of the traditional CMS, which will typically assist in constructing the HTML, developers can very quickly build up user interfaces and deploy these changes, assuming you have a well-architected deployment process in place: something that goes hand-in-hand with modern microservices architecture.
Secondly, customer reach. The content you are creating through a headless CMS is no longer wedded to a site. It is just content in its pure form, which opens up the gates to allow businesses to leverage content across channels – whether that’s websites, progressive web apps, voice, bots, smartwatches, etc. We can get greater returns on investment for the content that is created by using it through the channels that customers use at the right time.
Thirdly, future-proofing. A typical microservices architecture would be decoupled – essentially no systems are tightly bound together – so businesses have greater flexibility over the infrastructure. If it was decided that the headless CMS did not have a suitable roadmap or was proving to be less value for money, the content could be exported out into another headless CMS, the old CMS could be pulled out and the new CMS could be introduced, all with a lower amount of input from developers – a very different picture to the traditional architectures where it is more difficult to make such changes.
There are also benefits in terms of cost, innovation, greater control over automated testing – and happier developers. We rely on developers to deliver the solution. With traditional CMS, they are often hamstrung by the constraints of the system and prevented from using the latest tech. Using a headless CMS, we give developers the freedom to use the technologies they want.
Richard Jones, CTO at Inviqa:
Content and decoupled CMSes are helping organisations in the race to maintain, grow, and engage audiences in real time, in the right context, across a growing number of content-consuming devices – each with different contexts and capabilities.
Unlike the traditional CMS model, where content is tied up with presentation, this new breed of CMS makes it easier to deliver the right information to the right places by presenting content as clean, structured data.
Six examples of brands using a decoupled CMS
Changing to a decoupled approach from a traditional CMS could potentially be a large undertaking, so it’s important to be clear about why you’re making the change, and both the opportunities and challenges this will create for the organisation. A key driver is usually the organisation’s need to seamlessly deliver content to new platforms and for emerging use cases (for example, for voice user interfaces like Google Home or Amazon Echo).
Is a headless CMS suitable for every organisation? When should brands consider using one?
Richard Jones, CTO at Inviqa:
The first consideration needs to be the current structure of your content. Structuring your content into reusable components might sound simple, but remember that content often fits together in complex ways. Any ambiguity in the content model will make it hard for content-consuming platforms to understand the context of your content.
That’s why I always recommend going through a content modelling process that helps the organisation understand the domain of the content without being distracted by its layout and other cosmetic implications. Starting with connected content design is a good thing to do when thinking about a decoupled CMS.
Rick Madigan, Digital Marketing Strategist at MMT Digital:
There is no definitive answer here and it should always be treated on a case-by-case business. While there are trends showing businesses moving towards this, there are a number of factors that can determine whether the approach is suitable and feasible for businesses.
You can boil these factors down into two broad groups – infrastructure and technology, and people.
Starting with infrastructure and technology: the move to a headless CMS is unlikely to be simple. In the majority of infrastructures there are dependencies and constraints which can come from the hosting environment, the way in which the digital ecosystem has been architected – as in, how systems fit together – and even in the different systems or software in operation within the ecosystem, some of which may be business-critical.
You need to analyse the journey from the current situation to where you want to be, devise an iterative strategy for getting there, and that in turn will reveal the budgets and timeframes you will need to work to and give you an assessment of the feasibility of such a move.
As far as people are concerned, you can split this up into editors and developers. For editors, the move to a headless CMS can be jarring. It’s a different mindset and, to an extent, a different approach. Content is intended to be treated as just that, agnostic from any channel, so sitemaps and site trees are gone. It requires a shift in mentality which some will handle better than others.
With developers – do they have the skillsets required to handle not only the migration but also ongoing development? It’s a cultural shift. It’s bit of a generalisation, but from experience, developers will often handle the change better than editors.
How can brands who want to manage their content in this way get started?
Rick Madigan, Digital Marketing Strategist at MMT Digital:
With most of the large organisations that we work with, the advice is to start small. Find a use case within a smaller project that provides an opportunity to spin up a new website or application that could use a headless CMS rather than having to be implemented in the legacy CMS. Beyond just the content, start to think about how you could develop modern microservices to interact with other platforms that you need (e.g. CRM, analytics etc).
As part of this project, work with architects to map out the ultimate goal. What would a complete shift to microservices look like in terms of search, personalisation, marketing automation, business services, CRM, data & analytics, etc.? Whilst this is probably handled with a small number of legacy platforms, what might it look like in the future?
You can then devise a strategy to iterate towards that goal without having to throw everything out and start again.
Richard Jones, CTO at Inviqa:
First, step back and work through the content modelling process. Getting the content design correct is the most important foundation piece that can be put in place. Only then should you start looking at the technology and determining which system best supports your content model and, importantly, your editorial workflow.
One of the key considerations of headless technology is that you’re no longer designing for a single end point, so the concept of the editor being responsible for content layout will diminish if not disappear completely. This is a big transition for some organisations used to WYSIWYG systems.
Once this is done, consider how to migrate the existing content from the current structure to the new connected content world.
Let’s use a recipe page as an example: in a traditional CMS there might be a single text area where the editor enters the ingredients, instructions, and so on, but with editorial guidelines around how this should be done. With a well-designed content model, this could become a number of specific fields for each ingredient and instruction step.
Repurposing recipe content into different formats
Once this is done, consider replacing some elements of the website first rather than trying to do everything at once. You might consider category listing pages or news pages as a good place to start.
A final piece of advice: now that decoupled is becoming more of a mainstream concept, there are many different CMS systems coming onto the market – both commercial and open-source offerings.
At the same time, traditional CMSes like Drupal are adapting their approach so as not to get left behind. While the CMS market has been consolidating to a number of key players over the last few years, we are now seeing a reverse of this, with lots of smaller services available.
In a crowded market, it’s important to be careful when making technology choices, so consider:
- The system’s maturity
- The cost model (for Content-as-a-Service systems)
- How fast-moving a system is when it comes to the code base (this is related to maturity)
All this being said, the different systems now available often have very similar concepts when it comes to content structure. As a result, it’s possible to move between them fairly easily as needed.
Further reading: