The Dawn of the Web Content Delivery System (WCDS)

By Deane Barker on June 13, 2010

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 —

  • Search
  • Permissions
  • Templating (you can further customize template by content location, relative to other content)
  • Navigation management
  • Content rating
  • Commenting
  • Conversation (A/B) testing
  • Integrated analytics
  • Reporting
  • Language management
  • Integrated SEO tool

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 wth 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 (evidently pronounced “ja-ya”) 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.

Gadgetopia
What Links Here

Comments

  1. John: I specifically avoid the word “portal.” It’s too loaded. It carries with it too many implications of interface issues and intranet-ish purpose. That, and the fact that the word lived large and died hard back in 2000 – 2002.

    There are some other differences as well, but I’d need to reflect a bit more to articulate them well.

  2. Interesting post Deane. I like the concept and I think you need a new name. This is coming from someone who loathes false starts, especially when it comes to naming things, it’s major pet peeve of mine. Reason being, your system does more than delivery — it’s allowing for authoring, annotation, rating, review, etc. Community generated content is first class content in my mind. Calling this a “content delivery system” because it delivers content feels just as wrong as calling it a “content production system” because it enables community generated content. This comment is anticlimactic as I don’t have any better names coming to mind. But my recommendation is to think of something that isn’t so overloaded.

  3. Deanne, I am so excited to see that you’re discussing this. There is a name for it – component content management (CCM) – and it’s been ignored for way too long. In fact, it’s considered such a niche market that there are only about a dozen players in that space. (However, a couple of big-box CMS vendors have bought up smaller CCM products to be able to extend the reach of their CMS.

    It’s not a portal at all. Completely different concept. What it does is move the control of content repurposing and re-use upstream. in a WCMS, the re-use is done by automating movement of content through customization. A WCM example would be news releases. If only the title and intro paragraph are to appear on the home page, and the entire news release in the news section, and anything older than a month in the archives only, the integrator writes that script and creates the templates to enforce it. The writer does the “dumb input” and the system moves the content around.

    A CCM example would have the writer control the components. To over-simplify the explanation, the writer creates re-usable components – in your example of thousands of documentation pages – and then decides, during content creation, where those components get included and re-used. If there were a common procedure, it could be re-used tens of times across that documentation set, not by copy-and-paste, but by dragging-and-dropping a pointer to the source procedure. This also means that one central update to the source file means a global fix to all the files where the pointer exists. (I wrote a post about this using the mash-up metaphor: http://intentionaldesign.ca/2009/09/11/component-content-management-as-content-mashup/.)

    For the most part, this happens behind the scenes, and then the files are exported to a WCMS. However, I think it’s only time before these technologies begin to integrate. Right now, organizations think of marketing copy as the content that needs to get managed. However, the marketing copy is like the icing on the cake; the product/training/technical/support content is the cake itself. For every file on the marketing side, an organization can have tens, hundred, or even thousands of supporting technical files. As their content strategies are becoming more inclusive of “back end” content – the content that marketers always found boring and safe to ignore – they’re realizing that these corporate assets could be put to way greater use if they look at the creation and delivery technologies.

    Wonderful discussion, Deanne. Looking forward to more.

  4. Hi Deane,

    Thanks for a very thought-provoking article.

    Tridion has always had a very clear separation of web content management and delivery. Content is usually created on the CM system, and then rendered transforms of that content are published to the content delivery systems.

    Whether or not your tool of choice has these sub-systems laid out as explicitly as Tridion, it’s still tremendously important to treat the two problems as distinct. As you’ve noted, it’s also perfectly possible to build integrations between different systems that take care of the respective needs of each.

    User-generated content is a particularly interesting topic. Traditional web content management and delivery architectures have commonly assumed that content would come from within an organisation. These days, you can’t assume that any more.

  5. I just stumbled upon this and totally agree. Coming from a CMS for publishers perspectives, we had similar thoughts in 2007, in that the WCMS (as it was called at the time) is more about the delivery of the content through the web channel, and all of its related functionality, but the content management and production process should be elsewhere. This is our view from a publisher’s perspective and interesting to see others outside publishing are coming to the same conclusion. http://blog.reallysi.com/2007/08/the-content-in-.html

Comments are closed. If you have something you really want to say, email editors@gadgetopia.com and we‘ll get it added for you.