Easing Documentum User Adoption Using Adobe Flex

From anyone who’s ever introduced Documentum to a new user base can probably attest, the biggest risk is not technological or related to the deliverables themselves, it’s the adoption of a given interface or tool by the end-users.  Users often make a judgment on a product first by the GUI or access mechanism and then by (and this is often a far second) the technical merits/drawbacks of a platform.  As the saying goes “Perception vs Value”.  Compound that by all the other challenges like change management, politics (sorry, the evil word), acceptance testing, et cetra, it can become quite a fun time.

I’ll be very honest, verrrrryy honest.  I have found in my experience that every project I ever work on with Documentum (especially prior to 6.5) has been an uphill battle in the area of user acceptance.  It’s not really because of Documentum being unable to deliver the goods, it’s how Documentum looks delivering the goods.  This said, I am becoming giddy as things are looking up, especially with many of the new interfaces that are now available and beginning to mature very nicely.  I really need to tip the hat to the IIG team.

With any new project, the first tip of the day is, understand the use case and understand it well.  Additionally, when understanding the use case, also examine the business context in which it falls.  Spend some time in the trenches with the user and find out what antiquated tools they love best.  You might be taking aim at displacing one of these tools but if the tools has become loved, it’s obviously either addressed their use case or most likely created their use case.

One mistake I have personally fallen into, making assumptions of a user groups’ way they will use the tools and how the features need to work.  Second assumption, a wdk based application are easy to swallow in this day and age of Web 2.0, AJAX and FLEX.   EMC’s response as of late is to introduce new user interfaces using AJAX and Flex as their foundations, and honestly, the reaction by users has been good from what I’ve seen.  Challenge of the day, put a regular end-user in front of eRoom and Centerstage and see which they prefer.  Second challenge, put a user in front of DAMTop and Media Workspace, see which gets them excited.

Now I regress to my point of the user’s use case.  Don’t try and put a square peg in the round hole.  Asking a TCM user to use a DAM interface or a knowledge worker to use a TCM interface like Documentum’s Taskspace is a deadly mistake.  By understanding the use cases presented and ensuring the appropriate interfaces are provided is key to success.

This is where FLEX has come to save the day.  With EMC’s own adoption of FLEX in their new products, the happy bi-product is the Documentum Foundation Services (DFS).  DFS in essence exposes Documentum using SOAP services.  This is key that SOAP is very much a well adopted and understood, it really allows applications to utilize Documentum’s services with a minimum direct understanding of the underlying system.  (Let’s not get into a debate over SOAP, REST and JSON, we’ll leave that for later)  One thing thou, the out of the box DFS doesn’t support every feature and function of Documentum’s capabilities but with a bit of knowledge of DFC, can be easily extended.  DFS really was written to support EMC’s new FLEX based interfaces and the features they need access to but has become its out standalone component to Documentum utilized in many different ways.

This is where the magic begins, Adobe’s FLEX platform understands and integrates well with SOAP based services.  Simply provide it the WSDL  and Flex can be easily used to directly work with a SOAP interface.  In our architectures, we’ve taken the approach of having a Java middleware platform in between the FLEX application and the DFS.  Using this approach, we’ve infact ensured that the FLEX does what it does best, that is, presentation and asked the Java middle-tier to enforce the business logic.  In essence, this Flex/Java/DFS combo has provided a very robust and extensible platform to delivering very dynamic and compelling platform.

My own direct experience is that by utilizing FLEX, within a 3 month period (one single senior java resource, one senior Adobe Flex resource), we were able to take a project suffering from a lack of user adoption to a success.  From the initial prototyping, delivery and enhancement, this allowed our users to get the tools they needed and ensured our success.  The very happy side effect of this, the users now have a very rich experience and from a Documentum development point of view, all the limitations of WDK/HTML are lifted.  Documentum in essense can be made to look and feel as it needs to be for the organization’s needs.

Hopefully this little post helps you in your own projects and helps you get past that biggest hurdle we’ve all had in any large ECM project, getting the user to love their tools.

Advertisements

About ericgrav
Senior technologist specializing in information management and dabblings into cloud computing

3 Responses to Easing Documentum User Adoption Using Adobe Flex

  1. lopataru says:

    Good approach, although I when Java comes as a middleware I still use DFC (if it’s a LAN between the Java code and content server). Any screenshots for eye candy?

    • ericgrav says:

      Good point on using DFC instead of DFS. DFC is a much faster interface to use from a performance standpoint but does involve that deeper knowledge.

      DFC was one approach we had examined as well, but we ended up in the DFS approach as it fundamentally simplified the development from the standpoint that the Java developer didn’t require any specific DFC knowledge and could ramp up very quickly. At the time when we had started thru this process, our in house staff were not quite fluent in DFC. We were able to simply the process as the out of the box functionalities of DFS.

      On the subject of screen-shots, working on getting a set (the usual, “hey boss, can I post a few screenshots of our custom in-house UIs?”). Stay tuned 😀

  2. Pingback: The Refined Cloud – Bringing Perspective to the Cloudy Cloud « Cloud of Thought

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: