Monday, 21 July 2008

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.


Adam Pope said...

Have you heard of REST, Steve? It's an information architecture based on URLs and the verbs GET POST PUT and DELETE. And that's all. It's benefit is it's simplicity as it will be able to move with the times. There's a good post here that explains it easily. It's recommended by the guy who wrote HTTP and what Alfresco is based on. Theory suggests it could refer to the contents of a network drive as easily as a Facebook image.

Pedants who call people using minor grammatical errors 'pretentious' - have they any sense of introspection?

Steve Bailey said...

No, I hadn't come across REST but will look now with interest - I'm all for simplicity where possible (particularly given the speed and agility which normally comes with it).

As for the pedants - the phrase 'fiddling whilst Rome burns' sprung immediately to mind!



Anonymous said...

Some of the big ECM players have been doing this for a while now. They have a management layer which is separate from the content. This management layer and content layer could all the vendors own - more akin to an EDRMS.
The more prevalent approach with larger companies is for an integration with systems to manage their content. In this case SAP / Siebel / Sharepoint (and EDRMS) content is controlled by this management layer.
The EDRMS simply becomes a front end for the less structured processes. The more structured processes would probably have a dedicated front end.
Web 2.0 will be next on the cards. The only way this will work is to manage the original content, to take a copy and manage it or to manage the link to the original.