preston.so

In addition to its devastating human toll, especially across India at the moment (support Breathe India and India Covid Resources), the pandemic has ushered in new paradigms when it comes to remote work, distributed workflows, and the ongoing technological “quickening.” But as content editors, content strategists, marketers, and developers remain largely homebound, one issue seems to be just as vexing and intractable as ever: the problem of headless preview.

As content management systems (CMSs) grapple with the transition to the digital experience platform (DXP) market and the ensuing conflicts therein—and as architects and developers confront the evolving separation of concerns in CMS architectures, it’s becoming clearer that we need a sea change in how we characterize and think of CMSs and their role in our work, at their very core. To resolve the increasing demands generated by headless preview and the channel explosion, we need to make a clean break from the “experience manager” of old to the “experience orchestrator” of the future.

In this article, I discuss the concept of digital experience orchestration, why the phrase “digital experience management” urgently needs to be retired by vendors and customers alike, and how we can solve the problem of headless preview once and for all in the CMS and DXP markets without sowing confusion. In the process, I’ll explain how key infrastructural and DevOps concepts like continuous deployment (CD) are increasingly infiltrating editorial workflows and why we need a new model of continuous production (in the editorial sense, not the development environment sense) to equip our products for an unpredictable future.

The rendering era of CMSs is finished

If the classic era of CMSs is over, as my colleague Mark Grannan declared several years ago, then its last vestige and final repose, the “rendering period”—in which CMSs perform and carry the responsibility of rendering of websites—is also approaching its conclusion. The API-first and headless CMSs that heralded this epochal change are rapidly giving way to a new paradigm: the distributed CMS, as I wrote last year.

It’s now a foregone conclusion that the model of tightly coupling a CMS to a single presentation layer or to a privileged rendering engine is coming to an end, though it’s dying an ugly death, as CMS vendors continue to scrounge for scraps from the small subset of organizations still in the initial stages of their digital transformation journeys. The overarching question is now: “We have a website. What’s next?”

For architects and developers working with content and commerce builds, the answer is crystal clear. Presentation layers are now responsible for their own rendering, as they arguably always should have, and CMSs are now permanently out of the picture. Proudly rendered elsewhere. Good riddance, say the developers of single-page applications (SPAs) in universal JavaScript and static sites zipping along Jamstack deployment pipelines. Equally vaunted and pilloried, the content management system, finally and irrevocably, is out of the business of rendering at last.

In the frenzied world of JavaScript, perhaps nowhere has this become clearer than in the proliferation not just of development frameworks like React, Gatsby, and Svelte but also of new bundlers and build tools that are chewing away at long-established centerpieces of JavaScript development writ large. No longer are we contending merely with the constant renovation of the edifice’s fixtures and its façade. Instead, we’re increasingly dealing with switcheroos of the cornerstones and even the very tools of the trade that power JavaScript applications in the first place: what I call, much to the chagrin of my colleagues, the crown jewels of JavaScript.

Just a few years ago, architects and developers merely had to contend with deciding between frameworks and dependency managers like NPM and Yarn. Today, however, there is a dizzying array of bundlers and transpilers now taking the developer community by storm; Sucrase has now usurped Babel as the speediest ES6 transpiler, while Rollup is increasingly rolling up the welcome mat for Webpack. New build tools like Snowpack and Vite are challenging the very paradigms bundlers were built on.

Off the web, the picture is even less rosy. Walled gardens established by dominant players are enforcing massive distinctions between implementations for voice applications and immersive applications playing in the world of extended reality, much like the constant churn in the Internet of Things (IoT) ecosystem. There has never been a clearer period of fragmentation in rendering and presentation than this present moment, and it seems only to be accelerating.

But this dire situation doesn’t mean that content management systems will forever be left out in the cold, relegated to the status of glorified databases. In fact, the importance of a CMS, and especially one relevant for the omnichannel future, has never been greater. The CMS’s future isn’t in a role as a content repository and API layer, though some headless CMSs might disagree. In fact, I argue here, the CMS’s outlook is guaranteed with a renewed emphasis on orchestrating, not managing, where content ends up.

We must prepare for presentation beyond the web

Today, when it comes to experiences beyond the web, the infrastructures undergirding deployment and the rendering mechanisms materializing the presentation layer are both completely unique—by necessity—and entirely decoupled from the web-only CMS—for efficiency’s sake.

