Saw a tweet today that was pretty exciting. It was referencing a “comparison” between SharePoint and Documentum. I was initially excited. I’d love to see CenterStage and SharePoint compared. I compared SharePoint to eRoom a couple of years back and wasn’t planning on a comparison with CenterStage until the database/list functionality was ported over.
My excitement was short-lived.
I instead encountered a piece that resembles propaganda more than a fair and balanced comparison. That may sound harsh, but I will defend the charge.
Subtle Hints
I first got an indication that there may be issues in the opening section. This quote in particular was interesting.
[Documentum] can be viewed as a content aware RDBMS layer above the traditional data layer.
That understates Documentum’s capabilities dramatically. The point being made in this section was that SharePoint was design from the UI to the backend and EMC has traditionally been focused on the backend to the detriment of the interface.
That is true and does help frame the conversation. Then things fell apart.
Comparing Apples to Peas
So things start to become interesting when the next section starts to discuss business logic. I won’t dive into the synchronous/asynchronous aspects of the BOF (it can be both), but the statement
Lately improvements in .Net and Microsoft SharePoint’s best friend K2 has begun to fully exploit the SharePoint vision
Uh, I thought this was a comparison between SharePoint and Documentum. If SharePoint is going to bring friends, like K2 blackpoint, to the show, can’t EMC?
He then begins to belittle the Process Engine. The term newish is patently incorrect. It has been around for years. I’m not saying that it is better than K2, either the blackpoint or full-featured blackpearl product, but we aren’t comparing Documentum and K2, are we? I thought we were comparing SharePoint with Documentum.
Cloud Capability
Microsoft has the lead here. I’ve used Documentum in the cloud, but they don’t have a commercial approach yet. The sentence that catches my eye here was:
Microsoft on the other hand is now releasing Office/SharePoint 2010 expressly to improve (if not completely mature) the cloud model.
Really? We are now comparing an unreleased version of SharePoint with Documentum. Forget that there is an upcoming release and announcements scheduled for May at EMC World.
Funny side note, Microsoft has decided to release SharePoint during EMC World. Coincidence? Unlikely in this industry, but distinctly possible. The Documentum related announcements could be unrelated to the Cloud. I would say that comparing SP2010 to anything should at least wait to see where those products are at the time of the SP2010 release.
EMC keeps its cards closer to the vest than Microsoft, so rushing to any conclusions about where things will be after EMC World is premature.
Besides, I’ve used an Amazon hosted Documentum instance before. It was a year ago for the AIIM CMIS Demo and it worked just fine. It isn’t a technology issue, so anything could happen.
That said, does K2 work with SharePoint in the cloud? Will it work with SharePoint 2010? These are all gaps in the analysis that are left begging for answers.
I do love how he mentions that EMC needs to take virtualization into account. I wonder if he forgot that EMC and VMWare are kinda tight.
Oh, and for the multi-server installation. I can’t definitively tackle that one, but it FEELS misleading and wrong. I just can’t prove it without more research at this time. I don’t want to commit the same errors that I am bring the author to task.
Easy to Choose
It is easy to compare anything on just a couple of characteristics and pick a winner. Nothing is the best at everything.
“DOS is better than any operating system today because it’s memory overhead is incredibly small.” How many DOS deployments have you seen lately? There are reasons for that.
This is an extreme example, but it illustrates the fallacy of the approach taken by the article.
Give me a fair and balanced review. I don’t care who wins, just give it to me. I’ll be doing one of SP2010 to CenterStage this summer. I think that will be the right comparison point.
There are times when SharePoint is the right answer, and times when Documentum is the answer. The article, as written, will not help you figure out which is which.
Disclaimer
I may be a partner of EMC, but I have more revenue coming from SharePoint projects these days than Documentum. Documentum work isn’t slumping as much as SharePoint work is booming.
Word of Pie 
I’ve actually created a highly customized, internet facing, highly secure customer portal using Webtop, gasp – “What is webtop?” (EMC-Documentum’s feature rich J2EE web interface)… I’ve also seen eRoom, installed it, configured it, rolled i tout, etc. Also SharePoint.
I like SharePoint for what it is but to position it against Documentum you need to ignore two things 1) the true cost of SharePoint implementations ( ie most organizations hire a lot more programmers and admins for SP than DCTM even of the seats are the same) are higher than you think 2) Documentum does a ton of things out of the box without customization.
My only issue with DCTM, and I am one, is the high cost of expertise. DCTM experts – I mean really experts and not those who have padded their resume, who are rare as “hen’s teeth”. These sort of people can scare off managers, but imho, they are worth it.
LikeLike
I truly enjoyed your comments regarding my “comparison”…. I think it is pretty rare in the Documentum partner community to get a great conversation in the open regarding future prospects.
Please note that the intent is more to spur that conversation and raise the question regarding EMC Documentum direction (up or down). I have been working deeply with Documentum for over a decade now and see both good and bad with the present architecture. Many of my clients have been running implementations with pure Java blueprint UI’s for years without issue.
Please don’t construe my comments as being down on the “new” process engine… I actually think that Process Engine is the brightest piece of the backend server components at present. With that said the Forms Builder is let’s just say a bit behind the competition @ XForms 1.x (I prefer Silverlight to InfoPath btw).
The addition of a composition based UI (in-product process authoring, not thick client) would go a long way to bringing full K2 capability and ease of use into the Documentum stack. Hopefully we get this at EMC World along with a workable development environment allowing for reasonably easy implementation moves from test to qa to production.
I have had discussions with K2 regarding their future in the SharePoint online (BPOS) offering and the possibility definitely hangs on 2010 release later this year.
With regard to virtualization Documentum is pushing more deeply into JBoss with each release but the original content server basically remains intact from Howard Shao’s early days. Not bad, but not architected with the cloud in mind.
Running virtual server’s at a “cloud” provider isn’t quite the holy grail of multi-tenant cloud based services. Also we need an operational model for Documentum pricing – user/month fee based – to make the whole thing workable.
As long as I am rambling, I really like the prospects (admittedly not yet fully realized) that SQL server 2008 provides to encompass the content enabled back end in a single tier (the RDBMS is already the bottle neck). Hopefully Oracle and DB2 will add like functionality for File Streams.
Best Regards,
Ed Alexander
LikeLike
Thanks for replying. I like your comment more than the post that I dissected. My primary issues were around the comparisons being made versus the title of your post. Definite mismatch. K2 is not part of SharePoint. I have to go to another vendor, so it is more than an option.
That said, SP2007 was not designed for the cloud. Hell, for the “cloud” to be effective, it should handle anything, designed or not. I know Documentum will work in the cloud. Used it. What it needs is a 64-bit version that will allow it to marshall more resources without scaling with multiple instances. I would argue that SP2010 was also not designed for the cloud. Doesn’t mean it won’t work well there.
Pricing is a whole other ball of wax.
LikeLike
Yes, I agree about comparing apples with apples. If you look at a comparison where a solution ie DCTM/eRoom or SP meet a basic need that SP meets then I suppose a comparison is warranted for that situation. However, overall it is not an apt comparison at all.
On the cloud side, all it would need is some sort of SaaS provisioning front end and DCTM, with its robust scalability and security, would be great… if only that per seat licensing fee could be dealt with…
LikeLike
Great write up. Thanks for that. Would love to chat with you about it. Let me know if you have some time.
LikeLike
I’m currently knee deep in performing a comparison between our Documentum and SharePoint implementations so it’s a hot button. I’ll try to be brief. I’ll cross-post back to Ed’s blog as well.
I’m only going to take issue with the Business Logic section. (I’ll save any comments on Cloud readiness for another time.) From the way Ed wrote, he mistakenly implies that the Process Engine is “newish”. It isn’t new. Just a name change for something that’s been included with Content Server since the 4.x days. The heart of the code *hasn’t* changed.
Being old doesn’t mean that it’s outdated, instead is an indicator that EMC got it right the first time. The Business Object Framework, has been enhanced and supplemented by Documentum Foundation Services. Frankly, there are few limitation on what you can do with it.
I’ll go on record and completely disagree that using K2 and SP2010 won’t require a full-time person. It will. That person might not spend his entire time in Visual Studio, but it still takes considerable time to create and maintain a SharePoint workflow. For one thing, I’ll need to engage both K2 and MS and still do some custom work to equal that what I get *out of the box* with Documentum… in version 5.3. The workflow capabilities of Documentum are light years ahead of Microsoft in 6.5 and without the pain and effort required. Give me functionality *NOW* rather than betting the farm on a release later this year and another two years to learn and implement it.
Now you have something with Forms Builder. It isn’t where I want it to be as a product and the UI still needs enhancements. That being said, I tear my hair out more over Microsoft’s crappy XML implementation.
Two side notes: 1) The switch from Apache to JBoss in the method server was done from a performance standpoint. Apache was the bottleneck. If you really wanted, the method server can be run on any application server platform. Apache, JBoss, Weblogic, Websphere…
2) Anyone touting the superiority of using MS SQL server in a CMS environment is off their rocker. It’s good and it’ll do the job, but a “single scalable” platform is also a single-point-of-failure. I’d rather have the ability to separately manage my database and my files based on rules that I create. MS SQL doesn’t give me the flexibility that I want.
LikeLike
Apples to Oranges indeed !
SharePoint is ‘lightweight’ document centric collaboration – there is a reason the analysts coined the term “Basic Content Services” to describe it. I will not even call it an ECM platform, although it may reach that capacity with the SP2010 improvements.
Documentum on the other hand is an ‘industrial heavy weight’ – I admit its based on an underlying architecture that is getting on a bit, but if were are going to talk architecture lets not forget that worse thing about SP – by default it stores content items as BLOBS in the RDBMS – Yuck !
So, my bottom line is – you can’t compare them, they are too different. Pick the right tool for the right job – shock horror ! Wow, guess what, you can even use them together….. 🙂
LikeLike
Actually,
Apples to Apples
Microsoft SharePoint and EMC Documentum are kissing cousins in the latest Gartner Magic Quadrant (pre SharePoint 2010) with Microsoft in a slight lead [see CMS Wire].
Just to back up the claim, take a look at the pharma industry moving into SharePoint based FDA submission tools. Additionally, the last two banks I have worked for are moving into SharePoint as well. Don’t think that EMC does not need to compete with SharePoint for business in their traditional markets. EMC currently holds an advantage in records management and is soon to move on to its second generation composition model rapid CEVA development toolset. My personal belief is that when Documentum gets their technology direction focused (leave Adobe Flex behind) and update the composer toolset we will see lower prices and a push into the SMB market and cloud based services.
EMC does have a great product for removing BLOB storage from the SharePoint site collection (not Documentum though).
Best Regards,
Ed
LikeLike
Tap the brakes a bit on touting the “magic quadrant”. The placement of any company in Gartner is dependent on the weightings and the criteria. In the ability to execute section, Microsoft gets brownie points because of the high weighting to company viability. Forrester’s assessment has Microsoft outside of the Leader box because their greater weight on features. A company that’s doing their own product evaluation will need to consider what’s best for their particular situation and not solely rely on one researcher’s opinion.
(As an aside, if the evaluation was made pre-SharePoint 2010 it doesn’t make the report invalid. It’s impossible to fairly to compare feature sets of a unfinished product to one currently available. That is instead factored into the strategy/vision portions of the reports. If you disagree, then allow me tell you that Documentum 14 totally dominates SharePoint 2017.)
A few weeks ago, there was discussion here on how EMC needs to not ignore it’s traditional markets. Personally I think the current approach of “Peace, Love and We Can All Get Along With SharePoint” hasn’t been working as well as a more direct “SharePoint is nice, but you really doesn’t do what you think it does” approach could. Being more confrontational would drive innovation on both sides.
BTW – Could you clarify what you meant about removing BLOB storage… specifically the parenthetical “not Documentum though”? While SharePoint OOTB forces BLOB storage upon users, Documentum doesn’t use BLOB storage, hence EMC wouldn’t need to develop such a product for Documentum. Not exactly sure what you meant by that.
LikeLike
Chris,
I think Ed is referring to SourceOne for Sharepoint that is coming out in the near future. It will be able to extract BLOB content from inactive Sharepoint repository and put into searchable SourceOne repository.
-Johnny
LikeLike
I think what is driving adoption of SP vs DCTM is really a SP vs eRoom debate since it is all about collaboration portals for the most part. Then, once the content is hosted in SP, the question remains of what to do with it after the fact. It also raises the point; “Now that we have it in SP does it make sense to spend all that money on DCTM?”
I believe that the price war, other than the price of SP vs eRoom, is also the cost of developers, etc. Just try and find good DCTM people in outsourcing shops… I have tried and each time they say “Give us your requirements and we will provide resumes.” Then I see the jobs posted on the job boards…. Finding SP and Alfresco developers offshore is much easier. However I am not sure if companies now experimenting with the offshore SP customization route will find it acceptable in the long run. That remains to be seen.
If the outcome of the original question is use existing DCTM as a backend to a SP front end there are a good many solutions proposed and on the market now that require docapps, installations and web parts (SP) to implement. Most of them use a “put a link in SP where it can display the content which is hosted in DCTM” approach. This basically treats SP like a DCTM client. In some cases that will work but it restricts SP deployment and it looses much of it’s spontaneous departmental level deployment benefits. Usually departments deploying cms systems don’t think of the long term consequences of sprouting SPs like mushrooms until a crisis occurs. The eDiscovery people like Autonomy love random SP instances and shared drives because it costs oh so much more to do eDiscover when you don’t have an enterprise info strategy.
What I like is a distributed model where there is some sort of enterprise model for taxonomy and metadata and a way to have non intrusive, zero impact queries and updates to a centralized DCTM “mothership”.
LikeLike
Mike, you’re describing Content Intelligence. The magical ability to upload a document and the system decides (based on rules you created) where to stick the document. It’s called Content Intelligence because the end user often lacks the intelligence to sort documents themselves.
The first part of your message pretty much describes the Microsoft marketing strategy. Deviously brilliant, like a crack dealer they’ll give you the first sample for free until you’re hooked and then you have no choice but to continue paying for what you need. Seriously, it’s genius the way it works.
LikeLike
Chris, I like the concept of content intelligence. In fact I like to switch it around to call it intelligent content. Not too far fetched if you take it to the Java object level. My business partner, Andy Taylor, is the genius behind the Benow java object repository (http://benow.ca/admin/project/index.page) that we use as a platform for our integration engine which takes that approach.
I agree on the MS marketing plan. I don’t feel that DCTM have responded appropriately. This is probably due to their business model needing to be turned on its head, but the competition is heating up and they need to adapt and quickly.
LikeLike
Even as a MS Partner specialized in Sharepoint (with a Documentum partner) my neutral advice to customers is to use:
-Sharepoint for simpler projects with limited data ( 10 TB or > 20 milion docs) and high complexity (e.g. records management standards compliance and advanced content services)
That said Sharepoint 2010 is sneaking up on the scalability side, but will not match the “process” side capabilities (regulation in standards, FDA,…) of Documentum (and OpenText).
That said also licensing plays a role, even a corp already owns Sharepoint as collaboration hub, it’s difficult to sell Documentum if no advanced features are required …
LikeLike
Seems some sentences were cut from my comment.
I meant:
-Sharepoint for simpler projects with limited data ( 20 milion docs) and high complexity (e.g. records management standards compliance and advanced content services)
LikeLike
Stefan, I think that you have a good point about the simpler projects and lower volumes. I think your number of docs also needs to be balanced against the number of concurrent users as well. SharePoint is not going to scale well under a high volume of concurrent users, or at least not like Documentum will. I suspect your 20 million number might be a little high in many cases. There is also a lot of functionality built into Documentum like lifecycles and workflows and many other features and products that don’t compare.
What I find alarming is that in many organizations management is not placing appropriate value on proper analysis of the business process involved around the production of the content and merely throw technology at a problem which in fact just accelerates a bad or out dated business process.
LikeLike
Mike,
on the scalability/concurrency front I’m not concerned as Sharepoint 2010 will take care of that with Remote Blog Storage (where blobs essentialy bypass the RDBMS on storage and streaming), with MOSS 2007 we rewrote the standard Sharepoint pages with some tricks to better handle large files via http
As said, Documentum (and others like Open Text, Stellent, Filenet) are ahead in functionality out of the box (encryption, rights management, granular security) and from the insider in MS I know MS will never specialize Sharepoint as much …
Also with Sharepoint it’s possible to get the advanced funcionality (given time and money): we coded some extra bits and almost (RM auditors we’re happy already) got MoReq2 (European Records Management Standards) compliance on a Sharepoint implementation with lesser costs that the difference of Documentum-Sharepoint licensing …
Anyhow, on our next project we will tackle a project with Sharepoint 2010, where the customer produces 2-3 milion documents a month (and we might have go back 15 years if not more), I’ll hope to be able to tell you how that works out on Sharepoint
LikeLike
Stefan, that is a high volume per month. Good luck with that one. I suspect you will seriously need to tune the SQL Server instance and cluster the SQL Server and SP environments with fail over to allow for maintenance. If you would like to talk offline about high volume injestion or integration I’m at Mike(dot)clarke@qtility.com
LikeLike