There was a time when monolithic CMSs satisfied everyone’s needs. They offered the luxury of being able to quickly create and deploy websites. Best of all, they could be handled by users who had little technical expertise or design skills. This was a small business marketer’s dream, and even medium and large organizations found value in CMSs that coupled the content repository with the ability to manage webpage experiences.
Then, along comes the Internet of Things (IoT). Content is no longer confined to the web browser—it needs to appear on phones, smart TVs, tablets, watches, ATMs, car dashboards, etc. In addition to the innumerable visible user interfaces that need to be served content, there are also things such as chatbots, text messaging clients, and virtual assistants. These platforms also need to deliver content despite the lack of a web presentation. In most cases, consistency of content across these platforms is a key concern. This is particularly true in larger organizations with multiple entry points for customer interaction and highly regulated organizations.
To address this need, headless CMS offerings have gained popularity in the market over the past few years. The headless model offers a content repository that is completely decoupled from the presentation layer. The headless CMS provides workflows to create, read, update, and delete (CRUD) interaction either through a user interface or via APIs. The beauty of the headless model is that it allows front-end applications of all types to access a consistent set of content. The pitfall is that managing the presentation of that content is left up to the front-end application. While this works well for applications without visual user interfaces, the only real advantage it offers to systems with heavy presentation management needs is content consistency and sharing of content. In fact, it takes a step backward from the old monolithic WCMs in that it takes the ability to manipulate user experiences away from non-technical marketers and makes presentation management a developer-heavy operation.
So how do we address this need? Keep in mind that the features of the headless CMS—platform agnosticism, content sharing, and consistent voice-— are important. Equally important, however, is the need for non-developers to manage webpage presentation with the speed-to-market that is available from popular WCM systems. In short, we need to be able to add a “head” to the headless model, without breaking the decoupled nature of the content repository. There are multiple ways of accomplishing this:
- Roll your own—If you have sufficient developer capacity and time, you can build a presentation management application to sit on top of your headless CMS. This would involve creating APIs to enable content-as-a-service (CaaS) functionality between the headless repository and predefined templates. The nice thing about this approach is that it can be customized to fit the needs of the organization. The downside is that every new business need could result in a lengthy developer exercise.
- Find the unicorn—Recognizing the need for a decoupled presentation management solution, a few vendors have taken on the task of creating software that builds webpages with content sourced from an external CMS. This typically involves APIs that export the document object model (DOM), making it consumable by other applications. While this approach might offer a quick solution, the products in this category are sparse and relatively immature.
- CMS-squared—This involves using two CMS products. A headless CMS would serve as that repository for both structured and unstructured content. A WCM product would also be implemented to manage presentation, and it would exchange structured content with the headless repository through APIs.
Likely, the problem of merging the benefits of the headless CMS with those of a WCM system will be solved by future offerings in the industry. In the meantime, organizations that want to get ahead of the game are forced to blaze a trail of their own. Determining which of these methods to use is the new challenge. In any case, it involves strong collaboration between technical resources, business intent owners, and marketers. Ultimately, each of these groups must be satisfied with the solution for it to be successful.