An RM discussion going on......

A tenous link to the posting below - the link being the mention of Oracle (Stellen) products....

Laurence, James and Jesse (the ECM blogging 'regulars' ?) have been having a conversation on Records Management.

Its ranged from one end of the spectrum to the other, so to speak. It has been commented that to do 'electronic records management' you dont actually need ERM software, you need policy and procedures (and a way to enforce them ?) and nothing more cutting edge than Windows file shares.

Then James takes us into the area of where ECM fits in a "Compliance Oriented Architecture" and suggests that retention and disposition services should be exactly that - 'services' in an SOA that can be called by any application.

Anyway, follow the links its a very interesting discussion. However I think it points to the future of ECM in totallity - componentized services which take their place in the wider SOA stack to enable an Enterprise Architecture. Oh yes and 'tenous link' is that fact that Laurences post mentions Oracles Universal Records Management.

Any way, moving on: as the industry has matured, the vendors realised the DM, ERM, DAM, WCM etc can all operate with a shared set of 'library services', check in /out , version control, metadata management etc

This led to the 'suite' approach from the big vendors, Documentum, OpenText, FileNet et al - then add on your workflow / BPM tools, throw in collaboration and you have the full on ECM suite that meets the ability to Create/Capture -> Manage -> Store -> Preserve -> Deliver as defined by AIIM. (add on Heirarchical Storage Management for 'Information Lifecycle Management' ? ! ). Hey it works for some people! Its certainly a good approach for my organisation, but then we are in a position to consolidate all (well most) of our content in a single enterprise repository.

As my intrepid fellow bloggers have noted, most organisations will never get to a single enterprise repository, and so federated records management is required. So to get where James and Laurence want ECM to be absolutely requires breaking down the monolithic suites into thier 'bits' and hey presto we are round full circle the previous conversation on standards, where vendors all play nice, and their products all interoperate via the said standards.

During our ECM procurement competition a few years ago, a small, niche vendor asked me why we did not appear interested in buying (a bunch of) 'best of breed' products and integrating them together ourselves. My answer was that it was too much hard work for us, that web services was not mature enough, that a big 'suite' was better for us. Even in a standards driven ECM 3.5 dreamland, not all customers will want to do the integration work, or pay for SI's / consultants to do it for them, and thus the vendors will always be able to make a buck from the suite, even whilst selling the seperate bits.