preston.so

In recent years, there has seemingly been no shortage of prognosticators proclaiming that the end of content management systems (CMS) is nigh. These claims allege either that the CMS has long been an overloaded heavyweight marred by years upon years of poor decisions and technical debt, or that the CMS is quickly being superseded by no-code approaches that allow marketing functions in organizations to dispense with the CMS as a concept altogether. In both lines of argument, marketing teams have faced too many obstacles to get their vision in production, whether due to issues of developer experience or convoluted “low-code” user experiences.

Despite these predictions, however, I would hesitate to say that the so-called “post-CMS era” is here. In fact, as recently as last year, at keynotes in Ghent, Cluj-Napoca, Montréal, and Pune, I've contended that a CMS renaissance is imminent as architectures continue to evolve and developer and marketer experiences alike adapt to match growing expectations. After all, the last several years have witnessed an incredible degree of innovation when it comes to CMS architectures more broadly, yielding a fourth wave represented by the distributed CMS, a frothy market for digital experience platforms (DXP), and staggering paradigm shifts in longstanding CMS concepts such as the separation of concerns and preview beyond the web.

In this article, I describe the primary argument that increasingly characterize discourse surrounding the purported “post-CMS era” and challenge it based on a variety of considerations: the contemporary channel explosion, the frictions inherent to the marketer–developer partnership in organizations, and the relative power that marketing functions still hold in decisions concerning vendors, particularly in enterprise organizations. All of these lend support to the idea that the content management system as a concept is merely undergoing disruptive evolution and that the CMS as a nexus of interactions between marketing teams and engineering teams not only remains a fundamental confluence of collaboration but is also among the key motivators for the CMS in the first place.

The CMS is overloaded; “deconstruct the CMS”

Developer experience advocates contend that the CMS is simply too monolithic, too muddled, and too marginally useful for the sort of development best practices that are emerging today, such as interchangeable services and API convergence. The mere notion that a monolithic CMS displays an acute degree of inextricability among its tightly coupled components is anathema to developers who prefer to plug and play third-party services, leverage JAMstack and serverless architectures, and bemoan the admittedly unsatisfactory developer experiences many CMS vendors continue to claim are “modern.”

Before the approaches associated with the JAMstack emerged to provide a more palatable foundation for the dissociation from CMS architectures many were feeling, some architects framed their disassociation from the monolithic CMS as a matter of frustration. Two of the most influential and commonly cited pieces came from developers who had worked previously with monolithic Drupal. In 2012, the first influential broadside against Drupal came from Dave Cole at Development Seed, a consultancy once long involved in the Drupal community and the first to mention explicitly the desire for better embeddable services (something I explore at length in my definition of the distributed CMS). Later, in 2016, Davide Borsatto wrote that content management systems like Drupal “don’t just limit themselves to managing content, they force-feed you instead a whole system that you have to constantly fight against in order to manage just that, content.”

In Kaya Ismail’s dispatch in CMSWire, he eloquently describes this “post-CMS landscape,” as he characterized it in 2017: “When we moved into what some call the post-CMS landscape, the usage of static site generators (SSGs) and flat-file CMS for these microsites (and at times for lightweight corporate sites), grew. And now, with the headless CMS hype in full flow, the interest in these front-end solutions is returning.”

Another common thread in these arguments is the idea of deconstructing the CMS into its most essential parts and employing services that are optimized for that particular use case. As Bud Parr argued in a blog post that is no longer online (but quoted in Steve Schofield’s exploration of static site generators), “To my mind, ‘post-CMS’ means the disaggregation and, in many cases, elimination of the component parts of a CMS. What remains is simply the tools we need to for [sic] a particular project and nothing more.” But in the sentence immediately following, Steve admits that “static site generators are mostly the playground of developers.”

Why the post-CMS era is not here

Earlier this year, Janus Boye responded to a tweet by Deane Barker of Episerver on the flawed notion of believing in predictions claiming a crucial market is in decline. As he wrote on Twitter, “When somebody wise claims that something is dead, it is very rarely the case,” citing statements positing that the “CMS is dead” to be naught more than new installments in the long narrative of how undead trends like personalization, content strategy, and even the web are somehow “dead.”

In my view, Janus is exactly right. Fast-forward a few years since the breathless marketing surrounding headless CMSs and no-code solutions, and the content management system remains an immovable mainstay of marketing organizations not only in large enterprise organizations but also in small businesses and non-profit organizations. The CMS continues to enjoy extensive penetration in the public sector and higher education, two verticals that prize compliance and consistency.

