Documentum Webtop Customizations – What should you do next?

Webtop Customizations are a consistent source of concern for internal IT.  Concerns range from level of development effort to upgrade cost and long-term support.  Specific concerns include:

• Business changes and customizations must be redone when Webtop versions change
• Internal resource staffing and the need to retain Documentum programmers
• Documentum support for new releases

This post will address our thoughts on what clients are doing to either mitigate concerns in regards to customizing Documentum Webtop or applying lessons learned to future efforts.

Webtop Lessons Learned – Balancing Customizations with User Acceptance

IT divisions have issues about any Webtop customizations due to cost and support concerns.  We often hear the following rationale against customization from our IT clients:

• We added Webtop customizations in Documentum 5.1
• Those customizations wouldn’t upgrade to 5.2.5 (or 5.3 or 6.0….) so we had to redo them again and again
• We should stop adding Webtop customizations (or look for alternatives to Documentum that don’t require customizations)

As a best practice, we try to help IT balance these costs and concerns with the benefits (and reduced costs) of high user acceptance.  User acceptance is the reason all companies add customizations.  Most users can easily identify Webtop changes that would improve their experience and business process.  These changes include:

• Easier retrieval
• Quicker and more accurate indexing
• Enforced conformance to business rules
• Accuracy in applying business rules

At the end of the day, it is IT’s challenge to decide when/where/how to customize and how best to apply business funds to balance user acceptance with long-term support concerns.

Strict Out of the Box Equals Poor User Acceptance

User acceptance is dramatically impacted by how responsive IT is to understanding users needs for more than just out of the box.  Over and over we hear users say that Documentum is cumbersome and we just need something easy.  For example:

• Search – “So I have to select the document_type frzom this huge list and then build a query by picking an attribute from another list, and then choose the operation (equal, not equal, less, greater…) and then type in a value for department?  Then in looking at the search I should select view rendition?   I have to do this every day and only want to search on one document_type and a small set of values and view PDF’s – can you just configure it so I can skip some of these steps?”
• Author – “So I have to navigate to the right cabinet, select create, pick the right document type, store the document as version 0.1, and remember to update the attribute data for every document I store?  I am concerned that documents will be stored incorrectly in the wrong folder.  Can we do something to eliminate some of these choices?”
• Approver – “So I get this email, need to log into Documentum, select from my tasks and select either Reject or Forward – what does Forward mean – is that approve?  How do I see related documents or delegate this to someone else?”

Is There a Better Way to Customize?

As illustrated in the scenarios above, Consumers (search/retrieval) are different from Authors who are different from Approvers.  While Documentum and other ECM vendors all have a “do everything” application like Webtop, rarely are all the functions needed for the scenarios presented above that typically drive user acceptance.

TSG has seen mature ECM implementations move away from a “big bang” when it comes to delivering ECM functionality all at once.  As we pointed out in a previous post, one client is adding small modules in place of Webtop customizations to ease their upgrade.  In looking to reduce risk and improve responsiveness, companies are developing a modular approach to rolling out functionality rather than one large “do everything” ECM system implementation or interface.  By implementing a module at a time, companies have been able to reduce risk and complexity while delivering benefits to their users and reducing the size of their validation efforts.  Modules that relate to user acceptance scenarios and what we would view as best practices include:

• Authoring and Indexing – Simple bulk load or transactional module that includes logic to make sure items are stored and indexed accurately.
• Search and Retrieval – Simple search and retrieval module to allow users to search/view/print with minimal clicks and frustrations.
• Third Party Access – Treating external users that may be restricted like internal users that aren’t can be an ACL (access control list) nightmare in Documentum.  A simple application that allows third parties to do what they need to do without exposing restricted documents or functionality is better.
• Workflow review and approval – Simplified form and workflow creation along with email notification as well as a view that automates all the review/approval tasks.

Reducing Customizations Today to Make Upgrade Easier Tomorrow

We published a post back in July in regards how some clients are reducing bad customizations to make their Documentum environments easier to upgrade.   Documentum users should understand that some customizations to interface components of Webtop will not upgrade as illustrated in this post.

Mature Documentum developers realize that certain applications developed “outside” of the Webtop WDK interface will easily move between releases of Documentum.  Not only is the application focused on user acceptance, but the application has the added benefits of a smaller, more easily tested/validated and supported module.

Some relevant client experience:

• Life Sciences Company – Technical Architect inherited a ton of customizations on 5.3.  Has gradually been moving to separate modules outside of Webtop for search and approval to make his upgrade easier.  (Shout out to Mike if you want to comment)
• Life Sciences Company – Developed initial application on Documentum API 15 years ago and still in production.  Back-end has been upgraded several times without major interface redesign.
• Insurance Client – Developed custom claims on their own web service layer – actually moved from Documentum to IBM with no application changes.

No Interface is a Silver Bullet

To conclude, one approach might be blame Webtop and Documentum as we have often heard “Documentum requires customization and (SharePoint, Alfresco, Stellant) have a better interface that won’t need customization.”  For those of us that developed with Accelera, RightSite, Workspace, SmartSpace, Desktop Client, CenterStage and all the other iterations of Documentum, it isn’t the interface that is to blame, it is the approach.

There are good customizations and bad customizations and experienced ECM developers must balance user acceptance, support and testing/validation priorities when determine when/what/how to customize.