The different approaches to getting MoReq 2 compatible EDRM systems to work with SharePoint 2007

A great many organisations have purchased SharePoint 2007 for a great many different reasons.  SharePoint on its own does not provide a convincing facility for organising records and applying retention rules to them.   As a result many records managers are considering whether or not to advise their organisations to procure a MoReq2 compatible EDRM system to manage the records produced within SharePoint.

 The case for procuring an EDRMS is neither cut and dried, nor easy to articulate:

  • if SharePoint 2007 has already been purchased then going out to tender for an EDRMS to integrate with it adds extra cost, time, and complexity to the SharePoint roll out
  • it is not obvious to colleagues how an EDRMS would work in tandem with SharePoint
  • it must seem galling for organisations who have already shelled out money on SharePoint 2007 to have to purchase an additional system, which duplicates so much of the functionality already present in SharePoint (including most of the document management functionality of metadata profiles, version control etc.)

I am hearing through the grapevine of organisations who have successfully  integrated an EDRMS with SharePoint, but what we as a profession need are publicly available case studies that we can discuss, question, evaluate and talk to colleagues about.  I have not heard any such case studies at recent conferences. The programme for the recent Records Management Society Conference in Brighton contained no case studies of organisations integrating SharePoint with EDRMS.  At the forthcoming Cimtech conference ‘The future of electronic information and records management in the public sector’ there will be no case studies from organisations who have plugged EDRMS behind SharePoint 2007 (though consultant Lorna Hermin from Kainos will discuss SharePoint and EDRMS).

There are three reasons why an organisation might want to plug in a MoReq2 compatible EDRM system  behind SharePoint team sites:

  • EDRMS systems can hold a hierarchical records classification (a fileplan),  and can allow you to link folders of documents to the fileplan so that they inherit appropriate retention and access rules.  Fileplans make a lousy user interface (few people enjoy navigating through a classification covering all the work of a large organisation).  But they are still the best way of organising and applying retention rules to records
  • EDRMS systems automatically allocate a unique identifier to a document the moment they are saved into the system: a function regrettably absent from SharePoint
  • EDRMS systems compatible with Moreq2 will protect documents designated as ‘records’ from deletion or further revision.  In SharePoint 2007 only the records centre does this (see this previous post for the weaknesses of the SharePoint records centre)

The fundamental challenge with having an EDRMS work behind SharePoint is this: how do you determine which documents get moved from SharePoint into the EDRMS?  

The options available to you are:

  • you could ask colleagues to declare documents to the EDRMS if and when they are needed as records
  • you could map SharePoint document libraries to the EDRMS fileplan, and get the EDRMS to automatically take across all documents placed in those libraries (or all documents within those libraries that meet criteria that you define)
  • you could disable document libraries in SharePoint, and replace them with web parts that lead directly into the EDRMS, so that colleagues collaborate on documents in the EDRMS rather than SharePoint
  • you could set up connectors between the EDRMS and SharePoint, to allow the EDRMS to access documents within SharePoint and to protect, classify and apply retention rules to them in situ, without moving the documents from SharePoint

Some vendors (for example Autonomy with Meridio; and Open Text with Livelink) are offering a combination of most or all of these different options. This means that organisations can use different approaches in different parts of their SharePoint site collections. However the variety and choice doesn’t help colleagues visualise how the EDRMS  will work with SharePoint.

Here are some comments on each of these four options:

Option 1 (asking colleagues to declare records to the EDRMS)

This option has the virtue that the records found within the fileplan in the EDRMS have been concsiously placed there. A human being has decided that a particular version of a particular document deserves to be treated as a record, and has chosen which folder in the fileplan it belongs to. The weakness of this options is that colleagues will often omit to take the step of declaring the document to the EDRMS.


Option 2 (mapping SharePoint document libraries to the fileplan in the EDRMS)

For this to work every time a new piece of work starts someone has to create a document library for it within a SharePoint team site and link the library to the fileplan in EDRMS. An organisation may wish to cement this into a workflow so that whenever someone sets up a document library they are prompted to consider whether it needs to be mapped to the fileplan and if so where within the fileplan it should be mapped to.

When a document is taken across to the EDRMS it is saved as a record and can no longer be amended or deleted. A link is left behind in the document library.

