Documentum D2 3.1 – What are some of the limitations?

Recently there has been a lot of buzz and marketing surrounding EMC Documentum’s user interface, D2.  Many clients have asked for information on the product, and we’ve spent some time doing our own evaluation and comparisons with other products.

When weighing the costs and benefits of implementing D2 versus other available products like Webtop, TSG’s HPI, and TaskSpace, it’s important to consider the limitations of a configuration-only solution like D2.  This article will outline some of these limitations, many of which are not immediately recognizable until performing a deeper evaluation of the product.

For clients used to a robust interface, configuration, and development tools, this post will try to present some of the limitations of D2 compared with other common Documentum tools like Webtop.  Compared to other Documentum user interfaces, D2:

• Is highly configurable and brings many new features that have not yet been seen in other products.
• Can be configured through a user interface, without XML file manipulation or application redeployment.
• Provides configuration options for many common Documentum customizations, such as auto-naming documents, auto-filing into a metadata-driven folder structure, starting documents at version number 0.1, only allowing minor versioning on check in, and disabling various menu items.

While it’s easy to get swept away by the new configurable features that D2 can provide, it’s important to not lose sight of some of the limitations when evaluating new interfaces and user requirements.

Technical Limitations D2 3.1

(Editors Note – with D2 4.0 expected out early third quarter, 2012 – this review is focused only on currently released product D2 3.1.  D2 4.0 is a planned major release built with Sencha framework and Google Web toolkit – please see EMC World 2012 posts for more information)

• ActiveX is the platform that the D2 user interface is built on.  This platform is a big deviation from the existing Java stack that all other Documentum user interfacesand back end are built on.  Because D2 has no development kit or APIs, there is no way to customize the product outside of the out-of-the-box configuration.
• Administrative Privileges are required on the client machines that access D2 for the first time, or when an upgrade is deployed.  Even though D2 is technically a web application because it’s launched from a browser, the ActiveX plugin must be installed initially, and this installation requires admin rights on the client computer.
• Browsers Compatibility is a major concern for many clients.  Because the D2 interface is built entirely within an ActiveX plugin, it is only supported by Internet Explorer.  D2 is limited to IE 7, 8, and 9 on a Windows operating system.  Mac/iPad (Safari), Google Chrome and FireFox are not supported.  Blog posts in the Forums have pointed to that future releases will support different browsers but we feel moving an ActiveX tool to non-Microsoft browsers will be a major undertaking.
• Web Application Clustering is currently not supported by D2.  This is a huge hurdle for clients that need to implement D2 in a load balanced and/or high-availability environment.
• Integration with other products is not possible with D2 because of the lack of customization framework.  WDK-based applications allowed for integrations with other tools like Documentum PDF Annotation services, PDF Stamping Services, PDF Aqua, OpenOverlay, Snowbound, and Active Wizard.  These integrations cannot be developed for D2.
• PDF Compatibility – C2, which is the D2 add-on for PDF stamping, watermarking, and controlled printing/viewing, is only compatible with documents created in the PDF 1.4 format.  The latest versions of Adobe Acrobat and even Documentum Transformations services create PDFs in the unsupported 1.5 version.

User Experience and Functionality Limitations

• Documentum Presets provide the ability to configure WDK-based applications to show/hide different application components based on user roles.  Presets are currently not supported or easily ported to D2.  While much of the same preset functionality can be replicated in D2, all of the configuration must be redone manually.
• Lifecycle is implemented in a configurable way in D2, but in its own manner and does not utilize the core lifecycle framework provided by Documentum Content Server.  This introduces a new limitation that would prevent non-D2 clients (DA, Webtop, HPI, TaskSpace, migration tools, etc.) from performing lifecycle actions, such as promote or demote, on documents created in D2.  This would be a major hurdle for systems with multiple clients accessing the same repository.
• Search in D2 can be performed by using the advanced search feature that uses the “Build a Search” methodology, (see our related post on search best practices) which is cumbersome for users who do a lot of searching.  D2 allows query forms to be configured to make searching simpler.  However, these search forms are currently limited by only being able to perform “contains” searches on metadata fields, and there is no way to include searching against date fields unless the date fields are mandatory in the search form.  See our previous post for a deeper dive into D2 search functionality.
• Custom Action logic cannot be built into D2.  While there are many actions that are configurable out of the box, there is no framework for creating additional document or folder actions.  Power Promoting is good example of a custom action that we often implement for clients.  Power Promoting allows a power user to move a document from a Draft state directly into the Approved state without routing through review and approval and typically requires some type of program logic added to the interface.  This could not be achieved through D2 configuration.
• Custom Metadata Validation is also not currently supported by D2.  You can configure metadata fields to be required, but other validation is not available.  An example of custom validation would be if a metadata field required a user to enter a social security number, and you wanted to verify that the user input a value in the format ###-##-#### or potentially look up to see if the social security number exists in a back-end database.
• Automatically Launching PDF Rendition when one is available is another customization that we see many clients wanting to take advantage of.  In D2, the native content (Word, Excel, etc.) is launched when you double-click a document to view it.  You must go through the Renditions tab or select a menu option in order to launch the PDF content.
• Updating Select Metadata on Read Only Documents is another common customization.  Because ACL permissions restrict users from modifying read-only content, this functionality is usually accomplished by running a Documentum server method that makes the updates with elevated privileges.  There is currently no way to call Documentum server methods directly from D2.
• Modifying Document Metadata on the Check In Screen is another enhancement that many clients request.  D2 does not allow this functionality through configuration.  Users would always need to check in the document, and then update the metadata of the document as an additional step.
• Mobile Computing is quickly becoming a demand for many clients as the need for basic content management functionality on tablets and phones increases.  D2 currently does not have a mobile component, and the ActiveX framework used by D2 is not supported on mobile devices.  Because D2 lacks a development framework, any mobile platform would have to be built outside of D2.
• Pricing of D2 has initially been proposed as a new product although there are rumblings that existing Webtop users will be able to upgrade or receive some credit for their existing purchases and maintenance.

Summary –  “What if I want to add customizations?”

As we head into EMC World next week, we have predicted that the Momentum component of the show will be a coming out party for D2.   As we tried to point out in this post, D2 has lots of good “out of the box” features but we are disappointed that it only provides for configuration only rather than mostly configuration.

As a possible future direction, D2’s configuration only approach reminded me of the My Documentum for SharePoint  Web Parts session back at EMC World 2010.  In response to an audience member’s asking “what if we want to customize it?” the product manager stated “Why would you want to?”.   At the time we had similar requests from clients as critical requirements that would drive the need for customization if the My Documentum for SharePoint was to be deployed.  Ironically, about a six months later later, Documentum Consulting began offering their SDF – SharePoint Documentum Framework which provides for customization of the SharePoint component (only as part of a consulting arrangement) based on client feedback similar to ours.

With some of the Documentum Engineers being active readers of the TSG blog, we thought we would end with a positive note heading into EMC World/Momentum.  Future product direction for D2 could easily include integration points that could address many of the limitations pointed out in this post.  Documentum needs to embrace that integration and customizations aren’t always bad and provide for a more robust product, rather than focus on user complaints and competitive vendor propaganda that Documentum requires customization.  The truth is that Documentum allows for customization and that ability (and strength) provides for a more robust solution particularly when it comes to the client’s true ECM needs.

Let us know your thoughts below.