The next big step in electronic records management

The author was leader of a project funded by the European Commission for the DLM Forum, which produces MoReq2. He explains the uses, advantages and weaknesses of this ERM advance.

By Marc Fresko

All businesses, and organisations, rely on electronic records. The plunge in the price of computer systems and the growth of e-mail have seen to that. Yet the effective management of electronic records remains difficult, a paradox that puts us in an awkward situation.
The new ‘MoReq2’ specification is a significant step to removing that difficulty, by defining how to manage electronic records well. Any organisation can now use MoReq2 to ease the path to exerting effective governance over its electronic records, with all the evident advantages of compliance and efficiency that this brings.

What kinds of e-records?
Some will point out we have been managing electronic records successfully, and without fuss, for several decades – governments, banks, insurers and many others have held their records about us for as long as computers have been sold to them.
For this reason, we need to be clear that both the challenge of electronic records management (ERM) and MoReq2 principally arises with so-called “unstructured” records. That means records in which the content is relatively unstructured and is intended for human consumption, such as text documents, images, audio and video. E-mail messages are a good example of records with such “unstructured” content. Although they feature some structure, their content is mainly intended to be interpreted by humans and they are notoriously difficult to manage.
By contrast, the records kept by government bodies or financial institutions about their clients are mostly highly structured in the form of entries in databases intended mainly for processing by computer programs. These highly structured records are relatively easy to manage. So, while MoReq2 addresses any kind of electronic record, it adds value mainly when dealing with unstructured records.

Is e-record management new?
The history of ERM is usually traced back to the aftermath the First Gulf War, in the early 1990s. For it was after that war – the first major war to be fought with a heavy reliance on computers, and thus the first to create large volumes of uniquely electronic records – that the US Department of Defense realised that its records of that war were an electronic mess, poorly organised and documented.
Its reaction to this problem was to commission a standard specification of requirements, now known as US DoD 5015.2. This is widely regarded as the first standard specification of requirements for ERM; though in fact it is only the first long-lived, and widely-accepted, specification, for work in Canada had resulted in a comparable outcome seven years earlier (the FOREMOST standard).
US DoD 5015.2 was first published in 1997. It described in unambiguous language the functional requirements for the effective management of electronic records, as needed by the US defence establishment; its requirements were rooted firmly in, and extensively cross-referenced to, a range of American federal laws, federal regulations, military standards and the like. It was clearly intended specifically for the management of defence-related records in the USA.
Despite this limited intent, and perhaps because it was for a time the only specification available, its use spread beyond the military into civil government and beyond. It led directly to the generation of early ERM software systems, which it insists on calling “Records Management Applications” rather than ERM systems, as if to underline its American focus.
A key point, however, is that it catalysed both the software industry and the user community to move in the direction of compliance with its requirements – a pattern that has since been repeated elsewhere. As well as catalysing the development of ERM software, US DoD 5015.2 also caused other countries to develop their own specifications.
The year 1999 saw publication of a comparable specification by the UK’s Public Record Office (now The National Archives), and in quick succession we saw other, very similar specifications emerge from Germany, South Africa, Australia, New Zealand and elsewhere. All these specifications were attempts to define the requirements for ERM systems, but all shared one key limitation: they were built on the specific requirements of public sector organisations in one country, and so were strictly limited in their applicability.
This mould was broken in 2001 by the publication of MoReq, the first – and so far the only – specification that addresses the requirements of all sectors, public and private alike, and the first that is international in scope.

