So I’ve been doing some more thinking about the opportunities which will be brought about from the CMIS announcement. (I’ve also had a read through the Domain Model spec and will comment on that in the future). Where is the value in all this going to be? Probably the key question being asked right now. I’m not thinking technical here, at the end of the day your average employee will not give a damn about the fact that their systems now interact via REST, we can save that for the technologists amongst us.

My belief is that, when this comes to fruition, it will enable providers, be they SI’s or vendors, to provide more template based applications, the process templates which will underpin their core activities. By having the templates defined, configurable and reusable, customers will soon be able to focus on these business processes rather than the complexity of the integration with their underlying systems.

Consider a New Starter process where the offer letter is correspondence stored in one ECM system but the Induction Booklet is stored in another; the process definition could be consistent but the activites requiring interaction become more service based. Activities, or Services, become reusable from one organisation to another, regardless of the technology; a big step towards adding value through Service Oriented Architecture.

Organisations who grasp these opportunities will steal a march on others and lead the adoption of the standard as and when it becomes more widely available. These do not necessarily need to be ECM experts, but are more likely to be those who can add value to the operation of the business through increasing efficiency, reducing costs, improving rate to market etc… At the end of the day we are here to improve businesses, CMIS could be a big step in this direction.


Its almost like last week’s news, and there certainly has been some activity on this front on some of the blogs out there, e.g. Pie, BMOC, Craig and John Newton amongst others. In case you are not aware, this is what has sparked the sudden activity, CMIS.

From the link above there is some information on the focus of the first version of the spec, and it is very much early days:

“The initial set of deliverables will be targeted for the following use cases:

  • Collaborative Content Applications
  • Portals leveraging Content Management repositories
  • Mashups

The following use cases should be able to be supported by CMIS Domain Model and Bindings, but are not primary drivers:

  • Workflow and BPM-centric applications utilizing Content
  • Archival Applications
  • Compound and Virtual Documents
  • Electronic and Legal Discovery

The following use cases are out of scope for the initial set of deliverables:

  • Records Management and Compliance
  • Digital Asset Management
  • Web Content Management
  • Subscription and Notification Services”

I find this quite interesting, especially the move of RM to a later release. I do need to read the spec, printed it out today, but I hope that the minimum that it deals with are the Basic Content services. I can see the logic behind the drivers re Portal and Mash Ups, this is where we would expect current integration pain to be but I would think RM is such an important factor in the current climate that it would need early consideration. However I would not be surprised if one of the reasons for not having this in early is, to put it crudely, it is hard. I don’t mean necessarily implementation is hard but getting concensus on what would constitute RM is difficult with the various standards out there, e.g. DOD, MoReq2, etc…. There is also the question of whether compliance to these adds value to the customer, interesting discussions to be had. I’ll read the specs and post again.

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.