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.