First international standard
MoReq – Model Requirements for the Management of Electronic Records – was conceived by a European body, the DLM Forum , and was funded by the European Commission. It was developed by a team based in the UK and advised by experts in records management drawn from eight countries. It was intended for use in any sector throughout Europe, being based entirely on international standards and best practice, with no country-specific features; in practice, it has been used much more widely.
An illustration of its success is that it has been translated independently (that is, translated without support from the European Commission) into at least 11 languages. It remains an accepted specification that is used around the world. MoReq2 was published in February 2008.
MoReq2 builds on MoReq in an evolutionary way, taking into account the experiences gained from using MoReq since 2001. It includes many advances in technology that have arisen since then. Importantly, MoReq2 was not simply developed by a well-meaning group of consultants isolated in a closed room; it was developed with input from a wide range of stakeholders drawn from dozens of countries.
In all, over 200 system vendors, users, records managers, academic experts, trade organisations, professional organisations and others agreed to form volunteer review panels for the MoReq2 drafts – and this was in addition to the input from an editorial board constituted of experts, and reviews by DLM Forum members from all over Europe.
This unusually wide range of inputs made for a difficult development process that took slightly over a year, but also for a high-quality result which caters for almost all possible requirements in this field.

MoReq2 compliance
It is already clear that MoReq2 is heading for the same level of international recognition as MoReq. The leading vendors of ERM systems are all engaged in exercises to move their offerings towards MoReq2 compliance, and users are already beginning to use MoReq2 to specify requirements as they procure systems. And several translations are already under way; the first draft of one translation (Russian) is already complete.
All translations will be posted on the project website, http://www.moreq2.eu,as soon as they are released. This all points to the strong likelihood of a new era in ERM systems, one in which MoReq2-compliant software is available.
MoReq2 was developed explicitly to allow compliance testing. It has been delivered complete with a testing framework – essentially a set of detailed test data, test scripts and expected results, all presented in a format compliant with international software testing standards – that will allow software to be tested for compliance.
This testing framework was developed in parallel with the requirements specification, the testing process feeding back comments to the requirements drafting, thus ensuring that the language used is precise, incidentally making it clearer than many other specifications.
The DLM Forum is currently working out the testing regime for MoReq2 compliance testing – no mean feat when a single regime for testing across the 27 member states of the European Union is required. The current plans see the testing regime being in place by the end of 2008 – hopefully just in time for testing the first claims of MoReq2 compliance. The DLM Forum is also preparing a governance framework to ensure that translations of MoReq2 are accurate, that local extensions remain consistent with it, and that the name is not misused.
The final component to be delivered by the MoReq2 project is the MoReq2 XML schema. This will specify a format for the transfer of electronic records, between ERM systems, or between an ERM system and an archive. A draft has already been published for comment and the final schema will be ready later in 2008.
At the time of writing, MoReq2 is available in electronic form only, from the MoReq2 project website. The European Commission is preparing a paper version, which will be published in time for the next major DLM Forum conference in December 2008. The testing framework and XML schema are also available at this site, as are other supporting resources.

Uses of MoReq2
Who will use MoReq2?
MoReq2 will be valuable for several communities.

Users and potential users of ERM systems form the majority of users. MoReq2 is most useful as the basis for a specification to be used during procurement. It is essential to customise it – see below;
Vendors of ERM systems are using it to guide their product development;
Educators are using MoReq2 to help to train the next generation of records managers and archivists in universities and colleges;
Project teams can use parts of MoReq2, such as the introductory chapters and some of the appendices, to familiarise project team members and project sponsors with the concepts of ERM.

MoReq2 for procurement
By definition, MoReq2 covers all sorts of requirements for all sorts of environments. Consequently, it contains many requirements that will be inapplicable to any given situation. An example might be the use of sub-files, which is entirely optional. When preparing a specification for procurement, you should decide whether or not you will use sub-files, and customise the specification accordingly. This will allow you, as the procurement progresses, to see exactly how the products you shortlist perform the functions you need. If you do not customise the specification in this way, you will not have this benefit – and also you will simply defer the decision-making to later in the project, at a point where there is not usually time to consider the decisions properly.
You also need to customise the model specification by inserting details of your technical requirements. For example, you need to specify the operating system(s) and associated system software, and any legacy systems – these are usually straightforward. Some technical details are less obvious, such as your requirements for file format(s) for long term preservation.
In the same vein, many of the non-functional requirements need to be customised to reflect your needs. MoReq2 provides an extensive framework for the specification of performance and usability requirements, but without providing the metrics. So, for example, it shows how response times should be specified, while leaving the actual response times, volumes of data and numbers of users to be inserted during customisation. Collection of credible metrics can in some settings take a surprisingly long time, and it is best to start this task early.
Finally, any additional requirements can be added, taking care of course to maintain compatibility with the content of the rest of the specification.
Once the customisation has been completed, it is good practice to publish the changes only for the procurement – this avoids publishing an unduly long specification. This approach will be especially relevant once products that are certified as MoReq2-compliant become available.

