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.
Jerry Silver says
Thanks for the post – useful feedback. One alternative you didn’t mention is to use TaskSpace instead of Webtop. TaskSpace is optimized for creating task- and user-specific interfaces with minimal coding, and addresses most of the concerns that you mention.
Jon says
Thanks for the comment, you make a good point.
TaskSpace would be an alternative to look at along with the other approaches mentioned, and it is definitely more configurable without requiring coding when compared to Webtop. There would still be some things to consider though, like:
– Even with the advanced configuration ability, are there specific business requirements which would require coding or customization within TaskSpace. For example, what if it was necessary to conditionally append to a WHERE clause during searches to meet some business need? Could this be done easily while leveraging the Search templates from Forms Builder?
– As with Webtop or any other custom app, someone still needs to “learn” how to configure TaskSpace and leverage the tools like Forms Builder, BPM, etc. Probably need to weigh these training and skill requirements with training in other traditional development tools like Java when considering enhancements, support, hiring, etc.
– May need to consider the additional costs with TaskSpace as well as it is a separate product with distinct licensing.
Thanks again for participating on the blog!
Chris Durham says
TaskSpace should be considered over Webtop customizations in any case simply based on user acceptance. Simple things such as tailored search screens and targeted folder views make it a great interface for the average end user. It is not a magic bullet though. It’s quirks often require either customization or at least a degree of counterintuitive training, and occasionally it needs to be paired with other, custom, interfaces; however any of these options is a better one than out-of-the-box Webtop.
TSG Dave says
Chris,
Thanks for your comment. While it makes sense to consider Taskspace instead of Webtop – I would disagree with it being better for “any case simply based on user acceptance”. As I tried to point out in the article, user acceptance will depend on what you are trying to do for Search, Author and Approval. Often business rules have difficulty fitting into either TaskSpace or Webtop. One being better for user acceptance depends on the business process you are trying to automate.
Also, many clients have licenses to Webtop and do not necessarily want to commit to the license requirements of TaskSpace given that they might have to customize in that environment as well.
Just my two cents,
Dave
Paras Jethwani says
Great discussion
This will be a significant question facing may EMC customers going forward.
What about new EMC customers – who don’t have any Webtop deployments or licenses?
Ofcourse TaskSpace licenses (xCP user SKU) are more dearer than Webtop – but it just seems TaskSpace is more readily configurable for ‘pointed solutions’ than Webtop – e.g. something as simple as hiding certain fields depending on the user’s role can be customisation in Webtop as apposed to a few mouse clicks in TaskSpace Forms Builder.
EMC need to get their act together and make sure TaskSpace supports all content management capabilities of Webtop such as Drag-n-Drop etc.
regards
– Paras