Think soberly. Maturity myth

Original could be found there and there:

Documentum in Maintenance Mode

One thing that was apparent throughout the event was Documentum and existing interfaces (Webtop, D2, xCP) moving into more of a maintenance mode. Some examples included:

  • Rohit’s quote that Documentum was “feature complete” during the keynote.
  • Subsequent article in CMSWire that “No one is asking for more features or functions”
  • Documentum Roadmap that focused on releases that will make Documentum easier to upgrade.

Other expectations – moving beyond

Documentum is feature rich – not clamoring for more capability. As we pointed out from the morning Documentum 7 session, ECD is treating Documentum as complete and has focused on making it simpler to run Documentum.

Actually, the statement about “feature complete” is totally weird. If my memory serves me right, today is 2016 but Documentum still suffers from childhood diseases like:

  • Partial support of unicode
  • Extremely limited SOAP/REST API (please check my thoughts on ECN, actually, in my last project, I’m trying to map CRUD operations on DFC calls and got some progress on that)
  • Poor integration capabilities
  • Java-only API
  • non J2EE compliant DFC library
  • Poor java-api
  • Poor documentation
  • Poor performance
  • Poor security
  • Poor support

This is how “mature application” does look from EMC perspective. Actually, my opinion about maturity of Documentum is following:

  • in 2007 EMC acquired XHive and after that they implemented XHive storage support in Documentum (I have never used it)
  • further EMC implemented xPlore (also based on XHive), technically xPlore have no search capabilities at all: it grabs all data from database and storage, puts it into another big database and tries to performs XML queries against xml database
  • further EMC implemented xCP2 which relies on xMS which in turn based on XHive
  • further EMC implemented InfoArchive that is based on XHive
  • now EMC is trying to implement Horizon/LEAP which is also based on XHive
  • the co-founder of XHive was Jeroen van Rotterdam, who is ECD CTO in EMC now

From my perspective it is obvious that ECD/IGG/etc development vector had switched to XHive long time ago.

4 thoughts on “Think soberly. Maturity myth

  1. Nice insights into product philosophy of ECD…

    I cannot share all points, but in general you are right. IMHO, the big issue is that ECD missed the chance to develop a new backend server which causes a lot of the problems in newer days like poor security, performance, java-api and integration etc. Alfresco shows what is possible today…

    There is heavy invest into D2 at the moment- ECD adds new features in each release, but the configuration approach has always limits. Configuration works for much simple scenarios, but cannot work for complex features.

    Personally (!), I don´t like D2 at all because of several reasons like strange UI concept and lack of deep customizations/extensions…

    Status Quo of Documentum clients?
    D2 – good configuration, but no deeper customization and extensions possible.
    XcP- good customizations, but too heavy weight, too expensive and special use case driven.
    webtop – no one wants to use it anymore…

    A team of fme AG (including me) has developed a custom solution framework for Documentum, a state of the art stack on top of Spring and Angular. This “framework” should fill the gap for our customers which have highly customized webtop implementations and cannot switch to D2…

    More infos are available here:



  2. The problem is both you and EMC (and many other people/companies) are missing letter ‘E’ in ECM acronym. Ask yourself what had forced you to use/choose Documentum? With the current usage pattern, proposed by EMC, you may replace Documentum by MongoDB, for example, and you will loose nothing, EMC is doing the same: they have no idea about what the purpose of letter ‘E’ in ECM acronym, but instead of using MongoDB they had chosen XHive.


  3. Pingback: ACL performance | Documentum in a (nuts)HELL
  4. Pingback: Database connections. Part II | Documentum in a (nuts)HELL

Leave a Reply

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

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

Google photo

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

Connecting to %s