The State of Headless Web Content & Experience Management (WCM) in 2018

tags: cms, headless •

Key Takeaways

Introduction

It seems that “headless CMS” is everywhere, accompanied by claims that it will revolutionize web development and disrupt entrenched players. As usual, there’s some truth there, mixed with a fair amount of hype.

What is headless WCM?

A “headless” WCM is a system for managing content that delegates the delivery and presentation of that content and associated experiences to some other environment. A headless WCM provides management tools, but its delivery ends at an access API, through which other systems can connect to retrieve or manipulate content as needed.

It’s essentially a specialized repository with editorial services, optimized for managing content, rather than delivering experiences.

The hype wave is cresting

Remember that headless WCM tools have always existed at some level. One of the earliest WCM tools – Interwoven TeamSite – was proudly “decoupled” from any delivery systems. The only difference with today’s crop of headless systems is that they’re riding the tail end of the “cloud” wave, and they’re centered around remote APIs – usually JSON over REST – as opposed to direct database calls.

So, why is headless having its moment now? It’s due to a confluence of several trends:

  1. The proliferation of mobile apps, kiosks, and other non-web channel endpoints, which just need the content and will handle the presentation and experience in a device-native way.
  2. "Single Page Apps” that rely heavily on client-side browser code for rendering web experiences. Developers can pick among numerous presentation frameworks (React, Angular, etc.) which are naturally divorced from WCM-specific rendering.
  3. Growing desire to inject managed content into interactive applications like ecommerce platforms, banking portals, customer dashboards, and a panoply of other transactional environments. For example, your existing customers may never return to your marketing website ever again, but you still want to communicate to them through various application environments they access.

Who are the headless vendors?

The most visible “headless-native” player is Contentful, a Berlin-based startup that grew out of a mobile app company’s need to store content in the cloud. Over time, it became obvious there was a hole in that market for this type of platform.

You’ll find considerable distance between Contentful and other players. A notable recent entrant is Kentico Cloud, which is a from-scratch product from the existing WCMS company with no connections to their standard offering.

There are a number of open-source players which offer cloud versions as paid options:

Various traditional WCMS companies are releasing remote API add-ons to existing systems. A customer who simply ignores the system’s “normal” delivery architecture and interacts with the system only via it’s API can be said to use the system “headlessly.”

Also of note are hybrids or “meta systems” built on top of existing platforms. For example. Contenta is a headless CMS running on Drupal. And Google Drive CMS uses a combination of Google Docs and Sheets to cobble together a headless CMS of sorts.

Where does this end? Any system that provides structured content over a remote API is claiming the “headless” mantle at this point, make the edges of this market largely indistinct.

Just understand that the headless-only market is small, with a dearth of viable commercial players. We doubt anyone is turning a profit in this market at the moment.

Headless doesn’t change the basic features of WCM

It’s important to note that headless is an architectural paradigm, and nothing more. A headless CMS should be evaluated as any other CMS, except for how the content is rendered in the final channel for delivery.

Features like content modeling, content aggregation, editorial services, search, approvals, etc. are still core aspects of a CMS and have little intersection with the differences that make headless CMS what it is. Indeed, some of the from-scratch headless vendors are scrambling to rebuild basic functionality that has existed in traditional platforms for years. Once potential customers get past the novelty of “headless-ness” they’re finding that some core features are missing.

A key point when evaluating a headless vendor is not to let the headless-ness of the solution wallpaper over fundamental omissions. Just because you can deliver content easily to your mobile app doesn’t mean that approvals aren’t important. And all the JSON in the world is of little use if you can’t model your content the way needed to achieve your requirements.

Remember: headless is about delivery. All other aspects of CMS need to stand on their own.

It will make some newer development paradigms easier…and harder

As noted above, headless CMS was designed to make developing with “divorced runtimes” easier and more natural. For this, it succeeded admirably.

The chief reason is that a headless CMS is forced to maintain a competent remote API. The remote API is literally the only way an external process can interact with the CMS, so the API must be all-encompassing and the CMS can’t fallback to traditional server-side methods.

Additionally, given the recency of the headless paradigm shift, these APIs are very current and friendly to the latest generation of front-end developers. You can expect them to be REST-friendly and almost exclusively JSON-dependent. Older technologies like SOAP and even XML can be hard to find. Front-end and mobile developers should feel right at home.

Finally, one of the benefits of headless is that you can implement your website in whatever technology suits you, without having to sync with the rendering runtime of a traditional CMS. However, this can be a double-edged sword. While your developers might like building a website in their “framework du jour,” they might find themselves re-implementing a lot of web specific functionality – like navigation – that CMS templating engines have built specific functionality around.

Headless is often supported with traditional platforms

As noted above, a headless CMS exposes a competent API. Remember, that some traditional CMS have already been doing this for years. Depending on your requirements, any number of traditional CMS systems might be re-purposed by simply ignoring their delivery architectures and using existing remote APIs.

Many systems under active development have remote APIs, and others can be retrofitted with some effort. The underlying web developed framework behind your favorite CMS might have enough web service functionality to allow remote access to necessary content fairly easily.

Additionally, a dirty little secret of headless CMS might that most of them are actually decoupled. With most SaaS systems, the management system pushes content into a CDN or other interstitial cache for delivery to clients. This architecture might not be hard to replicate with some custom code and a selection of cloud services like Azure Table Storage.

Support for higher-end marketing and composition tools seems sporadic and might get complicated

A key weakness for headless is where content management and content delivery intersect. Two areas glow in the dark;

  1. Page composition
  2. Content preview

Headless systems seem to celebrate their explicit rejection of any concept of a “page.” Their battle cry is that “we deal with pure content, not pages.” This is all well and good…until an editor wants to compose a page of content using individual content elements. In many cases, an editor wants to place this content in that location, and a headless system that doesn’t even recognize the concept of a page will struggle to do that.

Additionally, content preview is necessarily dependent on channel-specificity. When an editor previews content, they are implicitly stating, “Show me how this content looks when rendered in Channel X.” As a headless CMS is divorced from channel rendering (that, indeed, being a purported selling point), content preview gets complicated. How do you render content in a channel when you have no relationship with that channel?

Other higher-end marketing tools might suffer complications. Personalization often requires cookies to be sent with every request in order to track user behavior. How will this work in contexts outside of a browser? If using server-side headless, how will you proxy those cookies back to the CMS from the inbound request? And is this even supported? Pure headless vendors haven’t yet caught up to the marketing features that traditional vendors have been working on for years, and traditional vendors might not be supporting those features in their headless API on initial release.

Recommendations

A key point when looking at headless systems is, “will this solve an actual problem in my organization?” And the problems that headless solves are not as common as you might think.

If you are serving a single website from a single repository of content, a headless CMS will be hard-pressed to deliver a tangible benefit. Managing a website from a CMS is a solved problem. There’s not a lot of mileage on the idea that a headless CMS solves this problem any better than a traditional CMS.

Also, be sure that the voice of IT is not drowning out the voice of the marketing department. Developers tend to enjoy headless because it frees them to indulge their preferences when building a website runtime. While we concede this is a benefit, it can come at the cost of considerable management functionality that will be sorely missed by your content editors.

In our experience, “headless only” situations are more rare than you might think. Most organizations will still benefit from a traditional CMS to serve a traditional web architecture, with selected needs in an around this that will actually benefit from a headless CMS. Call this “headless optional.” Those situations might make do with a traditional CMS and a competent web service API.

As always, examine your requirements carefully, and avoid jumping on bandwagons just to check a box or quiet a squeaky wheel inside your organization.