EMC Momentum 2009 – Summary

So its nearly a week since the event in Athens closed and I’ve had enough time to gather my thoughts, and write up some of the sessions, so it is time to summarise the 3 days which I spent there.

To put the conference into perspective I think we need to understand the market and past 12 months of EMC CM&A.

ECM Market

SharePoint continues to be the young pretender breaking into the market. They have no doubt increased their market share in the past 12 months, no figures to back this up unfortunately, and the release of SharePoint 2010 will be a major milestone in the marketplace in the next 12 months as it increases its DM and EDRM functionality. IBM and FileNet continue to be a confused product and player in the market, the traditional strength of BPM in the product is diluted by the integration into IBM and the Process Server product. OpenText remain strong and their relationship with SAP will see them continue to play strong in this area, whilst some of their SharePoint and Microsoft products are attractive. Their big strength though is their solution focus and they are very good at going to market with solutions which focus on business value. Adobe are making a strong play in the market with their forms product and the tie up with Alfresco is certainly interesting. The Open Source market will continue to grow.

Where does this leave EMC CM&A?

I believe they are still strong, going into Athens I believed they were in a strong position, coming out I believe the steps they are taking will ensure they remain a leader.

Momentum Summary

The messages I came away from Momentum with were the three new groups within CM&A:

– Information Governance

– Information Access

– Process

Of the three I see Process as being the one which can lead EMC to success, with Governance not being far behind. Why?

Information Access – of the three groups I believe this one will be impacted most by SharePoint 2010. Organisations will become less likely to look to another product to manage their documents when SharePoint can be considered good enough. When it comes to collaboration SharePoint is strong, no doubt about that, yes it has flaws but it is a product which does a job well. At Momentum 2008 EMC’s message was all about Centerstage; this year I did not get much of a feel for that (although I did spend more time on xCP sessions). Plus Centerstage has been delayed a number of times, I just think it will be a hard sell to push this as a Collaboration play within an organisation who are remotely interested in SharePoint.

Information Governance – the acquisition of Kazeon could be key to the success of this group. EMC can now deliver a compelling message about managing records in-situ, finding information to assist in meeting compliance needs and also about moving information to the appropriate storage tier. eDiscovery has been banded around in the market a lot in the past 2 years but I see this becoming more and more prevalent as organisations begin to act on the risk threats they perceive.

Process – as I said above, this one caught my eye the most. I went into the conference unconvinced about xCP, and to be honest version 1.0 is still nothing more than a collection of products, no matter what the marketing hype. However the ambitions which EMC have for this could really start to drive some opportunities. As I said above OpenText are very good at selling business solutions, the xCP programme where partners and EMC develop business solutions together, will put EMC in a position to challenge OpenText on a level playing field, except the BPM capability of Documentum is greater than that of OpenText. Also by moving the xCP platform onto the Centerstage paradigm it will enable more composite solutions to be built as this is much more aligned with Portals. From personal experience the ability to show Documentum information/content alongside other important information is something customers do wish for and the solution until now has been to bespoke this using a Portal solution or something similar. Also by improving some of the underlying architecture to support things such as relational objects will make developing these applications so much easier and instead allow us as SI’s to focus on the business value of the solution rather than how we relate a vehicle to a claim.

 

Was it worth attending the event?

Yes, definitely. Again this was an excellent networking event and I have made a number of contacts which I will work with over the coming weeks and months. Its also nice to catch up with some old faces such as Andrew, it would be great if Pie could find his way to europe one year although it could be said that I need to get stateside at some time. There is a lot more which goes on at these events than the presentations and these sometime become as important as the session. I enjoyed the news on xCP and will just have to be patient for this to be realised, if EMC can execute the plans in this area successfully, and importantly, in a timely fashion then I can see the product set breaking out of the pure EDRM mould and starting to play in areas of business where they have sometimes struggled.

Documentum Records Manager – Retention Policy Services

Ok, so following on from the post on Records Manager I said I would post on the Retention Policy element of the product. Remember this is also available as a stand alone product.

Firstly, this is the most complicated of the 4 policies available within Records Manager, but then it does the most complicated work.

Secondly, when you read the marketing material you get the impression there is a lot in there, one thing which was interesting to me was the ability to assign a document to be reviewed when its policy expires before taking action, i.e. letting the decision drive the action. I’ll come back to this.

