This blog post provides my perspective on the headless CMS (Content Management System) metaphor, although some of this content may apply to any headless system.
Different CMS vendors use different terminology and definitions. This is my general summary assuming a website as the default delivery channel.
- Body: The CMS back-end, where content management users maintain content (content management tier).
- Head: The CMS front-end, which delivers content from the CMS to visitors accessing the published website (content delivery tier).
- Face: The website itself (customer solution).
By this metaphor, CMS users and developers might be the neck and arms could be integrations, but the metaphor really does not hold up because the head and body can have different arms, legs (software platform?), and feet (hardware platform?). For me, it helps to think of a headless CMS as a browser-based user interface for editing JSON exposed via REST.
Before headless, CMS products tended to include a content delivery engine, whether using static file generation or CMS vendor (typically tightly-coupled, non-REST) APIs for content delivery, almost always using the same technologies (such as Java or ASP.NET) for both content management and content delivery. CMS customers would install the CMS body and head, configure the CMS body, implement a face on the body and eventually head, and publish content from the body to that face running on the head. With headless, the CMS vendor provides only the body, leaving the head for the customer to implement along with the face.
Some vendors use the term decoupled, which seems to have something to do with using different vendor APIs/SDKs in the body and the head, typically using REST to access the CMS from the head. This is one way for older systems to provide MACH-like facilities without rearchitecting the entire product to follow MACH principles (microservices, REST-API-first, cloud, headless). While there may be some value in decoupling, I see significantly more value in true headless solutions, especially with SaaS. Be careful to understand the difference between headless and decoupled, ensure that vendors use appropriate terminology, and select a solution that aligns with your interests.
One common point of confusion is that a headless CMS only appears headless to the CMS vendor, who has no responsibility for and theoretically no knowledge of the head or heads (another breakdown in the metaphor), although persistent REST calls indicate the existence of one or more heads. By this measure, the CMS may actually appear bodiless to the customer, who has no responsibility for the body. Although a customer can confirm the existence of a body through a browser-based UI and REST, they cannot really touch the body, in the same way that the vendor cannot touch the head(s).
With SaaS headless CMS, the vendor provisions a body in their cloud and the customer separately provisions a head using the technologies of their choice. The customer still designs the face and publishes content from the body to the face. To interface with the CMS, customer solutions invoke REST APIs and intercept webhooks invoked by the CMS, for example after publishing. Customers can extend the CMS user interface in various supported ways to integrate with other systems, but customers do not have complete control of the CMS application.
For this approach to have any value to the customer, the CMS vendor must maintain the body, which is why headless CMS provides maximum value on SaaS. Otherwise, the customer is still responsible for cumbersome, complex, expensive, and sometimes impactful upgrades to the body. Relative to alternatives, the relentless CMS upgrade penalty is a primary visible cost avoided by implementing SaaS headless CMS. The bigger the body, and the more integrated it is with other systems, the more difficult and expensive it is to upgrade, and some CMS products have very big bodies. Be careful to understand the difference between SaaS and other infrastructure options, ensure that vendors use appropriate terminology, and select a solution that aligns with your interests.
Headless CMS helps to avoid hidden costs as well. Implementing a content delivery tier that depends directly on the CMS product represents a strong form of vendor lock-in. This approach makes it difficult or impossible to migrate the customer solution to an alternate CMS. The tight dependency also increases upgrade costs. Be careful to understand tight coupling, ensure that vendors use appropriate terminology, and select a solution that aligns with your interests.
These vendor lock-in and upgrade cost issues are exacerbated most when customers extend, integrate, and otherwise customize a CMS body that is not headless. In many cases, the CMS becomes a sort of hub between various applications within the organization that all feed content to CMS channels such as the website. Increasing the number of programming interfaces employed by the CMS itself, even using REST architectures, increases the cost of maintaining, upgrading, testing, and extending the CMS itself. Headless CMS avoids these complications by supporting extension only on the CMS UI front-end rather than in the CMS itself, typically using code that can be hosted separately from the CMS to serve UIs that return data to the CMS for storage without impacting any back-end functionality beyond simple configuration.
As usual, I am just writing in a sort of stream of consciousness. I likely got some things wrong, left other things out, and repeated some things, so I will try to update this post over time. Any perspectives that you could share in the comments on this blog post would assist me in this effort.
- What Is SaaS Headless CMS?
https://deliverystack.net/2020/07/20/what-is-saas-headless-cms/ - SaaS is the Only Real Cloud
https://deliverystack.net/2020/07/21/saas-is-the-only-real-cloud/ - The (Best) [CMS] API Has No Methods
https://deliverystack.net/2020/07/21/the-best-cms-api-has-no-methods/ - Considerations for Headless CMS Architectures
https://deliverystack.net/2020/09/22/considerations-for-headless-cms-architectures/ - Considerations for Migration to Headless CMS
https://deliverystack.net/2020/09/08/considerations-for-migration-to-headless-cms/ - [Hard] Questions for [Headless] [CMS] Vendors
https://deliverystack.net/2020/08/26/hard-questions-for-headless-cms-vendors/ - The Three Types of SaaS Vendors in WCM
https://markdemeny.com/2019/11/the-three-types-of-saas-vendors-in-wcm/
Deliverystack.net 
5 thoughts on “The Headless [CMS] Metaphor”