Foreword

What would the IT industry be without standards? We wouldn’t have compatible databases, communications protocols, print data streams, compression and encryption specifications, or the World Wide Web. It’s hard to debate how standards have benefited the IT industry, enabling growth, collaboration in solving problems, interoperability across vendors (reducing vendor lock-in) and, most importantly, a much wider range of choices for companies. Unfortunately these benefits didn’t apply to the ECM industry until recently.

I first realized the need for a content management standard in 1992. I was involved in developing an application for a large corporate client that needed to access content stored in a popular repository. We immediately hit a problem—the content repository didn’t have public APIs. In order to get access to the APIs, we had to negotiate a long and complex contract with the repository vendor and agree that we wouldn’t use those APIs to migrate content out of the repository. This made no sense to me because we were adding significant value to the vendor’s software through this new application. Unfortunately, this type of thinking was typical of many content management vendors.

There have been several attempts at creating Enterprise Content Management standards over the last 15 years. The Open Document Management API (ODMA) in the mid-1990s defined an interface between desktop applications and content management systems. In 1996, work began on the Web Distributed Authoring and Versioning (WebDAV) extensions for HTTP. In the early 2000s, many of the key ECM vendors began work on a Java ECM standard called JSR 170. Although the technical contributions to all of these standards were excellent, none of them succeeded as a widely supported content management standard.

There were many reasons these standards didn’t achieve widespread success. Lack of interoperability testing led to incompatible implementations, and the lack of commitment by some vendors resulted in limited implementations and few exploiting applications. One of the biggest challenges with JSR 170 was the difficulty in supporting it on top of existing repositories that didn’t have a hierarchical data model.

In May 2005, AIIM started a standards group called Interoperable ECM (iECM). This group brought together many vendors and users to discuss the critical need to enable better interoperability across ECM vendors and applications. The iECM meetings were well attended, and it was clear there was still a strong need for a better ECM standard. In 2006, while attending an iECM meeting, I began talking with Cornelia Davis of EMC on jump-starting a new standard. We believed that coming up with an initial draft specification targeting key ECM use cases would reduce the amount of time it would take to produce a final standard. Ethan Gur-esh from Microsoft joined Cornelia and me, and we created the concept of Content Management Interoperability Services (CMIS). Additional people from our companies, including David Choy from EMC and Al Brown from IBM, became key participants. It was exciting to see how three major competitors could work together on solving an industry problem.

As we defined the initial CMIS specification, we knew we had to approach the problem differently than in the past. We had three key objectives in defining CMIS: (1) ensure the standard could easily be supported on a wide range of existing content repositories; (2) agree on the right level of function so the standard was usable for an initial set of key ECM use cases; and (3) define a process to ensure interoperability between vendors.

Once the initial CMIS draft was complete, we invited Alfresco, Oracle, SAP, and OpenText to participate. Momentum around CMIS built, and a lot of technical work was accomplished in a short period of time. We then moved the standard into OASIS, and twenty additional companies began actively participating in the CMIS work. In May 2010, CMIS 1.0 became an official OASIS standard.

I’m often asked if CMIS will become a widely used standard for Enterprise Content Management or if it will suffer the same fate as the previous attempts. There’s no way to know for sure, but CMIS is seeing tremendous interest and support and has very powerful supporters, such as Apache Chemistry, that enable companies to get started quickly. We’re seeing CMIS projects in large corporations and application vendors that are very promising.

There’s little debate that CMIS has the potential to increase the usage of content management systems across all industries and applications, dramatically simplifying and standardizing access to unstructured content. IT projects such as a customer portal that requires access to multiple content sources can be implemented more quickly with fewer dependencies on proprietary client APIs. Small software vendors who want to build cross-vendor industry vertical solutions can now easily do so. As CMIS matures, there will be creative new uses that we haven’t yet thought about. It’s exciting to watch the growth and evolution of CMIS.

A lot of people were key to creating CMIS, and I want to personally thank Cornelia Davis, Ethan Gur-esh, John Newton, Al Brown, Betsy Fanning, and Paul Fontaine. Without these people, and many others, CMIS would never have become a successful industry standard.

I would also like to thank Jay Brown, Florian Müller, and Jeff Potts for writing this book. CMIS and Apache Chemistry in Action is the most complete, authoritative work on CMIS you will find. It contains a wealth of technical insights as well as practical hints and tips. If you want to learn about CMIS, or start building software using CMIS, you will want to read this book.

RICHARD J. HOWARTH

DIRECTOR, ECM SOFTWARE DEVELOPMENT

IBM SOFTWARE GROUP