The (short) future of the enterprise CMS

As the customer experience increasingly spans multiple touchpoints, it makes less and less sense to use content management systems that are channel specific. The old-school web CMS is gradually being edged out in favour of decoupled content infrastructures, capable of serving content at speed and scale to a variety of front-end systems.

When the web was everything

Ever since the first web browser was made available to the public, in August 1991, organisations have been grappling with the question of how to manage and display their digital content in the most effective way. Whether publishing details of products, news stories or classified ads, a way to easily update existing web pages, and publish new ones, without having to employ an expensive web developer was essential. Out of necessity, the web content management system was born.

Because, as per Wikipedia, web pages are “primarily text documents formatted and annotated with Hypertext Markup Language (HTML)”, it made sense for the earliest web CMSs to mimic the electronic document storage systems already in use at large enterprises in the 1980s.

And that’s where the technology got stuck for a long while. The W3C standards mandated a certain approach to serving content via the World Wide Web, one which was reinforced by search engines, and the traditional CMS was a solution that worked. In the interim many bells and whistles were added – collaborative editing, version control, media management, automated templates, WYSIWYG editors, drag and drop page builders, RSS syndication – but most web content management systems follow the same basic setup.

There’s a database, which holds all the content; a presentation layer, which builds a requested page using the content in the database; and a graphical user interface (GUI) for authors, editors and admins to modify the content in the database and tweak the presentation layer.

It’s a configuration that proved to be versatile and flexible, easily accommodating ecommerce, mixed media and all manner of JavaScript-enabled functionality so that content creators could provide compelling internet experiences with little need for developer support. That is, until recently.

Keeping up with the mobile Internet

When the iPhone launched in 2007, the digital experience broke away from the confines of the desktop and began to colonise our persons (I’m ignoring the first generation of Internet-enabled mobile devices as the preserve of a small number of early adopters). The new world of mobile browsers and native mobile applications gave brands a way to reach their audiences on the go. In time, this was followed by many more devices going ‘smart’, from the TV, to the watch, to the fridge, to outdoor advertising displays. As the potential for creating compelling digital experiences across multiple touchpoints exploded, and the desk-bound digital experience became more marginal, the limitations of the traditional CMS became painfully obvious.

For those content producers who merely wanted to display responsive websites which functioned well on devices of any size, the traditional CMS was (eventually) able to keep up. But what about brands who wanted to manage content across many different channels, and display it appropriately to audiences depending on the context? The traditional setup with its database and GUI tightly coupled to a web presentation layer was of no help – it could only be used to publish content to a website (or sometimes multiple websites), but no further.

What the new era of multichannel marketing needed was a system for managing content across all of a brand’s owned audience touchpoints. Where content could be updated once for publication across multiple channels, and where presentation layers for new channels could be plugged in quickly and easily. It was time to decouple the CMS from the presentation layer.

Decoupled and headless content management systems

A dynamic and hard-fought battle is raging over the new model for managing and publishing digital content, as we see the emergence of two types of content management system where the back-end user interface and database (the content repository) are designed for creating, editing and publishing content to a variety of front-end systems (websites, mobile apps etc).

The first, the headless CMS, removes the presentation layer altogether and makes content available to any front-end system via API calls. The second keeps the default presentation layer in place, so that content can be published to a website or app using a set of templates and styling options, but also makes content available to other front-end systems via APIs. This is known as a decoupled CMS, and it’s a route that many traditional web content management systems are following, since it provides all the features that existing customers are used to, with the added bonus of being able to serve content to other types of front end.

A prominent new example of this decoupled architecture is the open-source Drupal platform. Starting life in 2001 as a traditional CMS with a SQL database and PHP code running on the web server, Drupal has become tremendously flexible and extendable over the intervening years through community-contributed plugins (modules, in Drupalese) which, used in appropriate combinations, allow the creation of simple websites, single- or multi-user blogs, forums, or sites driven by user-generated content. In its most recent incarnation though, Drupal 8, the community of Drupal developers, led by founder Dries Buytaert, has shifted to an API-first approach to supporting multichannel customer experiences by serving content to front-ends other than a website.

Buytaert wrote in 2016:

“I believe it is really important to continue advancing Drupal’s web services support. There are powerful market trends that oblige us to keep focused on this: integration with diverse systems having their own APIs, the proliferation of new devices, the expanding Internet of Things (IoT), and the widening adoption of JavaScript frameworks. All of these depend to some degree on robust web services.

 “Moreover, newer headless content-as-a-service solutions (e.g. Contentful, Prismic.io, Backand and CloudCMS) have entered the market and represent a widening interest in content repositories enabling more flexible content delivery. They provide content modeling tools, easy-to-use tools to construct REST APIs, and SDKs for different programming languages and client-side frameworks.”

 This new API-first approach moves Drupal into the fast-evolving space of digital experience platforms (DXPs), which serve users with personalised content across a range of touchpoints. In Drupal’s case, it becomes a fully-fledged DXP when used in conjunction with the Acquia suite of applications, provided by Buytaert’s for-profit drupal hosting and support services company. Other key players in the DXP space, according to Gartner, are Adobe Experience Manager, Sitecore Experience Platform, and BloomReach Experience (which, like Drupal, evolved out of a traditional web CMS, Hippo).

But what of these new ‘content-as-a-service’ platforms of which Buytaert speaks?

Digital experience platforms vs content services platforms vs content infrastructure?!

Another problem thrown up by rapidly-evolving consumer technologies is the speed at which enterprises need to move to keep pace with changing consumer behaviours. As new modes of interaction emerge, some fade away while others go on to become the new norm. But brands need to try out as many of these new technologies as possible, whether they turn out to be fads or not, for fear of missing out on the Next Big Thing. They therefore need the ability to quickly set up new front-ends, but also make use of existing content assets to reduce the time to market. To meet this demand, a new breed of content-as-a-service platforms has emerged, which not only allow for the retrieval of content by many front-end systems (websites, apps, Alexa skills etc) via API calls, but also control over how that content is structured and stored in the back-end system.

One of the contenders to which Buytaert alluded to above, Contentful, describes its offering as content infrastructure. Like an API-based digital experience platform which has evolved from a traditional web CMS, Contentful provides a central hub from which to serve content across many sites, apps and devices, freeing up digital teams to build their front ends using whatever technologies they like. But unlike DXPs, it also offers complete freedom to decide how content is structured and modelled in the central repository, instead of following a traditional hierarchy of pages, posts, comments etc. This makes it much easier to serve content via a variety of front ends, since non-developers can create and structure as many different content types as they require.

Contentful refer to their approach as being product centric, treating the website as a continually-evolving product instead of a large project that has to be tackled every so often. This approach aligns more closely with the Agile software development ethos, and the increasingly popular use of microservices running on the cloud instead of monolithic code bases running on self-hosted servers.

To quote Contentful from a recent whitepaper:

“Contentful makes content “portable” by allowing your team to create modular, reusable content components that can be repurposed for any website or application. The platform’s APIs govern how content can be accessed, viewed, handled, and delivered, as well as a set of content delivery networks (CDNs) for speedy delivery to end users. Moreover, Contentful is a fully managed service, so developers don’t need to build and maintain their own content infrastructure.”

The freedom and agility provided by content-as-a-service platforms is hugely appealing for organisations who quickly want to innovate and iterate new digital experiences across a variety of touchpoints.

Whether your organisation makes its first foray into this brave new world of write-once-publish-anywhere content with a digital experience or CaaS platform, it’s clear that, for all but the most parochial of use cases, the days of the traditional web content management system are numbered.