Documentum Implementations – "Over Customized" or "Over Sold"

Though-out EMC World, one of the main themes in many of the product presentations (xCP, MyDocumentum…) was a focus on configuration versus customization.  As a buyer of Documentum software, it is easy to see why configuration can be better than customization as it:

• Allows for a quicker deployment
• Allows for easy upgrades with reduced validation/testing
• Allows for less resource spend, whether those are internal resources or external consultants.

Sometimes clients that struggle with upgrade, support or expensive projects will hear from Documentum that they have “over customized”.   This is a term that is thrown around too often as it relates to projects that couldn’t solve the business problem with just configuration approaches.  This post will dive deeper into typical customizations to allow some comparison and support the argument that all customizations are not always a bad thing.

Over Customized or Badly Customized?

One issue we see consistently for controlled documentation is the concept of multi-document approval or a change packet.  Documentum Webtop cannot be configured to approve more than one document at a time, let alone relate a change request form to multiple approval and supporting documents.  There are multiple customized approaches we (TSG) have seen at various Documentum clients.

One Documentum client tried to solve the change packet problem by leveraging Virtual Document Manager (VDM) within Webtop 5.3.   One could argue that this was an excellent example of “Badly Customized and Over Customized” as the amount of code, type of calls (VDM is not an easy to manipulate model), long term support from Documentum (as they haven’t supported VDM and have moved to XML and dm_relationship) as well as the manipulations to the Webtop 5.3 interface made this a customization that will be difficult to upgrade and support.

For this client, we had introduced the idea of levering the Active Wizard, as it was already in place in another division and had a configurable approach for the form and approval already built into the solution.  The client chose to internally develop on the VDM based on the impression that “Webtop, VDM and WDK were the supported long-term Documentum directions”.  As the client has looked to upgrade to D6, the application, as written, would require considerable changes and rewrites.  Had the client chosen the Active Wizard, the upgrade would have required minimal code changes.

Custom is not always a bad word

In another division at that same client, an approach to a different issue, taken all the way back in 1996, was to build on the Documentum APIs and focus on Microsoft Word integration.  At the time, the Documentum interface options were Workspace and a soon-to-be released Accelera (does anyone remember the first Documentum Web Client?).  Bottom line, the resulting application is STILL in production today on a supported version of Documentum backend.  If the client had customized on Workspace, you could argue that they might be in production, although not supported.  Imagine if they had chosen the Web and consider the costs of upgrading/redeveloping through RightSite, SmartSpace, Webtop 5.1, 5.2.5, 5.3, 6.5…..

As another approach, in talking with a client at EMC World, they chose to front-end Documentum with Adobe LiveCycle.  As we discussed thoughts on CenterStage and xCP replacing Webtop, he was still very comfortable that his approach would continue to be easily upgradable given his reliance on Adobe rather than a Documentum front-end.  As with any approach, clients should make sure their licensing allows this type of “custom application” access.

Addressing “Over Sold”

Getting back to the title of this post, another term that is used too often is that the Documentum products are “Over Sold”.  The feeling of being “Over Sold” usually results from a miscommunication or assumption during a sale or implementation effort in regards to how requirements can be met and assumptions about cost, timeframe and functionality.  Just because Documentum can do certain functions, that doesn’t mean it will be easy to configure or customize that function to meet the business needs.  Similarly, one thing we (TSG) hear often is “SharePoint is easy – why should Documentum be so hard?”  Understand that implementing SharePoint for collaboration is easy (just like eRoom was) but implementing SharePoint for the types of structured things Documentum typically does is not easy and often not possible.  See our previous post for configuring SharePoint for controlled documentation. 

Lastly, as mentioned in a previous post in regards to Documentum Consulting alternatives, customers should “consider the source” as it relates to implementation efforts and functionality of the application to avoid assumptions and miscommunications that lead to the feeling of being “Over Sold”.  One thing we provide for compliance and controlled documentation clients is a common set of requirements from multiple clients with ratings of easy, medium and hard for each requirement.   Leveraging the common set of requirements helps reduce miscommunications and assumptions in:

1. what Documentum can do
2. how difficult it might be
3. what clients SHOULD do.

Wrapping it all up

As this post has gotten quite long (maybe a little wordy), it will end with some easy bullets to remember.

• Configuration is better than customization BUT not always possible
• All customizations are not bad but customizations and configurations can both be done badly
• If you are customizing, consider making the customization “interface neutral” rather than changing an interface that might be hard to upgrade to the new interface
• Understand not only what Documentum can and can’t do but also what is easy and what is hard