Building Content Bridges


      Bookmark and Share

BEST PRACTICES SERIES

Mergers and acquisitions are all too common, as are company reorganizations. SharePoint is an increasingly popular repository option. The increasingly common end result: More and more enterprises have important content in at least two incompatible content management systems, and most users cannot access all the systems. Even if you know what’s on the "other" system, getting there is usually a hassle. You can put in a service desk request for an account, get trained, and remember each system’s idiosyncrasies every time you log on. Or you can ask someone on the other system to export and give you whatever you need. That will get you the content but none of the rich metadata that each system maintains with the content.

So is there another option? Common sense would say that you need a bridge of some sort. The problem with content bridges is the incompatibilities between the two systems. Previous attempts at repository bridge-building have yielded "bridges to nowhere," and like that famous Alaskan project, they don’t get built. Once- hopeful acronyms litter the bridge on-ramps—e.g., ODMA, linking desktop applications with repositories; and AIIM’s iECM, promising interoperable enterprise content management.

I know what you’re thinking: "Great, there’s another content management standard coming." Yes, but unlike the others, this proposed standard was written by three very large content management vendors and is supported by a surprising number of others. The standard, called the "Content Management Interoperability Services Standard" or CMIS (pronounced "Sea Miss"), was developed and released by IBM, EMC, and Microsoft in September 2008. After demonstrating prototypes based on the draft standard, it was handed over to OASIS, a trusted standards body, for review and vendor comment. As of this writing in late November, OASIS announced it had formed a technical committee to advance CMIS as a solution for sharing information across protocols "in vendor-neutral formats, among document systems, publishers and repositories, within and between companies." The scope of the CMIS bridge is intentionally modest to ensure its success. Features common to all systems are supported. Folders, for example, are universal in all systems and, thus, CMIS supports folders. Every system supports versioning, and so does CMIS.

Why would arch rival vendors develop the initial standard and then hand it over to OASIS? They wanted to assure the standard’s success because each vendor was hearing similar customer complaints: These so-called enterprise repositories were, in fact, islands. That may have been acceptable a generation ago, but that’s not so in today’s heterogeneous world. And no vendor likes unhappy customers. Better to build a bridge than have customers see your product as a dead end.

I asked EMC’s David Choy, senior consultant, and Patricia Anderson, senior marketing manager, for some details. Choy said the principals decided to focus on the lowest common denominator—"CRUD"—meaning ways to create, retrieve (or read), update, or delete documents. Choy also warned that as difficult as the initial draft of the standard was, taking almost 2 years to make, getting a final, approved standard through OASIS would probably take at least 18 more months. Product road maps from each vendor might take an additional year. In the meantime, EMC and others will make prototypes available for customers to experiment with. Still, Anderson says the end result will be worth the wait. She says that this standard, the first based on web services, would enable distributed environments such as franchises to share information outside their own organizational boundaries. Companies could even deploy workflows between repositories. Applications built for one system will work with all CMIS-compliant systems. For the first time ever, web-based, service-oriented applications could be developed once to connect multiple ECM systems from the same or different vendors. Systems could connect across intranets and even over the public internet.

Day Software also supports CMIS. And given Day’s careful adherence to standards, I wanted to get the company’s take on this effort. Day’s CTO David Nuescheler cautioned that current prototypes are for review only before the standard is finalized. "The spec needs to be thoroughly vetted, updated, and finalized. Support can—and should—follow thereafter." Nuescheler expects a lot of changes from the "very early draft that we have seen so far."

Building bridges takes time. If you add up the steps outlined by Choy and add extra time to satisfy vendors such as Day, CMIS might take 5 years, start to finish. The Golden Gate and Brooklyn bridges each took more than 10 years to design and build. Let’s hope that CMIS can cut that time in half.