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.
Word of Pie 
Higher application release frequency is easy.
Complete independence though is costly. It requires multiple version of the application. One that benefit new platform features and one that do not. This is doable but at some point maintaining application consistency is hard.
LikeLike
That really depends on the features that the application is using. New Enterprise 2.0 features may be stored as XML. No platform changes required. From a WCM perspective, a lot of focus is in the design and interaction of the website. The role of the repository doesn’t change that much. It is the application that is changing.
It isn’t something I would do with Records Management, but many of other applications I would.
LikeLike
It may be hard, but it would resolve some degree of headaches, especially where upgrades are concerned. At this point, Documentum is terribly heavy with each release; and with some releases it is pretty obvious certain components only changed in version number.
This seems to be a penalty of trying to do it all. It is attractive from a marketing point of view, but when it turns the product into an obese creature to wrestle with each release, it isn’t so attractive from an end consumer/implementer point of view.
LikeLike
While sticking RPS into core, add in BPM & Forms as well. It seems ridiculous that usable workflow is a separate, chargeable item.
LikeLike
I certainly agree with adding in BPM. Workflow Manager is outdated, and BPM is the superior tool. I used to refer to BPM as WfM++, but someone corrected me the other day with the rational that BPM is actually the real WfM and WfM is BPM–.
As for the pricing, I’ve gotten to the point where I have to wonder if EMC isn’t trying to price Documentum in a way to kill it. They certainly make the more usable features prohibitively expensive. I don’t see how that “competes” when people don’t, won’t, or can’t buy it at that price point. Undercut and get market share… isn’t that how it’s done?
LikeLike
Thanks for both of your comments. I agree that the pricing is getting out of hand from a numbers perspective, and from the sheer number of items. I actually talked about that today.
I agree with your assessment with where Workflow manager fits into the equation. It is adequate, and should be included. Many client don’t need full BPM, so I don’t have a problem with that being separate as long as a long list of other items are included.
Oh, as for upgrades, they will always be a pain. That is the price of a system that is so old. On the otherhand, they don’t re-architect it every other year.
LikeLike
Basic workflow is already in there. If you were told otherwise, go hunt down that sales person. I have no problem paying for advanced BPM. Forms I’m on the fence with and I’ll lean towards EMC on this for the time-being. I see that as an interface that isn’t universally needed.
LikeLike
Don’t bother with WCM at all, admit that the core product is the focus, that CentreStage is a good collaboration environment for all those old eRoom customers, but equip the core Content Server to be a nice player with other WCM systems. My last employer in the UK has gone this route with what they describe as an “unholy alliance” of Content Server and Drupal !
I know CMIS is not aimed at the WCM side of things, at least not in version 1.0 of the standard, but with CMIS, various API’s and web services via DFS, take the ‘federated’ approach and let the customer base integrate their preferred ‘best of breed’ WCM application.
LikeLike
Hi All – in the same vein as my comment on the ECM definitions and CEVAs I think the word “application” is applied rather loosely in the ECM world.
So I’d be keen to see (and contribute) to a definition that seperates client components (my term for Taskspace etc) from line of business appications (CEVAs). Is Taskspace really an application>
Regards
Tim
LikeLike
While version separation is a good idea, I think one of the reasons it is kept in sync with core versions is to avoid confusion with customers. I bet you must have met hundreds of clients who complain about the fact that they do not know which version of application is compatible with what version of Content Server.
Imagine if Version 1.0, 1.1, 1.2 and 2.0,2.1 and 2.1.5 are all compatible with CS 7 but only 2.1 and 2.1.5 are compatible with CS 7.1. You see where I am going with this, it could make things a lot more complicated with a complex matrix.
Web Content management products (WP, IDS or SCS) I agree that these should be moved out of the release cycle, as they are almost always behind schedule. Thank god DCM is not in the picture anymore.
LikeLike
They have been solving this problem with CenterStage. It is compatible from 6.0 forward, limited compatibility from 5.3. The loose coupling makes this feasible now.
LikeLike
I would like to use an image from your Word-Of-Pie website locatedin section titled “The Three Products”. I aim to use it in a PowerPoint presentation for a business course assignment. May I have your permission? How would I properly cite this image?
LikeLike
Feel free.
LikeLike