A while back, I discussed the Three Fundamental Use Cases for CMIS. Since then, there have been some additional thoughts on this topic.  Since CMIS has been officially submitted as a standard to OASIS 🙂 I thought I would look at a couple of those thoughts.

The first was the EMC presentation on CMIS and DFS from the Momentum Europe in the fall.  It presented four cases, most notably a Migration use case.  This has popped-up in Twitter as well, so it obviously has some mindshare.

The other was a post by The Burton Group, specifically Larry Cannell, on How Will CMIS Be Adopted.  Larry focused on the business applications and had some good thoughts, especially regarding CMIS Clients.

Quick Recap

Not going to go into many details again. Feel free to read the post or check-out the related presentation.  Listing the use cases for reference, they are:

• Repository-to-Repository (R2R): This is where content repositories talk directly to each other.
• Application-to-Repository (A2R): This is where an application that uses content is plugged-into a content repository to handle all content services.
• Federated Repositories (FR): This is where an application talks to many different repositories while presenting a singular interface to the user.

So what else has happened?

CMIS for Migration

This is a two-pronged discussion.  The first is how it relates to the 3 cases listed above.  The answer is classic consulting-speak, It depends.  Why?  It depends on how you build the migration tool.

I could be a stand-alone that takes content from one system and places it in another in one process (FR).  It could export content in one process from the source and use another to import into the target in another (A2R).  It could be built within a repository and just suck content from other repositories (R2R).

So CMIS Migration doesn’t really fit alongside the three, so lets call it a CMIS business application.  That will work as a phrase for at least the rest of this post.

So should you use CMIS for migrations?

On average, I would say no.  Migrations typically involve lots of content.  Performance counts and using lower level APIs can provide a lot of performance gains.  There is also the opportunity to take advantage of performance features that some vendors provide through batch importing.

For example, EMC’s Documentum High Volume Server allows you to do use Batching and Scoping, minimizing database calls and dramatically improving performance.  If you use CMIS, you lose that performance gain.

If you aren’t migrating a lot of content, and don’t need to worry about quick switch-over from one system to another, then you can use CMIS.  In general though, I would say no.  Buy a tool or get some smart developers to write a one-time utility for you.

Blending Architecture and Business Use Cases

Over at Burton Group, Larry Cannell shared some very solid thoughts in his post.  He showed a nice understanding of the standard as well.  Larry shows the same flaw in his list that most people have done.

People are mixing the “architectural” use cases, R2R/A2R/FR, with “business application” use cases.  Putting them in a single list can cause confusion.  Larry was focusing on the business applications of CMIS variety, which is an important topic.  The ones that he listed are:

• Collaborative front-end to a repository: This is basically using CMIS to connect Jive, Quickr, or SharePoint to an ECM platform.  Classic A2R usage.  There is no reason it couldn’t be a FR design in order to work with content stored in multiple repositories.
• Mashups/portals: This is a good one and one that appeals to the RESTful binding of CMIS.  Bringing content into an application with data from others has great value.  For an energy company, having the electrical grid super-imposed on a Google map, with a click on a point allowing them to see service history and manuals on the equipment located there has great value.
• Lightweight desktop clients:  This is one that Larry adds a lot of thought an insight into during his post.  Aside from having a well developed application, there is the possibility of a streamlined security process.
• Migration: This is not in Larry’s post, but I wanted to list it here as I’ve discussed it above and it fits in this list quite well.

Now it is silly to try and list every business application.  Whenever you think you have a complete list, way to leverage CMIS will show up.  There is no point to such a detailed list.  Capturing representative examples has value as long as whenever someone thinks of a “new” use, you either take time to relate it to an existing one, or acknowledge it as a unique usage of CMIS.

A Parting Thought

You’ll notice that all applications could benefit from A2R and FR architectures.  Why?  Simple, why migrate everything when you can them marked as read-only and still interact with them from the same user interface?  Any new content could be place into the new repository.  As content expires, the legacy repository slowly fades away.

This could be done in a more advanced manner as well.  Think on it for a second. If some content was accessed, it could automatically be migrated behind the scenes.  For a more economical scenario, the migration would only happen if legacy content was modified.

After a while, all active content would be in the new repository.  The other could then be taken offline.  If written correctly, that feature could very well make migrations unnecessary for repositories that are simply being replaced.

I wouldn’t mind not performing another migration.  While necessary at times, they are far from fun.  Give me a good Content Management Assessment project any day.