The Dawn of the Web Content Delivery System (WCDS)

By Deane Barker 8 min read
Author Description

Web content delivery is becoming so complex and important that it’s deserving of a system all its own that aggregates, harmonizes, and enhances content for delivery.

AI Summary

This post explores the evolution of web content delivery systems, highlighting their significance in improving user experience and performance. The author discusses the challenges faced and the potential for future developments in efficient content delivery mechanisms.

Note

Clearly, I was trying to make the term “WCDS” happen with this. The term did not happen.

Also, note the date here. Back when I wrote this, a lot of this stuff would have been novel and interesting. Today it’s a little simplistic.

But, the ideas behind WCDS lived on as “distributed CMS,” which is something I’ve remained very passionate about. See my talk in Denmark called The Future Might Be Distributed, and a promotional blog post about the same thing I wrote a few years back for a different conference.

We need to start looking at Web content management (WCM) differently. We tend to look through the lens of the Web content management system (WCMS), which says that we have a content production, storage, and delivery system all-in-one. As time wears on, and organizational needs get more sophisticated, I think more and more that this definition is simplistic and needs to evolve.

It’s time to admit that there’s a big difference between content production and content delivery. With a WCMS, both are often rolled into the same system. But more and more, this is changing. WCMS are being called on to deliver content that they didn’t produce.

Take a leap with me for a minute, and envision your WCMS of choice. Imagine using that system solely to deliver Web content, none of which was actually produced in the system.

I’ll give you an example –

Bob’s company produces a massive knowledge base of documentation via DITA (Darwin Information Typing Architecture) with some client-side rich editor. These procedures are developed by a group of technical writers, and the the end result of their production is 7,000 HTML files. Bob’s company wants these on the Web.

Easy, Bob says, just give me an FTP account. And, sure, this is one way to do it. But this is very primitive delivery.

At the same time, Bob’s boss is looking over the competitor’s Web site, managed in something like Episerver, and he calls Bob up and says: “They have comments on their stuff. And people can rate their procedures. Why don’t we have that?”

“It’s not my fault,” Bob retorts, “You’re the one who wanted all this stuff done outside of a WCMS. I can’t do much with flat HTML.”

What’s the error here? Simple: Bob confused content production with content delivery. He thought that the usage of DITA limited his options for both production and delivery. But, in the end, DITA is just a method of production. It dictates no particular method of delivery, and the services Bob’s boss wants are a function of the delivery layer.

Put another way – just because some content was produced outside a WCMS, doesn’t mean it can’t be delivered by a WCMS. Rather than pushing the content directly to the Web server, which provides no services other than serving up request content, Bob should have pushed the content into a WCMS, which can provide a level of enhancement in the delivery layer.

As an industry, it’s time we start looking beyond the production and repository services a WCMS provides and start looking at it as a content enricher. Done correctly, a WCMS manages a delivery layer that provides services to content that add value by powering all sort of functionality. And if you pick the right system, it will provide these services whether or not the content was developed inside the CMS or outside.

Take Episerver, for instance. Let’s imagine for a minute that Episerver didn’t allow content editing. So, there’s no way to add a new page or edit an existing page inside of Episerver, and the only way to get content into it would by import, or API-level linking.

Well, what would be the point of this? What would Episerver exist to do?

A lot, it turns out. There are scads of value-add services that Episerver provides to your content in “the last mile.” Here’s a partial list –

The system provides this suite of services to make all your content better, whether or not the content originated inside of Episerver.

So, I’m officially coining a new term : Web Content Delivery System, or WCDS. A WCDS is a system that embraces content from a variety of sources, and does two things.

  1. Homogenizes it – unifies it in appearance, permissions, navigation, etc.

  2. Enhances it – provides services to that content to enrich it, and make it better.

I’ve been nurturing this idea for years. My original name for it was “content incubation system.” I liked the term “incubate” because this is what I felt the system was doing – it was embracing disparate content and giving it a place to thrive and grow. (In fact, we built such a system for a client once, and called it “Incubate.”)

Over the last few weeks, I’ve really started to sharpen my focus on this concept, and, in the process, have found I’m certainly not the only one to think this way.

