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.
That being said, my first post in this series, on Application Separation, had a great reply from Lee Smith which is worth looking at. Take a moment.
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![image[13]](https://wordofpie.files.wordpress.com/2009/12/image13.png?w=240&h=155 "image[13]")
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!
Excuse me?
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.
Word of Pie 
Great ideas, I would also include the following:
1. Logical backup and recovery (file, directory, user), i.e. think CYA.
2. High performance Import and Export tools for bulk load / transfer with meta data support and transformation.
3. Better utilities for repository moves / renames (installation owner change, SQL / Oracle moves, prod -> test replication, AEK changes).
4. Recycle bin in repository.
James
LikeLike
Great input James! I have a few thoughts.
1) That would be great. I wouldn’t mind a simpler version included with a bells-and-whistle version for a per-server cost.
2) I’d like to see it from the file system. Advanced stuff should be a simple price. 50K, use forever and as often.
3) HERE HERE!!! Damn straight!
4) It isn’t that hard of a feature. I wish they would make it standard.
Let’s keep in mind that they need to make some money. Great thoughts.
LikeLike
Great posts! So true…
I second the things said by James also (content migration/replication/import/export is a must).
LikeLike
Very good point here. I think some of this is a little much, but the point is right on. I have been eying Alfresco and have been amazed at what comes with it as standard. Even if one were to purchase the support, it is cheaper and more user-centric featured than basic Documentum.
LikeLike
Pie in response to your wonderful ideas, and those of your commentors, and also in response to the posting by Lee on his blog – the problem is EMC. Its old fashioned ‘big corporate’ with an appropriate (in their mind) licensing model. Why on earth would it roll elements in to the core product, when it can license them separately and fleece the customer some more. You may remember from the conferences where we met, that I have been fortunate to run an ECM programme in an environment where we got everything, all the modules, including the kitchen sink at a very, very good discount ! However we paid through the nose for a “solution” layer from EMC consulting which in the end was indeed ‘criminal’ – most of the features of that solution are now in the core product (or the various modules).
Happy Holidays from Canada ! 🙂
So playing devils advocate, from the mega-super-corp point of view, why would they want to change their licensing and charging models ? There is almost a de facto opinion in the market place – if your big and your doing complex ECM you don’t mind paying for EMC / IBM / OpenText (maybe Oracle). If your not, and budget is an issue then maybe its SharePoint or one of the other (much better) mid-level platforms, or Alfresco if you want open source. By the way, I am not defending or vindicating this point of view.
I also agree with your point ref DQL – I have seen Documentum grind to a complete half on what should have been simple metadata manipulation, and we had both EMC and MS looking at it – in the end we had to move to Oracle to get decent performance !
LikeLike
Thanks for joining the conversation. I understand the EMC point-of-view, the question is will it matter in a few years if they have been surpassed by people that simplified. They want to position ECM as infrastructure, but to do that, they need to provide it in a simple manner.
Most DQL problems aren’t anything that indexes or common sense can’t take care of for Documentum. I’m running 35 million objects in one SQL Server repository with no issues, at least not database related. I view moving to Oracle as a cop-out by EMC.
Happy Holidays to you. Get yourself to AIIM this year.
LikeLike
Not sure what happened, but the “Happy Holidays” was supposed to come at the very end of the above post ! Happy New Year too……..
LikeLike
Ahhh we are one day early for Festivus which officially begins on the 23rd. Let the airing of grievances begin!
I realy hope that anyone at EMC reading this will not blow this off, but recognize that these are core pain points for users.
1. Pay an english speaking “English” major to review and proofread your documentation and support notes on Powerlink. Isn’t about time you made your documentation as a wiki? This was suggested years ago by Craig, but alas, he is no longer with the company.
2. Documentum Administrator needs some polish. Why when rectivating a deactivated user do I have to go back into the user acoount a second time to enable workflow? Little things like this drive adminsitrators crazy. What should be a 3 click process is 6 clicks.
3. Reporting. Really? You charge extra to give me a reporting interface.
There are many more, but those are the first 3 that come to mind.
LikeLike
Greg, thanks for the additions. I’m sure that we could build one hell of a list of things to fix. I like the Reporting addition. Some reports should be out of the box.
LikeLike
Pie,
Good ideas and I certainly support you on all of them.
Keeping with your theme, my gift to EMC is the requirement and the importance to move fast with the Documentum architecture model and licensing to accommodate the cloud (virtual) pricing and deployment model.
In a simple cloud offering model, beside the simple basic system installation, it offers a temporary provisioning one of two ways, the dynamic allocation of temporary resources on the same virtual environment (CPU, MEM, Storage, etc …) or the instantiation of same environments over a specific period of time.
Recently, I attempted to create a proof of concept for these two scenarios on a private cloud for most of DCTM common components (app server, DM, ACS, etc …..). For now I can report even without jumping into the licensing dilemma, the architectural deployment was neither easy nor fun. In my view it was not even successful but this is a topic for another day.
Happy Holidays everyone and EMC too!
Walid
LikeLike
Walid, thanks for sharing about the cloud deployment. I actually know that they are looking at this. I actually used a Documentum instance in the Amazon EC2 cloud once.
However, it is important to keep on them until it is done. This is a need that will only grow.
How much do you want to bet that they’ll try and charge clients extra for the right to deploy to the cloud?
LikeLike
I agree on probably all of your points – James’ too. DA, Composer, RPS – yes, yes and yes. Add in BPM & Forms while you’re at it. Ditto for backup tools.
Scrap seat-based licensing. It just makes integration a painful exercise. For example, you need to purchase licenses for custom dfc clients – this is in addition to webtop, etc – absolutely ridiculous. Just base licensing on server products – price per cpu/core or similar.
On an ECM project a couple of years ago, the implementation team just about gave up on DCTM due to licensing, not the technology (bpm, custom portlets, webtop, etc). We would’ve gone with Alfresco if it wasn’t for the fact DCTM was already in place and this investment had to be justified.
Its amazing that ECM have not led with a cloud based offering yet but perhaps the complexity of the DCTM architecture is an obstacle. I would really like to see the improvements being made to installation/configuration. Make it simple, quicker (it’s sooo slow), scriptable.
Open the APIs (they’re useless with Content Server anyway), let paying customers see the code. Something a bit simpler – list the product dependencies so that we can build solutions using Maven.
LikeLike
This is a terrific thread following a terrific post. Thanks, Pie, and everyone else who contributed.
Watch for a spike, because I’m about to forward this link to the whole xCP product management list.
And while I do appreciate each and every suggestion, I also think someone should acknowledge the genius you showed when choosing a graphic for the post (maybe we just need to hire some engineers from Pacific Tech!).
LikeLike
Thanks Dan. That movie is one of my favs.
LikeLike
I think one important thing that you missed, was getting rid of redundant columns in the docbase schema. I think there are quiet a few redundant columns in the schema that are carry overs from Documentum 4i and older versions.
I get it that there are customers that have yet to upgraed (although it is virtually impossible to upgrade, migration would be a better path to take), but I hope in D7 / D8 they improve / simplify the overall schema, that would be a great way to improve performance.
LikeLike