A Slice of Pie

(with apologies to Pie on the title – it was too good to pass up! ๐Ÿ˜‰ )

For quite a while now, Pie has been on a virtuous crusade to clearly define what is meant by the term “Enterprise Content Management” (ECM). In a late December post entitled “Turning the ECM Definition Around”, Pie neatly justified his search as follows:

Back in October, there was some debate on updating the definition of ECM. Since then, there has been discussions out there about whether the term ECM should even be used anymore. My basic opinion is, and has been, that we need to fix/update the definition, not the term. Changing the term would require a lot of work to educate people for very little gain.

Earlier this week Pie continued his hunt for the (thus far elusive) “perfect definition” of ECM with his post ECM or Document Management?, and a number of the points made in the post rang particularly hollow to my ears.

To paraphrase, the post asserts that ECM, at its core, is little more than Document Management (specifically, management of the files produced by Office productivity applications), and that none of the other extant Content Management use cases (Records Management, Digital Asset Management, Web Content Management, Collaboration etc.) are necessary for a system to be defined as an ECM CMS (although they may be provided as optional extensions to the core DM feature set).

Micro Slice
At a micro level, I think this view ignores recent† thinking about what constitutes a “document” – specifically the accelerating move away from the persistence of content as monolithic “binary content blobs” (PDF being the canonical example) stored in simple folder hierarchies, to open, semi-structured formats (DocBook, DITA, ODF, the Office 2007 XML formats, etc.) stored in repositories with richer navigational constructs (search, tag clouds, categorisation, etc.).

While these semi-structured formats can usually be “flattened” into files (in most cases as XML, although there are other equally suitable structured file formats) and stored in simple folder hierarchies, this is very much a lowest common denominator storage format, and far more interesting (and valuable!) possibilities open up if content is stored in a more modern, non-file/folder based repository (see my earlier post for a brief discussion of the storage mechanism such a hypothetical CMS might use).

Current Document Management products, on the other hand, are still firmly rooted in the “big blobs of data stored in folder hierarchies” view of content storage, and that suggests a couple of things:

  1. There is demand for, and value in, systems that are rooted in the “dumb file/folder” world view. Whether these deserve to retain the title of “Document Management System” remains to be seen, but my $0.02 is that the definition of Document Management will evolve to keep pace with developments in the field, quite possibly faster than the current batch of “DM CMSes” can innovate to keep up.
  2. Balancing this, “Document Management” as a term has accumulated two decades of baggage, and (like the term ECM itself), that inertia will be difficult to shake off.
  3. ECM as practiced today is far more than “dumb file/folder” management – which segues nicely to a second helping of pie ๐Ÿ˜‰

Macro Slice
At a macro level I simply need to point to the types of content that many enterprises are managing and the use cases they have for that content.

Take Amazon for example, arguably the poster child of a wildly successful content-centric Enterprise (disclaimer: I have never worked for or on behalf of Amazon, so anything I state here is educated guesswork on my part, based solely on publicly available information). I would be very surprised if much of their content was in a file format of any flavour (binary content blob or semi-structured), and it’s highly unlikely that they manage it in “dumb” folder hierarchies either (whether on a “real” filesystem or in a file/folder-centric CMS).

On top of this, Amazon’s use case for their content is classic WCM – much of their content ends up on what is arguably the largest brochureware site on the internet, with the classic brochureware goal of enticing customers to buy more of Amazon’s product (which, in some cases, is itself digital content, but that’s a topic for another post).

Amazon isn’t the only example of an Enterprise managing content in this way or for this purpose, yet if (as Pie argues) the term ECM is synonymous with the narrow definition of Document Management, Amazon isn’t doing Enterprise Content Management! So is Amazon doing it wrong, or is our working definition of ECM still insufficient to describe how today’s Enterprises manage their content?

† “recent” meaning “within the last decade or so”

Share via del.icio.us Share via Digg Share via Facebook Bookmark in Google Share via MySpace Share via Reddit Share via StumbleUpon Favourite in Technorati Share via Twitter

Published in: on 2010-01-20 at 7:15 am  Comments (2)  

The URI to TrackBack this entry is: https://contentcurmudgeon.wordpress.com/2010/01/20/a-slice-of-pie/trackback/

RSS feed for comments on this post.

2 CommentsLeave a comment

  1. So, you read my post wrong because I agree with you. To keep it simple…

    ECM is the core, DM is an application that is on the core. ECM vendors should build and package DM with their core ECM platform.

    WCM is an application. An ECM may, or may not, build such an application. That said, their platform should SUPPORT that application.

    The Content Services that I mentioned are basically native handling of XML, HTML, video, audio, and just about any format you can name. They should be supported by the platform.

    You can solve DM without ECM, but that only works for smaller organizations in the long term, though CMS Watch may disagree with where the line is drawn. You can’t provide ECM without a DM app and the ability to support just about any Content Application we could think of over a pint.

    Don’t make me have to write another blog post on this. ๐Ÿ™‚


    • You’re assuming I actually read your post! ๐Ÿ˜€

      Seriously though, I don’t think I was clear either, in that I’m not sure how much commonality there is between, say, WCM and DM.

      DM (as currently defined and practiced) is basically just filesystem++ – the same tired old file/folder concept with a few frills lashed on top (metadata, versioning, workflow, etc.).

      WCM however, is a different beast. It’s not about files or folders – it’s basically about structured content models (and by that I don’t mean relational data models – there are many cautionary tales *cough*Vignette*cough* of why relational databases make for a terrible WCM content modeling platform). Some of the frills (versioning, workflow) are, at the surface, common, but when you start factoring in the fundamental difference between what is managed (files/folders vs structured content), even the seemingly common frills start taking on quite different shapes.

      I’ve been meaning to blog on this topic independently, but your post caught my eye as (appearing to) reinforce the view that WCM is just “DM for HTML, CSS and JS files”, but that couldn’t be further from the truth. Even the WPTs / PMSes of the world (Drupal and friends) aren’t managed using HTML, CSS and JS files (or any files, for that matter!) – those “files” are simply a transport format for the consumption side of the WCM content lifecycle.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: