Documentum Business Continuity – A Cached Content Approach

One of the more successful applications we see long-term Documentum customers implement successfully is a business continuity solution based on caching approved content to a separate “read-only” repositories.  This post will discuss the reasons for business continuity solutions and integration options for Documentum as well as business continuity war-stories from selective clients.

Defining Business Continuity

In regards to business continuity for Documentum or other document management systems, the key component needs to focus on answering the question:

“What documents (ex: manufacturing, operating…) would the business need access to, should the primary content management system become unavailable?”

Developing a cost effective business continuity solution requires an understanding the parts of the business that can have some flexibility in regards to system availability.  Typically clients will say that, given delays in typical approval cycles, document authoring and approval are not critical and could be postponed in the case of a short-term system outage. 

For most of our customers, 24 hour access can be described as:

“I need access to the latest approved documents for view and printing at all times.  I need to make sure that obsolete documents are not available when no longer current”. 

Business Continuity is more than just a mirroring

Unfortunately, Business Continuity is an easy buzzword for a hardware or software sales representative to use in regards to selling their solution.  Typically paired with “How much is it worth to insure that your business isn’t interrupted for X hours” to justify the price tag for a variety of hardware and software products.    Most of these solutions involve some type of mirroring of data between redundant servers or storage products.  Keep in mind that we are defining mirroring somewhat different than replication in that it is at the drive/disk level.  Replication is more at the application/server software level.

In helping to evaluate business continuity solutions, we wanted to share some of our war stories from different Documentum clients for reference where mirroring storage didn’t address the business continuity solution.  For ECM customers, how does your current business continuity solution address these issues?

1. Unix Admin Error – A Unix Admin (not TSG) accidentally deleted a directory that included multiple storage areas for Documentum.  The business continuity solution real-time “mirrored” the deletion onto the redundant storage area, deleting that one as well.  The Client needed over 5 days to completely recover.
2. Water – Another client had their server room in the basement in a newly updated building.  During a rain storm, water leaked down an A/C vent onto the server shorting out some key components.  The client used their staging server for parts during the first downtime.  Unfortunately, the client didn’t or forgot to either move the server or fix the leak.  During the next rainstorm, you guessed it, server was drenched again.  Replacements parts were ordered for both staging and production with the system down waiting for the parts.
3. Database – Too many clients have suffered from a database issue – table space, corruption… that has left them down working on a fix.  It is important to remember that mirroring solutions will not address this fairly common ECM continuity issue as the bad data will be mirrored to the other system.
4. Server Access – Through either power outages/surges, weather or data connectivity (we have seen router configuration issues), sometimes access to the server can be interrupted either at the data center or from the end-user location.  Mirrored solutions that rely on connectivity between the servers or are in the same data center would not be protected from this interruption.
5. Upgrades and Migrations – Typically, upgrades will require Documentum to be down for some time while the server is upgraded or content moved to a new instance.   This relates to the mirrored storage solution as well.

Caching for Consumers – a smarter approach for business continuity

Based on the above scenarios, many customers have chosen not to have a completely redundant infrastructure for Documentum authors but have instead developed a solution focused on caching content outside of Documentum for consumers of approved documents.  This is almost a light version of a fully replicated solution.  The solution involves pushing the content out to a read-only “cache” once the document is approved.  It also involves updating content (attribute changes, obsolete…) when approved documents are changed.  The approach has several benefits for business continuity including:

• Redundant, but cheap, servers – the cache is typically some type of index/database as well as the PDF rendition of the content.  The index database doesn’t have to be as full-featured as Documentum with clients typically choosing either MySQL or Lucene and Solr (for full-text searching as well as attributes).
• Location – servers can be placed outside of the data center where it best benefits the user.  This would include potentially placing servers overseas to reduce the data transmission as well as the risk of the transmission being interrupted.
• Multiple Servers – read-only servers can be placed around the network to provide for redundancy.

Other benefits for this solution include:

• Performance – with consumers performing expensive searches outside of Documentum, authors will not find their performance of everyday activities impeded by consumer searches.  With a smaller, more nimble infrastructure on the cache, we have seen performance dramatically improve for consumer search and retrieval.
• License costs – depending on licensing arrangements, groups or external parties that just need access to approved documents won’t require licenses to Documentum just like they wouldn’t for approved documents published to the web.
• Upgrade and Integration – With multiple clients, we see difficulties in performing a Documentum upgrade due to the amount of other systems that rely on Documentum for content.  By integrating other systems to the cache repository rather than Documentum, the upgrade is greatly simplified.
• Content Control – typical solutions will only cache PDF renditions rather than original documents offering both better control of the authoring documents as well as reducing costs of distributing authoring applications for view only consumers.

Caching More than Documentum – Enterprise Search versus a  “Push” approach

 Once clients have established a successful cache, many have started to look at other ECM tools that can leverage the cache for approved content such as SharePoint.  This is a substantially different approach than typical system integration or enterprise search efforts where a “crawler” looks to index content from different repositories and the search would attempt to retrieve the content from the repositories.  For this approach, content is “harvested” or synched from different systems into one main retrieval system.  The benefits of the approach for enterprise search initiatives include:

• Security – Enterprise search can be very difficult to coordinate security across multiple secured systems and repositories.  A “push” approach allows the pushing application to only push out those documents that can be seen by a wider audience when the content is ready.
• Performance – Systems owners can be rightly concerned that a “crawler” will be accessing their content throughout the day.  The push allows the system owners to schedule publish times with reduced overhead in regards to performance.
• Business Continuity – as mentioned throughout, with content in multiple locations, systems can be down or unavailable but content is still available.

TSG Product Offerings

Given the number of clients that have implemented these types of solutions, TSG offers several open source products that can give clients a jump start to this type of solution.  All have been validated as part of our life-sciences practice.

• OpenMigrate – Provides for the real-time push/synch between Documentum and the external cache.  A small footprint component can be configured to monitor (not crawl) the Docbase looking for new approved content to push to the cache or to delete content from the cache if obsolete.  OpenMigrate can be configured for either a light database or other cached repository.  OpenMigrate has had considerable success with a Lucene Solr approach cached repository for both attribute and full-text search requirements.  See a comparison of OpenMigrate to Site Caching Services in this post.
• High Performance Interface (HPI) – Provides for a configurable and efficient search and retrieval interface (whitepaper search comparison available here).   Based on OpenContent, our web services interface, HPI can execute searches against either Documentum or a variety of cached repositories.
• OpenOverlay – Provides for real-time watermarking of the documents (based on open source iText solution) with date/time and potentially user information.

If you have any additional thoughts or other approaches, please add your comments below.