Documentum or SharePoint

Eternal question for a large part of my customers.

Recently, this question turned into “Why keep Documentum if I have also SharePoint?”. At least for some.

Really… why keep it? When is Documentum better than SharePoint for an organization? It’s sure they can coexist, but are they both necessary?

I try to answer this without looking at the existing deployment of Documentum in such organization. This can be sometimes easily changed with a flick of a top management decision. Bad experiences can help also :). So let’s look at the future.

Limiting this further, let’s not talk about transactional content management. Let’s do an evaluation more on the so called “Information Worker” area. EMC purists will say “but since you are stripping away such pieces you’re dumbing down Documentum and it’s not fair”. Well, nothing is fair in love and war. And I’m pretty sure that if an organization would have a massive need for a transactional content management scenario it will evaluate it also from EMC side.

So, looking at Information Worker.. what can Documentum bring to the table?

Core DMS stuff… it’s already pervasive. Folders, files, documents, metadata, security, versions, light worklfows… All this is already in SharePoint. Don’t mind the small differences, they don’t count in this war.

Renditions? Yes.. this is a cool thing. but how to turn in into business advantages? The business is paying usually, not IT. So we need to explain this to business. Can’t. So it’s a no use feature for us. Moving on…

Virtual documents? Sorry. The concept is “so 90’s” (to quote some teens). I have yet to see a regular company making use of VDM and loving it. And we can pretty much implement related features in SP 2010, some ootb even.

What’s next.. storage management. Yes. This is really a differentiator. How to explain it to business? Tough… without a clear value proposition/great sales pitch  this is doomed to be just a bullet in a powerpoint slide.

Cool API (DQL/DFC/DFS)? I love them. Business couldn’t care less. Another bullet in my ppt.

xDB. Eh… another very very nice thing. Why should business care? Well.. we need to show a real use case. From their processes… show some ROI… This really needs to be brought forward since it has no match in SharePoint. Could be a winner, but still requires a partner application / specific solution / CEVA.

Ease of installation? Forget it!

Ease of maintenance? Who cares? And anyway, an existing customer would know everything about the ever troublesome Indexing Server/Agent, UCF and  Java Method Server.

Ease of deployment for customizations? Anybody with some multiple attempts to do DAR installations would grin. Show me how to record a custom metadata information in Documentum… sure.. it’s simple, install Composer, put your development hat, tinker in some “show more” menus, do the technical mumbo-jumbo, create the DAR archive (wtf!), go to the production server console (!), install DAR, should work. In SharePoint? Create new list. You see it works. Sure… it’s not the same outcome, but does the business care? Can you explain the differences? Who cares is not “properly” managed?

Plugins? This is good. Could bring you some leverage especially for surfacing / migrating old content from massive legacy repositories.

Aspects / BOF ? Not useful. In business talk, I mean.

Time/cost to develop something new?  Hmm.. come on! How many EMC Documentum knowledgeable people you have in your geographical area? What about Microsoft partners ready for a piece of SharePoint?

User interface? Sure… let’s change Webtop a bit for some users.. Call in the developers 🙂 Why don’t you use CenterStage? Uff… should I really answer this question?

What else? Search? Come on… I’m never sure what results the search will bring to me (remember, I’m taking about customers which already have and experienced Documentum for some years).

Upgrade to major versions? What about all the Webtop customizations I did? Well… you shouldn’t! 🙂

Why should I use Documentum? Only because I can see multiple business applications on it. But do I see them?

still thinking…..

Advertisements

5 thoughts on “Documentum or SharePoint

  1. I agree with a lot in this article. There are plenty of DCTM features that users are just not interested in. Does this make DCTM a niche product then? Also, if you look at this from the point of view of “what SharePoint features doesn’t DCTM provide?” then the list of shortcomings could include:

    1. User definable types aka lists. DCTM has object types that are developer definable.
    2. Windows authentication. This should’ve been available in Webtop years ago.
    3. Office integration. MS Office is ubiquitous yet there is no standard OOTB way to sync MS Office properties in DCTM. How about publishing content (e.g. Excel charts) to a website?
    4. Outlook integration. Does DCO or MyDocumentum for Outlook actually work? What about syncing contacts, etc?
    5. Web Parts & ecosystem around this. This is huge for SharePoint. Opening up the platform to 3rd party components that can be deployed at runtime is huge.

    Re your comment on Aspects/BOF. I think it’s a missed opportunity by EMC IMHO. Aspects/rules done the Alfresco way demonstrate how powerful they can be for normal users (transforming to PDF, syncing MS Office metadata, attaching Dublin Core metadata, autofiling, etc). Aspects aren’t even exposed to users in Webtop. WTF?

    Regards

  2. Good post. The only aspect I would disagree with you is with your position on virtual documents. There may not be many companies that implement Documentum virtual documents relative to the total number of Documentum implementations, but there are still a good many virtual document implementations out there.

    We’ve talked to quite a few who really wanted to migrate to SharePoint but could not because SharePoint does not have a virtual document implementation, not even SharePoint 2010. Yes, I know about document sets, but they do not behave the same way. I agree that you could certainly create a virtual document implementation on SharePoint using SharePoint components (we did with our docBlock Ascend product), but it is not available OOTB.

    The truth is that there are a lot of document authoring and document management scenarios that are not possible or impractical when your system represents each document as a single file. docBlock Ascend virtual documents allow SharePoint to represent a single document as multiple files opening the door to usage scenarios like authoring a single document across multiple SharePoint farms, read or edit rights to only portions of a document rather than the whole document, and allowing humans and automated systems to co-author a document without the risk of either the person or the automated system overwriting each others edits.

    You can get the details on the usage scenarios virtual document enable or enhance here:

    http://www.blackbladeinc.com/en-us/products/docBlock/Pages/UsageScenarios.aspx

    • Thanks for the heads up, Eugene. I missed the authoring and compound documentation use cases. It is indeed an area in which SharePoint can’t do it OOTB.
      I tried to address in this post the “typical” ECM customer, not a specialized use case (in which case advanced features do really matter).

  3. Pingback: Documentum or SharePoint – part deux « Me and Content Management

  4. Pingback: Documentum or SharePoint – part deux « Me and Content Management

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s