Someone pointed me at Lee Smith’s blog about Records management. He discusses that it is strange that there are separate products for Records Management. I totally agree with that perspective.
Lee writes: /QUOTE
Firstly I always wondered why Documentum needed a product specifically for Records Management, surely most, if not all, requirements of a Records Management installation could be achieved through out-of-the-box functionality, with some minor customisations/configurations.
So if we use the 4 policy objects we can pretty much deliver a solution which is compliant to the main standards for Records Management and it does not have to look much different to a standard Documentum app. A quick description of each of these:
– Naming Policies. These allow you to put rules around what the users can call their objects in the repository. Looks quite neat but some of the user interface used to create the policies is pretty poor, e.g. you have to type in the attribute name if you wish to create a construct value (why is there no dropdown??). In fact there is no reason why this should not be a standard part of Documentum, I know it would help a number of customers;
– Containment Policies. These allow you to set rules on how the repository is structured including number of levels and what can be put it in what container. Again, looks nice. Could be improved for the end user interface, e.g. if I have said folders should only go down 7 levels why let a user initiate the creation of a folder and then give them an error message, stop it at source! Again though, why not part of the core product?
– Retention Policies. Now of the 4 this is the one which is available on its own and is probably the most important and richest of the lot. I’ll post about this on its own as it really merits this.
– Security Policies. At first glance these look quite neat, enabling you to apply policies to folders based on object types. However they are not designed to work if you take control of the acl of your volition, for obvious reasons. So imagine a scenario where a document is in a lifecycle, yet also has a Security Policy applied. When the document reaches a state in the lifecycle which requires that it is available to a wider audience you lose the benefits of Security Policies. It would be great if policies could be applied based on more than just Object Type and Folder, at the end of the day these are just attributes anyway….increasing the number of attributes which have influence will make things much richer and yet keep some of the nice administration available in Security Policies.
My perspective is the following: If a content management system was designed correctly from the ground up then it has three core features:
1. Freely definable object types and relationships (provides naming and containment definitions)
2. Storage class definitions (provides the retentions policy and also where something is kept and if it has to be digitally signed or encrypted for example)
3. Role/policy security (defines who is allowed to do what with any object type)
There you go: That is your Records Management System.
The main reasons that Documentum are selling those functions additionally are sales reasons and second that all their functions and processes are hardcoded and can thus only be expanded by programming which makes even more revenue for Documentum. All that is very understandable from a technical and business viewpoint and not to be booed at.
But the problem comes later when REcords Management is suddenly no longer a standalone application but has to interact and interface with everything else. Suddenly you will be in deep programming mud.
With the ISIS Papyrus Platform things are quite different. Point 1, 2, and 3 are standard functions of the ISIS Papyrus Platform and used for ECM, BPM and CRM processes. Therefore Papyrus can be used as a fully functional Records Management System without the need for buying additional software or expensive customization. Furthermore, Records Management is suddenly deeply imbedded into ALL Inbound and Outbound document processes without additional effort.
That kind of consolidation is the future.