I just started writing a series on what EMC should do with their Documentum product as part of my Christmas gift to EMC. That part is key…this is a gift from the community because we want Documentum to be better and to stick around.
Why do I say the community? Simple enough…because I hear these things from many users at different installations across multiple verticals. I hear things from clients, partners, competitors, and random people at meetings.
We criticize because we care.
Today we are looking at the Content Server, the engine that makes everything work.
Upgrade the Content Server
Okay guys, this isn’t rocket science. You don’t have to be a genius to see things need to be updated. Several things haven’t been changed in over a decade, like Federations. This is a leading ECM platform, and rightfully so. If EMC wants to remain there, they have several things to fix…
- Optimize DQL: Recently I ran into a performance issue. If I ran a query with one condition, it was quick. If I ran it with another condition, it was quick. If I combined the two conditions into one DQL statement, the world ended. It was because one condition was hitting a single-valued attribute and the other was hitting a repeating-valued attribute. I fixed it by creating a Union query of the two quick responsive queries. Why can’t EMC do that in the code when translating from DQL to SQL? Why not spend some time with table indexes so people can look at the audit logs even when there are hundreds of millions of entries? Right now in many systems, that is a kiss of death. Run some database analysis on what happens when people click on those History tabs. Oh, and consider differences for Oracle and Microsoft.
- Security: Going to only address the functional aspect here. The proper management of security will be addressed in its own post. Did you know that the key used by Documentum to assign users to groups and Access Control Lists (ACLs) is the User Name, which is essentially the display name. If that changes, all the related tables have to be updated. Expand to 10,000 users and that becomes a large update. Now factor in the pulling of users from multiple sources where there is no way to guarantee uniqueness. The entire model falls apart. Documentum needs to use the built-in Object Id for users and groups for all of this. There is no excuse for this. As user populations grow, the existing model becomes more and more unworkable.
- 64 bit: Why isn’t there a 64-bit version of the Content Server? It creates a limit of 1024 connections and a limit of 2GB of memory usage for the Content Server. In the 10 years of working with Documentum, those limits have not moved. Give us a 64-bit version and let us take advantage of the average server that we would like to buy for production.
- Federations: This sucks. Documentum exports a file of users from one system and then imports it into another. If this gets out of synch, say because you deal with LDAP issues from having a few thousand users, this falls apart. I’m not sure if it is better to manage two LDAP configurations and the issues that arise from that or use a Federation which will at least give a variety of issues. I can think of several different architectures that would provide better response.
That is just a start, but you get the point. There are areas that could use some love. When most of my performance gains come from upgrading the database or the user interface and not the core server, that should tell you something.
Too Many Add-Ons
Here is a common scenario…EMC hypes a new feature for the Content Server. It is presented as part of the core architecture and looks like a great next-step in the evolution of Documentum. There is only one problem…
It requires an additional license!
So your telling me that if I want to add content or work differently with content, I have to pay more? How about the additional client licenses that I may add as well? Can’t you get my money there? How about when you sell me all the new storage I will require?
This has happened with High Volume Server and Documentum Foundation Services (though I think DFS is changing). XML Store is also licensed separately.
High Performance Server is a great boost to help with massive amounts of content. Why is it licensed separately? Why not say Hey look! Our Content Server scales better now than it did when we released 4i 10 years ago! Why not bundle it? Why not bundle the XML store? Why do I have to pay for the Documentum Administrator web interface?
The following should be included with the core purchase of Documentum Content Server. That itself should be for X users or X CPUs. I prefer CPUs at higher levels and users at lower. Maybe do a sliding scale. Users up to 250 at which point you switch to CPU. Do the math and figure it out. What matters is that the following is included.
- Documentum Foundation Classes (DFC): This has always bugged me that clients have to pay EMC money to write a custom application using the DFC when they are already per-user for the Content Server.
- Documentum Foundation Services (DFS): Same thought as the DFC, but even more-so for the world of SOA.
- Content Management Interoperability Services (CMIS): If you charge people extra to make your server the repository of choice for line-of-business applications, it hurts you.
- Documentum Administrator (Minimum of 5 licenses or 1 per CPU): Why should anyone have to pay extra to administer their system?
- Documentum Search Server (the full-text index engine): The current FAST search is included. Please keep this consistent.
- Composer: Can’t believe you licensed its predecessor, Application Builder, SEPARATELY. Criminal to say the least.
- XML Store: You sell it as a stand-alone, which is good. You need to market it that way more aggressively. Why not make the Content Server the best of the big players at using XML? Sell the advanced interfaces and the consulting services.
- High Performance Server: Really? The first real performance and scaling improvement in 10 years and we have to pay extra?
- Webtop OR CenterStage Essentials: Give people a basic interface. It doesn’t have to be fancy as you can sell the fancy one separately.
- Integrations into Microsoft Office: Make adoption easy and people want to use your software.
- Centera Integration: They’ll have to pay you for the hardware anyway. Why add to the hurdle?
- Retention Policy Services (RPS): Everyone has retention requirements. Sell them the full Records Management application if they have full records requirements. Many people will still buy that component. This isn’t part of the core now, but basic retention is so common that it should be there.
From here, clients can buy more specific applications or integrations for their business area. This will take some restructuring, but it will pay off when you can say, Oh, that’s included, in bake-off after bake-off.
Oh and did I mention that this will make pricing simpler for partners and sales reps. I’ve seen this messed up on many occasions.
If you have any other ideas, please add them.