Some years ago, I did a few months of architectural consulting for a Fortune 500 company in Japan with a globally recognized household name. You’ve heard of them. You probably have one of their products in your home. But despite their prevalence in most American residences, inside the corporation’s high-rise headquarters in Tokyo, deep frustration was taking hold as conflict spread between the digital marketing and engineering functions. Their primary website, the company’s flagship digital property, and their constituent brand websites, oriented toward disparate customer segments, were in deep trouble.
A cautionary content management tale
Torn between accelerating innovation in front-end development paradigms, shifting touchpoints among target consumers, and growing demands from marketing leaders for better brand experiences, this enterprise corporation was stuck between a rock and a hard place. For many years, they’d relied on Drupal, a formerly monolithic content management system (CMS) that has evolved to become hybrid-headless over the years, to forge that elusive great compromise between the digital marketing and web engineering teams.
But their digital transformation needed to get faster. Mobile, chatbots, and in-store experiences were becoming ever-pressing concerns. At the same time, developers in house were chafing against what they saw as restrictive development approaches in the front-end templating layer and theme engine that ship with Drupal. And in the end, as those of us who know large companies and their inner machinations intimately understand—different brands under the umbrella of the corporation’s leadership began to experiment and try different things, deviating from the norm.
The effect was a half-monolithic, half-headless architecture that was difficult to scale and led to headaches across the entire company and increased tension between editorial and engineering teams. You see, several brands had become so impatient with the inability of the CMS to cater to all needed digital channels and to the clear-as-day future of front-end development that they began to pursue their own paths.
A simplified illustration of the company’s previous architecture, which was a monolithic multisite approach, with brand websites all contained within a single multisite Drupal architecture with a shared Drupal visual editor lying underneath.
While more conservative brands in this corporation opted to stick with Drupal’s native static web layer, one brand chose to rebuild their website in React. Another chose Vue.js. Still another chose Angular. The result was complete chaos, as the principle of a single source of truth for content became violated and content syndication with a unified brand voice across the entire company became impossible.
As different brands began doing different things, some brands chose to remain on the Drupal site while others chose to move in a headless direction, leading to a disruption of the shared editorial interface straddling all of the brand’s digital properties.
When their consultancy partner approached me with this problem, I recognized the same patterns I had seen in many other enterprise companies across my time collaborating with editorial and engineering teams in Europe, Latin America, and Asia. Rather than tell the brands going off in their own direction that they were wrong, as some expected me to do, after listening to each technical architect’s needs and each marketing manager’s plans, I entered the picture saying that everyone was in the right.
As I’ve written before, architectural purity seldom reflects reality. And the narrative that many headless and composable vendors tell in the CMS is that a disruptive and earth-shattering replatform is what’s necessary to fix all of the ails stymying progress in digital properties. But as this Tokyo enterprise’s experience shows, what developers want, and what architects want, isn’t necessarily reflected in reality. Content management is about a give and take between stakeholder groups with often diametrically opposed motivations and goals.
The reality is far messier, and many CMSs today don’t recognize this. This company in question had a multisite architecture reliant on Drupal, with content syndication needs and massive editorial teams needing visual assembly and complex content workflows including scheduled preview and approval tracks. And they didn’t have time to retrain content teams to learn an entirely new CMS—or, even worse, an entirely new collection of CMSs—with tentpole marketing events coming every single month and every single quarter.
A simplified illustration of my recommended approach, which allowed them to maintain a single source of truth for content while enabling their developers who wanted to press ahead to access front-end innovations to proceed in their preferred direction, and their content editors who wanted to maintain their long-standing editorial interface.
Ultimately, I recommended that the traditionalists stay the course, because hybrid-headless CMSs are still the best solution for most multisite architectures. But I reeled in the headless upstarts, recommending a unified API—in this case Drupal’s GraphQL implementation—to reunify all data needs on a single layer usable agnostically across every framework, whether that was React, Angular, Vue, or whatever came next. Best of all, editorial teams could rely on a single shared user experience, the Drupal interface, to manage all of their content needs. The result was a more resilient architecture that respected both editorial and engineering needs while allowing this corporation’s digital transformation to proceed uninterrupted.
What developers want isn’t always reflected in reality
Developers, as the old adage goes, will always do what they want, even if it comes at the expense of other back-office stakeholders. As headless and composable vendors continue to appeal to frustrated developers with a bone to pick, they forget that there are other teams that need features and functionality that cannot be rebuilt or regained at the drop of a hat. Meanwhile, content teams, especially those with aggressive roadmaps, need to stay unhindered and independent as they continue to follow the digital transformation journeys dictated by their employers.
And in the post-ZIRP era, where budgets are tight and projects are chronically underresourced, it’s anathema to many CMOs and CTOs to engage in a replatform that completely disrupts the editorial workflows and marketing needs of content teams, especially when those teams are entirely dispersed with distinct roadmaps, as this Japanese corporation’s were. That’s why we now see headless CMSs rushing to “rebundle” their products by introducing visual editors that were once the unchallenged turf of hybrid-headless CMSs. Headless CMSs are becoming less purely headless, introducing impurity to attract increasingly discerning customers.
But there are still other concerns that often go unmentioned by headless and composable vendors in the content management space. Whereas headless and composable CMSs offer developers freedom, they institute a different kind of vendor lock-in. The great unbundling of content management systems also came with its inexorable move towards the pure software-as-a-service (SaaS) paradigm. While this meant no need to host or worry about infrastructure, it also meant giving up control over changes in the product and made certain approaches, like multisite implementations and complex intranets, much more challenging.
Finally, there’s another consideration that the migration towards SaaS engendered by headless vendors has ignored: a desire to use open-source technology and to self-host infrastructure due to data privacy or data security needs, a common concern among enterprise companies, particularly in more conservative verticals like financial services or health insurance. For those companies that understand and deeply value open-source software, most headless and composable CMSs are a nonstarter.
Add to the mix the channel explosion and the fact that marketers are contending with an increasingly complex landscape when it comes to engagement and digital touchpoints, and you have a recipe for disaster without careful consideration of how to evolve your content architecture.
A universal developer experience means freedom
So what are developers to do? Many engineering-minded folks reading this article up until now probably have a bit of a frown on their face, as it goes against their desire to pursue the latest and greatest technologies. In my opinion, in recent years, the content management world has done a poor job, both in the headless and hybrid-headless segments of the market, of respecting developers’ desires—and especially the diversity of those desires.
In order to cultivate an optimal developer experience, content management systems need to pursue a universal developer experience, an essential facet of the Universal CMS paradigm I first discussed last year—a reconvergence of headless and hybrid-headless architectural paradigms into a new category that serves both content teams and developer teams as first-class citizens without limiting one or the other.
That means unopinionated software development kits (SDKs) that free developers to do what they want in the languages, and especially frameworks, they prefer. For instance, at dotCMS, we empower developers and support them with both a vanilla JavaScript SDK that can be used in the context of any approach or any framework, respecting also the universal JavaScript development paradigm, and framework-specific SDKs that accelerate developer workflows.
But most important is the ability for developers to bring whatever technology and whatever framework they want to the content management system. Many CMSs have privileged certain frameworks over others. Drupal and WordPress, for instance, have favored pure React in recent years, much to the chagrin of Vue.js and Next.js developers (full disclosure: I led the Drupal community discussions that galvanized Drupal’s experimental adoption of React, though it went no further than experimentation and was never incorporated into Drupal core).
But many front-end developers today ignore the long tail of developer experience in content management systems. Many developers still strongly prefer to use PHP or Ruby or Java to build their websites, and their experiences are just as valid. That’s why we see headless and composable CMS vendors like Contentful racing to build SDKs not just for wildly popular JavaScript frameworks but also for back-end technologies like Python and .NET.
I worry, however, about those headless and hybrid-headless vendors that have gone a bit too far in the opinionated direction. Many traditional CMSs have bolted on GraphQL APIs that are simply forklifted versions of REST APIs rather than rethought implementations. Many of the same vendors have built SDKs that are so opinionated that they force front-end developers building headless architectures to essentially adopt the same mental models as those building monolithic architectures—and those SDKs remain rarely used. Finally, many headless and composable vendors have gone head over heels for a single framework like React or Next.js, without considering the fact that framework flux will continue unabated and that they will never be able to convince developers to stay on a single framework forever.
As year-end developer surveys in 2024 have indicated, some of the most popular frameworks from just a few years ago are fading into the darkness. Gatsby, a name once uttered in the same breath as Next.js (full disclosure: I wrote the book Gatsby: The Definitive Guide), is now in precipitous decline when it comes to adoption. Similarly, we’re seeing names like Svelte begin to dissipate in popularity in favor of more agnostic frameworks like Astro. Ultimately, CMS vendors, both in headless and hybrid-headless categories, must accept that there will always be framework flux.
For some CMS vendors, not all frameworks are created equal. Many have chosen to focus solely on React or Vue.js at the expense of others, whereas the optimal scenario is that vendors focus on all frameworks equally and agnostically based on the most common and important use cases for all developers irrespective of their framework preference. This holds especially true of new cross-platform and compile-to-native frameworks like React Native and Flutter.
If you don’t believe me, take a look at what’s happened with native mobile technologies. Ten years ago, the most popular approach to build native mobile applications outside low-level paradigms like Java or Objective-C was web-to-native tools like Cordova. Today, while still used in many circles (a segment we should continue to validate and serve), Cordova is no longer a common choice, with developers instead preferring cross-platform frameworks like React Native and Flutter.
Conclusion: Bring any tech, any framework to a universal CMS
The Universal CMS paradigm illustrated as a collection of digital channels, the baseline set of required tenets, and user stories relevant to each set of personas (developer teams, content teams, and DevOps teams) that are responsible for content management.
Some developers still need back-end technologies like PHP and .NET. Some developers still prefer monolithic CMS approaches to build a website in a day. Some developers want to use React, others Vue. Some developers want to use React Native, others Flutter. Some developers want to work with the latest technology, others with established tools. Some developers want to work with an open-source CMS, others with a fully SaaS CMS. A universal developer experience, as described by the Universal CMS paradigm, requires us to provide a compelling offering for all of these discrete demographics.
Most of all, the Universal CMS paradigm, in addition to unblocking developers and granting them freedom and true framework and architectural agnosticism, allows organizations to unblock the content teams in their midst. In 2025, CMS vendors would do well to stop blocking developer teams, stop blocking content teams, and start giving both groups what they want. The enterprise company I worked with in Japan did so, and they were able as a result to focus on the right things—and build better relationships with their customers.
Special thanks to Zain Ishaq for his feedback during the writing process.