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

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.

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 …

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.

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.

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”.

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

(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.

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

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…..

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.

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…