"Show notes" for this episode…

Episode 001 - Assumptions & Architecture

Synopsis

In the first podcast of the series James and Jon discuss the underlying assumptions behind the development of MoReq2010 and why it is different to other records management standards. They go on to explore the impact these assumptions have had on the overall structure of the specification.

Featuring

James Lappin and Jon Garde

When recorded

August 2011

Running time

70 minutes

Main topics

MoReq2010’s publication as an extensible living specification
ISO 15489’s focus on a single organisation
How to integrate records from different organisations together
Is classification really applied universally in organisations?
Are these false dichotomies?

Structured versus unstructured records
Line-of-business systems versus generic EDRM/ECM systems

Where Microsoft Sharepoint sits in the sphere of records systems
Configurability can be problematic to managing records
The compliance reporting option of MoReq2010
The underlying assumptions of MoReq2010 were different to other international and national specifications
MoReq2010 is not predicated on having a single place in an organisation to store records
With centralised management of records the system must have the one true copy – other copies should be deleted
Decentralised management means that every system has to be a records management system
Within the ideal organisation there are no business systems that do not have a records management layer within them
The end goal is records management as infrastructure as natural as TCP/IP on the Internet
Achieving this means taking a minimalist view of records management
The core services (chapters 2 through 12) are pure records management
It is hard to write a specification so that it cannot be interpreted differently by different developers making their individual solutions incompatible with one another
When we stop attempting to accumulate records centrally we need to ensure that we can access our decentralised records in the future
Expensive migrations are good for consultants but run contrary to fundamental principles of records management
MoReq2010 is highly prescriptive around basic functions so that disparate System A and System B can not just read each other's metadata but also understand and interpret it correctly
The MoReq2010 XML schema differs from other schemas, such as MoReq2 by strictly defining what values can appear in which tags and what they mean
Existing systems face a challenge implementing some of the more prescriptive parts of MoReq2010
MoReq2010 has introduced “model” core services in the area of roles (privileges) and contextual metadata to help existing systems convert
An existing system can achieve compliance with MoReq2010 by implementing model services in their own way according to their own internal functionality so long as they can be mapped to the standard XML schema
While it is essential that traditional suppliers come on board with MoReq2010 the team is looking to much broader adoption than just traditional ECM products
MoReq now stands for “Modular Requirements” not “Model Requirements” reflecting the high degree of modularity introduced into the specification
Consumers can buy MoReq2010 compliant records systems by specifying from a checklist which module they want
Future products may not be complete records systems but may be individual services that can be reused by many different records systems
The small developer may benefit from having specialised services that are available for reuse by other suppliers

Latest news

MoReq2010 is published and can be found at http://moreq2010.eu/ with additional information, commentary and news at http://www.dlmforum.eu/
The XML Schema for MoReq2010 is also now available at these same websites this is the BETA schema until it has been proven in the field
The DLM Forum executive committee has restructured the MoReq Governance Board to introduce a technical panel made up of suppliers who will help to define the specification going forward
Additional panels coming from the restructure include a practitioner’s panel; accreditation, testing and certification panel; and additional project panels
Looking forward to the remainder of 2011 we will see:

Extension modules
Test scripts and materials
Accreditation of test centres
The start of testing of supplier’s products

From the postbag

When I download MoReq2010 from the web why is it called “Volume 1”?
Why is the specification entitled “Core services and plug-in modules”?
What is a plug-in module?
The purpose of a plug-in module is to provide an alternative way of implementing replacement functionality
What is the difference between an extension module and a plug-in module?
The purpose of extension modules is to: