Of all my posts in this series, this is the one that is probably the least needed.  I say this because it looks like EMC is some of this now.  It does need to be said though, just so EMC know that we still care, and in case I am guessing wrong.  The themes for the Architecting of Content Applications is closely related to the Application Separation topic and in many ways, is the complement to the Focus on the Core edition.

I’m going to stay away from some specific feature requests for applications.  I would want to do complete run-downs on any app before I did that.  I want to be a little more strategic in my advice.

As always, please feel free to add/comment.

Old Reliable

I remember the WDK when it first started. Heck, I presented on integrating into the WDK at the 2003 Documentum Developer conference.  It was immensely better than RightSite, leveraged Java which was becoming a core technology for Documentum.  It allowed easier management of interface customizations.

It is now old.  Not just in tech years, but in dog years.  Webtop is still useful if for no other reason than it can test almost any Documentum feature from within an out-of-the-box interface.  For “power users”, it gives you lots of functionality.  For everyone else, it is a burden.

The problem is that EMC is now in a Catch-22.  If they get rid of Webtop, they have lost a great platform for testing all server features.  They would also have to replace Documentum Administrator.  I already have heard that TaskSpace will be moving away from the WDK in D7, but what about DA and Webtop?  Where will the equivalent apps live?

On the other hand, the WDK is old and tired.  Like any old race horse, it is time to put it out to pasture.  Maybe keeping it as a Content Server test-bed or as a development platform may be worthwhile.

Just remember EMC, if you do kill it, replace it.

Common Architecture

WDK-based apps have to go, so what now?  It used to be that if I could find a Java developer, they could use that skillset do to any Documentum customization.

Java isn’t going anywhere as it is a key part of the Business Object Framework and the basis of the entire DFC, which is the basis of DFS.  So do we want to start introducing more technologies for the user interfaces?

Here is where we need to take a lesson from CenterStage.  The tech is open and heavily based upon JavaScript, specifically ExtJS.  While it isn’t Java, it is related.  This is also the base platform for the next version of TaskSpace and xCP with D7.

If not already done, make it the core technology for ALL applications.  Forget Flash or Flex.  We don’t need to be having multiple developers and we can’t all afford to keep developers that are good at several languages.

CenterStage connects to the Content Server using DFS.  Make that the template for your business applications, like TaskSpace and Web Publisher.  That will help decouple from the Content Server.  That puts you one step from making those same applications work against CMIS, which allows you to sell those applications as standalone apps against CMIS repositories.

Which, if I count correctly, is another potential revenue stream.

It also allows me to use EMC applications fully against a Documentum repository and to find and use content on my “legacy” systems.  Migrations now become less of an issue when seeking to switch applications.

Play to Your Strengths

This will be short and sweet.  Documentum has always been one of the stronger ECM plays with workflow and BPM.  The introduction of ad-hoc approvals workflows in D5 was great.  I could quickly route a document for review to someone without creating a workflow and it would appear in their inbox with any other tasks.

So WHERE did it go?

Every single Knowledge Worker interface, CenterStage, Content Services for SharePoint, and the My Documentum suite failed to deliver an inbox.

Huh?

Back in 2000, I worked with Plumtree, which later was acquired by BEA and then Oracle, to develop and test four gadgets/portlets.  Do you know what the most obvious/important one was?

…the Inbox.

Many Knowledge Workers may not live in the Inbox, but it doesn’t mean that they don’t need to visit.  Keep your eyes on the ball people.

Free the Applications!

Break FREE from the release cycle of the Content Server!

SEPARATE yourself from the numerical advancements of other products!

Make your version numbers MEAN something again!

Become ONE with the market and don’t just react, LEAD the market with your application features!

SAVE yourself from the evils bugs that reside in unrelated applications!

Become your OWN product! Be YOURSELF!

Can I get an AMEN!?!

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 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.

This is the first in a series that I am writing as a Christmas present to EMC.  I want them to think about Documentum as a platform for the future and not on just adding on chunks that can be used to drive revenue.  Revenue is important, but investment now means revenue in the future.

After all, if they want their vision of SkyNet to come true, they need to get to work.

Why Web Publisher Sucks

I talked recently about how there are many ECM vendors out there that have sub-par applications, like Web Publisher from Documentum, that shouldn’t be required to be an ECM vendor.  It isn’t that they aren’t capable of writing good applications.  It is that the landscape changes faster than the release cycles for the platform.

This isn’t to say that they need to speed up the release cycle of the core platform.  After all, that would mean more versions of Records Manager to get certified, and that would suck.  It means that there needs to be an ECM platform that releases separately from the applications teams.

I am talking about EMC’s Documentum here, these comments apply to many of the established ECM vendors.

Keep the Core Intact

I listed some on the last post.  This needs to be met and many components could use a freshening.  There are too many things that haven’t changed since I started using Documentum, and that wasn’t yesterday.

The core server for any ECM vendor should be able to act as an ECM platform and support any type of Content Application, be it written by themselves or any third party.  This means functionality and sufficient interfaces to support them.

The Content Server doesn’t need a rapid release cycle, just its own cycle with robust testing for scaling and for the interfaces, DFC, DFS, and CMIS.

Oh, and take a look at how security is managed. Support for different Identity Management architectures is paramount.  If authentication and authorization can’t be streamlined at a higher level, then it all falls apart.

Spin Off the Apps

Right now, this appears to be occurring to some extent.  CenterStage is on a separate version line. Of course, this may just be because it took so long to get out that management got tired of relabeling the version number.  The WDK started out separately and then jumped from 1.0.1 to 5.1.

The point is that CenterStage is a good model for how applications should be designed to work with Documentum.  It is loosely coupled through DFS, allowing the latest version of CenterStage to work with multiple versions of the Content Server.  Properly managed, CenterStage 1.0 should work with Documentum 7 and 8.

Of course, you would want to upgrade CenterStage before that, as you would most likely upgrade CenterStage frequently and the platform every now and then.  The more important thing is that CenterStage 3.0 would still work with Content Server 6.5.

If Web Publisher was managed like this, it might actually have a shot of competing.  They could rapidly develop and release every six months or so.  The only testing would be the actual application.

If Web Publisher and CenterStage used CMIS instead of DFS, they could be sold to work with other systems as well.  Wouldn’t that be something, at least for CenterStage?

The key here is that the applications are optional. Oh, it would be silly not to have any applications, but you wouldn’t need them to be considered an ECM vendor.  EMC could give up on Web Publisher and focus on things that work well but could be better.

Three Product Types

From this, we get about three product types.  They are:

• Core Server: This is the Content Server and the default application, be it Webtop or CenterStage Essentials.  You either buy seats or CPUs for the Content Server and you get it all.
• Applications: This is the old CEVA and new Component Content Application (CCA). By product: TaskSpace, CenterStage, Web Publisher, DAMtop, and xPression. These applications get their own version numbering system and communicate to the Content Server via DFS or CMIS. Records Manager would fall into this category, but I would throw Retention Policy Services under the core.
• Tools: This is the transformation engines, thumbnail servers, and imaging applications.  They are optional parts of any number of solutions.  Take imaging. You could be scanning for archiving, records, or as part of a transaction.  Tools could be integrated more tightly using the DFC for more precise optimizations.

Now if I want to use Documentum with SharePoint, I buy the Content Server for 400 users and plug SharePoint in using CMIS.  If I wanted, I could write custom web parts.  If I decided I wanted a tighter integration, I could buy one of the offerings from EMC or a third party vendor.

The applications now compete on merit, but I never question the repository.

Of course, there are things that the repository needs to do to merit this consideration, and I’ll cover that in my next post in this series.