Component Content Management
January 30th 2007 - Originally posted to CMPros mailing list
In an article in the CMPros newsletter sent out this morning, Ann Rockley and Steve Manning take up the worthy task of defining Component Content Management.
http://www.cmprofessionals.org/resources/newsletter/cm-pros-newsletter-2007-01/forrester-wave-vs.-component-content-managementThe article foreshadows an energetic response from the community at large... so here comes my bit of that response!
I think that the proposed definition is, as the authors say, a good starting place, because it is articulate and descriptive.
But the problem I see with it is that this definition seems far too similar to the definitions and descriptions of CM systems in general. For example, consider the list of CCM benefits proposed - Greater consistency and accuracy, Reduced content creation and maintenance costs, Reduced delivery costs, Translation costs are reduced. While all of that may well be conferred by a good CCM system those do not seem to be benefits that would be unique to a CCM system and distinguish it from other CM products.
I have heard the criticism of the CM industry in general that CM vendor marketing literature is often so blithe, unspecific and buzzword-laden that it could be interchanged between different products without anyone noticing. (Here's an idea for the next CMPros summit - the CM Folger's Test, where we mock up three versions of a particular vendor glossy - one original and two that have the same graphics, styling, and layout but contain a competitor's marketing copy. Vendor CEOs can stand by to pull a lever that dumps a barrel of pink slips on top of any vendor employees that fail to correctly pick the real brochure of their own product.) For that reason it seems like we should avoid endorsing definitions that aren't discriminating and would easily let anyone through the door. Without putting some tougher measures into a CCM definition I'd think any ECM or WCM vendor would invite users to throw document components into the same storage and processes and features that were originally designed for entire documents, leave it to the user to write some front-end code that welds the pieces into a full document, and would say "We're a CCM product too!"
One nice and specific part of Ann and Steve's definition was "Each component has its own lifecycle (owner, version, approval, use) and can be tracked individually or as part of an assembly." Now that's something we ought to stick it to 'em and make a requirement in our definition, I think - it should be possible for any content component in a "real" CCM to be either tracked individually or grouped with other components through its lifecycle and it should be possible to change that attribute of a content component.
I've got nothing as far as a comprehensive definition of my own but I think that one factor we could use to tighten up the definition is to talk specifically about tools for compositing / assembling content. It wouldn't necessarily have to be a UI - maybe it's just a matter of having some specific methods in the API - but a "real" CCM ought to have some kind of tools for assembling entire documents from components. It should be an easy, commonly-performed task to set up a composite document and it should be possible to do it internally, within the system or its API. It might also be possible to do it externally, with your own code, but a system that forces its users to do their own assembly shouldn't get to call itself a CCM under our community standards, IMHO. And maybe we should even define specific capabilities or specific kinds of tools, I don't know.
Hmmm... here's another salient question... how is a CCM different from a templating system like PHP's Smarty Template Engine (http://smarty.php.net/) or ASP.NET's "Master Pages" functionality? Especially given the statement from the article, "In essence, component content management is a methodology for managing content, not necessarily a system." It occurs to me that in ASP.NET, without any coding (by adding XML tags to HTML documents you've re-named ".aspx" or by dragging and dropping things in Visual Studio) you have access to some rather sophisticated reuse and component assembly capabilities.
Well them's my two cents. To make my standard disclosure, I'm a CM consultant focusing particularly on Ektron deployments and I was formerly an Ektron employee. For the record I don't think that Ektron's CMS400 product qualifies as a CCM though I think they have many of the right capabilities in place if we give them some guidance on CCM features they should add.
