Wednesday, October 22, 2008 2:15 PM
An ISV's perspective on CMIS
CMIS is an emerging standard for defining an interface for basic document repository interaction. It is proposed by Microsoft, EMC, and IBM, who with SharePoint, Documentum and FileNet make up a big part of the Enterprise Content Management market. If you want to read more details, you can read the CMIS draft specification, or see the SharePoint team's blog or Andrew Chapman's (EMC) blog for the ECM vendor perspective. This blog by Chuck Hollis (EMC) gives a compelling case for why ECM customers should care.
The third type of player that cares about ECM standards is the company who delivers products that are meant to be added to ECM systems. Atalasoft has been an ECM Imaging ISV for several years with DotImage (our ECM Imaging toolkit). Our customers include ECM vendors, system integrators and consultants who build custom extensions, ECM add-on ISV's who use us to create their add-ons, and ECM customers who use us to write custom extensions themselves.
With such a diversity of systems to connect to (many of which use custom or one-off repositories), we usually leave the repository connection to our customers. We provide generic connectors to get to images stored in very common ways, so CMIS offers us an opportunity to extend DotImage to a few more systems. This is nice, but it's hardly a major part of DotImage, and it is not something I see as a major customer request.
Recently, Atalasoft has entered the SharePoint add-on space with VizitSP, and here it would seem that CMIS is a lay-up (and perhaps it would prove to be), but as I understand it, I don't believe CMIS will turn out to be as useful as it would seem to be.
The current Vizit offering can broadly be described as two major pieces: Vizit Scan-to-Sharepoint is a desktop installed application that makes it easy to scan documents directly into SharePoint. Vizit Previewer and Vizit SP are document image viewers that are installed as features into SharePoint and offer ways to interact with document images right in SharePoint (in the browser) -- you can get a quick look with Previewer or use the full VizitSP viewer to manage, view, clean and annotate the documents (see our product manager, Rutherford Wilson, demonstrate Vizit at DMS).
Vizit Scan-to-SharePoint is built on top of SharePoint's repository interfaces. Essentially, it needs to allow the user to browse the repository, upload a document and make sure it is checked in. All of these interactions with SharePoint are covered by CMIS, so by supporting CMIS, Vizit Scan-to-SharePoint would get the ability to scan into any ECM system that supports CMIS. That's great, but I still wouldn't be able to remove the SharePoint specific parts because:
- The current version of SharePoint doesn't support CMIS and maybe even the next one won't (no commitment yet from MS). I have to keep SharePoint specific code until we want to drop support for these SharePoint versions -- we are looking at 7-10 years from now.
- Even if CMIS is in the next version and MS provides it for previous versions and uses automatic updates to get it everyone, I still can't use it if its performance doesn't match the SharePoint specific way.
We would still want to add CMIS to support all of the other ECM systems, but if their implementation of CMIS doesn't match their proprietary API, then we may find ourselves still writing code for each one. The main reason is that if we have competitors, and if there is a performance benefit, it will outweigh the benefits of a smaller code base. Our customers won't care if we support other systems, only what the best one for their system is. So, the more successful we are, the more likely we'll be writing ECM specific code.
For the Vizit viewers, CMIS is not nearly enough. We need to be able to browse the hierarchy, check documents in and out, and update them, but more importantly, we need to be a seamless part of the UI of the system -- this is way out of CMIS's scope.
We could rewrite the parts that CMIS supports, but that's unlikely, because unlike Scan-to-SharePoint, which talks to SharePoint remotely, the viewers are in the process space of SharePoint and the richness of the object model available and the speed is never going to be matched by a web-service based API like CMIS.
So while I think the Vizit line will leverage CMIS in some ways -- right now, I think that it will be as a way to extend into the long-tail of CMIS implementors while we still use the proprietary interfaces for the popular ones. The two forces that would make this not so are ubiquity/uniformity of the interface and performance relative to the proprietary interfaces.