Another quiet period of writing, there are a few posts which are itching to get out but they’ll have to wait for another day. I do find though I spend a lot of time just keeping up to date with some of the more prolific bloggers and tweeters in this space such as Pie, Lee and Marko, Ron and Cheryl to name only a few.
Firstly I promise not to break into another post on the E in ECM, there are enough posts and tweets about this in the past to keep you busy but it has been discussed again at length over Twitter.
Three things of interest to me have cropped up in the past couple of weeks which are worth more than a Tweet response:
The Fallout from Info 360 and AIIM in the US
I’m only going on reading what people commented on the event but the things I took from it were:
- BOX emerging as a viable complementary solution to traditional ECM players. I’ve not completely got my head round the model and implications but the idea of being able to collaborate outside the firewall with other organisations and have that content linked back into your central repository is appealing. That comment is based on talking to customers as well as my own predictions. This is something definitely to look into in more detail.
- Buzzwords of Cloud, Social and Engagement. (Thanks to @ldallasBMOC for answering my question on what the buzzwords were at the event). Cloud is definitely something I am seeing increasingly as a discussion point, and it is starting to come across more and more in some of the delivery models. Social is something which is ahead of Cloud in its impact on the World Stage but I would suggest behind in the way we are dealing with it in Content Management.
- An emergence of EMC. Yes the event heralded the departure of Whitney Tidmarsh from EMC but it also saw Jeetu Patel present their vision for the future. This vision was first seen at the Momentum conference in Lisbon last year so this was perhaps the first time it was presented in such a public forum in the US. I was pleased to see this last year and I heard positive vibes from people at Info360 this year. The trick for EMC is now to deliver on that vision and to deliver in a timely fashion or at least to keep the excitement high in the period while we wait, ‘doing a Centerstage’ would be a problem for EMC.
An increase in SharePoint apathy
Now this is only an observation but I am seeing an increase in the number of posts and tweets which are advocating the approach that there is a limit to what should be done with SharePoint. Note the emphasis on should. Most people know how great a product SharePoint is and how it has helped to raise the game of other Content Management players by bringing Content Management more and more to the masses. The big thing though has been an increase in using SharePoint as a solution platform, extending the product to meet much more functionally rich and diverse needs. Now I am not saying this is not possible but there is a point at which you need to start to question whether this is the right thing to do. It is when this line is crossed that complexity and costs rise to a point which is seeing people start to question SharePoint. If you know what you intend to use SharePoint for and are clear on when it should not be used then this apathy can be avoided. This is easily solved through having a very clear roadmap or strategy.
Improved User Experience to be a game changer
This observation is following a post from Brilliant Leap. Now I agree with some of the points in the post about the delays in Centerstage causing EMC to lose market share and also about the consumerization of IT having an impact in the Content Management space. What I don’t agree with though is that this is a Game Changer in the Content Management space. (Note that the post paraphrases this from a presentation at Info360 and is not necessarily claiming it is the Game Changer). Maybe it is a semantic thing on the term User Experience, and maybe I am being a little picky. Why? Well I think if we can remove Content Management from the minds of the people who are creating and managing it and move to a situation where that content is being created and managed for a specific purpose and it is that specific purpose which is driving then we will have a game changer. In fact I had a similar conversation with someone else recently who was focussed on the Content Management solution for an organisation, I argued that Content Management was not a solution but was a layer in the solutions which helped them. With this in mind I really do believe that CMIS, if applied correctly, could be a game changer in the the Content Management world.
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!
There were a number of comments to my last post about whether an organisation can really attain the common goal of having a single ECM repository. Ultimately I do not believe many organisations will be able to reach this, and there are situations when they should not aim for this. One comment pointed out that a single interface is really the goal of an organisation, users do not care where the information is stored but they do want to know how to get access to it.
I then read Pie’s post on how CMIS is already affecting the market and how one organisation in particular have developed a solution which shows accessing multiple repositories through a single interface.
This is exactly where I see the market going, although I think this is a first step. Being able to search for and view all unstructured content is extremely powerful and Pie comments that the first to market is not usually the one who prevails over time, they will though get some traction in the market. Now start to expand this view, bringing structured information into this view as well. I’ve had a look at Palantir recently and this is very interesting technology, imagine the power of a solution which combines some of the visualisation of Palantir with the ability to add content to your collection. Being able to Tweet, or more likely Yam, on a suspect in a criminal case, or on a new drug development. Adding a drawing which shows how a certain part of an Energy plant works in the same view as looking at the organisational structure of that plant. Eventually people will stop accessing information through hierarchies and start to get access to information through subjects or topics, SharePoint is making a strong move in this direction in 2010. In this view of the world the Content Management platform becomes much more of an infrastructure commodity.
It would be interesting to hypothesize how this change would affect the way in which SharePoint has taken the ECM market. Whilst it is true that the UI is not the main reason why SharePoint has made this move it is still important and is a very convincing reason why people love SharePoint so much. Perhaps the power of SharePoint’s Portal approach, in my view not great but still an advantage over most ECM players, could be a compelling argument for SharePoint to continue to grow.
This may make life harder for end customers but there is every possibility that the vendor with the best, and most usable, interface, will not have the best content repository. However it will drive a lot of competition in the market and really get people thinking both about how they store their content and how they want to interact with it as well as interacting with other information sources.
Interestingly when I first read Pie’s tweet to advertise this post I thought it was going to be focussed on Content Enabling applications. I suppose it is but some of the applications he talks about content enabling are very close to the platform services being provided, e.g. WebPublisher and Centerstage. Does this mean I think it is wrong? No, not at all. Pie has exposed a model which is very interesting. With the Core Server customers would buy the platform and a way to interact with the basic services the platform provides, it would be interesting to understand where the line is drawn on Basic Content Services…e.g. is MOSS in this group?
For Applications Pie adds the likes of WebPublisher and Centerstage, the Documentum apps. In this space I see some separation between these style of products and the more vertically focussed implementations. Something more akin to:
- Extended Content Applications – those applications which are still focussed on providing horizontal content solutions but with enriched services focussed on a specific ECM Use Case such as Web Content Managment or Digital Asset Management;
- Business Solution Content Applications – those applications which are taking a specific business solution where there is a need to interact with unstructured content and providing the application to perform these tasks;
It is the latter which I am becoming increasingly interested in, I’m making some notes on a post about Case Management which I hope to post this side of Christmas.
So will Pie’s model work? Yes. Do I think the market is ready for this? Not yet, and I think it is the vendors who are the farthest away from this concept although CMIS should provide a vehicle for them to provide this. Take Documentum for example, with their CMIS release they have some very basic content services which they can expose…the decision they need to make now is which services form the rest of the platform services and how can they expose these in a way which enables CMIS to develop.
There is also a certain amount of kudos which is taken from having your app used by customers at the front end, moving ECM closer to being an infrastructure may not be something the vendors will necessarily embrace. But then how many times will you hear people say things such as “Documentum is a really annoying product” (Quote taken from a quick search of Twitter for Documentum)? The answer is quite high, and this is something which creates a poor reflection on Documentum as the users are typically complaining about the way they interact with the services and not necessarily the services themselves.
Any vendor that can shape themselves to providing the most scalable, performant, secure and compliant unstructured store which provides a rich set of services which can be used will be one step to establishing a differentiator for themselves. The second step will be to get a strong strategy of working with partners to use those services in business focussed applications such as Contract Management, Case Management and Purchase to Pay applications.
Pie seems to prompt a number of my blog posts on here, actually good that someone can initiate activity and spur me on to provide comment! Anyway, his latest prod has been on how we got involved in Content Management.
I actually started my IT career developing a set of workflow components based on Oracle technology, both Forms and some server side procedures. One of the implementations of this ‘product’ was in a pharmaceutical company within the manufacturing division. We implemented an application for tracking incidents in the plant to ensure they were fully investigated and any corrective action taken. As part of this various parties in the process would produce reports in the Document Management system they used, Saros Document Manager. I was very loosely involved in tha area of the system as I concentrated on the process design and implementation, nevertheless it was a start. (N.B. for those that don’t know FileNET acquired Saros).
I then worked on an eCommerce project for an online music store, well before Amazon! Whilst not Document Management this taught me the need for some of the basic Web Content Management services such as staging, approvals and content expiry…in effect we were building this functionality into the eCommerce application.
Anyway a change in career left me joining a company who specialised in Document Management implementations, amongst other things. To integrate me into the company I was sent to Sweden for 6 months where I learned an awful lot under the tutelage of some very knowledgeable, and patient, experts. The product they used the most was Documentum, and welcome to the world of RightSite…oh how life has moved on.
Interestingly I was asked to look at a new concept, this was in 2000/2001, Microsoft had released a product named Tahoe and I was asked to look at a new offering for the company called ‘Webben som Arbeitsplan’, or Web as a Workplace. We even built some integration between Tahoe and Documentum which we achieved through Web Services and the, at the time, emerging SOAP standards. Funny that 8 years later I’m still speaking to customers about the best way to achieve that!
Recently I posted a tweet that suggested I believe the imminent release of the Office 2010, and in particular the Office Web Applications, poses a threat to the likes of Documentum and Open Text. It takes more than a tweet to explain this theory.
The video I watched on Office Web Apps can be viewed on the Microsoft site.
So why do I think that putting Word and Excel functionality, et al, onto the Web will pose a threat to the ECM vendors?
I was definitely impressed with the brief video show above and look forward to seeing how this feels for an end user. The site notes that the Office Web Apps are only available when purchasing the SharePoint license. This clearly indicates that the content which is being authored is thus stored in back end SharePoint repository. This close coupling between the authoring tool and the content repository is the clearest threat to the major ECM vendors. It is extremely unlikely that Microsoft will publish an API which enables customers to pick and choose the repository within which there content is stored, I admit I have not looked hard for this information so if they have published anything, positively or negatively, on this front then please let me know.
By unveiling an approach which reduces the distinction between the authoring tool and the storage repository Microsoft have increased the pressure on the ECM vendors. Admittedly the strengths of the likes of EMC and OpenText remain, for example full ECM capability including DAM and WCM, RM and compliance functionality and true scalability. However I suggest that customers will start to look past some of these when they have the power to do so and accept some of the failings in the SharePoint product set in return for the complete solution. This will not be possible for all customers, for example Pharmaceutical validation will still require some of the rich functionality of a Documentum. It also may not be incentive enough for other more CEVAs which have been developed for customers, for example A/P solutions which may use the integration between SAP and OpenText.
For simple Document Management where customers are interested in using a repository which is ‘good enough’ then I believe this is a big play from Microsoft.
Also a number of the ECM vendors have solutions for native interaction with the repository from the desktop Office products; would this even be possible with the new model? What could help the other ECM vendors? CMIS.
If Microsoft were to make a leap and enable their Office Web Applications to be used with any CMIS compliant repository then this would be a step towards customers keeping their options open.
There’s a lot that still needs to be considered but if Microsoft do lock the Office Web Apps into a SharePoint repository then I see this as a major threat to the ECM vendors.
Documentum have announced that Magellan will now be named Centerstage, not sure about the name but it sure beats Magellan.
I was fortunate enough to see a demonstration/presentation a couple of weeks ago and it is very interesting. In fact I know of customers who are taking notice and starting to consider whether they should rush into a SharePoint integration with this coming down the line.
Speaking of which I’ve had some time looking at SharePoint recently and some quick findings are below. Its not the first time I have looked at it as I was the lead on a company intranet which was built on an early version of SharePoint but it has moved on since then.
- The UI is great, no doubt about that, it is so easy to chop and change the views and make everything easy for the end user.
- Usability, as a result, is no problem….I can imagine the cost of training is minimal compared to the problems with Webtop.
- Starting workflows is remarkably similar to in Webtop.
- Building workflows is a pain, unless you buy a 3rd party product prepare to get your hands dirty, very dirty.
- Audit capability….mmmmm. Have a good look at this, its not what it may appear at first sight.
- Lists, nice and easy…great feature…just don’t go over 2000 entries.
- Search, poor but then they have now got FAST so expect improvements.
I try not to pick on a product and the weaknesses it has but I’ve spent the past week working with SharePoint and in
particular its workflow capability and its integration with InfoPath. For a while I thought it was me being too picky and
relating too much to my Documentum experience but I came out from that slumber, some of this is basic workflow and the fact
that SharePoint does not do it or does not do it well was a bit of an eye opener for me. So what’s my beef:
Auditing – support for Auditing appears to be very poor, in fact when an instance of a Workflow is completed the audit trail is removed, or rather the association of the audit trail to the item. Now there are a number of solutions to this, one suggested one is to create a List to store the audit entries. Fine, but that does involve some coding to get the solution to write to the List…er not good. Then you uncover that Lists start to creak at about 200 entries….er not good at all. Auditing is a basic requirement of workflow and if a product does not support this then in a matter of fact way then its not worth its place on the list of products.
Forms – so we’re using Infopath forms to render forms. We’re not using MOSS, we’re using WSS. We wanted to have an Infopath form be displayed for a task which updates a data object, but we do not want to access the full data object…its unnecessary. One would think this is a straightforward requirement, oh no. In fact as we are not using MOSS only WSS, but with Forms Server, the tasks cannot be presented as Infopath forms…they need to be built as aspx forms; I can see my development work increasing all the time here. Then it becomes clear that SharePoint does not really support the idea of forms updating other objects, or parts therein, the full form should be displayed. I have to say I still doubt whether my reading of this is correct….but if it is, another black mark.
All in all it has been a less than positive experience of using SharePoint workflow. If I’ve misunderstood something above then drop me a note and I will correct it but unless there is a very big eureka moment I won’t be running to a customer with SharePoint as a solution to some of their business processing problems!
I’ve been having some fun(?) this week installing and configuring Documentum Archive Services for SharePoint, let’s just say the documentation is far from ideal on this and it is also far from clear some of the rationale behind some of the problems we encountered. Anyway, some notes which may provide useful if you too try this installation:
Note: We were installing into a WSS installation which was configured through multiple users and with all users within a domain but which also had Microsoft Office Forms Server installed.
The following steps are required to install the Documentum Archive Services for SharePoint:
1. Create a SQL Server database as specified in the document Documentum Archive Services for Sharepoint 5.3 SP5.
2. Install Documentum Foundation Classes (DFC) and Primary Interop Assembler (PIA) on the WSS server. Note that once DFC is installed it creates an msi which should be used to install PIA.
3. Run the DCTM Archive Services.msi to install Archive Services. Ensure you have the server name and database for the database created in 1 as these will be used.
4. In order to configure the product to run using a domain user the following steps are also required. These are an amended list of steps taken from the document Documentum Archive Services for SharePoint Release Notes.
a. Grant the SharePoint Application Pool account full control permission on the DOCUMENTUM location.
b. Add a folder e.g. c:\dctm_tmp.
c. Grant the SharePoint Application Pool AND SharePoint MOFS Admin account full control to this folder.
d. Add the path to the [DMAPI_CONFIGURATION] section of the dcml.ini file in C:\Windows. Local_path = c:\dctm_tmp.
e. Grant the SharePoint Application Pool account full control to the Documentum hive in the registry.
f. Add the following to [DOCUMENTUM]\dfc.properties:
g. Reset Internet Information Server, iisreset.
Note that Step 4 above removes the need to follow a solution on EMC Powerlink, ID esg44475, as this creates an alternative location for the dir.lck file.
Also note the reason for ensuring that the two users have access to c:\dctm_tmp, as defined in 4c, is due to the fact that the first time a Mapping is created everything works fine with just the Application Pool account having full account but future mappings require the MOFS Admin account to have access.
I’ll post some more next week on some of the experiences we have with the product and why people need to read Pie’s excellent post on the virtues of patience with SharePoint and Documentum.
MOSS and Documentum
I’ve had some time lately to think more about the question of integration, or unification, between MOSS and Documentum; or any other ECM system for that matter. This came about as a result of a couple of situations where I found organisation looking closely at how to integrate the two producs; plus some reading of Andrew Chapmans blog.
Taking a big step backwards for a while I started to get a little concerned the way things are moving here, it feels as though there is a great deal of momentum behind the movement to have both systems operating together. Is this really the best way to serve an organisation’s requirements, in fact what are the organisation requirements?
It is not pushing things too hard to suggest that an organisation would like to capture, store, manage, use, distribute and possibly archive some of their content. I doubt there is any requirement to have these things met by having two repositories of information so what is it that one gives that the other does not?
One of the key arguments in the pro MOSS brigade is the UI and the level of collaboration available within MOSS. I’ve asked a few people a number of times and if anyone out there has any suggestions but what collaborative features are people looking for which MOSS provides which Documentum cannot? With regards UI, if people move down the approach of Webparts then at the end of the day the UI they use to access Documentum through MOSS is the same as using Webtop basically.
The weight here is usually behind the issues of compliance and scalability. Compliance is something which MOSS is starting to deal with and I expect it to be comparable in the near future. Scalability remains a concern for MOSS implementations, however I’d expect this to be resolved in the next 12-24 months.
Perhaps I am missing something here but it does seem that the approaches being proposed are not actually going to solve the business problems but will instead justify the need for having two ECM systems when one will do. We should be evaluating the systems against the requirements of the business and deciding which one is the best fit.