In San Francisco, during a CMS GeekUp after the Gilbane conference this year, I sat down with Peter Monks from Alfresco. We had a lively discussion about this same concept, which he had named a “presentation management system” (awkward acronyms be damned…).

Peter has blogged about this concept on a couple of occasions:

(Interestingly, Alfresco provides perhaps another example: they have had integration with Joomla for some time. One could fairly easily imagine large amounts of content produced, stored, and managed in Alfresco, but delivered via a “slave” Joomla install that existed for no other reason than to put a pretty, Web-friendly face on content in Alfresco.)

I also got to talking to Seth Gottlieb about this. He mentioned a system called ATG Dynamo, from the late 90s which sought to do this same thing. Dynamo no longer exists, but it was one of the first “application servers” which really looked at the delivery layer as a location or unification and enhancement, no matter where the content might have come from.

Seth also turned me on to Jahia which is a Java-based CMS that really champions the WCDS concept. They call “Web content integration” (a phrase which is a bit too abstract for my taste).

Differences in nomenclature aside, Jahia’s Web site has a bang-up definition of the concept I’m trying to explain here:

[Jahia’s goal is to] act as a federated integrated hub by making it easy to connect with all of your heterogeneous content sources and helping you best leverage and reuse your existing content assets over the web.

Jahia makes another good point on their Web site.

Web projects requirements […] juggle increasingly confusing definitions of what “content” actually is. The convergence of web, document and portal capabilities creates overlaps in the users’ minds.

Too often, we think of “content” as “whatever our WCMS manages.” This is far too restrictive. Really, anything under your domain name or branded by your organization is content, and it needs to managed and delivery with exactly the same level of commitment and services as some page we created directly in the WCMS.

But, in the end, what is a WCDS, in software terms? I don’t think it exists in isolation. You can’t go out and buy a pure WCDS. Even Jahia is a WCMS first, but provides and promotes some WCDS capabilities in addition.

WCDS is really a capability of a WCMS. It’s measured in the ability and willingness for a WCMS to deliver and enhance content it didn’t produce. In more specific terms, it’s measured in degree of capability in areas like import/export, CMIS, API usability, repository abstraction, etc. WCM systems vary widely in their ability to do these things, so some will make a better WCDS than others.

I don’t think they’ll ever be a day when you go out and buy a WCDS. You’ll buy a WCMS and use it as a WCDS, most likely in addition to its core content management functionality. But the day has absolutely come to define some WCDS core competencies and include these in any content management evaluation process.

Links to this – Decoupled Content Management 101 March 26, 2011
Originally, content management repositories were separated from the publishing layer. This line has blurred over the years, and there are numerous models that combine aspects of both decoupled and "active" delivery tiers.
Links to this – Deane Barker's Resume
A long-form resume I keep generally up-to-date.
Links to this – WCM Vendors: It's Time to Abstract Your Repository September 5, 2010
Over the last decade, content management has become increasingly focused on the web. However, in this world of true multi-channel publishing, the web is just one of many channels, and its time CMS vendors made their repositories less web-specific.
Links to this – The Bifurcation of Content Management and Delivery May 10, 2011
Content "management" and content "delivery" have diverged into two separate concepts. The disciplines used are different, and I argue that it won't be long before vendors start splitting off their delivery suites from their management suites.
Links to this – Advanced Topics in CMS: Course Syllabus
This is the content for Deane Barker's 'Advanced Topics in CMS' course taught at FH Joanneum in Graz, Austria.
Links to this – Is there a distinct type of CMS for "news"? May 13, 2011
What is a (news) CMS? : Interesting comments about how news organizations need a CMS specifically wired for news. This involves, among other things, abstracting your repository from the presentation layer. News organizations should instead be “content-first,” and use tools that promote content...
Links to this – What is Content Integration? April 27, 2015
We spend a lot of time making content that _doesn't_ exist in our CMS look like it does. This is an attempt to put a definition around that discipline.
Links to this – Professional Interests
A list of things in the content industry that I'm fiddling around with these days.