Blimey, two in such a short space of time. This one has been rattling around in my head for some time and I was prompted to write based on the post from Real Story Group.
Now I am not a subscriber so I have not read the full report but the mere fact that there is interest in this subject prompted me to write this. I think CMIS and SharePoint is a difficult topic and I think it is a difficult topic for the SharePoint world. Why? Well its not a simple answer but take a look at this diagram. This describes how SharePoint has been built from the UI backwards. It is the UI which has pushed the development and growth of SharePoint and it is the UI which people focus on.
As a sample when I asked a number of SharePoint Consultants how to integrate SharePoint with an ERP solution they ALL assumed that I meant to have the ERP solution as the back-end repository but with the front end being SharePoint. When I clarified that I wanted SharePoint to be used as the document store for content which is used in ERP transactions then they simply didn’t get this.
CMIS is disruptive to this view in that it puts an unknown on the UI and relegates SharePoint to be a document repository. I use the word relegate on purpose as I believe this is how the SharePoint community would view this Use Case. This is wrong, this is an opportunity to open up a new set of solutions for SharePoint, for it to become more embedded in organisations and be more of a platform service.
I’d love to see some uses of SharePoint with CMIS and how this can open up new opportunities for SharePoint usage in organisations.
One of the reasons why I have not posted something lately is that I wanted to allow the experiences of a SharePoint/Documentum integration project to really settle in before publishing it. Plus I had the opportunity to see where the integration products were heading.
So what has been learned from the experience?
1. Understand why you are integrating the two products! I know this is stating the bleeding obvious but it should be 100% clear from day 1 why you are looking to integrate Documentum and SharePoint. What will the business gain from having this integration? What are they looking to achieve? Is there a specific pain which has been caused which an integration can resolve? I’m a bit fearful at the moment that companies will go down this integration route because it is seen as the thing to do and it will improve their management of content by having an integrated approach. Actually an even better improvement could be settling on one product or the other.
2. Understand the limitations of the integration products. We have used the EMC Documentum Repository Services for SharePoint AND the MyDocumentum for SharePoint products. Using both products is not something which I would usually advocate but the specific needs of the customer required this, and the solution does meet their needs. However you should understand that there are weaknesses to each of the products. Do not expect MyDocumentum to allow you to do all the things you do in a WDK environment through SharePoint. MyDocumentum provides you with a fairly basic UI through which you can view and manage documents in Documentum through a SharePoint user interface. If you have deployed functionality within the WDK layer then it is likely it is impossible to recreate this functionality in the MyDocumentum product. As such do not expect 100% of your users to switch to using the SharePoint user interface. With the EDRSS component you should have a very good understanding of the way content is journalled through to the Documentum repository. Do not expect that this content is fully available through a Documentum and SharePoint interface once it is journalled through. The journalling is enough to reduce the impact on SharePoint storage constraints but does not provide a fully integrated environment. e.g, the metadata which is journalled through to Documentum is stored within Documentum as an XML rendition of the content.
3. The technology alone is part of the solution. If you look at the last point on metadata and the way it is journalled then consider the following scenario. Typically in SharePoint there is less governance around document types and these tend to be of a greater variety. Documentum implementations however tend to have much more control over document types. Do not expect that there will be a match between the types in two, and if you want to achieve this alignment expect a whole host of pain on the way. The current users of SharePoint are likely to be unhappy at having their freedom restricted, or the alternative approach could be complex to achieve through the Documentum products.
Does this all mean that I think integrating SharePoint and Documentum is the wrong thing to do? Absolutely not, but doing it for doings sake is. However I can think of many Use Cases where this is an applicable and appropriate approach. As I mentioned at the start I have seen some of the improvements which are in the later versions of the integration products, some to highlight include:
- The ability to add custom menus in MyDocumentum. Whilst this won’t replicate the WDK experience in SharePoint (which should not be a desired route anyway) this will help to fill in some of the functionality gaps which you may experience;
- The addition of a Subscriptions Web Part; interestingly we found the users were really interested in having this so was a big plus for them when we discussed the future functionality;
- Metadata based journalling rules in EDRSS. I can see this helping organisations achieve what I have seen as the vision of using SharePoint for ‘collaborative’ content in SharePoint but managing the more compliant content in Documentum. Will still need some thinking but could be a step in the right direction;
- Content Migration. On our implementation we were faced with migrating a lot of content from SharePoint through to Documentum using the EDRSS component. The method in 6.5 was fairly crude and involved a back-up and restore of the content, with a quick configuration switch in the middle. Now though there is a much improved solution which allows you to schedule and throttle this migration very easily;
This is a subject which has been talked about a lot in the past 12 months, I expect the next 12 months will see the market really understanding how they can use the two technologies together and whether they should. As I say I think there is a place for this but I think we should all be conscious of what we are really trying to achieve!