The DLM forum is having its triennial conference in Brussels this coming December. I responded to the call for speakers with the following submission:
MoReq2010 can be seen as an attempt to ensure that the records management baby is not chucked out with the EDRMS bathwater.
The EDRM idea was solidly based in records management theory, but lost its market viability after 2008 thanks to the global economic downturn, the rise of SharePoint, and perceived problems with usability and user acceptability of EDRM systems and their attendant corporate fileplans.
SharePoint 2007 and 2010 both offer records management features, but neither offers a well-thought through records management model. Most organisations with SharePoint implementations have not attempted to use records management features such as the SharePoint records centre. Of those that are trying to use those features only a relatively small number will be able to impose sufficient governance to enable them to viably manage records in SharePoint.
For most organisations SharePoint will be a records management problem rather than a records management solution. In a few years time more organisations will be saying ‘we need help managing the records that are scattered around our SharePoint implementation’ than will be saying ‘thanks to SharePoint content types we can now apply retention rules to records across our organisation’.
MoReq2010 doesn’t kill off the EDRM model (you can use a MoReq2010 compliant system as an EDRM provided it complies with the plug-in modules for a user interface and a hierarchical classification), but it does not attempt to revive it either.
The fact that MoReq2010 is offering two alternative to EDRM, rather than just one, whilst continuing to support the EDRM model itself, indicates that the profession is not yet ready to commit its weight behind one single approach. It also means that we are in a transition period, during which many records managers and consultants will be uncertain as to what approach to advise their organisations to take.
The two new approaches offered by MoReq2010 are ways of dealing with the ‘multiple repository problem’ – the fact that every organisation deploys numerous different applications to create, capture and store content and records. EDRM systems rarely tackled that problem. They typically relied on colleagues voluntarily declaring material into the EDRM as records, and there was rarely any incentive for colleagues to move documents out of a line of business application into an EDRM.
The back-end repository approach
The first of the two approaches is what I would call the back-end repository approach (I would like to call it repository-as-a-service but I fear you may mistake it for a cloud offering). In this approach a MoReq2010 compliant system governs content captured in the multiple different applications of the organisation. It governs either by taking that content out of those applications and storing it in the MoReq2010 compliant system, or by protecting and governing that content whilst it stays within those applications themselves.
This is an approach that vendors have been working on over the past five years – both EDRM/ECM vendors looking for ways to continue selling to customers who have chosen SharePoint instead of an EDRM, and e-mail archiving vendors looking to expand the scope of their archiving systems. It is also compatible with service orientated architecture of IT departments, but no-one knows yet how it will play with moves to the cloud. MoReq2010 for the first time offers a certification regime for vendors taking this approach, giving the approach more gravitas and credibility, and offering buyers reassurance that their back end repository/archive will not in itself become a black hole from which it is hard to migrate records.
The back-end repository approach significantly changes the role of the records manager. In EDRM implementations the records manager was interacting with users, training them, cajoling them, tackling change management challenges, and designing classifications that end-users would directly interact with In the back-end repository model the records manager has a different role – connecting legacy applications to the back end repository, and trying to ensure that no new application is deployed into the organisation unless it hooks into the back-end repository from day one. The interaction with, and impact on, end-users will inevitably be reduced, but it is to be hoped it won’t be eliminated entirely. It will still be important for end-users to be aware of whether or not a piece of content that they have contributed to a particular application has been captured by the back-end repository.
The in-application approach
The second of the two approaches is the addition of records management functionality to each application deployed in the organisation so that these applications can manage their own records.
This is the approach that I sense the authors of MoReq2010 would like to see prevail in the world. They are well aware that every time a record moves from system to system it loses context, and that ideally records management metadata would be captured from the moment a record was first captured into an application.
This approach is beyond the capabilities of any single organisation – no organisation could customise all their applications for them to become MoReq2010 compliant. It becomes viable only when the vendors of line of business systems, make their products MoReq2010 compliant – whether they be sector specific applications like social care systems for local authorities, or line of business applications like HR systems. Its a battle worth taking on for the profession, and worth fighting, but success is likely to be patchy. The hope is that a tipping point could be reached when everybody expected every application to be MoReq2010 compliant, and felt that something is wrong if it was not compliant.