(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).
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:
- 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.
- 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.
- ECM as practiced today is far more than “dumb file/folder” management – which segues nicely to a second helping of pie 😉
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”