Friday, September 28, 2007
Enterprise Architecture: ECM and Compliance Oriented Architectures
I wonder if folks in the ECM world have ever read about Compliance Oriented Architectures as written by James Governor of Redmonk?
Both Laurence Hart and Jesse Wilkins said something in their blog that got me thinking about the importance of disposition and how it too can become a service. While the original discussion was all about IDARS, Alchemy and Documentum, I came to the conclusion that retention is not only something that should be part of an ECM platform and not a separate SKU but that this too needs to move away from the ECM-oriented insular thinking and migrate to be service-oriented.
Of course, I am of the belief that Enterprise Architects at Morgan Stanley in terms of their records management initiative are more than likely focused on productecture and consumed by features instead of architecture and thinking about how disposition fits within a larger context, but I will of course allow folks from that enterprise to chime in and provide their own perspective to readers in the blogosphere.
Let's consider the scenario where I am an Enterprise Architect for State Farm and I have three different platforms. I have a policy administration system, a claims administration system and my wonderful proprietary closed source ECM platform with horrific WSDL. From a retention perspective, I may want to have a retention policy for my policy administration system that says keep all insurance policies for cat insurance for two years after policy expiration unless they are in the state of Wisconsin and know how to bark which we want to keep them for four years after policy expiration.
Likewise, I may want to have a policy for my claims administration system that says to keep all claims information related to cat insurance for nine years or until the cat runs out of nine lives. Of course the claims administration system may not want the policy administration system to remove its information especially if the claim is still active.
From an ECM perspective, one could envision that the policy administration system stored pictures of cats, their favorite toys and the application they filled out prior to getting the policy which may have included their favorite food and whether they like catnip. It may even store audio of cats who know how to bark. One could also envision that the claim administration system also leverages the ECM platform and would store pictures of the cat being chased up the tree by Clifford and Blue.
If you think of this business scenario, you may conclude:
| | View blog reactionsBoth Laurence Hart and Jesse Wilkins said something in their blog that got me thinking about the importance of disposition and how it too can become a service. While the original discussion was all about IDARS, Alchemy and Documentum, I came to the conclusion that retention is not only something that should be part of an ECM platform and not a separate SKU but that this too needs to move away from the ECM-oriented insular thinking and migrate to be service-oriented.
Of course, I am of the belief that Enterprise Architects at Morgan Stanley in terms of their records management initiative are more than likely focused on productecture and consumed by features instead of architecture and thinking about how disposition fits within a larger context, but I will of course allow folks from that enterprise to chime in and provide their own perspective to readers in the blogosphere.
Let's consider the scenario where I am an Enterprise Architect for State Farm and I have three different platforms. I have a policy administration system, a claims administration system and my wonderful proprietary closed source ECM platform with horrific WSDL. From a retention perspective, I may want to have a retention policy for my policy administration system that says keep all insurance policies for cat insurance for two years after policy expiration unless they are in the state of Wisconsin and know how to bark which we want to keep them for four years after policy expiration.
Likewise, I may want to have a policy for my claims administration system that says to keep all claims information related to cat insurance for nine years or until the cat runs out of nine lives. Of course the claims administration system may not want the policy administration system to remove its information especially if the claim is still active.
From an ECM perspective, one could envision that the policy administration system stored pictures of cats, their favorite toys and the application they filled out prior to getting the policy which may have included their favorite food and whether they like catnip. It may even store audio of cats who know how to bark. One could also envision that the claim administration system also leverages the ECM platform and would store pictures of the cat being chased up the tree by Clifford and Blue.
If you think of this business scenario, you may conclude:
- ECM is not an insular domain and should participate in a larger context
- While the notion of retention has been built into ECM, it really is a larger problem
- ECM platforms should consider the fact that retention rules should not be proprietary but ideally described in an open, portable way as other systems may also need to consume them
- To get retention right, ECM platforms may not only need to expose retention functionality, but the platforms themselves may need to consume other services to get it 100% correct
- Retention is not about ACL++ but more about business rules. Maybe this is an an opportunity to incorporate algorithms such as RETE into ECM
- If you look at the horrific WSDL being created by ECM vendors, this couldn't be accomplished as the interfaces don't account for this business scenario
- Documentum, Alfresco, Nuxeo, Stellent, Filenet, OpenText and others are way too insular and need to start thinking more about how folks outside the ECM domain may use their products.
