Separating management from storage

I’ve recently been mulling over the nature of the relationship between where we store the information we create (the repository) and the rules governing its management – not least because it seems to represent one of the fundamental divides between the approach to records management which I am advocating (RM2.0 for shorthand) and the majority of ECM products on the market.

In the pre-Web 2.0 world there was a division between the applications we used to create information (e.g. MS Word) and the repository we used to store our outputs. We didn’t store our documents in Word, we stored them on our C://, on a separate file server, or even a removable storage device (though the MOD are beginning to wish they hadn’t!). All of which created a separate shared repository available for the storage of unstructured information created by a range of applications. This, in turn, influenced the nature of first EDRMS and latterly ECM technologies, the majority of which included their own separate repository for storage and intrinsically linked it to their management/rules layer.

As noted in Managing the Crowd: "The crucial difference with Web 2.0 services such as You Tube, Flickr, Facebook and the like is that they are content storage repositories as well. They no longer just represent the tools, but also the filing cabinet" which changes things considerably – especially when you consider that the majority of these services may be hosted outside the organisation. In this model there is no shared underpinning repository, nor is it possible to create and rely upon an intrinsic link between the management/rules layer and the repository of content we wish it to control. To my mind, this places those systems which are built upon the assumption of a combined repository and rules layer at a severe disadvantage by closing off the ability to manage information which it does not itself ‘physically’ hold.

One of the reasons for musing over this now was in the wake of an interesting chat I had the other day with some folks from Computer Associates marking the release of their new CA Records Manager product. In contrast to most other ECM products it apparently does not include its own integral repository – it’s a management layer only, managing content in its original native location. Though there are still currently limitations in terms of how widely this management layer can be applied (not yet extending to encompass the externally hosted Web2.0 services mentioned earlier) it seems to me to at least represent a more open-ended solution which at least offers the promise of achieving some of these wider, more demanding goals, further down the line.