What is wrong in Documentum? Part I

Two weeks ago I read interesting blogpost about Documentum future. Actually, the blogpost mentioned above is very controversial from a technical point of view, but it gave me idea to write this one. TSG guys are worried about non-existence of Documentum 8 roadmap, but when I have taken a look at “improvements” which were made in Content Server since 5.3 release (7 years have passed since 6.0 release), I found out that the count of new features, introduced in 6.x – 7.x releases, is hardly enough even for one major release. Below I have tried to combine all release highlights into one single list (let me know if I have missed something):

  • fast and simple tomcat was initially replaced by weblogic and then by jboss – now time taken to start JMS is about 60-90 seconds, instead of previous 3-5 seconds
  • FAST Search was replaced by xPlore – OK, but full-text search is still unusable for large repositories
  • CREATE/UPDATE/DELETE DQL statements now honor TBO – totally useless
  • LEFT OUTER JOIN in DQL – does not work properly
  • RETURN_RANGE DQL queries – very limited syntax due to transformation to SQL. Why do not limit returned results at content server level?
  • new privileged groups – OK, but not properly documented
  • dynamic group enhancements – actually, I consider dynamic groups as an attempt to solve some design gaps in security model
  • UTC dates in database – implementation is very crude
  • LWSO – have never used before, need to investigate
  • database partitioning – to get performance benefit you should permanently use “WITHIN PARTITION” clause in DQL statements (in Oracle such implementation is known as “System Partitioning”), very arguable solution
  • Java Method Server high-availability support – Why do not improve stability of a single JMS?
  • Kerberos support – OK, but setup is a challenge
  • 64-bit builds – less than ten years have passed since Intel and AMD announced x86-64 processors 🙂
  • Intelligent Session Management – not a CS feature 🙂
  • Non-anonymous SSL communications between DFC and CS – breaks compatibility with old clients
  • Aspects – very limited syntax in DQL
  • Non-qualifiable attributes – very useful, but rarely used

