Whenever I am in a room discussing all things content management with peers and talking about the definition of “headless”, “hybrid headless” and “composable” I’ve found that even among a group of five people you’ll get six opinions. What is clear is that “headless” is a pretty poor word to describe headless content management systems, if only that as a start, its core definition is related to what it isn’t rather than what it is – specifically it refers to a content management system that is intentionally lacking delivery capabilities (known as the “the head”). Therefore, by the core definition of being less a head, a headless CMS lacks this capability.
Of course, this definition falls down fairly quickly, because a content management system that is designed with delivery capabilities (“the head”) can also have the ability to serve content through APIs – which is where the definition of “hybrid headless” comes from.
So, in fact, a slightly clearer definition of “headless” would tend to be “a content management system that is capable of exposing content via APIs such that it can be easily consumed by services or frameworks that can handle the delivery of content”. I think the second part of that definition is key – core to the value proposition of headless systems is the ability to be easily fitted to a “head”.
However, even this definition does not fully capture the details of whether that API is particularly good at the core task it’s being assigned – and it completely ignores structured content, which is one of the key principles for making it all work. It becomes even more confusing because the market definition of headless is even more loaded with nuance. If your agency says “we think a headless CMS would be appropriate for your use case” what they really mean goes well beyond that “base” definition of exposing content via APIs and generally also means various degrees of the following:
- Ability to facilitate structured content
- API quality
- API performance
- API-first design
- SaaS delivery model
- Ability to manage the content management system programmatically
- Built around particular (newer) standards (such as JSON and support for Javascript frameworks and mobile SDKs)
I’m not going to delve into the details of each of those criteria above – partly because it would make this blog post into a small ebook, but mostly because I already wrote that guide – which you can download. I’m also doing a livestream series over a number of weeks where I discuss these in detail with colleagues and other folks.
Similarly, the term “composable” overlaps with many of those criteria above – but where “headless” originates from the technology side, “composable” originated on the business side from Gartner in 2020 when they published “The Future of Business Is Composable”. Again, I won’t go too much into detail, because we already published a much larger piece on the topic, but I will highlight some of the key pillars, which are supported by many of the architectural characteristics above;
- More speed through discovery
- Greater agility through modularity
- Better leadership through orchestration
- Resilience through autonomy
Composable systems and architectures are made up of technologies with capabilities that enable those key pillars. You can be “headless” without being “composable” if those systems (and what you eventually assemble) do not easily enable teams to fully accomplish discovery, modularity, orchestration, and autonomy. An example of a headless CMS that would be “more composable” is one that allows you to easily export your content models and more advanced elements such as workflows or user and group permissions. The more you can do via APIs and script – the more likely you can easily interconnect and automate processes or change systems.
When talking about vendors, there is some confusion because headless vendors can enable being more composable in various degrees (largely through the criteria we discussed earlier; more capable and wide-ranging APIs) but “composable” can also be a noun and shorthand for digital experience composition (DXC) and vendors such as Uniform, which can enable those pillars by providing a layer in which to those functions – enabling business users to be able to connect to, and build upon underlying systems easily.
Ultimately the end product and overall “composability” depends on how you assemble and implement these technologies and support the larger composable business goals.