How MoReq 2010 differs from previous electronic records management (ERM) system specifications

On 5 April this year I sat on a panel at the UK Information and Records Management Society (IRMS) conference. We were each asked for our view of the future of technology. We talked about the cloud, and also of the end of the dominance of ‘the document’ as a format. One member of the audience brought us back down to earth with the comment ‘never mind the future, we don’t know how to manage records in all the many and various systems our organisations have now’.

Ed Fowler of Cap Gemini said that organisations will need to get used to the fact that their records will be created and stored in many different content repositories, and that few if any of these repositories will have records management functionality.  Ed said records managers should abandon any hope that they could specify and implement one corporate electronic document and records management system (EDRMS) and expect all their colleagues to save their records into it. Recently he had only seen one UK organisation tendering for an EDRMS.

Ed was announcing the death of the traditional EDRMS. I would add a caveat here – information systems don’t die, they just lose momentum. EDRMS has lost momentum but most of those organisations that have succeeded in implementing them corporate-wide have felt a benefit and will continue to maintain and develop their systems.

The loss of momentum in EDRM is nowhere better illustrated than with MoReq, the European Union’s specification of electronic records management (ERM) systems. In early summer 2008 MoReq 2 was launched, only to be scuppered by two tornadoes: the global economic downturn, and the rise of Microsoft’s SharePoint (which took the collaboration space out of the reach of EDRMS vendors). By the end of the following year, 2009, only one vendor had submitted a system for testing against the specification, and the decision was taken by its sponsors, the DLM Forum, to commission a radical rewrite to the MoReq specification. The rewritten specification, called MoReq 2010, will be launched at the next meeting of the DLM Forum, in Budapest, next week.

The previous day (April 4) of the IRMS conference had seen a debate between Jon Garde (author of the new MoReq 2010), and Marc Fresko (author of its predecessor, MoReq 2).

Jon Garde introduced MoReq 2010 by arguing that we needed to revisualise the ERM system.  Previous specifications saw an ERM systems as a stand alone content repository that stood alongside the other content repositories within the organisation. MoReq 2010 sees ERM as a capability that could be embodied within each separate application that the organisation uses, or that could sit behind those applications and manage records created within them.

Marc Fresko was critical of MoReq 2010. In his view it introduced too many new concepts too quickly and the timeframe for the publication of the specification has left too little time for debate.

The fact that Jon and Marc differ so sharply in their viewpoints shows how different MoReq 2010 is from previous versions of MoReq.

Previous versions of MoReq aimed to specify systems that could serve all the records management needs of any organisation, in any sector. They created the breed of information system called the EDRMS. The idea was that an EDRM system would be rolled out to all users, and would hold within it a hierarchical classification (called a business classification or fileplan) that covered all the work of the organisation. Users would capture and store documents and e-mails needed as records into the EDRMS, within files (folders) classified against the business classification/fileplan.

The traditional EDRMS could not on its own solve the problem of multiple repositories. In organisations some functions (types of work) are more important than others. The more important functions will usually have a line of business application procured or developed specifically for them. An EDRMS, because it aims to cover all the diverse activities of an organisation, by definition cannot be tailored to any one type of work.  This means even those organisations with corporate-wide EDRM systems still get the problem of managing records in multiple repositories. Once SharePoint came along this problem was made even worse – if an organisation is putting a lot of time and effort implementing SharePoint for collaboration they will probably not have the capacity to implement a corporate EDRMS in tandem with it, however much they recognise the problems of SharePoint sprawl and the weaknesses of SharePoint’s own records management model.

MoReq 2010 has been written to encourage different models of records management system to emerge. It does this by adopting a modular structure. All MoReq 2010 compliant systems have to comply with a core set of requirements. Beyond that there are different modules which vendors can chose whether or not to submit their product for testing against. Some vendors may well decide to submit traditional EDRM-style systems for certification. But they are also able to submit systems for testing that meet a completely different model, for example:

  • Systems that end-users do not interact with directly, but instead capture and store records that users had created in other systems
  • Systems that do not store records, but instead govern and protect records held in other systems
  • Line of business systems or single purpose applications that are not intended to be a general records system but which have have the ability to manage the records that they capture
  • Systems that can fulfill two or more of those roles – for example a system that could be deployed as a traditional EDRM that some end-users would interact with directly, but which also possessed the capability to manage records held in other content repositories

