Headless Content and Digital Experiences
Thoughts and ruminations of a DXP Architect
Given the title of this piece, it would be prudent to share a little bit about my story to set the context right. I have dabbled and thrived within the Digital Experience Platform (DXP / DEP) space for nearly two decades now, working closely on a variety of platforms and tools. When I started my journey, terms like DXP, DEP, Headless, Decoupled, Non-Headless, or even Hybrid Headless — were far from existence. So, allow me to unfold my thoughts with a small story of my first ‘CMS’ (Content Management System) project on a platform called ‘Vignette Storyserver V5’ back in 2000 (if you’re smiling now; I am guessing you and I have sailed the same boat then, and we are perhaps about as old in this craft!)
The Vignette Corporation was bought over by OpenText and it eventually became part of a larger OpenText umbrella of Content and WEM (Web Experience Management) offerings (amongst other acquisitions they made). On this first project of mine, 20 years ago, my Chief Architect (I was fairly novice then) shared two basic principles of working, with me:
1. Always separate content from presentation.
2. Design your “content types” for a high degree of reuse.
These two insights made good sense then and hold high relevance in today’s times as well. Putting my learning to practice, on that project, we designed the content model in Vignette in a complete presentation-agnostic format, managed only the content (not the presentation) in Vignette, published the content to a ‘Java delivery application’ (through a combination of publishing workflow and database stored procedures), and allowed the delivery application do its thing — paint the UI or “render the Glass” as we like to call it today.
Wait, let’s take a pause. — Isn’t this what Headless Content or Headless CMS is today? So, did this exist 20 years ago? Hmmm! Well, the honest answer, I think, is — Yes and a No.
Yes, Headless as a concept is not new; the first CMS/ DXP/DEP platforms were Headless by design; you only managed and authored content in what was called a “form-based authoring interface and let someone else worry about rendering. This was the true content-type definition. That is how the earliest versions of Vignette worked; that is how Interwoven Teamsite and FormsPublisher worked, and so on. Of course, very quickly, most of these systems then graduated to incorporating presentation technology and the idea of templates and components to render these components. They did so for a good reason — why would a business pay millions of dollars in licensing only to acquire a ‘glorified’ content repository, when what they needed are the tools to efficiently and rapidly manage the actual consumer experience. From there on, we all know the story and how it played out for each of the big players that we see today, whether that is Adobe’s evolution from Day Communique to Adobe AEM or Drupal’s advancement from its earliest version to what D8 and D9 offer today. So, it sounds as if we moved from what was earlier pretty much a Headless world, to a non-Headless world.
Now, as if we were not “happy enough with that ending,” it seems Headless is back-in-action, with full force, and in a slightly different avatar. And this is where I get to the “No” part of my answer for “Is this a repeat story?” Truth is that both consumer behaviour and technology have evolved rapidly. We went from a few channels and touchpoints to multi-channel and now we expect omnichannel experiences. The systems and solutions went from the simple days “content in, content out” to much more complex integrated experiences and applications that seamlessly blend experience and brand with transaction and commerce. Businesses are hence seeking experience-led transformation, which is what we do at Isobar. This makes for the come-back case of Headless — we need Headless to help solve some of these things, deliver experiences across channels, integrate across numerous back-end systems using APIs and stitch together consumer journeys seamlessly.
And yet — marketers, merchandisers, and business users are not willing to let go of their “newfound power” that we gave them when we switched them from their old world (which was not too far away from the Headless of today) to a presentation-integrated authoring experience, with all the freebies of WYSIWYG, in-context, and i-love-drag-and-drop. Why would they? That’s like degrading someone from first-class to the economy-class, after they have travelled first class for several years now, right! Well, at least that’s the perception or the under-current, so to speak. That has led to something more recent that many have started to call “Hybrid Headless” but in simple words, the quest and the hunger to enjoy the best of both worlds — retain my first-class seat as the business user or marketer in control of the CX, and yet give developers, front-end engineers, and IT architects, the scale and freedom to build highly scalable, very agile, and integrated customer experiences.
The point of my prologue — The Headless agenda and its concept has completed almost a “full circle” over the last two decades in my humble opinion; it was there earlier too in a different and potentially a simplified avatar, and it’s back now in full-force in a newer avatar, with additional complexities, drivers and trade-offs to be made. At the outset, strongly feel that Headless is not for everyone, and should not be treated as a silver bullet for every architecture to be designed and every solution to be built. It has some significant advantages, and some serious considerations as well, and there’s enough said and written about those.
In this think piece, I will attempt to share my point of view on two aspects:
a). The dominant patterns in Headless Content and Experiences as I see them today.
b). How the notion of Headless cuts across both the marketer/merchandiser experience and the consumer/end-user experience.
Headless Patterns
If you’ve experimented a bit with Headless, chances are that you are familiar with the terms — decoupling, headless, API-first, breaking the monolith, etc. However, beyond the jargon and the terminology there, what does this mean to the architecture pattern for a digital experience platform? How do these choices affect the three most critical layers of the typical DXP solution, namely the Presentation (Front-End/CX), the Content and Experience (Back-End Experience Platform), and finally Integrations (the Integration Layer or the middle-tier)? There are numerous patterns and approaches to building CX (Customer Experience) and integrating or deploying a DXP solution, but in the context of all discussions around Headless, four dominant patterns have stood out in the more recent times:
- Integrated — Traditional aka non-Headless
- API-first aka Flexible Decoupling
- Pure Headless
- Hybrid Headless
At the risk of potentially over-simplifying them a bit, here’s a simple narrative I use to describe each of these.
Integrated — Traditional aka non-Headless
This was the centre-stage pattern, for nearly 10 years, from 2005–2015. The same system, typically the underlying DXP (WEM or CMS) was the guardian of all layers of the architecture, from the front-end presentation, templating, rendering, to the integrations, and the Content and Experience layer. Of course, you still had flexibility here with a lot of the “dynamic” presentation being client-side rendered (using JavaScript technologies), and even many of the integrations being managed directly through the client-side. But on the server-side, all three layers were closely knit and tightly integrated. This was the bull’s eye target for every major DXP technology platform, and it gave marketers and merchandisers a ton of control. Of course, the reason why this wasn’t universally loved and accepted, goes back to the changing consumer trends and the IT complexity drivers that were highlighted earlier in this thought piece. And hence, while it still works great for many scenarios, it was condemned by many others as a “Monolith”.
API-first aka Flexible Decoupling
Before we jump to the Headless model (coming up next), it’s useful to consider (and quite frankly often overlooked and downplayed several times) the potential benefits and upsides of an API-first approach to building these solutions. The API-first approach has a simple principle: every layer of the application must be able to expose its services over API. That applies to Content and Experience (digital assets), and to Integrations too. If everything can be exposed As-a-Service, then you’ve already taken the first major step in your architecture evolution towards Headless, in that you have provided “choice” and “flexibility” — in how you want the Experience to be built, rendered and assembled. In that sense, the API-first approach is less of an opinionated approach or a “mandated” approach; it guarantees that everything is exposed over well-defined Representational State Transfer (REST) APIs, but does not necessitate a Headless Architecture for every single touchpoint and experience. The presentation layer has the “choice” of consuming the REST APIs, receiving content and data in JavaScript Object Notation (JSON), and managing its presentation (which may be the case for a channel like a Native Mobile App, a Kiosk, an IoT device, or more), but can also fall back to the traditional aka Integrated pattern for more mainstream channels such as Web and Mobile Web. Also, from an Integrations perspective, by exposing each integration point as an individual, well-encapsulated REST-ful APIs, you have likely already introduced the early beginnings of an underlying Microservices architecture in some shape and size. Overall, in many cases, this flexibility and choice can be a blessing, and at the least, is a great starting point on the road to fully Headless, so it should be carefully considered before the departure to a pure Headless world.
Pure Headless
The Pure Headless model takes the API-first architecture pattern one level further, by mandating that pattern for every single touchpoint and every single channel. As Dries (founder of Drupal) refers to it, it’s a shift then from an API-first strategy to an API-only strategy, from the perspective of the underlying platform at least. There are of course several drivers for making this shift. The biggest one is to have a true omnichannel experience across journeys and touchpoints, and the ability to design and deploy this experience completely independent of any underlying platform. The second big driver then is to unite all of the underlying platforms, technologies, systems in a seamless way. The third and often underplayed driver is the unification of consumer data — by separating consumer experience and touchpoints into one independent and common layer, it’s often relatively easier to start aggregating consumer interactions across channels into one common data layer for downstream processing and to build a 360-degree view of the consumer. With Pure Headless, you are consciously agreeing to let go of “choice and flexibility” with regards to experience management and delivery integration, and you are making the somewhat bold decision that experience must be completely independent of the underlying content and data that feeds it, must evolve on its own, and must evolve faster and quicker than the underlying platforms. It is practically a full breakdown of the monolith. One thing it ensures is that it elevates the role of the CX engineering team aka your Front-end engineers quite significantly, in that they shape, drive and direct every single consumer touchpoint, and they take responsibility of everything CX from the ‘creative’ elements of the look and feel, to the functional and non-functional elements of the application itself.
Hybrid Headless
The Pure Headless model almost sounded like a state of Nirvana, didn’t it? Then why do we need to go any further? Why do we need this “Hybrid Headless” model? What purpose does it solve? And is this our creation, and the conjuring of some wild ideas in our heads? Well, let’s start by answering that first. Three years ago, what was a niche term is now being used extensively by every major DXP/CMS platform player. From Adobe to Drupal to Sitecore, everyone is talking about Hybrid Headless. But why? What exactly with Pure Headless did the world not quite like, that necessitated this? Well, kind of goes back to the point about taking power away from marketers and merchandisers, and limiting them from where they were in life, which is in one way what pure Headless did for them.
One of the challenges with Headless is that the conversation is very focused on the customer experience, the delivery of it more specifically. And what is missed in this conversation quite often is the marketer and merchandiser experience, the business users who need to actively manage that experience and need a rich toolset for this, the back-office of the CX if you may. Pure Headless didn’t have much to offer for them. Of course, you could still create “pseudo-presentation-metadata” models in a pure Headless CMS, and do things like creating a “Page Content-Type”, or specify presentation and placement metadata inside the content CMS — things that are seen quite often in a pure Headless CMS project — after all — we do need to specify where our content will render. Yet, this is a drastic compromise from the rich editorial experience that marketers would get in an Integrated (traditional) model and retain almost all of even in the API-first model. Moreover, it takes away capabilities around layout management, template component, visual placement control, and so much more. So the argument for Hybrid Headless is simple — if the CIO, CDO and the enterprise architecture team have agreed that Headless is what will drive agility, omnichannel experience and competitive differentiation for the business, how do we still satisfy the CMOs and their marketing team with their editorial needs, ease of experience creation, full control over the end CX without IT intervention, and also not make it sound as if we ‘deprived them’ of all the goodness that exists out-of-the-box (in many cases) from the big investment they made in their favourite DXP/CMS of choice. This is quite the reason why Hybrid Headless has taken off — it’s a balancing act, and potentially a much-needed balancing act to deliver scalable and agile CX platforms on the one hand, and yet provide rich merchandising and authoring capabilities to content marketers, almost making them believe they were not working in a “headless model.”
From a practitioner, and from someone who’s “been there, done that” — Hybrid Headless is most likely going to increase the effort and complexity, even more, from a pure Headless model — at least for the initial build, that will likely be true. While earlier one had to worry about building your front-end and integrating it with the CMS over Content-as-a-Service, now one also will need to worry about concepts like “Experience as a Service”, “Layout as a Service” and much more. We need to think about how marketers will be granted flexibility in a template and layout design, page design, etc., using built-in CMS and DXP authoring and tooling, and then how one can merge that with the CX App/Front-end App Design system, which could be React, Angular, or anything else. This is where “hooks” or some alternate mechanism will be needed to “bind” front-end components to DXP components and templates. Pay attention to how WYSIWYG previews and WYSIWYG in-context edit experiences will work seamlessly in the authoring UI. Admittedly, this is an area where all the major players are making investments, and so one hears of a lot of “authoring tool investment” in this area from all the major platforms. And yet, to say this is seamless and out-of-the-box is far from the reality of what such an implementation might look like. So when you choose the Hybrid Headless route, make sure you have a strong team across all disciplines and people who can carefully and thoughtfully design the solution.
All in all — I would recommend using these patterns as a ‘Catalog’ or a ‘Menu.’ There is no right or wrong, good or bad, in any of them. Each is purpose-built for a certain situation. As a DXP Solution Architect or a Platform Architect, your job is to understand the needs of your business and apply the right pattern. I am also not suggesting that these are the only patterns; there are likely many more variations to this. Yet, these patterns should serve as a good guide to navigate this construct.
I want to switch gears now to a related topic, and one that I touched on just a while back in this thought piece. How do we develop a more holistic thinking around Headless and Headless solutions and experiences? When we think of Headless, we largely think of the Consumer or Customer experience (CX), the front-end architecture, and the content or experience delivery architecture. Which is a key part indeed. But, how about the creation of the experience? When we go Headless on the CX or Front-nd, how does that have to tie up with what we do on the “back-end?” Let’s delve into that a bit more.
Headless Back-office and Headless Front-office
If you think of the Consumer Experience and all the channels, touchpoints, and experiences that the end-consumer interacts with as the Front-office, then think of the core DXP platform, the marketer, merchandiser interfaces and tools, and all of their UIs and interfaces with the DXP management and administration interfaces as the Back-office. The question that we need to examine in this context is — what is the “game” for Headless across the Back-office and the Front-office? What are the different flavours of Headless for back-office and front-office? And most importantly, how do these work in tandem? Can we do Headless Back-office aka Headless Authoring with non-Headless aka Traditional Experience Delivery? How about the other way around? I have been pondering over many of these questions, and hence sharing some of my two cents here on the topic.
The first thing here is to acknowledge that there is a choice around “Headless” to be made at two different levels within the overall solution.
1). The Back-office aka the Authoring experience for the marketer or merchandiser within the DXP.
2). The Front-office aka the Consumer experience and the rendering or delivery of that experience to the end-user.
It is possible to design either or both in a headless manner, and which combination will work best, will largely be dictated by the use case. Let’s take a closer look at each of the key scenarios that emerge from this 2x2 quadrant.
1. Experience-driven Authoring and Integrated Experience Delivery
This is pretty much traditional aka the integrated pattern that we discussed earlier. In this model, content is authored and created in the context of the experience itself. Visualize an authoring experience where the author knows exactly which content is being placed in which slots and components, placement of content is tightly controlled. In the worst-case scenario (avoidable though), the content may even “live within” the presentation context and may be tightly coupled to the presentation structure itself. From an experience delivery standpoint again, this is the traditional templating and rendering mechanism supported by the DXP. Content is rendered using templates within the DXP, and typically rendered straight to HTML and served to end-users, all from within the DXP. With this workflow, everything that the DXP or the CMS platform offers out-of-the-box is yours to leverage and enjoy — including the full WYSIWYG authoring and preview experiences, in-context edit, etc.
2. Experience-driven Authoring; Headless Experience Delivery
This use case is most relevant when we think of experiences in the context of “widgets”, “fragments”, or “micro-experiences” that need to be published and distributed as “services”. In this model, marketers and merchandisers seek to create experiences in a rich visual authoring environment, somewhat similar to #1 above. However, what they typically create is not a full-page context, but more of a widget or a fragment, or a container of widgets or fragments. Within the container, they have full control over placement, etc. From an experience delivery perspective, the goal is to then take these containers and widgets and publish them over an API/Service, that could be consumed by any consuming application. We are talking about Page-as-a-Service, Layout-as-a-Service, and Experience-as-a-Service. This leads to many possibilities — including of the idea of DXP-managed fragments and widgets and containers, being consumed in the context of Front-End Apps or Web Components or other widget-based front-end technology, or even extended to other channels such as kiosks, screens and IoT Devices. Even though I say this is typically not for “full pages”, there is evidence of this model being applied to full pages as well — i.e., delivering a fully composed experience page as an API / service, serialized as JSON! The authoring interface seems familiar and traditional, but under the hood, it is designed to publish all experiences as a service over an API endpoint.
3. Headless Content Authoring; Template-driven Experience Delivery
This is the classic use case of designing the core content model and the content authoring experience as well in a “Headless” fashion, with atomicity, reuse, modularity of Atomic content, typically being the key goals and concerns, and then repurposing this atomic and headless content, within the context of experiences that are driven and integrated within the DXP. This could well be perceived as a step on the route to a pure Headless, or a fully Headless model, or at the very least, good content modelling and design practice, to ensure a smoother transition to headless at a later stage. Visualize this — a pure content authoring experience that is not page-driven, but is forms-driven, allowing you to create content as strict content types, or fragments if you may, with absolutely no semblance of how these will ultimately render within an experience or a presentation context. And then, a separate Experience authoring environment, where you can leverage and reference those atomic content types and content items, “pull them in,” and lay them out on a page template or layout for experience delivery. This model of working, and the previous one as well — on #2 above, is the sweet spot for many Hybrid CMS platforms today.
4. Headless Content Authoring and Headless Experience Delivery
We are now in the pure Headless or fully Headless world. There is, of course, a whole new breed of platforms such as Contentful and several others that were designed exactly for this one. In this model, Headless is the only way to go, across the authoring experience and the runtime or delivery experience as well. Content has to be created in a fully presentation-agnostic manner, using nothing but the metadata (taxonomies, tags, keyword metadata) as “binding criteria,” to help the Headless Experience “pull” relevant content for each route, each page, and each module on the page. For all practical purposes, the DXP and CMS know nothing about the front-end in this case. Of course, Hybrid CMS and Hybrid Headless pull this in a different direction, as we’ve discussed earlier. But if we stick to pure Headless across authoring and delivery, we’re setting ourselves up for the true omnichannel, fully decoupled, and strict separation of DXP platform from the consumer experience. We are also moving heavily to an API-driven architecture here, where APIs are not only pulling content from the underlying content system (as JSON) but also enriching, aggregating and orchestrating across multiple systems. This is the ripe ground for capabilities such as Microservices, API composition, API orchestration, Cloud-Native platforms, and modern service-driven architecture.
Now here’s the fun part — in the two decades that I’ve spent working on a variety of different Content and Experience Platforms, most platforms, products, and technology providers would NOT want to “box themselves” to only one of these patterns/models, and would rather spread their wings and flex their muscles (so to speak!), or at least portray them as such to cover multiple patterns/models, to suit different customer needs. Sure, there are niche platforms designed for the pure Headless and API-only world and that breed is definitely emerging, but then if you look at all the others, there is a promise of the “AND” in their marketing message around these patterns — which is where it seems the DXP space has started to love the term “Hybrid Headless” a lot.
The key point I want to conclude with is, that Headless does need to be thought through in the context of both the Authoring Experience and the Delivery Experience. As solution architects, you need to pick your sweet spot in the quadrant and figure out which of the four models are best suited for you. You could also strive for middle-ground if you want to, which goes back to my point about API-first, but not necessarily API-only.
Headless Content and Experiences, as a trend and an architecture pattern, is here to stay — it’s going to get more relevant, as channels and touchpoints explode, integration complexity increases and data-driven experiences become a key differentiator. The way to make the best of it to navigate it wisely, focus on what is the finest fit for your context and choose patterns that make your business successful.
Author: Amit Xerxes, Vice President, Engineering, Content and Martech Practice Lead, Isobar| amit.xerxes@isobar.com