Criteria needs to be determined as to the basis on which the EDRMS takes documents from the designated document libraries in SharePoint.  The aim is to bring across documents that are worthy of being captured as records, but which colleagues will not need to revise further.

  • to reduce the risk of the EDRMS taking in, and locking down, documents that need further revision you could set the EDRMS up to bring across any documents within the document library that have not been changed for a designated time period (two/three or six months)
  • to reduce risk of EDRMS capturing documents that are not worthy of being treated as records you could adapt the approach that DEFRA took when using the SharePoint records centre. They ask colleagues when they save a document whether it is of high, medium or low importance and use the answer to filter the documents that they bring across to the records centre (they bring across only documents designated as high or medium importance)


Option 3 (replacing SharePoint document libraries with a web part that leads to the EDRMS)

In this model colleagues do all their work on documents within the EDRMS rather than within SharePoint.  The SharePoint team site provides collaborative features (discussions, news, blogs, wikis etc) and acts as the portal into the EDRMS.  

There is less administrative overhead in this model than in option 2, because there is no need to map SharePoint document libraries to the EDRMS fileplan, and no need for documents to move from one system to the other.  This model provides a greater degree of document control than either Option 1 or 2, because the EDRMS allocates a document a unique identifier when it is first saved, that the document keeps as colleagues work on it and revise it within the EDRMS.

The challenge for this model is making sure that you avoid forcing the user to navigate around a corporate fileplan to save their documents. There are two ways that this can be avoided:

  • by having the web part(s) in each team site point directly to the node(s) in the fileplan under which you want records of that team’s work to be saved
  • by programming the EDRMS to make suggestions as to which folder in the fileplan the document should be saved on the basis of the identity of the person saving the document, and the identity of the team site through which they are accessing the EDRMS


Option 4 (documents are left in their SharePoint document library, but they are controlled and managed by the EDRMS)

The advantage of this option is that it has the potential to be extended beyond SharePoint.  Once an EDRMS has the capability to access, protect, classify and control documents held in SharePoint team sites, then it can equally be set up to control documents held in legacy systems, shared drives, and line of business applications.  The EDRMS is set up to to access and control the document within the native application, and there is no need to move the document into the EDRMS.

In the medium and long term this is the direction in which I suspect EDRMS will head. It focuses EDRMS  on its unique selling proposition of the provision of back office information governance and control. I spoke to one vendor at the RMS conference who admitted to me that ECM vendors had ‘ceded the collaborative space’ to Microsoft and SharePoint. If that is the case then vendors should consider providing slimmed down versions of their products that omit the features that duplicate those offered by SharePoint. This way organisations won’t feel as thought they are paying for two similar and competing content management systems when they buy an EDRMS to work with SharePoint.

The challenge with this approach is that it is new and substantially untried and untested.  There is no word yet from authorative professional sources (such as the National Archives) on the practicalities and technicalities of this approach. This usage of an EDRMS is not covered in MoReq2 or in predecessor statements of functional requirements for electronic records management.  In theory this approach is great, but we need a professional debate about it. In particular I would like some discussion around the questions of:

  • what functionality do we need in an EDRMS to enable us to be confident that it can access and control records held in another system?
  • how can we be confident that any particular product possesses that functionality?  The scope of MoReq 2 does not include the use of EDRMS to control records housed in other systems, and hence it will also be beyond the scope of the MoReq2 testing regime
  • what features to we need in line of business and legacy systems in order to ensure that it can provide an EDRMS with access to the records that it holds?
  • how much customisation and configuration is required each time the EDRMS is set up to access and control records in a new system?
  • what are the implications for colleagues of this approach: when someone starts a piece of work, in SharePoint or in a line of business system, what would they need to do in order to make sure that the information outputs of that work are recognised and protected by the EDRMS?

One thought on “The different approaches to getting MoReq 2 compatible EDRM systems to work with SharePoint 2007

  1. At Wiltshire Council we are going through this at the moment. We have been deploying both a corporate EDRMS and SharePoint together but not yet linked. Our plan is to integrate both into a single platform and use the power of the EDRMS to manage both content and metadata through a webpart and disable the SharePoint library. It’s early days though.

Leave a 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 )

Google+ photo

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

Connecting to %s