ECM or Document Management?

imageI’ve been working to help re-define ECM these days.  It has been a matter of using the term Enterprise Content Management versus creating a new term.  My theory is use the term that a lot of people know and don’t start the education process over.  John Mancini, the president of AIIM, talked the ECM label on his Digital Landfill blog.

A more important question has arisen…is ECM even relevant as a concept?  CMS Watch really kicked this thought process off by saying that the term should be reserved for that rare breed of big, complex, and typically very expensive platforms that actually merit such a grandiose term.  For other systems that may aspire to ECM, but aren’t there, Document Management is the term.

I’m thinking Yes and No.

Before we look at Document Management, let’s look at ECM as a platform.

ECM as a Platform

There is a real good discussion on the definition of ECM in the comments of my recent post  and I’ll be re-visiting that in detail in the near future.  What I want to cover here is the concept of an ECM platform.

I recently talked about better defining what an ECM platform needs to do and told EMC (though the advice applies to all ECM vendors) that they should further separate their applications and platform, both architecturally and in regards to the release cycle.  There is still one problem with this information

It is still too complex for simple discussions like this one.

Time for a simple architecture for the ECM platform with the features all sort of “baked-in”.

  • Repository: Store it here.  The repository is the home of the storage, Library Services, Content Services (native XML support, emails…), Process Services (retention, lifecyles…), and all that fun stuff.
  • System Interfaces: Plug into it through an API or some service-based mechanism like web services.
  • Administration Tool: You have to manage the manager of your content

That’s it.  Oh there is a lot of work actual features and details, but that isn’t key to this discussion.

From a practical standpoint, vendors add tools and applications to their offerings.  That is what drives sales and new features in the platform.  That said, the apps aren’t the ECM platform themselves.  In the third part of the recent Razmik Abnous interview published on the Documentum Community, Razmik stated it clearly:

…a platform by itself isn’t a finished product. If all Intel sold is a processor chip, it would be useless. I need a computer and peripherals to make the Intel processor great. ECM is a great platform, but like an Intel chip, by itself it’s an unfinished problem. With a point application around it the value gets realized.

Which brings us to Document Management…

What was Old is New Again

image Document Management is what many current ECM vendors called their systems before they became ECM platform vendors. Documentum, FileNet, and PC DOCS were key players in the 90s in this area (Razmik agrees).  I was working in with DOCS Open which was a great, and simple, Document Management system.

The question is, what are you trying to really solve with Document Management?  The management of Documents? Sure, but what are Documents?

Well, if you look back in time to see what was being solved then with these systems, you were dealing with office productivity documents, like those spawned by Microsoft Office.  You were also dealing with scanned images and PDFs that were either collected or rendered.

Did email count?  Back then, not as much.  Email itself is a tricky beast and there is a fine line to be drawn between email archiving and “email document” management. The second is more discretionary and dictated as much by records policies as anything else.  For now we are going to gloss over RM and email as one could argue that they are both applications independent of DM, though no less important to the business.

What makes a great Document Management application?  Well, ease of use for the office worker is my first requirement.  You want it to be easily integrated into the applications that people use all the time to generate documents, like Word, Excel, and PowerPoint.

This is why SharePoint is such a killer DM application.  It integrates into MS Office better than everyone.  The problem is, a Document Management system is not necessarily an ECM platform.

Document Management is an APPLICATION. It is a core application that all ECM vendors provide.

Document Management can be stand-alone.  So can a Web Content Management application, otherwise known as a Content Management System (CMS) or whatever it gets renamed to this year.

In fact just about every use of content, from documents to images to web pages to videos to anything, can by solved with a stand-alone application.  Sometimes it is the correct thing to do.  Sometimes, you want a platform to be the back of those applications.

The ability to find a stand-alone system doesn’t preclude it from also being an application for an ECM platform.  SAP stores documents, but it can also store, and retrieve, them in an ECM system.

We shouldn’t avoid Document Management.  It is a use-case like Digital Asset Management, WCM, and Collaboration.  It can also be sold separately.

Closing the Circle

What conclusion have we arrived at? Several, but one that needs to be stated to make it clear is that an ECM Platform MUST have a solid Document Management Application bundled.  It addresses the realization of the ECM platform value at the most basic level in the organization.

ECM vendors can let others build a good WCM or DAM application on their platform, but Document Management needs to be solved as a core point solution.  Document Management is too closely tied to the platform at this point.

That is until someone creates an Office integration using CMIS.  😉

3 thoughts on “ECM or Document Management?

Comments are closed.