Retention Policies are actually lifecycles which are applied to an object which is associated with the document. With a Retention Policy you can have Phases, Authorities and Conditions. Authorities sounds like very grand terms and I expected them to be users of the system who must authorise actions, they are not, they are just a label in all truth. At the end of the Retention period a number of actions may be initiated including Destroy, Export and Review…in numerous guises. Destroy does as it says on the tin. Review merely holds the object at the phase until someone elects to push it on. Export is interesting as it exports the source object and the metadata to a location which can be defined. This actually looks like an interesting feature which could be explored for other uses.

Back to review though, assuming I have a Retention Policy which states I want the document reviewed before an action takes place. Well thats all it will do, Review, you have to create another Policy for the destruction if it is approved. And there is no easy way to let someone choose whether to Destroy or not. In fact the way to achieve the functionality I mentioned earlier would be best achieved with a custom lifecycle and some custom workflows, ideally achieved through BPM.

Conditions too are something which appear to be more than they are, as with Authorities they are just labels for the Policy to follow. If you want real conditional processing then this would need to be built into either a lifecycle definition or into a Business Process which drives an object through a lifecycle.

With Retention Policy Services it is clear there is a good framework for a solution, but it is far from the end solution. As with most Documentum products there is a starting point which needs to be extended through the usual methods of lifecycles, workflows etc…. The management of the Policies looks to be sound enough and once you have understood what you do or do not get then there is no reason why a strong solution cannot be put in place.

Documentum Records Manager

I’ve recently found some time to look at the Records Manager product. Having only dabbled with it in the past it was good to really get to grips with it, and I was quite surprised with some of the things I found.

Firstly I always wondered why Documentum needed a product specifically for Records Management, surely most, if not all, requirements of a Records Management installation could be achieved through out-of-the-box functionality, with some minor customisations/configurations. Having looked at the product now its a lot clearer. Records Manager is based on some basic principles:

Policies: there are a number of policies which can be applied to objects in the repository, these are Naming Policies, Security Policies, Retention Policies and Containment Policies;

Formal Records: the product also lets you declare items as formal records, a folder, cabinet or a document. Actually you create formal cabinets or folders and you can then declare documents as formal records.

Upon closer inspection the Formal Records are actually pretty much useless, unless you are interested in DOD compliance. In fact worse than being useless they create an overhead as they create another object in the repository as the formal record and another one as the assembly for the formal record. Unless you need to comply with DOD I cannot see a reason to do this; but can think of many reasons not to!

So if we use the 4 policy objects we can pretty much deliver a solution which is compliant to the main standards for Records Management and it does not have to look much different to a standard Documentum app. A quick description of each of these:

– Naming Policies. These allow you to put rules around what the users can call their objects in the repository. Looks quite neat but some of the user interface used to create the policies is pretty poor, e.g. you have to type in the attribute name if you wish to create a construct value (why is there no dropdown??). In fact there is no reason why this should not be a standard part of Documentum, I know it would help a number of customers;

– Containment Policies. These allow you to set rules on how the repository is structured including number of levels and what can be put it in what container. Again, looks nice. Could be improved for the end user interface, e.g. if I have said folders should only go down 7 levels why let a user initiate the creation of a folder and then give them an error message, stop it at source! Again though, why not part of the core product?

– Retention Policies. Now of the 4 this is the one which is available on its own and is probably the most important and richest of the lot. I’ll post about this on its own as it really merits this.

– Security Policies. At first glance these look quite neat, enabling you to apply policies to folders based on object types. However they are not designed to work if you take control of the acl of your volition, for obvious reasons. So imagine a scenario where a document is in a lifecycle, yet also has a Security Policy applied. When the document reaches a state in the lifecycle which requires that it is available to a wider audience you lose the benefits of Security Policies. It would be great if policies could be applied based on more than just Object Type and Folder, at the end of the day these are just attributes anyway….increasing the number of attributes which have influence will make things much richer and yet keep some of the nice administration available in Security Policies.

So all in all, a real mixed bag. The policies are, for me, the value of the product and I would love to see Documentum being more imaginative in how they sell this product. We don’t need the Formal Records etc…., they add fat to a product which simply does not need it. I’d like to pick and choose the Policies which are important to the client I am working for and pay for them. Have Formal Records as a DOD add on for Documentum, just don’t call it Records Manager.

Records Manager also includes Physical Records Manager, again this is worthy of a post of its own and I will do that in a few weeks time. First impressions though are that it looks neat but a lot of thought and care will be needed to implement.