Category: Documentum

EMC Documentum tips and tricks.

Alfresco ECM is 96% cheaper than legacy ECM vendors?

If you are evaluating ECM solutions, particularly if you are interested in cost, you need to take a look at Alfresco’s TCO Whitepaper. In it, Alfresco uses licensing numbers they snagged from the United States government to compare the first year costs of their solution with EMC/Documentum, OpenText, and Sharepoint.

When the whitepaper came to my attention, I expected it to be Marketing hype, full of soft numbers and exaggerated claims. While readers must take the paper with a grain of salt considering the obvious bias of the source, Alfresco does a good job of avoiding Marketing speak for the most part and simply laying out the facts. The whitepaper shows line item detail for licensing and support for the first year. If you want to include supporting infrastructure (OS, application server, database) in your analysis those are provided for you as well.

The paper shows that for document management plus collaboration and integration with SharePoint, you’d have to pay EMC/Documentum $863,937.98 for a 1000 user configuration as opposed to $318,738 for SharePoint and $33,500 for Alfresco for similarly-sized systems with equivalent functionality. Those numbers exclude the supporting infrastructure software.

So what’s the fine print? Here are some considerations…

The numbers Alfresco used are from a government price list. It isn’t clear to me whether those numbers are “list” or are a negotiated, reduced rate, but from my past experience with Documentum, I’d say they are closer to list. I don’t think it is likely that anyone would actually pay $800k for a 1000-user Documentum system. Even if you were to negotiate 50% off of those numbers, though, the difference is still significant.

A portion of the “first year’s cost” is maintenance and that recurs every year. For Alfresco you are only paying for maintenance, so the entire $33.5k will be due every year. Using the numbers from the whitepaper your Documentum maintenance bill would be about $115k every year. I think in all cases, the maintenance is probably understated for what typical clients will pay because most will want “top shelf” SLA’s. The numbers used here are for lower levels of service.

The legacy vendors have 1000’s of product configuration options. The line items Alfresco chose to include for the Documentum configuration look roughly right, but with so many options you can’t say with certainty that what’s listed is what everyone who needs a 1000-user document management system built with Documentum will use. So tweak the table using the quote your vendor gave you and come to your own conclusions.

Alfresco showed a 2-CPU configuration for their 1000-user config priced at $33,500 which included a test server. Then they showed a “high availability” config with a $9,250 up-charge. But they didn’t double the procs. If you’re going to be HA, you’ll need at least two of everything. While they did double the test server procs, they didn’t double the production server procs so the HA version of the 1000-user config should be more like $76,250, in my opinion. Incidentally, it isn’t clear to me what you get for that extra $9,250. I have an open question with the Alfresco folks to clarify both issues.

What about services? Honestly, it’s usually a wash. There are things you can get done faster because you can see the source code but there are other things you may end up spending more time on. When it comes to services, the primary value of open source is in the ability to spend less on the software and still end up getting something closer to what you actually need through customizations (See “Why Open Source?”).

Obviously, big decisions like this should never be made on cost alone. Documentum, FileNet, SharePoint, and Alfresco aren’t perfectly interchangeable. You still have to figure out which one is a better fit for you along all sorts of dimensions. But the stark analysis Alfresco is providing is likely to get a lot of attention from buyers who are particularly price-sensitive in today’s market.

Dogs and Cats: EMC, Microsoft, IBM, & Alfresco release CMIS

EMC, Microsoft, IBM, and Alfresco are announcing today a new specification for interoperability between content management systems (EMC press release, Alfresco press release). The specification is called CMIS which stands for Content Management Interoperability Services (full specification). Other major players involved with the spec include OpenText, Oracle, and SAP.

What the spec outlines is essentially an abstraction layer between content-centric applications and back-end repositories. The abstraction layer is implemented as a set of services (SOAP-based and REST-based). The services are primarily focused on CRUD functions but they also include a SQL-like query language. In his blog post on CMIS, John Newton says that CMIS will become “the SQL of content management”.

