To CMIS or not to CMIS, that is the question

Categories:
Posted on: Tue, 2013-09-10 12:45

CMIS is HOT in ECM!

Well CMIS has been a standard for well over 3 years now and many vendors have implemented CMIS compliant repositories.  Recently, CMIS 1.1 was approved as an OASIS specification.  In my consultancy role at Alfresco Software (one of the ECM vendors that has implemented CMIS), I have run into a number of projects that have vigorously embraced CMIS.

For the record, I think that CMIS is awesome.  CMIS can reduce the amount of work needed to build applications, shorten the ECM learning curve and allow developers who are not specialists in any particular ECM product, to create content based applications.

What I find concerning, is the number of projects that adopt a "Pure CMIS" mantra at any cost. The reasons for embracing "Pure CMIS" vary from project to project. Some of the reasons that have come up are.

  • They are using an off the shelf application that has been designed to work against CMIS compliant repositories
  • They are using an external development team who is familiar with CMIS but not Alfresco.
  • They want to avoid vendor lock in.
  • CMIS is cool and the organization has bought into it politically. (Nobody ever says this outright, but certain things come out that just make you suspicious).

Many of these reasons are valid, but I would make the argument for pragmatism when building applications that you are betting the enterprise on.

CMIS Compliant Repositories were not created Equal

Many clients look to make their applications vendor neutral by employing a "Pure CMIS" strategy.  I think that vendor neutrality is over-rated.

When a company choses between a number of competing products (whether they be databases, business process engines, storage systems, operating systems, and yes content management systems), a number of factors are considered.  They include (not an exhaustive list):

  • Feature set
  • Cost
  • Performance
  • Stability
  • Scalability
  • Ease of Operations and Maintenance
  • Support
  • APIs and Extension points

Beyond the list of differences that we see in any set of competing products, it is important to remember that there is a fair amount of flexibility in what constitutes a CMIS compliant repository.  Within CMIS, there are a number of optional capabilities that CMIS compliant repositories can chose to implement (or not).  So even when you chose a CMIS compliant repository, if you use any of the optional capabilities, you could be limiting yourself to a subset of ECM vendors.

While CMIS, might not bring vendor neutrality , by reducing the reliance on proprietary APIs, it can reduce the cost of moving to another ECM product in the event that a new product is better suited to the requirements of the project.

CMIS Does not Cover all the functions in a Repository

There are a number of functions that are not covered in the CMIS Spec, for example...

  • Creating users and groups.
  • Adding users to groups
  • Using Aspects (this is supported in CMIS 1.1 but not CMIS 1.0)
  • Support for objects that are not derived from cmis:folder or cmis:document (support for cmis:item was added in CMIS 1.1)

These are just a few examples of functionality that is not covered by the CMIS spec. This functionality would require vendor specific code.

A Pragmatic Approach to CMIS

I would recommend being pragmatic about the use of CMIS.  In many instances, it makes sense to use CMIS.  There are, however, some instances where CMIS will not be the right solution, and you will need to access the repository using proprietary interfaces.  One way to reduce the risk associated with changing repositories, is to create a repository access interface that provides layer of abstraction.  This can be used to isolate any repository specific changes the class implementing the interface.  An additional benefit is that this can allow the team to benchmark alternate implementations of the interface.

CMIS is a great standard, and there are some instances where "Pure CMIS" will work just fine.  That said, in many enterprise use cases, a hybrid approach will be more effective.