TSG recently worked with a client evaluating EMC’s Retention Policy Services (RPS) product. For those unfamiliar with RPS, RPS is used for automating content retention and disposition, while also allowing for holds that prevent disposition. Additional information can be found on the EMC website here: http://www.emc.com/products/detail/software2/retention-policy-services.htm
The client liked many of the features of the product and its user interface (which is very similar to Webtop). One of the appealing features is that RPS allows a clear separation of duties between roles of users along with multiple tools for managing retention with the WDK-based Retention Policy Services Administrator (RPSA). In this case, the end users are never aware that RPS is being used unless they try to delete a document that has a retention policy applied. For this client, a major concern focused on the RPS performance overhead of applying retention policies and mark ups to a multi-million document repository.
RPS was designed to be applied to many different types of document retention situations. To give RPS its flexibility, the product creates and maintains new RPS objects and audit trail events for each object under retention. Retention policies are applied to objects, and the policy denotes the length of time until the next action is invoked (culminating in disposition).
Typically a retention policy is applied to a folder where it can then be inherited without instantiating retainer objects to the documents in the folder. With this approach, if a folder had 100 objects or 3 objects there would only be one RPS retainer object. If a retention policy is applied at the document, or individual, level then there is a 1:1 ratio with the RPS retainer object. For the client, this implied that if we had one million document objects we would also have one million RPS retainer objects. This drastically increases the number of retainer objects and the overhead in the repository.
An Alternative Solution?
With a better understanding of the RPS performance impact to the repository, our client is determining how best to handle other RPS features that might need to be customized due to the large number of documents, as well as the restrictions placed on end users regarding deletion of their documents ahead of RPS schedule.
- For approval of disposition, when a document is ready to be approved, the user is sent a notification. Our client was worried about getting hundreds of notifications (and emails) on any given day. We were thinking of a way to do this more in a bulk mode where a user could approve large batches of documents all at once rather than hundreds of emails and inbox entries via a Webtop customization (the RPS Engineer was intrigued by this idea!)
- For postponing disposition, the client was looking at a way to not require end users to make use of markups (which normally can only be done by an administrative role within RPSA), but instead use Webtop to postpone disposition until a later date when they are prompted again.
- For deletion, documents in a specific folder are earmarked for disposition after a certain length of time. With this approach, If a user wants to delete a document sooner it is not an issue since the retention policy is geared more toward making sure unnecessary documents are deleted. Using an alternative approach resolves the restriction in RPS where only a user in the Retention Manager role has access to delete the document.
Implementing Alternatives for Document Retention
In working with clients evaluating RPS, some have decided to go with a simple custom solution instead of RPS for a combination of reasons including functionalty as well as licensing. Typically, this type of solution revolves around adding an additional attribute to the existing object type to denote the retention date, and running a job at set intervals that determined which objects need to be disposed of based on the attribute (and generated a list of these objects ahead of time for anyone to review).