This means that, theoretically, a content-centric application can be written that will work with any back-end CMS that implements CMIS. If it sounds like JCR that’s because the two share the same goal, but CMIS is broader because it is language-independent. (Not to be a buzz kill but think about how many applications you’ve seen where the underlying JCR repository could truly be swapped out at no “cost”. It is too early to tell whether that will get any better with CMIS).

In what is really a “dogs and cats living together” moment, think about
this: The new Alfresco Share client (or any Surf-based web application
for that matter) can now be used as the front-end for any
CMIS-compliant repository like Sharepoint or Documentum. (Maybe that’d be a nice “bridge” to have in place while you’re migrating off of those legacy repositories!)

In my post back in June (Slinging some ideas around RESTful content) I mentioned Apache Jackrabbit, Apache Sling, and how there ought to be a standard, REST-based API for working with content repositories. I wondered if Alfresco’s inclusuion of Abdera, Apache’s implementation of the ATOM Publishing Protocol, into the Labs code line signaled Alfresco’s move in that direction. Well, CMIS is that standard. And if you look at Alfresco’s Draft CMIS Implementation, you’ll see that Abdera is, in fact, in the mix.

Back during my Documentum days, a spec was mentioned called iECM that I thought Documentum and maybe AIIM were working on together. But then it seemed like it kind of died. The goals (and some of the details) sound eerily familiar to CMIS. Could the popularity of more modern content management API’s like Alfresco’s web scripts and Apache Sling have spurred the legacy vendors into actually doing something about interoperability for real? (I just saw in John Newton’s blog post that iECM did spawn CMIS but it doesn’t speak to the motivation of the other vendors).

You can try out Alfresco’s CMIS implementation by downloading the latest Labs 3.0 B build. targets Documentum with new ECM functionality

According to CMSWatch, is going to begin offering ECM capability. The post says the CEO is boasting that customers can get rid of their Documentum implementations. For some clients who may be under-utilizing Documentum, that could be true. But I imagine is going to have a lot of work to do to get its acquired Koral software at the functional level required to supplant most large Documentum installations.

Alfresco’s John Newton comments on Dave DeWalt’s departure

John Newton, Alfresco CTO and Chairman, comments on Documentum CEO, Dave DeWalt’s recent departure on his blog. John worked with Dave when he was at Documentum.
As a side note, I’ve met Dave on a couple of occasions–one was a surreal experience in which Dave, Joe Tucci, one of my clients and I threw beads at conference goers from a mini mardi gras float (post). I was impressed with his desire to make a connection with as many conference attendees as he could. Rather than being ushered in and out of a large conference hall never to be seen again, Dave walked amongst the crowd and genuinely listened to feedback from his customers.

I also know he had developed sort of a cult following amongst Documentum employees. From a culture perspective, his departure from EMC seems like a huge loss.

Proprietary ECM solutions continue to aggravate resource availability issue

Alan Pelz-Sharpe noted in a recent post at CMSWatch that it is becoming harder and harder to find talented Documentum and, more generally, ECM skills in the marketplace. This is yet another datapoint in a trend that has been building over the last few years. (In a post last January, I asked Documentum to open up the WDK. The resource shortage was one reason.).

In my opinion, this problem is only going to get worse, at least until open source ECM solutions unseat the proprietary vendors. Developers in the ECM space are much more excited about investing their limited
resources in open, standards-based platforms.

Becoming a guru in a proprietary solution within a rapidly commoditizing market may yield short-term gains but is a dead-end in the long-term. Ironically, it’s those short-term gains that make the problem worse–the people currently enjoying those short-term gains are more likely to continue riding the wave than they are to move into an IT shop.

So I see open source ECM solutions as helping the ECM market with the resource availability problem in two ways: (1) by being built on the frameworks today’s developers are interested in learning and (2) by removing the primary barrier to entry (software license and cost) thus exposing more developers and companies with ECM solutions.

