Article by Deane Barker, Chief Strategy Officer at Blend Interactive.
I suspect we might be reaching an inflection point in the evolution of content technology. We might be reaching the point where vendors stop pretending that servicing large web properties from a single CMS is a good idea, and instead they begin to embrace and even celebrate the idea of orchestrating content from multiple providers.
Historically, the standard vendor strategy has been to be “The One CMS To Rule Everything.” Vendors wanted to be all things to all web properties, no matter how large and deep. But, years from now, we might look back at this as slightly naive, for a few reasons.
Content is becoming more diverse and richer at the same time. More esoteric types of content (video, VR, etc.) require different editing tools, and a single platform is hard-pressed to provide them all.
As websites become larger and larger, they suffer systemic complexity issues, where it becomes difficult to isolate one part of the content footprint from others, and hard to predict how changes might ripple across the system.
The sheer enormity of some web properties cause deployment issues. Deployments become something like turning the Titanic. Regression testing — however automated — starts introducing more and more overhead and friction.
Development teams have constrained resources, and introducing new functionality requires someone who understands how to develop with the CMS. Eventually, the injection of new code into the CMS environment threatens stability, and the system begins to creak under its own weight.
Speaking solely of web platforms for a moment, consider your “URL space” to mean all the URLs your organization publicly exposes to the world. This is your “real estate” on the web. Why do we believe that this entire URL space has to be “owned” by the same content system? Well, because this is vendors have told us.
But what if inbound requests to the same web presence could be directed to a backend provider best equipped to service them? What if a single, integrated web presence could be serviced by an array of systems, each working independently, and providing content to a “last mile delivery system” which massaged and homogenized it, and provided a set of delivery services — analytics, security, design systems, etc. — to optimize it?
To this end, let’s coin a couple definitions:
Content Provider: any system that produces content and can make it available to a “downstream,” consuming system
Content Provider Management System (CPMS): a single front-line system that receives inbound requests and orchestrates “upstream” Content Providers to generate a response that looks as if it came from a single entity
Put another way: what if your CMS didn’t originate any content? A CMS becomes a CPMS when it manages backend Content Providers, rather than providing content of its own. A CPMS eithers (1) acts as an interstitial host for content published (cached) into it, or (2) brokers an inbound request to the correct Content Provider in real-time.
(A friend, on reading this, responded: “A portal. You’re talking about a portal.” However, in reality, most organizations would opt for a CMS that could also act as a CPMS for selected content. So, perhaps 80% would be served traditionally from the CMS, and the CPMS would orchestrate the other 20% from other providers. So, when we discuss “CMS” below, we mean a CMS that selectively acts as a CPMS, likely for a minority of requests.)
Consider these examples:
You have a traditional marketing CMS for your corporate website, but the CEO really like WordPress and wants to use it for her blog. No problem — requests to “/blog” could send a “proxy request” back to a hidden WordPress installation, then intercept the response and manipulate it to look like the rest of the corporate site before sending it to the visitor.
Your press releases are managed using a hosted newswire service. Through an API, press releases are pushed into your CMS on publish, where they exist in a cached state to fulfill web requests. The Investor Relations team might generate and manage thousands of press releases through the newswire service, which will all quietly cache inside your CMS — the team might never even know that they were remotely manipulating this data.
Your Marketing team has some very intricate landing pages built in hand-coded HTML. Requests for these vanity URLs could retrieve and deliver static file contents from a cloud file service, populated out of source control by a Git publishing hook.
Your Finance team wants a complicated loan fee calculator added to the website. They have one built already, but in an entirely different language. Using a proxy to push data back and forth, this calculator can appear as if it lives directly in the website while it’s actually running in a different environment and developed in an entirely different language.
Your dealer management team needs to maintain a simple list of highly structured content. You don’t want to train them on the full CMS, so you give them access to a SaaS-based headless CMS and train them for five minutes. Their section of the website translates inbound requests to the correct headless queries, then formats and delivers the response.
In these situations, the frontline CMS is operating as a “ringmaster” or “orchestrator.” Multiple backend content providers are “projecting” content into the CMS for it to handle the last mile delivery to the visitor. The visitor has no idea of this orchestration taking place under the surface.
Of course, we absolutely do this now. System integrators often deliver this level of orchestration through custom development. But could we be entering an era where vendors design their systems for this, natively? Will vendors concede that they can’t be all things to all people, and instead deliver tools and features to orchestrate multiple providers?
The benefits of this model are numerous and they scale up as your web presence grows larger and larger:
Content can be managed in systems designed specifically for it. Video can be managed in a video-specific platform, hand-coded HTML can be managed in files via source control, etc.
Development teams can work on parts of the system without upsetting the whole. Functionality can be selectively deployed to different backend systems while the core CMS is unaffected. Content provider development teams don’t have to know anything about the CMS — they don’t even have to know the same language — and their content providers can often be “sandboxed” so errors don’t become systemic.
The output of diverse content providers can be visually integrated through a master presentation system. Individual content providers can either generate output according to a markup guide, or can be forcibly coerced through parsing and reassembly.
Security can be centrally managed through proxy connections that first authenticate to the CMS, then, once identity and authorization is established, retrieve content from backend providers.
There’s a common theme here: your CMS as a gateway to a larger array of content providing systems. The visitor can’t see any of this — to them, your website is simply an integrated, seamless whole.
In the end, performance art provides us with a handy metaphor —
When you visit a theater, you sit in the gallery and watch the production through the proscenium. There’s a lot of stuff that happens which you can’t see — actors are moving through the wings, light operators are working their controls, sets are moving in and out — but you don’t care about this, because you can only see what’s on the stage. The performance involves some level of chaos behind the scenes, but it all comes together through the lens in which you view the performance.
Your end-stage CMS — your Content Provider Management System — can be the stage through which your visitors see an integrated performance from a system that orchestrates and coordinates multiple moving parts to form a greater whole.
I’m anxiously waiting to see which vendor leads this charge.
PS: Meet Deane at the CMS Expert group meetings in North America.