Visions of Jon: WCM is for Losers
Ain’t it just like the night to play tricks when you’re tryin’ to be so quiet?
We sit here stranded, though we’re all doin’ our best to deny it
- VISIONS OF JOHANNA
The end of the decade is nigh, and the mystics at CMS Watch have been throwing the bones again. They’ve released their very interesting 2010 Technology Predictions. The first of these caught my eye:
CMS Watch: Enterprise Content Management and Document Management will go their separate ways
I don’t agree with the terminology here. In my world, Document Management is one of the pillars of Enterprise Content Management. Enterprise Content Management is not a technology, it’s a business problem. Documents are one of the types of content the Enterprise needs to manage. So they can’t really go their separate ways. The wise Pie responded quickly to this prediction with an alternative:
Pie: Enterprise Content Management and WCM will go their separate ways.
Now this I agree with more than the CMS Watch version. Parts of ECM include Document Management, Records Management, Collaboration, Imaging, Workflow and all that good stuff. It is these pillars that allow a business to manage their content. The end game of all of these technologies is content sitting in a repository that can be easily found and consumed. The includes all the fun with versions, security, compliance and anything else you’d want to do with it. But it does not include setting up web based delivery channel that exposes some of this content. WCM should not be considered part of ECM.
Now Pie also acknowledges that his prediction isn’t going to happen, although it should. My prediction is even less lightly to happen, but here it is anyway:
Jon: Enterprise Content Management is well defined. The term WCM is horseshit, unnecessary and should take a long walk off a short pier.
I can already see the news headlines: LONDON, 2009 – SHOCK HORROR! WCM Geek Demands Death of term WCM. But it’s true. I’m of the camp that wished the term WCM would cease to exist.
The W is meant to stand for Web, which makes people think Web Site. But it also includes Mobile, Kiosks, TV and various other HTML based delivery channels. Many vendors are trying to deliver their WCM content to print channels too. I want any product that ends in “CM” to focus on content creation and management. As Pie said, this content should be accessed via an API or repository standard. A Content Management System should be an extensible application that works pretty well out of the box. The kind of standard these systems care about include data/process standards (for example DITA, BPEL, or Dublin Core) and repository access standards (for example JCR or CMIS).
The other half of the coin is the delivery framework. These are called Web Publishing Tools (WPT) in NPR’s COPE and Presentation Management Systems (PMS) by Peter Monks. Things like Struts, Spring Web, ASP.NET MVC, Ruby on Rails and many many more are all delivery frameworks. So are Portals. They let you manage authentication, URLs, site structure, templates, layouts, page composition, personalisation, aggregation and more. They understand standards like JSON, AJAX libraries, Web Services, SAML, OAuth, OpenID, Open Social, Portlets, Gadgets, WSRP, and so on and so on. They let you call any API to bring in content or functionality from any source.
Of course you can use these technologies to power sites that aren’t “content managed” at all. They should treat CMS driven content components, SoCo powered UGC components, DAM powered media components and anything else that can sit on a web site as equals. Interestingly, it isn’t uncommon to see “Web Content Management Systems” used to power sites that that aren’t really content managed. Take something like Drupal – it’s often simply used as a delivery framework without any content modules. I’ve launched sites running on .NET “WCM” systems that have never intended to have any content changed post launch. In these examples, the WCM product is being used purely as a good delivery framework.
But sadly, my prediction it isn’t going to happen. I’m just going to have to keep thinking of a WCMS as a tightly coupled hybrid of a content management system and a delivery framework. On the plus side, I’ll continue to make money out of poor customers that think a “WCM migration/replacement” doesn’t involve a complete site rewrite as they’re throwing the delivery baby out with the content bath water. Losers.
RSS Feed
Follow Me
Jon great post, though i have to dissagree.
WCM is the same as the ECM, its only a definition of a problem space and not product or solution.
The Web becomes a diverse delivery application platform and as such demands multiple delivery applications, one of them is the old term for web which is the website, others like SaaS/API make the information available over HTTP to other delivery methods like AIR/Silverlight desktop implementation.
The only thing that is changing is the web and its definition the WCM is just maturing as the web does and becomes a complex space.
Move the plank away and set WCM free.
Y.
Agreed that WCM defines a problem space at the moment (badly). Which is why I grudgingly use the term WCMS above, although you’ll never see anyone say ECMS. Being an Open Texter, would you say that Vignette Content Management addresses the same problem as Drupal? If not, how what you define a) the problem space and b) the class of product to show the differentiation.
Bearing in mind that (at least in my world) ECM includes Records Management, Doc Management and more that the VCM doesn’t address. So I’ll agree that the *OpenText Suite* is an *ECM Product Suite*. But if you had to classify just the VCM, how would you do it?
Actually, defining a WCMS as “a tightly coupled hybrid of a content management system and a delivery framework” is quite helpful — thanks for that
You’re right in saying that the term Web Content Management System itself is vague, or misleading, and probably doesn’t cover what those systems do. But you’ve managed to quite succinctly pinpoint what people mean, when they do talk about a WCMS.
My two-pence to the discussion, from a guy who spent more than 10 years in document management.
The term Document Management System (DMS or EDM – Electronic Document Management) is an abstraction of a file system.
Enterprises produce and receive information in various formats (mail on the post, faxes, Word documents, video clips, telephone calls, emails, etc). The first function of the DMS is the transformation of all of this into an electronic format that can be stored in a computer system. The information becomes a computer file. The second function of the DMS is indexing, or assigning metadata to each of the electronic files using various techniques, like OCR, ICR, barcodes or simply manual data input. With metadata, the file becomes a document. The third aspect of a DMS is retrieval. This includes structured and unstructured search, hierarchical presentation and other methods of browsing the document vault. Document management also involves security, version control, traceability and archive management.
When you start moving around and modifying documents, according to predefined business rules, you enter the realms of a Workflow system. Typically, good Workflow systems are extensions of good DM systems.
When you start concerning about the location of the originals and retention and destruction policies of not only those originals, but their electronic versions, then you are talking about Records Management.
I’m not quite sure I agree. I think I see where you are coming from, but maybe (actually very probably) our clients have different requirements from content management in general.
If I’m reading you right, you seem to be saying that ‘ECM’ should cover all of the content in the organisation and that ‘WCM’ should die as really is should just be the distribution channel for the content from the ‘ECM’ system to web/mobile/tv/etc.?
If that is the case, then are you advocating that every organisation goes out and buys some kind of ‘ECM suite’ to store all their data in and then hook some WCM (or delivery mechanism) up to it? That seems a bit heavy handed. Maybe all of your clients need to have data in some ECM system… most of ours have their data for the web in the WCM system. OK, so maybe that is encouraging silos of information, but I have to say very few of them really have information that needs to be in both (and what little there is can be bridged between the two easily enough via various APIs).
So, going with your comment above about does VCM address the same issues as Drupal… if a site is using Drupal then you must be either saying:
1) Drupal is an ECM system
or
2) Drupal must either die or not call itself a WCM system, but just some delivery system.
I’m not sure either of those statements fully capture what organisations need to do. What about all that content that is *just* for the web (as opposed to for the business’ core processes) such as the page with directions to the head office, or the CEOs blogs, or the ‘About us’ page? None of those I think belong in an ‘ECM’ system (for my definition of ECM). But they need to be managed. If you remove the term WCM and say that there just needs to be a web delivery channel to an ECM then what product do I use to manage the content on my website? Do I then need a ‘blog content management system’, and an ‘about us page management system’?
IMHO, Something just seems missing if you remove WCM.
-Matt
I’m not for a second saying that everyone needs an ECM suite. I think that the management of the kind of content that ends up on the web is part of the Enterprise Content Management problem space. It seems that the moment that our definition is something like this: THE CONTENT IN AN ENTERPRISE = DOCUMENTS + RECORDS + DIGITAL ASSETS + SOURCE CODE + PRODUCT INFORMATION + COLLABORATIVELY GENERATED STUFF + X. In this formula, X is the stuff managed by a CMS. The rest are managed by DM, RM, DAM, SCM, PIM, Social/Collab software respectively.
I think the VCM and Drupal are fundamentally different, and neither are an ECM system. The problem we have at the moment is that both of them are called WCM systems. The VCM is purely about managing content and provides an API to that content. It has no delivery capabilities at all (which is why VIGN/OTEX flog the Portal with every sale). Drupal is primarily about page composition and delivery with pretty light Content Management modules kicking about. The fact that we have to put them both into the same WCM bucket kills me. The VCM should be a CMS. Drupal should be a Delivery Framework|Web Publishing Tool|Presentation Management Tool – pick your favourite name for it.
And before you reply, Yuval, “Enterprise Content Management” != “Enterprise Wide Web Content Manangement”.
OK, I think I understand what you are getting at now. I agree that tools like VCM and Drupal being in the same bucket makes it a very awkward shaped bucket
So I think you’ve just accidentally coined a new term there then: XMS
A management system for all the stuff that isn’t DM, RM, DAM, SCM, PIM, Social/Collab.
I don’t know much about VCM so can’t comment on that, but I really don’t see why you wouldn’t call Drupal a WCMS. After all it lets you manage web content. That is not to say that *all* content for the web in an organisation would be managed by it. Much of that content might come from elsewhere and you would use something (maybe Drupal, maybe something else) to publish it to the web.
Or put another way, if you killed the term WCM, then I think you’d have a hard time to find a term or set of terms to describe Drupal, Plone, MySource, Jadu, Terminal 4, etc, etc. Most of them all do more than one part of “Delivery Framework|Web Publishing Tool|Presentation Management Tool” and that sure ain’t a catchy term if it provides all 3 of those parts! What if one of those products includes workflow (which most of them do) is that part of web publishing? or part of Delivery framework? What about search?
I agree with you that WCM is a pretty imprecise term, I also agree with you that it probably will not go away anytime soon
-Matt
+1 !
More thoughts on this idea here.
Agreed with all the points on the bifurcation of WCM from ECM (this happened a long time ago) and the impending bifurcation of content and presentation. On that topic, I’d argue that the current growth in the WCM space is coming from the vendors that figured out the right combination of content management, delivery, and applications (Day, Ektron, Sitecore, etc).
My problem with the WCM term is that it often misrepresents the value customers will receive. I’m seeing WCM projects being justified by the benefits to brand, revenue, loyalty, and engagement. The traditional operational efficiency benefits from managing content are important but often not the primary reason for acquiring WCM. I tried to capture this thought during my Interwoven days http://interwovenblog.com/2008/11/07/redefining-the-m-in-cms-and-wcm/.
Again maybe I’m being short sighted here. I’ve yet to have a single customer want to ‘monetize’ on their content with WCM. I can see that being an obvious goal for a newspaper, or other online media publishing business, but other than that I’ve not seen it.
I’ve seen a push in all the major commercial CMS vendors to offering marketing suites that offer things like multivariate testing and the likes. This is probably the one main area where I think the commercial WCM vendors are ahead of the Open Source ones. Then again, the cynic in me says that the only reason the commercial vendors are pushing these marketing suites is because they need to have *something* to differentiate themselves from their rivals and offers an extra license revenue to them. If this kind of function was in so much demand then the open source crowd would have built something. I think most are happy with what Google Analytics and the likes offer and so provide integration with them.
From what came out of the #fixwcm discussions Jon started and presented at JBoye it seems like CMS users really just want to basics done properly, and don’t want yet more functionality added. But then, for commercial vendors, features == license revenue.
-Matt
This is a really good post and I like the comments too.
* I agree with Adriaan that “a tightly coupled hybrid of a content management system and a delivery framework” helps to describe most WCM software.
* I don’t think that “web content management” has too much to do with ECM: it’s not really about managing lifecycle of assets in the same way as DM. It’s about providing tools so that good information can be published to the right audiences over a limited number of channels.
* The thing that complicates ECM vs. WCM is that many ECM assets will no longer be documents in the near future, but more akin to what we now call “web pages”. Pie is on the money there.
* I think XMS is brilliant. I’m going to file a patent for it before Kas Thomas does.
I agree with Seth Gottlieb here… everything in the enterprise is going to have a URL, it is all going to be delivered by HTTP, and it is going to move from the old style of legacy documents that combine the presentation layer with the applciation layer in the document processor, to the WCM style model of separate presentation layers, with documents stored as HTML, XML and so on. Content Management will therefore look much closer to WCM than to legacy document management. CMIS is an attempt to not get locked out of this architecture, which is why it is significant.
Which is not to say that the WCM systems will look like the current crop, many of which are skewed by short term needs, largely caused by the disjoint nature of document management creating different areas of expertise.
I certainly agree that everything in the Enterprise will have a URL and be delivered over HTTP. And that means Web. Sweet! So I think it’s high time we introduced the terms Web Document Management, Web Records Management, Web Digital Asset Managemeent and Web Product Information Management. The word Web in front really adds so much value.
Or let’s just drop the W from WCM and call it Content Management like we use to …
Very interesting post and comments!
In my posts about COPE, I tried to make a distinction between tools that capture content in a presentation-agnostic way and those that capture them for one (or more) specific presentation. I call the latter WPT (web-publishing tool), although Peter Monk’s Presentation Management System is in some ways a better term in that it is broader, covering systems that don’t just apply to the web.
For me, however, the future of the content management systems (CMS, or whatever acronym you want to give it) is in their ability to capture the content in a clean, presentation-independent way. Then, as Pie states, the content should be retrievable through a series of API’s, enabling the content to be distributed to any other platform. If available through an API in a truly portable, presentation-agnostic way, the system can then service any presentation layer.
So, I would suggest that the divide in these systems will be between tools that capture presentation-agnostic content and those that capture content to satisfy specific presentation goals. I don’t really care about the terms or acronyms as much, although for this conversation I would probably go with the distinction between CMS and PMS/WPT.
Finally, I would suggest that there is a place for both types of systems in our future. For organizations (like NPR) that have a real need to publish everywhere, it is critical to have a true CMS. But individuals and smaller organizations probably won’t have such a strong need to have comprehensive distribution strategies which means a PMS/WPT is probably suitable for them.