The Dawn of the Web Content Delivery System (WCDS)
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.
Homogenizes it – unifies it in appearance, permissions, navigation, etc.
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.