It’s been more than a decade since Content Management Interoperability Services (CMIS) came into the ECM industry with the hope of establishing a standard for easier, cheaper and faster interoperability. Designed through a collaborative process with vendors like Adobe, Alfresco, EMC, HP and IBM (among others), the standard was poised to offer a simplified and standardized way to access unstructured content across ECM systems. It was destined to be a game-changer – the solution to all our interoperability challenges that made adoption of new ECM systems a prohibitively difficult undertaking.
In theory, the CMIS standard was a fantastic (and very welcome) idea. In execution, though, it has missed the mark.
Inefficient and outdated
The standard was developed with the intention of being easily adopted and supported by the widest possible range of vendors and users, providing a simple method for accessing repositories regardless of environment. It was designed to allow a generic application to access any content repository without product-specific code, but – as ECM vendors have adopted varying levels of CMIS support – this standard might not be a true standard.
In today’s state of ECM, CMIS’s architectural issues are hard to overlook. The largest problem we’ve seen is that CMIS supports only very basic ECM methods. Customers are finding that they still have to create their own abstraction layers to support the varying degrees of CMIS and non-CMIS ECM methods.
A recurring problem is that industry experts keep adding CMIS to boilerplate request for proposals (RFPs) that set unrealistic expectations of the standard. Companies are sold on the fact that this ‘magical’ standard will allow for true interoperability between ECM systems and ultimately allow them control over vendors. But that’s not the case.
There’s a noticeable disconnect between the defined CMIS standard and what CMIS actually delivers. The danger in this is that ECM analysts and consumers alike aren’t getting a clear picture of the state of interoperability in our industry. CMIS hasn’t been the superhero we hoped would save the day, and maybe that’s a conversation we need to have. Let’s shed light on the true state of the standard so that users can make informed decisions on the best approaches for their particular use cases.
Breaking away from CMIS
As promising as the standard looked at one point, CMIS didn’t pan out to be the interoperability champion it was meant to be. Alternatives exist in the emergence of true service-oriented architectures (SOA) since the advent of CMIS. ECM vendors have created platforms that can leverage and provide access to documented application programming interfaces (APIs).
The key is to know what your true goals of CMIS are within your ECM strategy. If you need to leverage the different capabilities of your vendors, you may be better off working directly with the documented APIs in an abstraction tier because ultimately this is what you will have to do for anything more than the basic.
At Systemware, we continue to have success in increasing interoperability by leveraging appropriate technologies to access content from existing customer repositories as part of an abstraction layer. Most of the time – due to limitations – this moves beyond CMIS. Ultimately, this approach offers customers the ability to gain the interoperability they desire.
CMIS wasn’t by design a bad idea; the intentions of the standard were right on point. But time has revealed shortcomings in this industry standard, and it might be time for our industry to begin looking toward next steps in reaching our interoperability goals.
Do you think that CMIS was a hit or a miss? Let us know in the comments below![/fusion_builder_column][/fusion_builder_row][/fusion_builder_container]
