I know what you’re thinking. “Is this another blog article on how a headless content management system is better than a monolithic one?” No, not really. There are lots of those articles and white papers, including our (particularly good) Headless CMS Buyer’s Guide. This is commentary on a trend we’re seeing that I believe is confusing the market: the so-called “hybrid headless” CMS that can be both headless and non-headless, with a front-end environment and authoring UIs right into a single site design and layout. I’m here to say that there is no such thing as “hybrid headless”. The CMS you’re considering or using will be either headless as part of a MACH implementation, or it won’t, and it is up to you to decide on one approach or another. Allow me to explain why.
It goes back to MACH
Many moons ago, a group of like-minded tech leaders came together as an alliance to advocate for the creation of a de facto standard for composable approaches to commerce and marketing technologies. Amplience was one of the first of these companies. Business and technology leaders could then make more confident decisions about which best-of-breed products to consider in their composable technology stack, ensuring what they were implementing was flexible, future-proof, and best fulfilled their requirements. That de facto standard is known today as MACH. To be included in the MACH Alliance, technology vendors must prove that they are Microservices-based, API-first, Cloud-native, and Headless. If a vendor doesn’t check all four satisfactorily by their peers and tech leaders, then they aren’t part of the Alliance, nor will they be recommended as suitable for a composable implementation. The MACH paradigm is intended to be clear-cut so there’s no confusion in the marketplace: a vendor’s product is either headless, or it isn’t.
Is there any such thing as “hybrid headless”?
In the CMS world, “hybrid headless” tends to be mostly older monolithic systems that are attempting to breakout their front-end presentation layer from any back-end management and delivery capabilities, realizing that there are many businesses who need the flexibility of a headless implementation. In many cases this is very hard to do because the underlying legacy code is so entangled with the back-end functionality, or because their customers have built experiences solely around the capabilities of the front-end layer and they are struggling to keep up to date with ever-changing demands of their customers. Hence the rise in replatforming projects by forward-thinking businesses over the last few years from burdensome monolithic platforms to innovative and flexible headless approaches, especially during Covid times when business leaders had to adapt their shopping experiences quickly or risk going out of business.
Interestingly, some headless CMS vendors have introduced UIs for authoring right within the layout and design of a single site, just like the monolithic platforms do. This defeats the benefits of being truly headless where business users can author once and then preview, schedule and publish across virtually any channel, device or front-end, much like our customer Traeger Grills does.
More recently, we have started to see some headless CMS vendors introduce front-end development environments and personalization engines for their customers. One less vendor to work with is a good thing, right? Not necessarily. This approach conflicts and competes with the vendors out there who have their own established and proven solutions, including the digital commerce platforms that you rely upon. That just sets businesses up for the same problems that they had with the traditional monoliths. So, in an attempt to not confuse the market, these “hybrid-headless” vendors have also been positioning themselves as DXPs – Digital Experience Platforms. But let’s be real here: these days DXPs aren’t something business leaders buy from a single vendor. A DXP is built from multiple vendors who follow MACH principles and more.
The difference between “hybrid” and headless CMS
With a truly headless CMS implementation, business and technology leaders will always have the freedom and flexibility to adapt and augment the front-end experiences they provide - both for today and whatever comes in the future - without having to create silos of redundant content for specific channels and use cases. They can choose from many best-of-breed front-end technologies to suit their requirements, whether it’s an all-purpose standards-based solution, to one which is provided by their digital commerce platform. Add contextualized AI content generation capabilities, integrated digital asset management (a natural complement to a CMS given the tight relationship content has with its supporting assets) along with globally available, high-uptime content delivery capabilities, and businesses are ready for whatever experiences their customers demand of them today and tomorrow. Now don’t get me wrong; there are suitable use cases for a monolithic CMS or a single site authoring UI, such as an editorial-heavy website or an internal-facing application. But they are different than the high-performing experiences that a headless CMS with AI and DAM capabilities and global CDN built on MACH principles are made for and that your customers expect to have from you.
If you’re considering using a headless CMS that also has a front-end development environment or authoring UI built in to the design and layout of a single site, then know that what you will choose is in many ways a traditional, monolithic, non-headless technology. Are you really ready for the restrictions that imposes? Or would you prefer to have the flexibility of a headless CMS with more powerful asset management and contextualized AI capabilities purpose-built for generating and delivering shopping experiences for virtually any channel, both today and tomorrow? It’s a yes or no answer.