Reality – Back in 2008, Microsoft, IBM, and EMC drafted an initial proposal for an ECM interface specification. This proposed draft specification was shared with Alfresco, Open Text, Oracle, and SAP, later refined by the CMIS TC (Technical Committee), and became an official OASIS standard in May 2010.
Now the leading ECM vendors face a difficult situation: the point of no return is passed; now, they have to support the new open standard although they know that the usage of CMIS will weaken their relationship with existing enterprise customers.
CMIS helps customers to avoid vendor lock-in and give them independency from a single ECM infrastructure vendor. With CMIS, the ECM repositories will become more and more a commodity, and it will be much harder to successfully monetize a proprietary ECM platform. That’s the reason why the big vendors will not really push the broad and fast adoption of CMIS. They will not spend their marketing-dollars to speed up the necessary customer education. This task has to be done by independent analysts, consultants, ISV’s, and the systems integrators who will see the chance to generate new business based on the upcoming changes in the marketplace.
Reality – Some people believed that CMIS would change the ECM world overnight and are now disappointed that one year after the release of the standard most solutions are still working based on the native interfaces of the different ECM vendors. The reality is that only 12 months after the initial release of the CMIS standard, there are more than 50 CMIS implementations available in the marketplace.
However, it is more important that every single major player not only announced but also delivered a CMIS-compliant version of its ECM repository. This is a huge success and was never achieved by any other attempt of standardization in the ECM world in the past.
But most customers can only move slowly to new CMIS-compliant versions of their mission-critical ECM platform. So it will take yet another two years until the majority of customers are in the position to implement CMIS-compliant business applications. This will be the starting point for a new industry, and we see already today that many systems integrators and ISVs prepare for their move into the fast-growing space of vendor-independent composite content applications that can run on any CMIS-compliant ECM repository.
Reality – The functional approach of CMIS is indeed similar to SQL, and I love the vision that CMIS would change the ECM market in a way similar to the one SQL transformed the database market rapidly 30 years ago.
But the situation we face today in the ECM market is quite different: when IBM invented SQL, this was really disruptive and created a whole new industry for RDBMS-technology. This was possible only because, at that time, there were not so many database management systems widely deployed.
The ECM industry today isn’t that lucky since, over the years, customers have been investing billions of dollars in the deployment of ECM repositories and content-centric applications supporting their mission-critical business operations. There is no reset button that we could press for the ECM industry.
So a primary goal in the specification of CMIS is to protect past investments of both customers and software vendors. This will not lead to technological perfection but will help customers to unlock the hidden value of information by breaking down the information silos.
Reality – It’s true that especially the large ECM platforms of leading vendors like IBM, OpenText, or EMC Documentum deliver a lot of functionality in their native API’s which is not covered by the actual CMIS 1.0 specification. But all the core features needed for comprehensive document management solutions are already included.
Take a look at the AIIM CMIS products guide with applications like ZIA Freshdocs or WeWebU OpenWorkdesk to see what is possible already today based on the open standard. And if your use-case needs more than what CMIS 1.0 has to offer today, you can easily create a CMIS extension for inclusion in your application. Many systems integrators have experience creating this type of extension and consider it a best practice.
Over the next years, the CMIS standard will further evolve and will reduce the needs for such individual extensions. The CMIS Technical Committee at OASIS is working heavily on the upcoming versions 1.1. as well as 2.0 of the standard. But there’s no need to wait – even an 80% standard would be much better than a proprietary solution. Don’t you agree?
Reality – So far, some repository vendors did a poor job in implementing the CMIS standard. Imagine that somebody was just bolting together a CMIS-provider as a wrapper around a JCR-interface which a few years ago was built as a wrapper for a native API to an ECM-repository. What do you think about how fast this solution would be?
But fortunately, most vendors (like IBM and Alfresco) did a much better job implementing the CMIS specification than a few others. We tested CMIS-compliant business applications against many different CMIS repositories and found big differences in performance.
If the CMIS API of a repository is well designed and implemented, than you will not face any performance issues with your CMIS based business application, but don’t just trust all the repository vendors claiming to be CMIS-compliant. Test your applications carefully against your repository of choice and don’t blame the CMIS standard but the vendors if you experience suboptimal results.