Regarding the first point, when you compare a developer who’s built expertise around Documentum’s Web Development Kit (WDK), a JSF-like framework for building Documentum web apps, with one that’s invested in Alfresco in which the development model is based on JSF/Spring/Hibernate, the Alfresco developer has a better foundation of transferrable skills, whether that’s to pure web application development or other open source ECM solutions built on a similar stack. Developers spend time learning stuff they are interested in and they pay attention to transferability.

As for the second point, freely-available open source ECM solutions are more likely to find their way into the hands of developers (and the servers of enterprises, see this post) because there are no barriers to entry. This should result in a larger pool of resources experienced with working with ECM, in general, as well as specific open source solutions.

As a thought exercise, think about what the resource pool would look like if closed-source, proprietary vendors were the only game in town? The demand would have to be much greater and the solutions much more interesting to develop any sort of resource base interested in specializing. (SAP seems like a real-life example. SAP folks are expensive and hard-to-find and I don’t run into too many up-and-coming developers begging to be sent to SAP training at this point).

So if you are an enterprise struggling to staff your ECM “Center of Excellence” or maybe you can’t even keep the lights on in your server room, maybe it is time to take a long, hard look at open source ECM.

Is Documentum really “Opening Up”?

One of my former colleagues sent me a link to ComputerWorld’s recent article entitled, “EMC opens Documentum up to software vendors”. Pretty catchy, huh? You might think the leading proprietary ECM vendor has seen the light. Of course you’d be wrong. The article is actually about Documentum’s “Embedded Documentum” OEM offering. I don’t know, maybe I’m just being an over-sensitive open source zealot, but there’s nothing open about Documentum or its embedded offering.

And while I’m on the topic, if I were a software vendor, what would make me want to embed a proprietary offering like Documentum within my software? Wouldn’t it make more sense for me to use something standards-based and open? No OEM license to worry about. Easier to deal with in general. Low or no switching costs if it doesn’t work out. Access to all source code in case I need to make some tweaks. Seems like a no-brainer. It’ll be interesting to see what becomes of it.

Thoughts on workflow and jBPM

I just got back from jBPM training at JBoss. The class itself needs a bit of streamlining but the instructors are aware of that and are working to improve the offering. The technology, though, is very cool. It really got me thinking about how my own workflow apps have evolved over the years and made me even more excited about the up-coming Alfresco 1.4 release (see Roadmap) which will include jBPM as its workflow engine.

Just about every application I’ve developed over the last thirteen years has had some type of workflow. In the early Lotus Notes days, Notes equalled “workflow”. What that meant to most Notes applications was that there was a field on a Notes document that kept track of the document’s status. Security on the document (or even fields on the document) would change based on that status field. Moving from state-to-state was handled by any number of bits of code in actions (macros) or form events. Every aspect of the business process was essentially diffused into every nook-and-cranny of the Notes database. There was no concept of a central definition of the business process–the process was everywhere. Ironically, Lotus Notes–the de facto standard for “workflow” applications–didn’t have a built-in workflow engine as we would identify one today.

Custom techniques for handling workflow evolved over time. In a custom content management application I was involved with, for example, we developed our own XML-based state engine to handle workflow which was a vast improvement over simple field-based state management. It had its own API you could call to move documents through the process and supported simple events like sending an email notification. At about that time, third-parties began offering add-on products for Lotus Notes and Domino that let you define, manage and execute a process in a similar fashion. Although loosely-coupled with the app, you were still tied to the underlying Notes/Domino platform.

