A few weeks ago Kaya Ismal published a great article on CMSWire called “The Headless CMS Hype: Someone, Please Think of the Marketers.” I’ve been wanting to shed some light on SDL’s views on this topic, since I think he’s spot on with his observations.
If you haven’t already read it, his piece can be summarized with: headless doesn’t solve your CMS issues, it just creates a larger “Franken-platform” of digital marketing technologies, cobbled together to deliver the capabilities and agility needed by today’s marketers. Marketers still need to deliver content on specific channels, so “… those front-end tools need to survive any headless shifts, and they need to be upgraded in terms of speed, functionality and ease of use.”
Repeating the words of Boris Kraft, co-founder of Magnolia CMS, about traditional CMSs: “A CMS typically provides things like asset management, navigation, security, workflow, access control, caching, categorization and link management to name a few. These and many more are not immediately available with a headless CMS approach.”
But looking at Forrester’s report “The Rise Of The Headless Content Management System” from March 2016, we can see that traditional CMSs suffer from content cluttered with markup and metadata, tightly coupled authoring and delivery environments that make it hard to reuse content elsewhere. They also treat APIs as an afterthought, and product packaging makes it difficult to buy just the content repository.
Digging deeper – the actual use cases
So there seems to be a strong case for the traditional WCM system, and an equally strong one for the headless CMS. How should we deal with this paradox? First let’s look at the various cases in which CMSs are used most of the time (sorted – more or less – from most to least frequent):
- Managing longer-life websites (.com, country sites, extra & intranets)
- Delivering these sites on a wide range of devices, mostly web and mobile
- Campaign sites and other short-lived online properties
- Syndication of content to affiliate sites / companies, or for to instance your ecommerce environment
- Reusing content on other channels, in particular mobile apps, but also other devices such as POS displays and kiosks
- Potentially reusing some of this content on social channels
Clearly this list may not be complete for all the use cases in your company, and your priorities might be slightly different – but it should broadly cover it.
Items 1 and 2: Let’s now put ourselves in the shoes of the marketer. Clearly you want those use cases that eat up most of your time, to be the most optimized. As you can see the top 2 are straightforward website management activities, the realm of the traditional CMS where you need all the features listed by Boris Kraft (workflow, link management etc.) as well as WYSIWYG (aka in-context or in-page) editing.
Item 3 is a tricky one, since on antiquated Content Management Systems you might be depending on a lot of IT handholding. Modern CMSs should support this and put control in the hands of the marketer.
Item 4 and 5 are the first occurrences of where content should be strictly separated from markup and formatting, and these would be good use cases for a headless CMS that just manages the content. Typically this content is largely the same as what you need for items 1, 2 and 3 so managing that separately doesn’t make a lot of sense – you’re better off with a traditional decoupled CMS that manages content separately from the presentation layer, and that enables you to export it to XML or JSON formats. Even here, previewing would still be possible provided you’re using a decoupled CMS with a proper set of API’s that have the ability to provide a live preview that comes out of another system – and such CMSs exist.
Item 6 is arguably the least interesting use case for reuse of CMS content. The question is whether you would author such content in your CMS in the first place. Only binary assets – such as videos, pictures or PDF’s – are typically reused, so make sure you seek out a CMS that can post such items to external platforms. For most CMSs this is not rocket science, and again it doesn’t mean you need a headless CMS.
The case for a headless CMS
In many cases a traditional CMS can do the job, provided you selected the right one. Where we see specific use cases for headless CMSs is in the following examples:
- The CMS sits behind another system that manages the actual customer experience – think about for instance an eCommerce-led digital experience
- The content being managed is completely separate from the regular websites, for instance purely for syndication to other players / systems that handle the actual publishing of that content
- To drive specific content into new channels such as VR, IoT, or highly specific apps
- Where you have a very strong IT group and there is a need to build highly bespoke digital experiences that pull information from a wide variety of content sources
A few last words on the traditional CMS
Most companies are on their 2nd or 3rd generation “traditional” CMS, so they have quite some experience with it, and know what to ask for when they engage with vendors during a replacement cycle. Nevertheless some final things you might want to keep in mind:
- Check whether your new CMS is decoupled, separating out the content management environment from the content delivery environment
- Ask if the vendor has a standard “head” for the CMS – a best-practice web implementation that uses the (documented) APIs and shows how to best build your responsive web application, as well as expose content in XML or JSON format to other channels
- Check cloud options – if the system is truly decoupled, does the vendor offer the possibility to serve just the content management element as a PaaS cloud solution for instance, so you have more deployment flexibility?