Apologies to Andrew on this post, but I’ve got to get everything out of my system before I learn anything new NDA items about the two products working together. I think EMC is moving in right direction on these products, but they aren’t there yet. That being said, their current approach is easily the best that I’ve seen, and I’ve seen a lot.
Why SharePoint Repository Services Rocks
This is the product that Andrew has been hinting at for a long time on his blog. It uses External Blob Storage (EBS) to intercept content being stored in the SQL Server database and places it in the Documentum Content Server. The most important details of this product are that it has ZERO impact on the user interface and is completely independent of any customizations that may be made to SharePoint by the organization.
It is only a point-forward solution, but if your SharePoint system is still functional and not bogging down, it can keep it that way. A backup-and-restore of your SharePoint site can get things moved into Documentum, but that should only be done by experienced people. I’ve yet to meet anyone who considers such a procedure routine, so it should only be done if necessary to take a SharePoint site that is suffering from too much content and get it all into Documentum.
Now there are a couple of flaws, like SharePoint versions being stored as separate documents in the Content Server, but is just one way that things aren’t as simple as they seem. This flaw is going to be addressed in a future release and only exists due to some fun complexities in how SharePoint manages versions. It does lead to some other issues.
Where the Solution Falls Down
So here is the basic problem, or problems. All of that content can’t really be interacted with through many normal Content Server based interactions. Oh, there are some basic things you can do, but you can’t change the security and I suspect the ability to create new versions within Documentum and having them appear in SharePoint may be tricky.
Don’t forget that a versioned document in SharePoint spawns multiple objects in the Documentum Repository. That makes some actions difficult.
Of more importance is the fact that you can’t start declaring records directly from the SharePoint Document Library or see documents within SharePoint that originate from within Documentum. You can do those things using Content Services, but that is a Web Part and IS something different for the users to use.
And don’t get Chris Campbell or I started on the lack of any workflow interfaces in the solution as a whole, but that is another post.
What Can Be Done?
Um…Nothing? I’m not sure what can be done. This is a very complicated problem. To make things work in a way that will be seamless to the user while enabling all the requisite functionality is going to require a much more intrusive SharePoint customization process. To complicate things, SharePoint 2010 is on the horizon with its 64-bit architecture and CMIS support. What that will mean to users is unknown at this point. What it means to developers of SharePoint solutions is that they should be careful to not invest too heavily in items that won’t carry forward into SP 2010 readily. Web parts are probably good, and probably EBS, but everything else is risky.
These are still two different systems and nothing in the near term is going to change that for anyone. Content Services for SharePoint may be a decent client into Documentum, but it ignores existing SharePoint Document Libraries and is not the perfectly seamless answer. Repository Services is a great way to add some advanced ECM services behind the scenes of SharePoint, but it has several limits.
The problem is we need both, and in a way that inter-operates well. After a few years of watching many different vendors attempt this, I’m not sure if it is even technically possible given the constraints of integrating into SharePoint. EMC is moving in the right direction, but I’m not sure the desired state is possible.
Any bets on whether or not SharePoint 2010 will make this all easier? I know which way I’d bet.