So, After more than 7 years of development we have only two or three useful improvements in Content Server, i.e. one improvement per CTO :(, and I bet we won’t see anything useful in Documentum 8 too. In next blogpost I will try to describe what is really missing in Documentum.

21 thoughts on “What is wrong in Documentum? Part I

  1. They usually focus their effors in clients (“new” webtop 6.x, D2, etc.) than in CS, which I think it only gets “improvements” developed for certain customers or “forced”, as xPlore was developed because MS stopped support for FAST, and I think there was a technical reason for moving to weblogic/jboss (EJB support?). You can take as example the deprecated API, or the #~@@#~!! EBS files which should have been removed long time ago… As the TGS post says, most of the original developers left EMC and they are probably afraid to touch anything that has to do with CS core modules…

    Like

  2. There is no rocket science in Content Server: it has about 470 RPCs and the only thing it do is sending SQLs to underlying database. 7 years is a very log term even for rewriting everything on Java.

    Like

  3. Just wanted to clarify some points:

    – TSG is not “worried” about Documentum 8 not being in the roadmap. We tried to point out that our clients want stability and want to avoid the hassle of upgrades. We mentioned in our EMC World recap that we actually think IIG/Documentum is doing a good job at moving forward in small increments under Rick’s tenure – http://blog.tsgrp.com/2014/05/23/documentum-momentum-emc-world-2014-recap-some-bunts-hits-as-well-as-some-swings/

    – your post mentioned that our post was “very controversial from a technical point of view”. Don’t want to offend anyone but what part was controversial? We have tried to make blog.tsgrp.com neutral from customer viewpoint in reviewing IIG/Documentum. We would be happy to have a dialog in the blog or here defending our views.

    Like

  4. > We would be happy to have a dialog in the blog or here defending our views

    Ok.

    > much of the underlying code base for Documentum is still C code circa the 1990’s client/server environment from the initial Howard Shao and John Netwon era complete with Remote Procedure Calls

    There is no problem with RPC at all, RPC is just a way how processes communicate with each other. Take a look at MySQL client/server protocol (http://dev.mysql.com/doc/internals/en/client-server-protocol.html) – it is the RPC, and, yes, MySQL is written on C/C++ in ninetieth – this fact does not make MySQL codebase obsolete. When you compare Content Server with Alfresco just imagine that Content Server is an “advanced” RDBMS and everything will fall into place. The problem here is Content Server is not so advanced RDBMS as we would like to see: a lot of logic, that should persist in such database, is delegated to client level (i.e. DFC), for example: when I’m coding some business logic in TBO the only thing I’m overriding is doSave() method, so, technically I do not need TBO at all – it would be enough for me that server had some pre-/post-save hooks like P8 does (http://www-01.ibm.com/support/knowledgecenter/SSNW2F_5.2.0/com.ibm.p8.ce.dev.ce.doc/server_concepts.htm?cp=SSNW2F_5.2.0%2F10-2-1-24-4-0), but someone made a wrong bet on client-side TBO (and Java), that eventually narrowed the number of supported client platforms (though I do not think that it is a challenge to implement basic scripting engine inside content-server).

    > DQL and other older components that are not required in new internet based environments

    Why DQL is old and not required anymore?

    > Cloud, Node, Distributed , NoSQL Databases – technology is moving quickly with a variety of tools for making an ECM platform more “cloud ready” along with development easier.

    “Cloud” is just a buzzword, what does make Documentum not “cloud ready”?

    Like

  5. Good points – most of my thoughts come from the people side of the equation rather than just the code. Some thoughts:

    – it is not that I am saying there is something wrong with the RPC calls (or even the C code). Just other alternatives that developers would use if building it now from scratch. We see it with our products, engineers want to work with the new framework/stuff because it is faster/easier to develop than enhance the old code. IIG/Documentum issue is not that the code is not working, it is more that Documentum might have a hard time maintaining or updating it as new developers are not using those tools (and most Java guys don’t want to). We would see it as very difficult for Documentum to hire new engineers for an old code base. That being said, there are C developers available but they are different from the Java engineers. This is why I thought the strategy with InfoArchive/aPaas as a new tools that could evolve to replace Documentum was a good strategy.

    – DQL is proprietary to Documentum. Again, it works, but finding new developers that know it (or want to use it) versus other alternatives.

    – I think you are right here – would agree that cloud is a buzzword. That said, newer technologies like NOSQL are getting a ton of traction from a variety of sources.

    My two cents – thanks for posting,

    Dave

    Like

  6. > We see it with our products, engineers want to work with the new framework/stuff because it is faster/easier to develop than enhance the old code.

    In my opinion, “modern frameworks” (for developer perspective) is just a way to protect job security: “I know spring a little: today I’m coding alfresco, tomorrow I will code in-house application”, such developers are charlatans – they do know neither spring nor target platform. However, there is some truth in your statement: EMC does not provide OOTB bindings to modern frameworks, so every developer invents his own square wheel – customer gets into developer’s lock-in.

    > That being said, there are C developers available but they are different from the Java engineers

    “There are” – what country are you talking about, India?

    > DQL is proprietary to Documentum

    Oracle SQL extensions are proprietary to Oracle, but Oracle has a working jdbc/odbc/etc driver, tons of publically available documentation and open SQL-grammar and the most important thing: Oracle SQL is ANSI compliant.

    Like

  7. Pingback: What is wrong in Documentum. Part II | Documentum in a (nuts)HELL
  8. Over the past few years, there has been more and more new features in Documentum than say, a decade ago.
    People, but customers and management @ EMC should have realized it is not so possible to replace the 13 million C++ lines into java code and get same features at same performance.

    InfoArchive does use CS at the backend so it’s not going to replace CS but rather sell it.

    Documentum Content Server as a platform has its benefits and is definitely going to stay for long time. Native implementation does has performance benefits which Java and other high level language implementations cannot match.

    CS is not just a SQL re-writer. If it were Andrey would have provided his own CS alternative long by now rather than complaining so much against it 🙂

    > “There are” – what country are you talking about, India?
    Sure, why not? All sorts of people make up the 1 billion mass, even the clever ones and the complaining ones 🙂

    Like

  9. > 64-bit builds – less than ten years have passed since Intel and AMD announced x86-64 processors 🙂
    and less than 6 years have passed since CS is 64 bit 🙂

    > Intelligent Session Management – not a CS feature 🙂
    All features end up in/need support for CS

    > Non-anonymous SSL communications between DFC and CS – breaks compatibility with old clients
    doesn’t mean you always delve in the past…btw have you moved to XP yet, now that everybody has at least tagged along to W7 if not W8…

    Like

  10. >Over the past few years, there has been more and more new features in Documentum than say, a decade ago.

    I’m sure you are able to provide a short list of new features in CS, aren’t you?

    > EMC should have realized it is not so possible to replace the 13 million C++ lines into java code and get same features at same performance.

    That would be true if Documentum had it’s own database implementation, but currently Documentum is just an
    intermediate layer between database and client.

    >Sure, why not? All sorts of people make up the 1 billion mass, even the clever ones and the complaining ones

    https://blog.documentum.pro/2014/09/19/what-is-wrong-in-documentum-part-ii/

    Like

  11. > I’m sure you are able to provide a short list of new features in CS, aren’t you?
    no need, you are good at covering the tip of iceburg yourself. look at release details for full list

    > That would be true if Documentum had it’s own database implementation, but currently Documentum is just an
    intermediate layer between database and client.
    yes, a layer earning millions, if not billions, both db & client excluded

    Like

  12. > Try to say the same to UNIX customers.
    oh ok. you mean you *cleverly* (ahhm) left this detail out in your original ranting?

    “EMC experts” may be just some managers or some support guys who try to help out bloggers but may not have full picture or may not want to disclose it either

    Like

  13. >you mean you *cleverly* (ahhm) left this detail out in your original ranting?

    This does not matter, or you what to talk about stability of first x86-64 windows releases?

    >“EMC experts” may be just some managers or some support guys who try to help out bloggers but may not have full picture or may not want to disclose it either

    Now I’m sure that Patrick Walsh (a content management specialist with over twenty years’ experience building large-scale information solutions. Currently he is an EMC product manager charged with the roadmap of the Documentum Platform and its Extended services, and as an EMC veteran ready to comment on just about any product, or connect you with someone closer to the details needed) “may not have full picture or may not want to disclose it either”

    Like

  14. i don’t want to refer their notes and you poking at each of them saying ‘complicated’ or ‘old’ or ‘not useful to me’

    whatever, i would rather have those millions myself if i could and if it is so simple and useless layer 🙂

    Like

  15. > Now I’m sure that Patrick Walsh (a content management specialist with over twenty years’ experience building large-scale information solutions. Currently he is an EMC product manager charged with the roadmap of the Documentum Platform and its Extended services, and as an EMC veteran ready to comment on just about any product, or connect you with someone closer to the details needed) “may not have full picture or may not want to disclose it either”

    btw, do i detect a tinge of (rare?) appreciation for PW and/or EMC?
    i think you really bit the bullet in this one.

    Like

  16. Pingback: Dumb dmbasic | Documentum in a (nuts)HELL
  17. Pingback: aspects or not aspects… | Documentum in a (nuts)HELL
  18. Pingback: JMS high availability feature | Documentum in a (nuts)HELL
  19. Pingback: Hardware company mantra. Part III | Pro Documentum

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