Documentum vs Sharepoint – Round 1

I have been asked by many people to differentiate Documentum and Sharepoint.  For a detail analysis, I have always recommended that customers contact Gartner and other like firms that can truly perform a competitive analysis.  That being said, I think I can at least identify some obvious architectural differences that might aid potential customers who have to choose one platform.

  1. The obvious – Sharepoint only runs on Windows using Microsoft SQL Server.  If you are enterprise standard is UNIX/Linux or Oracle/DB2, then Sharepoint is not a valid option.  Documentum is OS and database agnostic.  Documentum is supported on various OS and database configurations.
  2. The next obvious – Sharepoint is built on ASP.NET; thus, customizations are done via .NET framework.  Documentum is built on DFC, which is built on Java.  You should consider the development and support skills of your staff when considering which system to choose.
  3. Content Storage – Sharepoint stores content within the SQL Server database.  This allows Sharepoint to utilize SQL Server native search capabilities.  This also means that backup of content is solely dependent on backing up of the database.  Documentum stores content on a file storage system and content metadata in any database.  This architecture allows for multi-server single docbase configuration.  Since content is stored on file system, you can also create a mix storage architecture composed of SAN, NAS, RAID, tape, etc.  

Stay tune for Round 2high level feature comparison.


13 responses to “Documentum vs Sharepoint – Round 1

  1. Interesting comparison….I never thought sharepoint and documentum were solving the same problem though so I’m not sure what the point of the comparison is. Documentum is a repository for long term data management….while sharepoint is a collaboration and document interface.

    Shouldn’t the comparison be eRoom vs. Sharepoint?

  2. Hi Josh,
    You’re absolutely right. From an application perspective, the Sharepoint features should be compared to eRoom features. This post was more focused on an infrastructure perspective (OS, database, etc). In my next post, I will try to highlight application feature differences.

    One question I have for you is what is your definition of “long term data management”?

  3. I’m still confused then, Documentum scales very well with SQL as the database and windows as the OS (regardless of any sharepoint integration). If the company uses primarily windows apps and needs to solve the problems that documentum solves….then they absolutely should deply Documentum with the windows components. If they happen to be more unix focused, then they should use unix. I’m still not sure what that has to do with the problems that sharepoint is solving and the problems that documentum is solving , the two co-exist just fine…

  4. They do co-exist fine; more so when D6 comes out. As you indicated in your previous post, the real comparison comes into play when looking at Sharepoint features vs eRoom (or Webtop Collaboration edition) features. Before looking at the features, you should always examine if the infrastructure required for each app matches your company’s environment.

    If your company is primary a unix shop, buying Sharepoint may not be beneficial, since you have to invest in windows hardware and .NET programmers.

    If your company is primary a windows shop, then there is a lot more to consider when deciding to buy Sharepoint, or Documentum, or both.

    I hope this clarifies the intent of my post. Maybe I’m pointing out the obvious to you, but I have had quite a few people ask me whats the difference between the two.

  5. ok, I see the point then, from a unix shop perspective…is sharepoint something that should be looked at.

    Interesting that it comes up from that perspective, but I guess it makes sense.

    Looking forward to the next post!!

  6. if you’re talking about an architectural perspective, what about other options besides sharepoint out there like vignette or alfresco? in fact alfresco is an open sourced ECM option that is also built on j2ee technologies and offers similar benefits that DCTM does.

  7. Your absolutely correct spacegiblet – there are other ECM options out there in the market. I only highlighted Sharepoint because its a topic that many of my blog users search for and I am familiar with Sharepoint architecture. Feel free to post your knowledge about these other products 🙂

  8. I think the Dctm v Sharepoint debate is going to be a very hot one over the next 18 months – I already have clients asking why do we need Dctm if we are installing Sharepoint. In fact it is clear that whilst Sharepoint might have started out as a collaboration tool and dctm was more oriented toward classic document management, there is a definite convergence of features. Sharepoint is considered by many companies as being a possibility for providing content management features and emc/dctm seem to be pushing more and more collaboration features into the core product.

    The most interesting point to come out of Momentum 2006 was the apparently tight integration there is likely to be between D6 and Sharepoint (2007?). The message I took away was that MS Sharepoint is likely to become (for many companies) the UI of choice but EMC is looking to compete with the infrastructural and back-end services.

  9. MOSS 2007 is the best solution to go for if the use case does not demand hard core document management features.
    For example, SharePoint does not support two files with the same name in a document library. But on the other hand, DCTM allows you to store two files with the same name in the same folder within a cabinet (both files will have different docIDs).
    I feel DCTM is a very robust and full featured solution.
    Other thing that drives SharePoint is it’s licensing. WSS 3.0 comes free with windows server 2003.

  10. it’s been almost a year, but I’m impressed with the accuracy of Robin East’s comments.

  11. Pingback: A year later - where is Documentum and Sharepoint today? « Ask Johnny! - Documentum Guru

  12. I would like to know that custom type object should intherited from dm_sysobject or dm_document. what is the difference if we use dm_sysobject in place of dm_document?

  13. Some system level administration objects are created as dm_sysobject, so when performing a generic dm_sysobject select, you will get a lot more results than you expected. So to filter them out, I would perform a dm_document select.

    If you look at the object model, dm_document does not have any attributes of its own. It inherit all attributes from dm_sysobject. I would derive custom type on dm_document just in case DCTM adds some document related attributes in the future.

Leave a Reply

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

You are commenting using your 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