Then I began working with Documentum. Documentum’s Workflow Manager (and, later, Business Process Manager) uses a graphical tool to define process templates which are then instantiated and executed in a run-time (Tomcat) that runs within the context of the overall Documentum content server. It worked pretty well for every project I ever used it with, but it has a few short-comings:

  • Although the marketing hype is that any business analyst can create and manage the workflow, this is true only for the simplest of processes. Every workflow I have ever worked on is complex enough to require automated activities (tasks written with code). In Documentum’s workflow tools automated tasks are not transparent to the analyst. So working with workflows is inherently a “development-oriented” task. Expecting that a non-technical business analyst can change a workflow without significant knowledge of the underlying application just isn’t realistic.
  • The process definition is proprietary. Your two choices for creating and managing process definitions in Documentum are to use Documentum’s graphical tools or by writing your own custom code against the Documentum API to create process definitions. On a related note, the definition isn’t human readable without the tool–you can’t just pull up a Documentum workflow template with a text editor to see what’s going on.
  • The concept of lifecycles and processes are separate. To me, the concept of what state a document is in (Documentum calls this a “lifecycle”) and the process a document goes through (“workflow”) are so interdependent they should be modeled together. In Documentum these are two separate concepts. I suppose it can be simplifying–if you only need states you can just use lifecycles without workflows. But I always found it a bit clumsy when dealing with the interactions between the two.
  • The process definitions are tightly-coupled with the Documentum platform. The obvious problem with this is that processes defined within Documentum are not portable to other content management systems or workflow engines. In my clients, I also saw this as a source of confusion–when should they use the “embedded” workflow within Documentum versus another workflow product?
  • The framework is limited and cannot be easily extended. Documentum’s workflow is purpose-built for moving documents around, not data. That’s great if you are working with files but there are many applications that need process functionality that aren’t document specific. If you’re working with the Documentum workflow engine and you just want to route some raw data around your only real choice is to put it in a “content-less object” and route that around. And because the framework is proprietary you couldn’t fix this if you wanted to.

Now I’m digging in to jBPM and I’m excited about what I’m finding. Loosely-coupling the workflow engine with the content management system, basing the process definition on open standards, making the implementation open and extensible, and providing a run-time that requires nothing more than a servlet container and a relational database creates a robust, flexible workflow engine that addresses many of the shortcomings of embedded, proprietary solutions. jBPM is one example of such a solution but there are others in the open source world.

jBPM process definitions can be defined graphically using an Eclipse plug-in. Because the process definition is expressed in XML, you also have the option of writing these by hand, programmatically, or with any tool that can output XML.

Don’t like the out-of-the-box jBPM implementation for a “split” or a “join”? No problem. Override their implementation with your own logic. In fact, adding your own logic to the process is usually as simple as pointing the event handler for a node or transition to a POJO that implements a simple, often single-method, interface.

Any application can take advantage of the engine. Integration is possible by directly talking to the jBPM API or through less tightly-coupled methods such as JMS and web services.

If you are a Documentum customer about to implement a process-centric application, should you ditch Business Process Manager and go with something like jBPM? I’m not ready to draw that conclusion. What gets me excited, though, is knowing that I can implement robust workflow in any application I build by leveraging an open tool like jBPM. And when open source projects like Alfresco incorporate it into their solutions, I don’t feel like I’m giving up anything when compared to proprietary competitors. In the case of Alfresco with jBPM compared to something like Documentum and its proprietary, embedded worklfow engine, it actually feels like I’m gaining functionality.

To learn more about jBPM, check out the jBPM Wiki. Specifically, the Getting Started Guide has everything you should need to start learning.

High-end document management getting squeezed?

Tony Byrne points out something I’ve seen happening at my clients recently as well: collaborative tools like Sharepoint and eRoom are being leveraged for “informal” document management while high-end tools such as Documentum are used for “formal” document management.

This sounds familiar. For most of the 1990’s me and my colleagues were hardcore Lotus Notes developers. We never saw any competition in Documentum. At that time we saw Documentum as a niche solution for high-volume, highly-regulated content, or imaging.

The current release of Sharepoint lacks “table stakes” functionality for all but the most basic of document management needs. The two critically lacking features are document-level security and any semblance of a basic workflow. But Microsoft looks to be addressing both of those features and more with its 2007 release.

As the price gap between Sharepoint, eRoom, open source solutions and high-end ECM platforms increases, and as things like web services make integration less of a headache, could we be seeing a regression in how the market views offerings like Documentum, i.e., only for the 10% – 20% of the specialized document management needs in an enterprise?