Classification EDRMS and ECM Open Source Records Management Software

The future of EDRMS: change is ours for the taking

In my previous post I dealt with a fundamental difference between records management and the Web 2.0 environment – namely hierarchical classification vs tagging. I posited that EDRMS providers will have to take this, as well as other Web 2.0 functionality, into consideration when building their systems for the future. Steve Bailey has prompted this post’s structure by asking a number of questions in the comments field of that post. Let’s look at them in turn:

1. Are EDRM vendors able to adapt their product sufficiently to move in this direction? It would need a substantial revision of the basic architecture underpinning most systems and it will be a brave vendor to move beyond what the testing regimes say is mandatory in such a radical way.

The ability to tag documents does not stop records managers from using a classification system – in fact, a hierarchical classification is still essential for maintaining a retention schedule without which we’d require a fundamental paradigm shift. What needs better management from records managers and software developers is the automatic classification of documents into the hierarchy to relieve the burden of classification from the user. The vast majority of documents – perhaps 95% – ought to be easily classified based on the user (their position, access rights and which groups or teams they belong to) and the document (the date, format and the content all of which can assist in it’s classification).

The facility to automatically classify documents is not new. Autonomy was doing it in 1999, the Alfresco EDRMS claims to be able to do it creditably, and Paul Dodgson spoke at a recent RMS Local Government Group meeting of having had a 100% success rate whilst piloting this at his local authority.

The basic problem of revising the underlying architecture is not at issue, but perhaps you’re right about the ability of vendors to adapt. I’ll tackle this chestnut under question three, but let’s take a look at the records managers…

2. Will records managers be willing and able to be flexible in how they approach the management of such resources. It may well be that the kind of detailed micro-management we are used to and aspire to is not possible. Records management may need to operate in a very different way in order to be effective.

In an automatic classification environment, records managers will need the retention and business classification knowledge they’ve been trained to use like never before. They’ll also need to continue to negotiate with and monitor system users to ensure information is being effectively captured in the right areas. EDRMS developers will need to work with records managers to ensure the system is simple to manage.

Whether records managers are capable of this challenge, I leave over to you, reader, what is your perspective on this? Feel free to use the commenting forum below to air your views.

3. Will users be willing to leave behind their favoured web 2.0 application/service provider and adopt the official, authorised version? The rate of development by small, agile web 2.0 houses will always exceed what the organisation can deliver so there will be an inevitable sense of the organisation’s offerings always playing catch up and looking slightly ‘old hat’. Unless the organisation is also going to open up its tools for use by their staff in their domestic lives it is also likely that staff will lose some of the familiarity with technologies that they are using in both their domestic and work lives (i.e. Flickr).

Small, agile Web 2.0 houses almost always have one thing in common. Their dependence on open source software to ride the wave of changes. After doing the research their operating systems and servers are invariably based on Linux and Apache notes VentureCake and SourceWire confirms leading Web 2.0 sites such as YouTube, Flickr, Technorati, Facebook, FeedBurner, Wikipedia, Digg, LiveJournal, PhotoBucket,, all use MySQL – the fast and scalable open source database – to power their content management systems. Even this blog you are reading is run on a Linux machine with an Apache server and a MySQL database underlying the WordPress content management system/blogging software all of which is open-source. It’s a content management system that’s missing the records management component.

How are we to learn from this? If our public authority has perhaps one to thirty IT developers to work on an EDRMS they’re always going to be playing catch up attempting to incorporate the latest technology into their systems. But what if all the developers across central and local government departments, universities, NHS Trusts, Police and Fire departments banded together and worked on developing an EDRMS system under the leadership of JISC or TNA using the open source business model? It wouldn’t be long at all before a secure, scalable and rapid system with sufficient options was built that could cater to staff tastes for all that web 2.0 schnazz.

With the Council of Information Officers considering the directive to have EDRMS in use in all government departments to have been a ??500,000,000 failure there’s nothing to lose. If they want to stay in the pockets of the ‘failure is in our interests’ proprietary vendors, EDRMS will continue to be seen as ‘old hat’. When they start thinking inside the mainstream Web 2.0 box, EDRMS implementations have the potential to become popular, funky systems that incidentally ensure the integrity of documents.

6 replies on “The future of EDRMS: change is ours for the taking”

This is a good article. I work at an Archives Institution. We are replacing the application that tracks the physical location of archival material, space management and accessioning(data entry). I’ve been asked to see if software from a Tower, OpenSoft (and similar Records Management companies) could handle tracking, space management and data entry.

Has anyone seen any articles about where records management succeeds/falls short when used to to archives management work?

If anyone has any comments (who is not part of one of these record management software companies, I’d be delighted to hear from them.)


Having seen the “enterprise level” Hummingbird R/KYV EDRMS, it may be easier than you think. That monstrosity stores documents in the file system, with all workflowing being scripted in files called 1.scr, 2.scr etc which have to be edited manually, and with the clunkiest web interface ever seen. Please rid the world (and some of my working life) of utter, utter rubbish like that trainwreck.

I’ve experience Hummingbird, and it was riddled with bugs – however – I’ve come to the realisation that most EDRMS implementations fall short because of a purist and heavy handed approach from the central records management authority within the organisation. I agree with one of the comments above, in that we should question the micro management approach to all documents created or received by business users. Most people will get used to a new piece of kit, but it is often the configuration and governance choices which stick in people’s throats and actually create further problems.

I’d be deeply suspicious of anybody claiming “100% success rate whilst piloting this at his local authority.” Ask around at the said local authority and they will be less than complementary about the process, project or software implemented – ‘Wisdom’ was perfect Orwellian double speak for the whole thing!
The inside track …

Good post!

My great concern is that the EDRMS train has already left the station. The train cost a fortune to build. You and Steve Bailey are making very sound sense but you are also trying to stop a fast moving train, that we all know is going to crash.

I am about to embark on this journey to implement Hyperwave as a solution for our Local Authority EDRMS. Guidance sort on best approaches to file structures and nice to haves now and later.

I agree with comments on costs and failure to meets users requirements.

Leave a Reply

Your email address will not be published. Required fields are marked *