Historically, websites were the only “presentation layer” we needed to worry about as content architects and practitioners. Mobile applications didn’t exist, and the idea of a dynamic application with link prefetching and service workers was laughable to developers who played in the sandboxes of DHTML and even VRML. As I wrote in CMSWire last year, CMSs hitched their wagons to websites because, for all intents and purposes, they were the only vehicles around for managing content.

Needless to say, this made the issue of content preview an incredibly easy problem in those days but is a disastrously misguided mishap by today’s standards, though it’s a blameless blunder. The compromises we set at that time are now unraveling in the most spectacular ways as content strategists and marketing teams cry foul at the prioritization of web preview—and coupled web preview, at that—above all else.

But editorial exigencies haven’t changed; in fact, requirements have grown as editorial organizations continue to face friction with tools that ostensibly were supposed to make their jobs easier. Core issues remain around how to enable editorial workflows like transitions between draft, approval, and published states for digital channels beyond the web. Take, for instance, these examples:

• For voice content, how do you “preview” a voice application and show different workflow states of copy across multiple implementations built in Dialogflow, Oracle Digital Assistant, and Alexa Skills Kit, all at the same time, when that content relies on CMS consumption?

• For augmented reality and virtual reality, which may leverage any number of web and off-web technologies with entirely different infrastructures, how can content editors see their unpublished content in the context of their CMS or by configuring their VR headset?

• For digital signage and IoT builds, are editorial teams really relegated to having multiple digital signs in their offices to track every content item in the context of their finicky hardware setups before it goes live?

The promises CMS vendors made to their customers are now coming back to haunt them, as early assumptions about web-only content preview show they cannot withstand the demands of presentation layers that bear no relation to one another and will only grow more distant over time.

Experience orchestration, not experience management

We need to stop selling the unrealizable wish of “digital experience management” to our customers, which suggests that every channel, web or not, is on a level playing field in our content management architectures when it comes to our control over them. No longer can we “manage” disparate digital experiences in the same way we adjust teaser and summary fields or modify rich-text formatting on websites. In my conversations with clients in India, Japan, and the United States, all wrestling with these multichannel mindbenders, I hear several common refrains:

• “Our editorial team doesn’t code and doesn’t understand any of this stuff. They just want to put in content, hit save, and see a preview.” How does this work when single-page applications and voice assistants are now on entirely distinct hosts from their content sources and are now proudly rendered elsewhere?

• “How can we change moderation states like draft and approval phases and preview those in headless presentation layers entirely on our own?” For editorial teams, it still isn’t straightforward to see how their draft content or needs-review content looks in multiple versions of a Jamstack site or augmented reality overlay.

• “How can we preview our content in the environment it needs to be delivered to in the context of the CMS?” One of the most common complaints I hear from clients I speak to is the lack of any tether between where they feel most comfortable—the CMS—and the gobbledygook URLs developers send them via disjointed Slack messages that look, from their perspective, like phishing sites (I’m not kidding).

As CMS architects and practitioners, we urgently need to decouple, once and for all, the notion of “digital experience management” and the assumptions therein that have persisted over decades from the much-needed innovation in workflows, not tools—in discontinuous architectures, not contiguous systems—that needs to take place in the CMS industry. Instead, we need bona-fide digital experience orchestration that not only acknowledges but respects the rich diversity of rendering mechanisms and hosting infrastructures.

I define digital experience orchestration not as the management or manipulation of digital experiences in the same way we manage content but rather as the enablement of disparate digital experiences to retrieve and render content in their own ways with the CMS as a centralized hub of processes, workflows, and triggers in addition to content. Experience orchestration, unlike experience management, makes no assumptions about how a presentation layer is rendered, nor where it’s hosted. Experience orchestrators are the air traffic controllers, not the flights themselves. They are the switchboards, not the cables themselves.

An experience orchestrator is a puppeteer rather than the puppet itself. It isn’t a service to be deployed; it’s the signaling mechanism that triggers the deployment. It isn’t another site providing administrative features; it’s the arbiter that administers how the applications look to teams who don’t wield a command line. A future-ready CMS performing experience orchestration is the conductor and the arranger, not the violinist or composer.

In other words, we need to let the artists and performers—developers of digital experiences and their deployment infrastructures of choice—do what they do best and focus on helping them do their jobs well. It’s time to stop doing their work for them.

