Documentum Development Divergence

Please refer to my previous post, A Brief History in Time (DCTM Development), to get a perspective on the evolution of DCTM development.

With the birth of TaskSpace, the WDK/DFC development model was no longer an absolute necessity.  Many clients as well as new developers have complained that it took too long to learn/customize WDK.  I’m not saying that this is a bad thing (I am avid supporter of TaskSpace), but it did mark a change in the development paradigm.  This was the start of the DCTM development divergence.

Fast forward to today.  With release of 6.5, there are a quite few products that are no longer based on WDK.  CenterStage Essentials (aka Magellan) is based on DHTML and extended javascript.  Media Workspace, an add-on to Digital Asset Manager, and Page Builder, an add-on to Web Publisher, is built on Flex and web services.  DFS 6.5 is starting to hit prime time with the inclusion of records management services.  While WDK/DFC is still the core of the development paradigm, how long will this last?  What’s next?  Is it DFS or is it Flex?

Based on the marketing materials for 6.5, it seems that EMC is addressing what the market is asking for and is focused on delivering solutions and not just technology (e.g. WDK).  What clients and EMC executives may not have considered is that delivering these very specific solutions based on different technologies MAY increase the cost of customization.  I’m not saying that the cost WILL increase, but as these various solutions use different technologies, it may be harder to find developers/consultants who can customize the individual solutions.

Today, if I need someone to customize Webtop, anyone with Web Publisher, DAM, or DCM can do this.  This may not be the case tomorrow.  A Flex developer might learn about DCTM by customizing Media Workspace.  This person is not going to know how to customize Webtop or even CenterStage Pro (the full version of CenterStage Essentials that is supposed to have its own APIs).  I know that the product managers for each of these products had their reasons for choosing these other development technologies for their products.  EMC as a whole needs to focus its energy into developing the next WDK – a unified (not divergent) development paradigm.


10 responses to “Documentum Development Divergence

  1. My impression from the EMC World 2008 was that WDK isn’t going anywhere during the next years at least. I also clearly felt that DFS was highlighted as the API of the future. I am not a developer but I sensed that there was an ambition to provide a new set of extensible APIs that will allow for a lot of customizations in CenterStage. However, I see your concern for developers since WDK has been around for a while and based on skilled developers there is a lot of flexibility that I also would like to keep. For instance, we have a lot of customizations in DAM, most of which are done based on usability requirements and to ease the kind of collaboration that CenterStage hopefully will offer.

  2. Hi quicktimeuser,
    I strongly believe that WDK will remain through D7, and maybe in some supported fashion, thereafter. So as a client, I would not be too concerned about the divergence I was talking about. My concern is from a developer’s perspective. It looks like going forward that there might be different APIs for different products (e.g. CenterStage Professional, TaskSpace, etc). I am in know way telling the product managers to dump the latest technology and go back to WDK. I’m just trying to point out that there does not seem to be a universal customization strategy (as with WDK). I’m not sure if this even feasible, but its worth some serious thought.

  3. Sure, a unified developer framework would be ideal. what would be even more ideal is to have an API that completely decouples from the interface.

    So, in essence, the developer has access to the core capabilities, objects & properties of the DCTM platform but when it comes to the interface component, the actual rendition of it and behavior management should be a customer decision.

    With this sort of “RenderKit” model, it doesn’t matter that Flash/JSF/JSP/ASP.NET/JQuery or Telnet. Who cares. Java Server Faces’ component architecture is very similar in this context. In the sense that the component model and rendition are two different things. The same component can have multiple different mark-up outputs for browsers, consoles or other display modes.

    The key is to promote solution flexibility through flexible interfaces should the customer need them. If they just need minor modifications because their use-case is basic, they can customize CenterStage and be done with it.



  4. Hi Zubin,
    I believe the core capabilities that you are speaking of is the basis for the development of DFS (Documentum Foundation Services), which is leaves the rendering to web service consumer.

    As for CenterStage, or any product that supports “minor” customization, once you give the client the capability to customize, the line between “minor” and “major” customization quickly disappears. Documentum has always been good about architecting for the future, but I think with the 6.5 release of new products, they were focus on delivering solutions for today.

  5. Johnny, I share your concerns. I heard repeatedly that Webtop and the WDK wasn’t going anywhere. I feel it is safe through D7, but after that it is too far to accurately predict.

    The multiple tech is a slight concern. The interface for CenterStage isn’t too far from the WDK when you consider that it is simple web development. Flex is a little further afield, but hopefully the need to customize those are more limited.

    It is a far cry though from just having to know Java, JSP, and basic web development that the 5.x platform required. Then again, we don’t have to worry about Docbasic, so that helps.

    My largest concern is around CenterStage. People will want to customize it and won’t want to have to redo everything when they upgrade or just apply a patch. It will need to mature.


  6. Hi Johnny,

    Yes, DFS theoretically achieves that, but they have opted for a “heavy” WS-* centric approach with Apache Axis and now JAX-WS as their engine. Most experienced web developers will be glad to share how wonderfully superfluous the WS-* world can be.

    Modern initiatives take a far more lightweight approach and allow developers to actually focus on the solution vs. spending significant time on making sure their implementations are WS-* compliant.

  7. Hi Pie,
    I completely agree with you that people will want to extend CenterStage. Hopefully, whatever APIs EMC will offer, it will have a more global reach than just CenterStage. Otherwise, we will end up having conglomeration of products – vs products built on core platform with a core development/customization strategy.

  8. Thanks for you additional comments Zubin. I now see where you are coming from.

  9. I agree that CenterStage is the key thing here. I strongly believes that merrying userfriendly Web 2.0 technologies with an advanced ECM repository is the smartest way ahead if you are serious about information and knowledge management. Maybe this means that old KM visions to some degree can be a reality and not having a KM-effort reduced to just installing a search engine.

    In order to create “Facebook for the Enterprise” I also agree that the adaptability of CenterStage (Pro) is crucial. Even though David LeStrat and Gideon Ansell have made a great job of identifying key features there is still a need to harness the creativity of the developer community. That way it is important that the API and development support does not inspire to too many short cuts but instead focus on a more long-term strategy for creating reusable and configurable components. That goes both for the GUI but also for integration effort. For instance having presence information in CenterStage could take some time before EMC have it ready and maybe a developer can show the way here if the APIs are good.

    When it comes to MediaWorkSpace it seems like a different thing. We have just got it installed at work and it support only images for the time being but there is a clear ambition to make it a worthy DAM replacement and that development effort could possibly make the customization need a little bit smaller than for CenterStage. Even though we use it as our main client I guess most users will have CenterStage as their main client unless for graphics departments and such.

    I guess in the end the thing to say to EMC is to live up to the intention of being open and provide good API and development libraries together with good documentation….


    Alexandra Larsson, Sweden

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your 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