The old aspirations that MoReq 2010 abandons

MoReq 2010 is a major change from all previous specifications of electronic records management systems. It is a break not just with the previous two versions of MoReq issued by the European Union (MoReq and MoReq 2) but also with the UK’s TNA 2002 standard and the US DoD 5015.2 standard.

MoReq 2010 abandons three big aspirations that all those previous specifications shared. It abandons:

  • the idea of the ‘file’ in the electronic records management system being the ERM system equivalent of the traditional hard copy file MoReq 2010 replaces the concept of the ‘file’ with the new concept of an ‘aggregation’ This is a major break with the vocabulary of the hard copy era. In a MoReq 2 compliant system a ‘file’ was limited to two levels of hierarchy beneath it (file/sub-file/parts). In a Moreq 2010 compliant system an aggregation can have any number of levels of hierarchy. The MoReq 2010 ‘aggregation’ has a different relationship to a business classification/fileplan than a MoReq 2 ‘file’. The MoReq 2 file sat at the very bottom of the business classification/fileplan. An aggregation can be a multilevel hierarchy in its own right, so it can sit separate from the business classification, whose role is not so much to act as the only means of navigating around the records system, but more to apply retention rules to records.
  • the idea of one monolithic corporate business classification/fileplan universally applying retention and access rules to all records In previous versions of MoReq only one classification could be linked to retention rules and used to apply retention rules to records (a hierarchical corporate business classification, also called a fileplan). In Moreq 2010 compliant systems there is the possibility of having several classifications, any number of which can be used to apply retention rules to records. If a record is classified against more than one classification then one of them should be nominated as the ‘primary classification’ for that record. The primary classification is the one that the record inherits its retention rule from.
  • the idea of their being a single type of ERM system that can meet the needs of all organisations in all sectors Jon Garde identified that MoReq 2 was twice as long as the first MoReq. Jon says the reason for this is that both MoReq and MoReq 2 tried to specify systems that could meet the records management needs of all organisations, whatever their sector. This meant that if any sector of the economy could prove they had a genuine records keeping requirement then MoReq would try to incorporate it into the specification. The disadvantage of this is that vendors had to configure their systems to cover all sectors and all eventualities, which pushed up the cost for them of developing compliant systems. MoReq 2010 has been written so that the core module contains only requirements that are common to all or most organisations. If a sector has specific requirements they are able to write a separate MoReq 2010 module to capture those needs. Vendors that wished to target that sector could add that functionality to their system and ask for it to be tested and certified against that module. Vendors that didn’t wish to target that sector could ignore it. Jon Garde argues that the MoReq 2010 will be more sustainable over time than previous specifications, as new needs can be incorporated into new modules without having to republish the whole specification. Marc Fresko gave the counter argument that the structure of MoReq 2010 will be more complex for records managers in organisations to work with, because they are going to have to decide which modules are important enough for their organisation to insist upon.

The new aspirations of MoReq 2010

In place of those abandoned aspirations MoReq 2010 brings in three new aspirations:

  • the idea that the electronic records management system will sit behind the existing applications used to create and capture records in the organisation A system can be MoReq 2010 compliant without having any user interface. The core module merely insists that if a system does not have a user interface it must have an API (application programming interface) to enable it to integrate with those systems in the organisation that users do interact with to create records. Note that integrating an electronic records management system behind existing content repositories poses very different challenges to those posed by implementing a stand alone EDRMS that end-users directly engage with to save their records. It is likely that your various content repositories will have been procured from various vendors, written in various programming languages, and have varying quality APIs. Each integration to each content repository is a project in its own right. Aside from the technical challenge there is also the semantic challenge – each of those content repositories will have their own way of organising and describing content.
  • the idea of MoReq compliant systems controlling records held in other systems a system can be MoReq 2010 compliant without having the ability to store records, provided it has the ability to apply classifications, access rules, and retention rules to records stored in other systems; provided it can protect those records from deletion or amendment; and provided it can maintain (and export) an audit trail of events that happen to those records.
  • the idea that when an organisation changes its records system the new records system could understand everything that had happened to those records in the outgoing records system. Record systems capture records and apply retention rules to them. Jon Garde points out that the span of years of many of these retention periods is longer than the life of most records systems. Jon wants a MoReq 2010 compliant system to be able to export a record and its associated metadata at any point during the retention period, so that the receiving system could understand what retention policy has been applied to the record, when that retention period started, and how long it had left to run. The new records system could then apply the remainder of the retention period. MoReq 2010 is much stricter than previous specifications on how a system maintains its audit logs. The system must be able to export an event history for every object in the system.  The event history must record everything that has happened to that object since it was created in or captured by the system. In order for this event history to be understandable by another system MoReq 2010 insists upon the use of unique identifiers. A MoReq compliant system needs to allocate unique identification numbers to every type of object (records, aggregations, retention policies, classification headings etc.); to every actual object; to every type of event in the system (for example ‘the title of a document is changed), and to every actual event.
  • the idea of line of business system vendors incorporating records management functionality into their systems By stripping down the core requirements to a very minimum the DLM-forum hope that providers of line of business systems will see that it is possible for them to seek MoReq 2010 certification.  The hope/dream is that providers of finance systems, human resource management systems, facilities management systems, and customer relationship management systems will add MoReq 2010 functionality to their applications . Note that vendors of those kinds of applications won’t start to think about MoReq 2010 compliance unless and until purchasing organisations start specifying a preference for MoReq 2010 compatible applications. The challenge here is that records managers often do not have a voice in those kind of procurement exercises.

The likely impact of MoReq 2010

MoReq 2010 will bring interesting effects for records managers. The standards we were used to in the first decade of the 21st century (TNA 2002, DoD 50.15, MoReq 2) all ended up certifying a very similar type of system, implemented in a very similar way. Not quite ‘seen one EDRMS seen them all’ but almost.

Out of MoReq 2010 will sprout a variety of different applications, which will need a variety of different implementation methodologies. This is a challenge for the wider records community, not the sponsors of MoReq 2010. All MoReq 2010 can do is to encourage vendors to provide applications that manage records created and/or held in different content repositories (and provide certification to verify that they have that capability).

Whether or not MoReq 2010 ends up being successful will ultimately depend on whether we records managers can come up with viable implementation approaches for the type of application that it will certify.

5 thoughts on “How MoReq 2010 differs from previous electronic records management (ERM) system specifications

  1. Hi James Thanks for this. I was sorry I couldn’t get to the Conference this year, we just don’t have a budget for such things at the moment and not likely to for a number of years. So thanks for posting this summary of a very important debate.

    I, like many others, need to think very carefully about the implications of this, particularly when authorities are procuring new systems. I have been lucky here in Dorset County Council to get a high enough profile to make sure that our EDRM has been included in the procurement specifications for a number of our newer core business information systems, as well as continuing to deploy it as a means of managing our unstructured data.

    I don’t see the imminent death of EDRM, just new approaches to use them. After all for those in the public sector who have invested in such technology that underpins core systems and that gives us tangible benefits, the thought of abandoning it for something else is not a realistic one. However EDRM should be seen as only one tool in our information management tool set and surely the future for the profession is to embrace the wider information management agenda and strategy to use it to underpin the efficiency drive taking place across the Public Sector.

  2. Hi James,

    I am a member of the MoReq 2010 project team. I have to admit that my contribution is relatively small and that the bulk of the work has been undertaken by Jon Garde (as author) and Richard Blake (who has contributed enormously to the review).

    The public comments last year have also made a huge contribution, much of the delay has been caused by the need to take on board the 600+ contributions that were received.

    I would not see MoReq 2010 as signalling the death of EDRM but the transformation of electronic records management into a key service supporting the business. MoReq 2010 itself adopts the idea of records management functionality as a number of different services.

    The core modules of MoReq 2010 will be formally launched at the DLM Forum Meeting in Budapest next week. I would urge anyone with an interest in the functionality of records management systems to consider joining the DLM Forum.

    MoReq 2010 is designed to be extended and control of the development of MoReq 2010 is run by the DLM Forum’s – MoReq Governance Board. Like any organisation primarily run on the contributions of volunteers it seeks new members who are prepared to contribute.

    The next six months will see the development of test scripts and the establishment of a testing regime. There will also be further new modules.

    One exciting area for MoReq 2010 is the possibility of industry-specific modules addressing requirements of specific sectors. The DLM Forum will be actively seeking contributions from organisations who are interested in developing such requirements.

    The next few years are likely to be exciting times for electronic records management. I am a firm believer that with issues such as security and compliance and with the volume of information growing across a growing range of devices that records management will become more challenging and the contribution records managers with the right skills can make will be increasingly important.

  3. MoReq 2010 certainly seems to be a significant development in our field and plaudits are due to those associated with its development. It is not, however, strictly true to say that MoReq 2010 is a major change from all previous ERM systems specifications.

    I would like to draw your attention to some 2008 specifications issues by the International Council on Archives that appear to be not so well known by colleagues in Europe. The ICA specifications were developed between 2006 and 2008 by a multinational team of experts (including people like Richard Blake and Hans Hofman). Called “Principles and Functional Requirements for Records in Electronic Office Environments”, or ICA-Req for short, the specs were issued in three separate but inter-related modules.

    Module 1 is a high-level overview document that sets the scene and articulates first principles. Module 2 is a set of globally harmonised specs for EDRMS systems. Module 3 is a set of requirements and implementation advice for managing records in business systems.

    Module 3 was the new and exciting work forged by the ICA team, while modules 1 and 2 were really just a harmonisation of received wisdom. Module 3 recognises that digital recordkeeping does not have to be limited to the EDRMS paradigm – the insight that has now been picked up by MoReq 2010.

    I commend ICA-Req to people as a globally-endorsed set of flexible requirements. Early this year all three modules were endorsed by the International Standards Organisation as ISO 16175, parts 1-3. I have an article on the project appearing in the forthcoming issue of the Canadian journal Archivaria (issue #71).

    ICA-Req is available to ICA members via the ICA website. As the project was co-sponsored by the Australasian Digital Recordkeeping Initiative (ADRI), they are also available to the world on the ADRI website at:

    Australia and New Zealand are now leading a second ICA/ADRI-sponsored project to develop detailed implementation guidance and training material for ICA-Req, particularly for use in low-resource environments. These new products will be launched at the ICA Congress in Brisbane, Australia in August 2012 – with exposure drafts to be released on the ICA website in late 2011.

    Adrian Cunningham

  4. A South African records process perspective!

    Firstly, the people involved in putting together the MoReq 2010 document must be commended for their efforts and obvious passion in what they do, not that I am forgetting about the folks who originally developed the MoReq spec.

    I must be quite honest that 520 pages is daunting and I am not sure I have the energy to go through the document and give it the justice that it deserves.

    Be that as it may, what I would like to put the table is that even though records managers face an ever incredibly difficult task, that at the end of the day they cannot address multiple system(s) issues unless they address the problems at a process level. Many of these problems are because businesses continue to go out and buy system after system that they think are a panacea for all their EDRM issues. The only way to understand the problem is to understand the process and then try and fit it to the system(s).

    in addition, no matter whether a record is one item or format or an aggregation, you can only have one record (in a business context) just like you can only have one original – is a printed pdf of a signed purchase order the record, is the scanned copy of the hardcopy the record or is the transaction in an ERP the record? How many records or copies of the record do we want to manage? Simplistically I only have one birth certificate or passport or drivers licence – why would a business want multiple copies of a record or aggregation of a record?

    Turning to the new MoReq 2010 I am not so convinced that line of business system vendors will incorporate electronic records management functionality into their systems – what is the benefit imperative to them? Just as is what is the bottom line benefit to a business forcing a vendor to be MoReq 2010 complaint? What was the benefit in the original MoReq 2 and if there was such how many BS vendors requested certification?

    I fear that the world-wide community of records and information management practitioners is creating standards that are slowly becoming a rocket science monster that is going to destroy us.

    If I was to want to implement a records management “system” today where would I start – ISO15489; ISO/TR 15801; ICA-Req; GARP; SEDONA; et al! There is just too much to comprehend and I would strongly advocate a call to go back to basics.

    Only once you have mastered the basics can you start looking at all the problems of aggregation, compound records, multiple business systems and EDRMS and EDMS and ECM and, not forgetting the 800lb gorilla in the room, SharePoint!

    Finally, what I have promised myself, despite feelings of suicide may be a serious option, is that I intend over the next 6 months fighting my way through every single page of the 520 in MoReq 2010 with the hope that I can understand exactly what it is and what it is trying to achieve.

Leave a Reply to Vaughan Spooner Cancel reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s