• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar
  • Skip to footer
TSB Alfresco Cobrand White tagline

Technology Services Group

  • Home
  • Products
    • Alfresco Enterprise Viewer
    • OpenContent Search
    • OpenContent Case
    • OpenContent Forms
    • OpenMigrate
    • OpenContent Web Services
    • OpenCapture
    • OpenOverlay
  • Solutions
    • Alfresco Content Accelerator for Claims Management
      • Claims Demo Series
    • Alfresco Content Accelerator for Policy & Procedure Management
      • Compliance Demo Series
    • OpenContent Accounts Payable
    • OpenContent Contract Management
    • OpenContent Batch Records
    • OpenContent Government
    • OpenContent Corporate Forms
    • OpenContent Construction Management
    • OpenContent Digital Archive
    • OpenContent Human Resources
    • OpenContent Patient Records
  • Platforms
    • Alfresco Consulting
      • Alfresco Case Study – Canadian Museum of Human Rights
      • Alfresco Case Study – New York Philharmonic
      • Alfresco Case Study – New York Property Insurance Underwriting Association
      • Alfresco Case Study – American Society for Clinical Pathology
      • Alfresco Case Study – American Association of Insurance Services
      • Alfresco Case Study – United Cerebral Palsy
    • HBase
    • DynamoDB
    • OpenText & Documentum Consulting
      • Upgrades – A Well Documented Approach
      • Life Science Solutions
        • Life Sciences Project Sampling
    • Veeva Consulting
    • Ephesoft
    • Workshare
  • Case Studies
    • White Papers
    • 11 Billion Document Migration
    • Learning Zone
    • Digital Asset Collection – Canadian Museum of Human Rights
    • Digital Archive and Retrieval – ASCP
    • Digital Archives – New York Philharmonic
    • Insurance Claim Processing – New York Property Insurance
    • Policy Forms Management with Machine Learning – AAIS
    • Liferay and Alfresco Portal – United Cerebral Palsy of Greater Chicago
  • About
    • Contact Us
  • Blog

Documentum D2 4.0 – Risk Mitigation Strategy

You are here: Home / Documentum / D2 / Documentum D2 4.0 – Risk Mitigation Strategy

August 21, 2012

We had a good discussion with a client last week that is looking to implement D2 4.0 out of the box for an extranet application.  Given a new product and an end of year deadline for implementation, we discussed steps to take to mitigate the risk of D2 4.0 (or any product).  This post will touch on those thoughts and share best practices mostly focused on a “try it before you buy it” approach.

Try it before you buy it – User Requirements and System Capabilities

Core to our approach for mitigating risk of any project is a small “Phase 0” or “Sprint” focused on understanding the business requirements and how well they match the capabilities of the system.  For a D2 implementation, a key risk will be that D2 is a “configuration only” application.  While this approach could be beneficial for clients looking to reduce customizations, we get concerned that, for certain requirements, the D2 system may not be able to be configured to meet the requirements.

As we pointed out in our D2 limitations post, Power Promoting – the ability to move a document from Draft directly to Approved – is something that is not provided by D2.  If the business has that requirement, users should understand that it is not possible and should look for alternatives within the D2 capabilities.

We would recommend a risk mitigation plan that focuses on a small prototype of D2 with a core group of requirements as the initial Phase 0 activity.  In this manner, the risk that D2 cannot meet requirements can be addressed at the beginning of the project.

Try it before you buy it – System Stability

One valid concern about X.0 releases is stability of the new release, given the specifics of a client’s environment.  Back in 2005, we had two clients looking to develop Documentum systems.  One client chose the 5.2.5 platform for stability; the other went with the new at the time 5.3 SP0 release.  While the number of stability issues associated with 5.3 SP0 cost the client and put some of the project at risk, the 5.2.5 client had to pay for another eventual upgrade to 5.3 at significantly greater cost and effort.

At this point, we would not recommend clients consider D2 3.1 to avoid the cost of a later upgrade.  Given the newness for D2 4.0, we would recommend a risk mitigation plan with a phase 1 (after the phase 0 POC for requirements) that focuses on stability testing.   Given the number of differences with D2 from existing Documentum infrastructures (Interface, Lifecycle, Security, Watermarks….), successful clients will be the ones that learn about issues associated with stability before attempting to release and later finding these issues in production.

Try it before you buy it  – System Performance

One of the items that Documentum clients typically avoid is a performance test with appropriate volume of users and documents.  While the system can perform well with small amounts of documents and a couple of users, performance issues can arise when production volume users attempt to access the system concurrently from a variety of geographic locations.

One difficult issue to address when trying to catch this type of problem before system deployment is the ability to set up a realistic performance test.  While there are tools on the market, given the variety of users and activities, it is often very difficult (and expensive) to set up a realistic test to mitigate the risk without large costs without reducing the risk.  The effort and possible lack of results (still get performance problems in production) is the reason many clients skip a large performance test.  To avoid the cost and expense of attempting a full-blown performance test, TSG tries to mitigate the risk in a number of different ways.

  1. Migration and Production Volume – typically we will recommend clients do a production load into the new system to be able to test the Documentum Content Server with full volume of documents.  This testing is not as involved as multi-user testing and can help with performance tuning of the docbase.
  2. Pilot Versus full-production Rollout – rather than a big-bang approach to production rollout, we recommend small groups of users along with their content to be gradually rolled into the system.  In this manner performance issues might come up over time rather than a big-bang approach filled with lots of complaints from lots of users for performance and other issues including training, bugs and volume.
  3. SWAT team once in production – given that it is very difficult to catch performance issues in development, one risk mitigation strategy would be to allocate resources from the development team to be able to quickly address performance issues if they arise in production.

Try it before you buy – Support

With any new product, support can be an issue.  While users will uncover issues, a bigger concern is that the support engineers are new to the product as well.  A successful risk mitigation strategy might be to test the support capabilities of Documentum with D2 as issues turn up in the Phase 0 or Phase 1 testing before moving to later implementation phases.

Summary

Successful risk mitigation strategies with D2 4.0 focus on having an understanding of how the software capabilities, performance and support will work in production before the application goes into production.  We have suggested some of our standard approaches in this post.  If you have other thoughts, please add below.

Filed Under: D2, Documentum, Testing / Validation

Reader Interactions

Comments

  1. Paras says

    August 21, 2012 at 6:10 pm

    Great article – but *I ask with a little bit of sarcasm* how do you get your customers to pay for all these mitigations and still deliver the project within 3 months and true to the business case?

    e.g. Great tips on the mitigating the Performance Issues – we also recommend the same approach to our customers but many times the issue we face is that the customers want to onboard a small group of users from – each region/BU – which can be challenging due to other constratins in the solution or the business e.g. if a Contrats Management solution is limited to one Department then senior management does not get full visiblity of all contracts from the new solution.

    Is it easier & overall cheaper to just have an oversized platform instead?

    Reply
    • TSG Dave says

      August 22, 2012 at 6:16 am

      Paras,

      I would typically say that the mitigations vary in price based on the risk. We recommend the Phase 0 regardless of the size of the project for all the risks associated with user acceptance and requirements matching up to the new tool. Some of the mitigations wouldn’t be needed for .1 releases but, given the rewrite for D2 4.0, we think they are all important.

      For a 3 month implementation, all mitigation efforts around perfromance and stability could be in parallel to the development effort.

      Oversized platform wouldn’t mitigation user acceptance/requirements or stability so still think worth doing those.

      Thanks as always for your thoughts,

      Dave

      Reply
      • Paras says

        August 22, 2012 at 7:12 am

        But (generally speaking) performance is heavily influenced by the customisation/configuration which can take some time to be defined and built – before it can be performance tested.

        Are you anticipating this challenge? I guess D2’s configuration only model might have some benefits here.

        Reply
        • TSG Dave says

          August 23, 2012 at 9:57 am

          Paras,

          I agree that changes affect performance but see volume as a bigger driver than customization. Expensive queries like folder and repeating attributes will work great in small volumes but completely bog down with more documents. Typically having experienced Documentum developers understand the expensive stuff can help do the parallel performance testing before all customization/configuration is complete.

          While D2’s configuration only model might eliminate the ability to customize, it is important to remember that many times customizations are done to improve performance (more efficient query – ex: begins with rather than contains).

          My two cents,

          Dave

          Reply

Trackbacks

  1. Documentum D2 4.0 – Initial TSG Review « TSG Blog says:
    October 11, 2012 at 1:53 pm

    […] you would like more information please visit the Learning Zone (D2Demonstration), review our D2 Risk Mitigation Strategy post and our D2 white paper located in our downloads section. Share […]

    Reply
  2. Documentum to Alfresco Migration – Maturity of the platforms « TSG Blog says:
    October 26, 2012 at 12:25 pm

    […] In regards to interfaces, clients should consider the relatively risk of new releases and new products.  Documentum has recently released D2 4.0 .  While we applaud Documentum’s effort to offer new interfaces, we cautioned clients to review the tool as any other new product as mentioned in this post. […]

    Reply

Leave a Reply Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Primary Sidebar

Search

Related Posts

  • Documentum or Alfresco Interface – Ready for an Upgrade?
  • ECM Large Repositories – Volume Testing With the TSG Test Harness
  • Documentum – Getting more out of Documentum D2
  • Documentum purchased by OpenText – 4 ways to reduce the risk of an unknown OpenText future
  • Documentum D2 vs. HPI – Administration
  • Documentum D2 vs. HPI – Working with Multiple Documents
  • Documentum D2 vs. HPI – Document Annotations
  • Documentum D2 vs. HPI – A Closer Look at Search
  • EMC World 2016 – Momentum – Recap – #MTMM2016
  • EMC World 2016 – Day 2 – ECD Roadmap and Vision

Recent Posts

  • Alfresco Content Accelerator and Alfresco Enterprise Viewer – Improving User Collaboration Efficiency
  • Alfresco Content Accelerator – Document Notification Distribution Lists
  • Alfresco Webinar – Productivity Anywhere: How modern claim and policy document processing can help the new work-from-home normal succeed
  • Alfresco – Viewing Annotations on Versions
  • Alfresco Content Accelerator – Collaboration Enhancements
stacks-of-paper

11 BILLION DOCUMENT
BENCHMARK
OVERVIEW

Learn how TSG was able to leverage DynamoDB, S3, ElasticSearch & AWS to successfully migrate 11 Billion documents.

Download White Paper

Footer

Search

Contact

22 West Washington St
5th Floor
Chicago, IL 60602

inquiry@tsgrp.com

312.372.7777

Copyright © 2022 · Technology Services Group, Inc. · Log in

This website uses cookies to improve your experience. Please accept this site's cookies, but you can opt-out if you wish. Privacy Policy ACCEPT | Cookie settings
Privacy & Cookies Policy

Privacy Overview

This website uses cookies to improve your experience while you navigate through the website. Out of these cookies, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may have an effect on your browsing experience.
Necessary
Always Enabled
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Non-necessary
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.
SAVE & ACCEPT