Taking Centerstage and some words on MOSS

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.

SharePoint Workflow

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!

MOSS 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?

MOSS

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.

Documentum

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.