Well, the time has come to talk about the elephant in the room, SharePoint. It was a slow conference for me regarding SharePoint. I didn’t attend any normal sessions on it as I was usually being pulled away by other items. I did get a lot of time with Andrew, Erin, Craig (yes, Craig), and a boatload of partners talking about the SharePoint problem.
Problem? Yes, problem. The problem is that nobody knows what to do to make everyone play together. I’ll tell you right now, playing together is required.
Partner for Your Thoughts?
In the expo area, every other partner had a SharePoint/Documentum solution. The rest were either storage partners or ones that won’t have a booth next year. SharePoint was that popular. I had a heck of a time talking to colleagues and friends working booths with SharePoint solutions.
There are a lot of solutions out there. A majority of them focus on creating Web Parts and using them to interact with Documentum. These are basically using SharePoint as a portal. I was able to throw several requirements at each partner that showed gaps in their solution.
That isn’t to say that the solutions were bad. Far from it. Many were innovative and implemented well. I will be keeping several of them in mind for use at clients. They are just solutions to aspects of the bigger problem. They aren’t a true joining of the two technologies into something that can work for the Enterprise.
They are old-school solutions using new technologies to jazz them up.
EMC and SharePoint
EMC’s status was both disappointing and reassuring. The disappointing part is that there is no architectural improvements to the solutions being offered. They are basically the same as those last year. The reassuring part? Simply put, they looked at what they had been working on as a next step and realized that it wouldn’t solve the problem either.
A lot of what I learned was that the SharePoint team has been trying to determine where they can best add value for their customers. Trying to do it all would equate to no solutions in the short-term, and people need help NOW. There are a couple of levels to the help needed, which I, and others, shared with Andrew and Erin.
The biggest need is to take the content out of SQL Server and store it in the Content Server. It can’t end there though. If content is just going to be stored there, why not throw the content on a secure file share? Easier and cheaper. To store it in an ECM system, you need to add business value. The act has to “enable” the content for use throughout the organization.
The added value is the crux of the problem. If you are going to interact with the content through Documentum or in some other interface other than the original SharePoint site, you have to take Identity Management into account. If someone secures a document in SharePoint, shouldn’t that be reflected in the Content Server? If a records administrator locks a document down in the Content Server, shouldn’t that be reflected in SharePoint? These permissions, and the users and groups involved, need to be everywhere.
My favorite challenge presented by Andrew on this thought, and he had an excellent point, was what happens if a user wants to remove it from SharePoint, but they don’t have rights to delete it in the Content Server? Do you allow the user to delete the shortcut in SharePoint or fail the operation completely? My answer: YES! It should be configurable by installation and site, and transparent to the end user.
ECM 2.0 is key here. The SharePoint user shouldn’t know that the content isn’t stored in SharePoint natively. It should appear as if they were only using SharePoint.
What about throwing Lifecycles and Workflows into the mix? I can see EMC providing some actions on a document through actions to the document library, but leave the web parts alone. The partners are ahead on that and they are doing quite well.
EMC should probably play the leading partner solutions up on their website, delineating what they do and emphasizing the value that they provide. It should be very visible. The partners and clients would LOVE it. Thus, it probably won’t happen.
Did You See That?
Yes, I threw in the need for Identity Management up there. Just because we want users, groups, and access control lists everywhere doesn’t mean I want to go everywhere to administer them. I want to manage it all in one place.
I hit the DFS people up on this need and told Andrew why he needed it as part of his solution. SharePoint and Documentum should work together using an ECM SOA standard. A key aspect of this is the ability for the systems to share Authentication and Authorization sources. This is a problem that everyone faces. The first ECM vendor to solve it will have a leg up on the others when it comes to being the backbone of the Enterprise.
Right now, if you lock something down in SharePoint, you have to lock it down separately in the Content Server. The exception is content exposed in Web Parts. The content isn’t really in SharePoint, which limits the ability to truly collaborate.
Is web parts the answer? Kill Document Libraries and just use the web parts? That solves the problem on some levels, but it isn’t what I would call ideal. It turns SharePoint into a portal and shifts the focus away from being a collaborative platform. That is its strength and why it has spread so widely.
Take that away and we may as well wait for Magellan. 😉
7 thoughts on “SharePoint and Documentum, Patience is a Virtue”
I’m interested in why an organisation would want to hook up SharePoint and Documentum.
Is there any value in integrating Documentum with SharePoint? Why bother with Documentum at all when you can just use SharePoint? Basic Content Services appear to serve the needs of many (most?) organisations. SharePoint lacks feature depth compared to ECM heavyweights like Documentum but despite this has blitzed the competition. For any missing ECM features, you could integrate with more MS-orientated products such as K2, Meridio, etc. Wouldn’t a more MS-centric approach provide tighter integration with SharePoint compared to Documentum plus Vorsite/Wingspan/etc?
I just don’t understand why organisations are trying to integrate one ECM with another. Would it make sense to just pick one solution and make the best of it? I get the feeling that the SharePoint integration is just EMC attempting to convince customers that Documentum does not have to be replaced but can co-exist. Rather than ride the coat tails of SharePoint I would like to see EMC and other established players attempting to take SharePoint head on (Alfresco seem to take this approach).
Is this where Magellan fits in?
Your problem here is that SharePoint is not an ECM solution. It breaks down under volumes and in mid to large size organizations, it is actually creating silos of content.
SharePoint is probably two releases from being able to handle it. First they have to get the content out of the database. Then they have to scale. They’ll make great strides in the next release, but the amount of content to store is increasing, so it will take a couple of releases to catch the curve.
In the meantime, I’d rather minimize the missing functionality with as few vendors as possible.
As for Magellan, way too early to say. It looks promising, but a lot of it will depend on timing and quality.
>Your problem here is that SharePoint is not an ECM solution.
I agree that SharePoint isn’t ECM in the same way as traditional ECM products. This isn’t necessarily a bad thing though. If this was a problem then SharePoint would not be as popular as it is. Sure, there are features that would enhance SharePoint but by the same token perhaps Documentum & co are a little bloated and overpriced. Perhaps Sharepoint is popular because it’s not a typical ECM solution.
I’m not sure what you mean by silos of content. If you’re referring to having multiple content stores then yes most businesses have such silos whether they have Documentum or not. Are silos really a problem in the age of SOA, search engines, etc?
>SharePoint is probably two releases from being able to handle it.
Possibly. SQL Server.next will allow content to be stored on the file system so it seems reasonable to assume that SharePoint will get this feature soonish. I’m not aware of any scalability issues with SharePoint – can you point me to any articles on this? I thought that SharePoint _was_ being used in large organisations. Don’t MOD & US Navy have large SharePoint deployments?
I appear to come out in favour of SharePoint but my background is actually in Documentum. I am wary that SharePoint changed the ECM game and that the traditional ECM players appear to be slow to react (other than providing SharePoint connectors).
SharePoint Scaling Limits by Mark Harrison. Those limits are pretty soft. Remember, each version of a document counts against the limit. Some good qualifiers are listed here.
Craig Le Clair of Forrester wrote about the limits in even better detail this Spring.
I know that the Navy is not using SharePoint for ECM as a whole. They are using it for collaboration. They have ECM systems as well.
We can agree to disagree, but SharePoint is not ECM. It doesn’t scale and it most of the important features in an ECM system are missing. It is a Collaborative tool that can hold content and that can serve as a portal. Period. It may be more one day, but it isn’t now.
As for silos, that is a whole other problem.
Hey guys, I have to disagree with both of you !
Whilst I agree with our earstwhile host Pie, that MOSS2007 (aka Sharepoint) is absolutely not an ECM system, neither is it a collaboration system, it is in fact a good old fashioned ‘portal’. The other part of the Sharepoint family, WSS is fairly well focused on collaborative web sites, and MOSS adds to this for sure, but it a portal framework, hence WebParts !
I shall blog on this and link back here later 🙂
The big issue is security
Where you need a secure environment .Net does not do the business. MI5, CIA and others need a secure repository hence a Solaris ECM solution
I disagree, to a point. I don’t think the problem is the underlying tech. The problem with security is the design of the security. There are too many security systems that won’t talk to each other.
Comments are closed.