ECM Web Services

Laurence has written an excellent post about fitting Sharepoint into the ECM picture.

The comments about the rewrite of eRoom are interesting and confirm thoughts which I am sure a number of us have had for some time. eRoom as it is does not have a future and EMC need to repurpose it and break down its features into a number of services which can be added on to the core Documentum products and then exposed through the clients. This started in the past with the Collaborative Services.

The killer in Laurence’s post is his dream of standard ECM Web Services definition. This should not be a dream and should be something we are moving to, but I am not sure it should be about plugging in an ECM platform to either Sharepoint or eRoom but more about exposing the ECM and Collaboration services which the products expose into whichever presentation layer the customer wishes to use. Note I am saying ECM and Collaboration services, both are required.

On a recent project we used Trac for our wiki and Subversion for our Config Management, this included code and documentation. If there had been better support for some of the config management services of Subversion which the wiki could have harnessed then we would have not had a slightly awkward UI to battle through to get to important documents. No reason why this could not have been through standard EMC Web Services.

When we start to consider some of these we will be moving much closer to the Web 2.0, SOA buzz words which are being touted much more. Something to ponder and think about no doubt.

Agile Documentum continued…

I posted a few weeks ago that I had an opportunity with regards a short piece of work on a Documentum project, its coming to a close now, or should I say the first phase is coming to a close. It has been an interesting experience. The approach taken was:

• perform 4 1-week iterations focussed on specific features
• start each iteration with a demo of Webtop to focus minds on requirements
• end each iteration with a demo of completed work
• allow for time in the following iteration to make changes to the deliverables from the previous
• MOSCOW the requirements as much as possible

Scope was a big problem to manage, as ever, but we agreed up front that we would do no work which required ‘development’, i.e. everything we would do is to be done in DAB, largely Document Types, Lifecycles and Permissions.

What worked well:

• as a way to flush out requirements it was fantastic, we now have a Use Case model which includes requirements which have been delivered but also those which will still require work
• stakeholder buy-in, good buy-in to the solution and the possibilities with Documentum

What did not work well:

• quality of high-level requirements were poor and changed throughout the period. We managed this well despite the challenges but it confirmed my fears that the Object Model was insufficient to progress into this stage.
• lack of environment control. We were not in charge of the environment, it was there when we arrived and for us to deploy into, lack of non-functional requirements were surprising to say the least.

Overall it has been successful and one group within the organisation now have a system they can use as the early adopters while we focus on cross-organisation requirements, both functional and non-functional. Persuading the client to take the step back was hard but necessary and now we have built confidence in our ability to deliver enough for them to trust us. It also provides useful feedback into our process for delivery, a step too far with agile, but a managed success.