The consequences of headless for your content organisation
Author: Tim Hanse
Content management consultant at Crossphase
Published on 14 August 2019
And then, suddenly, it’s there. A headless CMS. And unfortunately, it’s not that easy to get rid of, either.
But what should I do with it as a content manager?
It sounds perfect. A CMS that will allow me to service all channels through an API. Omnichannel. Something that I – maybe one day – can connect to AI, and that can serve the right content on its own. Something that can serve any customer with the right content on any channel.
Sounds good, right?
But what is a headless CMS?
A headless CMS is a system in which the front-end code is detached from the content database.
And that’s where the confusion starts. Which of these two components should you then call the CMS?
Where do we manage content?
My answer: We can call both parts a CMS. Because we manage the content in the database where we edit and save it, and we also manage the content in the front-end module, where we connect it and give it a purpose.
To avoid any confusion, though, I will call the database ‘the database’ in this article. And that brings me to my first point.
To use the content optimally, we need to get rid of the idea that content is a ‘finished product’. With ‘finished products’ I mean web pages, newsletters and applications. Content should not only be recyclable within the communications channel but also outside of it, and it should be reusable for other purposes. A simple example of this is an image used as a header on one page. It can also be on another page and it can also be in background of a newsletter. Text should also be reusable. This means we can’t store content as complete pages anymore, we need to store it in smaller parts or components. Even though I would like to refrain from using the word ‘components’ in this article. Components often have a purpose, such as header block or intro field. In essence, content should be broken up in small, ready-to-use pieces. You can think of it as a crate of Lego blocks. We sometimes refer to this as the ‘granularization of content’. These Lego blocks should also be retrievable. And managed in a database. And that requires a specific way-of-working.
Storing all these small fragments of content is something that you can’t just do in a folder structure. You can do it, but you’ll need a search engine so you can always retrieve the correct content. In addition, you often use folders to delineate borders and serve as containers for content. And in the end, you want everything in a big content container. That container can then be used to retrieve the content.
You can do that by giving each piece of content metadata – not to be confused with the metadata for SEO, by the way. We’ll refer to this as micro-metadata.
This metadata contains information about the piece of content.
Think of properties such as name, content, potential channels for usage and potential functions.
Similar to the way we’ve categorised animals and plants into different kingdoms, we create a categorisation for the ‘content kingdom’.
But is that enough? What if we want to connect AI to this data? And how do we join this content into coherent pieces? How should we store different content pieces relevant to each other? Can we provide content with metadata that can show relations between different pieces of content?
The answer to this is ‘yes’. We can do that by applying ontology to content. Ontology?
Ontology, or the branch of metaphysics that deals with the nature of being, can be applied though usage of RDF and OWL2.
RDF is a way to enrich the linking structure between items. This enrichment is written in OWL (Web Ontology Language). This is literally the relationship that two items have. In short, the link between two items can be included in the metadata.
AI will make managing data in a database more challenging if we go for the ultimate option. In practice, we will probably not see that much granular content.
With an eye on the developments described above, I predict that we will have new specialisms within the content realm. The work of the content manager will be divided over the two applications that can be used: the front-end module and the database.
The front-end module will need both marketeers and writers. People who can set up and manage campaigns. This is the creative side of content management. They will have to switch their current ‘end product’-based conceptual way of thinking to thinking in modules and fragments.
For the database, we’ll need people who are good at managing large amounts of data. A data manager. And I think that, with the trend towards headless systems, will also be a larger demand for good taxonomists who can supply content with the right metadata.
In the end, all these parties will still need to collaborate, but your team will need a broader range of expertise to tackle these challenges. In addition, many organisations are not set up to be flexible enough, with many silos within the organisation catering to a broad range of channels. I understand that it’s not always possible, but there is an increasing need for central content teams who can manage the content or the data properly. I would like to close off by saying that all of this is still some way off into the future. The near future, perhaps. But you can continue with your daily business tomorrow morning.