Limitations of MoReq2
For all its virtues, MoReq2 has some limitations that need to be borne in mind. The obvious, and thankfully temporary, limitation is that there are no MoReq2-compliant products available today, let alone products that are certified to be compliant. This should change later in 2008 as compliant offerings start to reach the market.
First, it is intended for the specification of a software product, not for how the software is implemented or used. Many might want to use it to test, or certify, a specific implementation of software, to validate that an organisation is applying good practice in its records management.
While it may be possible to use MoReq2 in this way, that is not the reason for which it was designed. But more importantly, the fact that an ERM product is certified as complying with MoReq2 does not mean that it will meet your record-keeping needs. All that certification means is that the product is capable of meeting the requirements for good records management in the tested configuration.
Your implementation of a package would differ from the configuration tested for certification purposes in many ways – system software versions, the combination of modules implemented, the settings of the configuration parameters, the interfaces, and so on; so a certification will tell you that the package is likely to manage records well in your environment, without being able to provide any guarantees.

Best practice
The MoReq2 specification defines “best practice” for ERM software. It defines what software has to be able to do in order to qualify as a good, generic, electronic records management package. Inevitably, this means that MoReq2 represents a superset of possible requirements – it includes (for example) everything a large complex company might need to manage its unstructured electronic records, while allowing for these to be omitted if the software is used in a smaller, simpler, setting.
In keeping with this philosophy, MoReq2 is highly modular – more than any earlier specification. The “core module” defines the requirements that are considered essential for the good management of records. Unlike many other specifications, this includes practical requirements for administration, for usability, for interfacing and for other non-functional features.
Interestingly, it also includes mandatory requirements for integration with both an e mail application and scanning or imaging sub-systems. This conscious decision has led to some debate: are e-mail and scanning interfaces truly essential for the good management of electronic records? Clearly we believe that they are, in almost all real-life settings that will rely on electronic records management. But, to be fair, if you don’t care about e-mail or scanned images, then you can still manage other requirements and these requirements will not be relevant.
MoReq2 also includes no less than 13 optional modules, dealing with features as varied as the management of physical records, national security markings, and content management system integration. These features, and those in the other 10 modules, will be essential for some users but of no interest to others, which is why they are packaged in individual optional modules.
Software suppliers seeking MoReq2 compliance certification will need to demonstrate their software complies with all the mandatory requirements of the core module. They will be at liberty to choose any combination of optional modules to be tested, and the certification will specify which optional modules have been tested. This will allow users to choose products that have the combination of features they require for their environment.

Evolution not revolution
And there is more, of course – this is just a sample. It is not possible to describe here all the innovations and improvements that MoReq2 is bringing to the world of electronic records management. But despite all these novelties, the overall picture is one of evolution, not revolution.
MoReq2 will result in vendors producing software systems that are consistent with, and compatible with, the well understood and universally accepted principles of records management. It does not introduce radical thoughts such as “virtual folders” or non-hierarchical classification schemes. MoReq2 simply adds the new requirements into the framework of existing records management philosophy. However, MoReq2 does not prohibit radical ideas either – so vendors are entirely free to introduce them in addition to the traditional techniques required for MoReq2 compliance. Now, there’s a thought...

Marc Fresko is a director at Serco Consulting. He led the project that developed MoReq2, and before that the MoReq project. He is responsible for Serco Consulting’s Information Management consultancy, and can be contacted at marc.fresko@serco.com.