Why is it that the CMS seems to have such staying power despite these admittedly compelling critiques challenging the justifiability of its very existence?

Not everyone can afford developer teams or learn Markdown

There are certainly business rationales for remaining loyal to a particular choice of CMS, whether it is for compliance reasons (such as HIPAA, FedRamp, or GDPR) or for integration reasons (the need to integrate seamlessly with a CRM or DAM product). But these rationales aside, one of the most significant boons of a CMS is also the easiest counterargument to make against the notion that the monolithic CMS contravenes progress toward a favorable developer experience.

One of the common tropes I’ve seen from proponents of innovative technologies like Gatsby and MDX is the notion that Markdown is easy enough to write for any marketer without experience in HTML or other common web languages. This argument is often leveraged to argue that the existence of marketing organizations that cannot rely on developer teams does not preclude them from making full use of JAMstack architectures and headless CMSs. But when you remove from the marketing team all of the features they were accustomed to in the workflows of a monolithic CMS, the answer cannot be “have your developer team implement a headless preview solution for you.” And it isn’t clear that marketers prefer Markdown over collaborative-by-default environments like Google Docs and Office 365.

Frequent client complaints bear witness to the notion that marketers still need to have a semblance of control and to collaborate with developers in a centralized fashion. After all, this is one of the most frequent complaints I hear about headless CMS products: the distance continues to grow between content editors’ experiences previewing and visually managing content and developers’ experiences building highly customized implementations. Marketers’ hands are tied when they must tap the shoulder of a developer to implement a custom preview system for React or when they require a new deployment for a menu change to go live on Gridsome.

Several years ago, I heard the horror story of a client who had received a decoupled Drupal implementation fronted by React from a consultancy and promptly called the agency back, demanding to know where their administrative menu had gone (a ubiquitous feature in Drupal-built sites). Even though the front-end performance of this implementation was leagues ahead of that afforded by the foregoing architecture, the perceived importance to the content editors of features like administrative menus and in-place editing matters much more than the actual value they represent.

This brings me to one of the most important reminders I can give to developers and product managers today: Not everyone can afford a developer, let alone learn Markdown. Many marketing teams lack developer functions they can depend on, particularly given the fact that many marketing teams receive much less support in the form of engineering resources than mission-critical product roadmaps or other company initiatives. And large enterprise organizations still need all the hallmark features of a digital experience platform (DXP) to be integrable by marketers, not by developers. Marketing departments should not need to rely on technical resources for digital asset management (DAM), personalization, analytics, or any other example in the host of features that are common in more established CMS products like Adobe, Acquia, and Oracle.

The CMS renaissance is nigh

This brings me to the two key points that I believe are driving not only the continued staying power of more established CMSs but also their continued uptick in adoption.

The first is that marketers lend a great deal of importance, no matter how misguided, to the features they have long leveraged for many years. A perceived loss in this functionality is still damaging to marketing teams’ ability to control how content is delivered to settings beyond the web. Despite the fact that it is a universally acknowledged fact that diverse digital experiences necessitate developer involvement when it comes to enabling high-fidelity preview or emulation, the CMS remains the place that marketers expect such preview functionality to be made seamlessly available. For this reason, I believe that platform-based approaches that incorporate infrastructure into the equation will remain popular in the CMS landscape, because they facilitate a better end-to-end experience that also smooths the user experience of marketing organizations with robust editorial workflows.

Secondly, I don’t believe that the newest iteration of CMS products, namely those that market themselves as headless CMSs, are the end-all, be-all solution to the issues that plague marketers. Developers may certainly derive their optimal experiences from headless CMS products, but these clearly leave marketers and content editors behind. As I wrote in my previous article about the second CMS war and impending redefinition of the DXP as a product category, the very idea of presentation management relies on the availability of effective marketer tooling. In many respects, the agnosticism that headless CMS products have touted for many years has come to bite them back; after all, aren’t headless CMSs “adrift” without mooring to a single dedicated presentation layer or at the very least prestiging some front-end frameworks over others?

There is a middle ground between the overloaded, oversaturated nature of monolithic CMSs from the 2000s and early 2010s and the developer-friendly, marketer-unfriendly posture of headless CMSs. And this middle ground, as I’ve argued previously, is what will galvanize the coming CMS renaissance and the pitched battles of the second CMS war. But for now, neither headless CMSs nor monolithic CMSs, which have struggled to keep pace with market trends, are satisfactory for the discerning marketer.