James McGovern, in responding to my previous post, brought up an interesting problem that I’d run across before, but hadn’t paid much attention to at the time. Not because we didn’t see the importance of the problem, but because we were several stages away from being able to even worry about it. When you don’t even have policies, getting into the nitty-gritty about implementing them across multiple systems from one control is not first on your list of concerns.
The Basic Problem
In my wonderful dream world for ECM, I have all my content stored in my ECM platform. It is accessed by a combination of Content Applications and other Enterprise Applications. All of these applications have data of their own about the context of the document.
In the insurance industry, a picture of a diamond earring is nice, but without the policy, and any potential claim, it loses its meaning. In fact, if one is eliminated, then the other is either incomplete or meaningless. So the same retention policy(s) needs to be defined for both the content and the data residing in the other system.
The problem…Where do I define the policy? Do I trust the Application to track it and just have it apply the proper controls through “standard” (bear with me on this) ECM approaches? When the Application purges a record, it cascades it down to the content. Do I have the policies implemented in the ECM system? What if the content has different retention policies from the base account?
Enter Compliance Oriented Architecture?
Welcome to marketing hell. This is a problem, but we don’t necessarily need a new fancy name for it. It should be quite simple. You define your policies in one place. These policies are then enforced in the different systems. Doing this within ECM systems is well defined and understood. How about everywhere else?
Well, Bex Huff (one of my favorite bloggers out there), posted on how Oracle, through the acquisition of Stellent, already had this capability a couple of years ago. Using the Oracle Records Management Agents, you can manage records where they are, all from Oracle’s Universal Records Management. Now I couldn’t find information on their Records Agents, but the description seems to fit the Federated Records Management approach.
There are other approaches to managing some of that application data as a record, which the legal guys might like. However, I’m with Bex that it is not the target solution. I am sure that there are cases though where that is the best approach, for now. After all, people need RM now and can’t always wait for the technology to catch up.
2 thoughts on “Retention Across the Enterprise”
I think you, Jesse and James are basically laying out the future of a componentised / SOA’d ECM world – keep up the ‘visioneering’
This one of my favorite topics; here’s some food for thought. When you are considering a federated approach to policy management you need to differentiate between “immutability and disposition” policies and a more generalized compliance policy federation. I think that federating immutability- and disposition-based policies is possible because they can be generized fairly easily. Try expanding this to say redaction or watermarking across different applications. Some are a little easier to imagine generalized and implemented across systems – basic access control, enhanced auditing, for example.
I’d agree that federated just the policies may give you all you need rather than trying to federate the functionality but it seems just as troublesome to implement sometimes!
Comments are closed.