Continuous production

In traditional publishing, a piece of content—a newspaper front page or magazine cover—undergoes production, the process of preparing it for distribution to the masses. But as we know from nailbiter presidential elections and Super Bowl games, media organizations prepare by having multiple conceivable outcomes ready if things go the other direction. It’s a trite example, given we know that content managers do this day in and day out, but it’s a useful way to consider what the analogue of continuous deployment (CD) in infrastructure would be as a tangible process in the content management world.

Today, the predominant paradigm used by developers when implementing applications is continuous deployment (CD), where each and every code change they make to a codebase—an application in progress—is deployed to a URL where they can preview their changes before they go live. A slew of continuous deployment providers have emerged in recent years that furnish “deploy previews” when each Git commit is pushed to the repository. For web developers who leverage more traditional workflows, it’s Browsershots but with fully fabricated applications ready to go for each possible state of code—a preview for each branch, a preview for each pull request.

Like CD providers, CMSs can fill the gap between how content managers think about their production workflows and how developers conceptualize deployments that make them more efficient. Just as these infrastructure services deploy a new build of the application on each code change, content management systems need to trigger a new build of the application on each content change, even though they aren’t ultimately responsible for those deployments. Alternatively, for universal JavaScript architectures, they need to invalidate any caches that prevent new content from going live in a previewable or published state.

The future of the CMS in the DXP segment isn’t so much a FrontPage- or Dreamweaver-like tool as it is an arbitrator of events and of reactions to content changes, in the same way continuous deployment platforms react to code changes. When an editor clicks the save or publish button, our architectures need to respond in the same way a hosting provider responds to a developer’s opening a new pull request or pushing a new branch of application code.

The result is a seamlessly orchestrated architecture that remains distributed and eminently extensible but has multiple entry points—hosting providers and content/commerce systems—acting as mutualistic switchboards. Whether it’s responsible for the infrastructure or for the content, they choreograph the deployments developers and content editors both need for their preview and workflow purposes.

To take the overwrought metaphor further, what we need is for the CMS to act as the printing press, not the typesetter. In other words, what we need is continuous production on the editorial side—of proofs approved by the editor-in-chief, of magazine covers greenlit by the board—that mimics the continuous deployment on the development side.

How experience orchestration solves headless preview

This powerful idea of the content management system becoming an orchestrator rather than a micromanager illustrates the need for us to move past experience management and firmly into the realm of experience orchestration. Digital experience orchestration means delegating the rendering and staying tightly focused on empowering the personas at the center of the CMS.

The beauty of zooming out to enable headless preview from the aloof perspective of orchestration rather than the overbearing ownership of rendering means that it works gracefully for static sites, single-page applications, traditional websites, and other experiences beyond the web. React Native developers can leverage the

react-native-web

unity-webxr-export

Moreover, infrastructure providers that perform continuous deployment implicitly recognize, both through their API- and webhook-first architectures and internal capabilities, that the CMSs and DXPs that will succeed in the future are those that focus first and foremost on editorial workflows as fastidiously as hosting platforms treat their developers’ needs. Advancements in incremental builds of static sites and other innovations are tides that lift boats both engineering and editorial.

Conclusion

In the end, CMSs need to let presentation layers do what they do best by giving them the inputs to bundle and render themselves, and they need to let infrastructure providers do what they do best by letting them build and deploy those presentation layers. Finicky half-measures like SPA editors no longer cut it. We need content management systems capable of orchestrating content events, of getting out of the way of developers, and of giving editors the tools they need to succeed in a rapidly changing world: EdOps, if you will.

A year ago, I joined Oracle with the mission to solve some of these tough headscratchers for Oracle Content Management as the product moves into serving digital experiences beyond the web. Fortunately, some of the stickiest issues were solved before I even arrived, like channel-differentiated publishing workflows. Ultimately, the CMSs and DXPs that win out in the post-pandemic landscape will be those that recognize the necessary baseline of flexibility for developers to use the renderer and deployer of their choice, and flexibility for editors to edit and preview the channels of their choice.

The new grand compromise is here, and it’s high time we embraced it. When we need to work richly with experiences beyond the web, there’s no other way besides true digital experience orchestration to provide a win-win for content practitioners and developers alike.