Orcmid's Lair status 


ODMA: The Little Middleware That Could

ODMA: Open Document Management API

When I first learned about the formation of an Open Document Management API coalition in early 1994, I didn’t expect to be its principal technical coordinator/evangelist/support contact ten years after the first specification was stabilized and the ODMA Connection Manager (the ODMA “middleware”) shipped in 1995. 

On attending the second 1994 meeting on ODMA, in Orem, Utah, I was easily satisfied that ODMA was a good idea and there was no reason to do anything but to encourage and support it.  I arranged to host the third meeting at Xerox PARC.  At a Massachusetts meeting I lent my voice to Arnie Epstein’s lobbying for use of the Microsoft Component Object Model (COM) at the ODMA integration layer. COM was felt to be too unknown and too new and too Microsoft to adopt for the application-facing API.   At that time, Windows 3.11 was the in-use target platform, with some concern for use on NT.

What Is It We Like About Standards Wars?

While my attention through 1998 was on Document Enabled Networking (an effort of Xerox XSoft with Novell) and its merger with Shamrock (an effort led by IBM with Saros) to form the Document Management Alliance, I always regarded ODMA as complementary to, and separate from, the DMA model and interfaces.  ODMA provided a smooth integration of desktop applications with document-management; DMA provided a federation of document-management systems facing out to the server islands. 

It was always surprising to see the hostility that adherents of one approach had for the offerings of the other, and the degree to which each group feared the other would steal its thunder.  I found it inexplicable.    There was no conflict of scope, but apparently one of ambitions.

Keeping It As Simple As Possible

What only time would reveal was that ODMA was also targeted at an important sweet spot, was timely, and worked well enough.  Meanwhile DMA took too long and was seen as too complex as well as unresponsive to new technologies (like Java).  ODMA’s developer audience, on the other hand, would eventually be more concerned about the inability to integrate using Visual Basic.  We never go to show, in delivered systems, how DMA and ODMA could work together to integrate from the desktop out to the repositories.

Some of the focus (and a certain edginess) by which ODMA succeeded is explained by this manifesto at the beginning of the first ODMA specification:

  1. If the standard does not solve a problem it will not be used.
  2. If the creation of the standard takes a long period of time, it does not solve the problem.
  3. If the standard is difficult to implement, it does not solve the problem.
  4. The standard must be vendor independent.
  5. The standard must not try to solve all vendors problems, or it will be big, complex and take a long time to implement. This violates rules 1, 2 and 3 above.
  6. It is the customers that lose if there is not a straightforward way to integrate applications that create documents, and applications that manage documents. Easy integration between applications and document management systems will grow the industry and increase sales for the entire marketplace.

It is difficult to express the importance the initial members of the consortium placed on wanting to create a useful API that is vendor and platform independent while still simple to implement. They recognized that they could solve 80 percent of the problem easily and were willing to live with having to solve another 10 percent over time and probably never being able to solve the final 10 percent.

It is difficult to comprehend how a motley band of document-management vendors managed to come together long enough to produce something that solved a problem for all of them but that none of them could get enough value from providing on their own.  Integrating between document-management systems and the desktop and getting out of the way of users had been a constant and costly challenge.  The ODMA API, Connection Manager, and underlying integration model (think ODBC or TWAIN for comparable approaches) reduced the cost of entry onto the Microsoft desktop.  It dramatically reduced the cost of retooling and customizing for each new desktop-application release.

I think the generosity and willingness of SoftSolutions, contributor of Brad Clements’ original proposal, was crucial.  It also would not have worked if enough desktop applications were not arranged to be ODMA-aware.  WordPerfect, then joined along with SoftSolutions into Novell, took the first step and Microsoft provided the sustaining presence from Word 97 through 2003.

But No Simpler

AIIM DMware was created in 2001 2000 to provide a safe-landing of public code and support after dissolution of the ODMA and DMA coalitions.  As the technical coordinator for continuation of DMware, I had a big surprise in store for me.  While traveling in Italy and studying the language for six weeks, my arriving e-mail (via MSN in London to cell-phone modem to laptop) was suddenly all about support problems with ODMA.  I was receiving my initiation in ODMA trouble-shooting and the finger-pointing among desktop vendors and DMS vendors that found ODMA a convenient target in the middle.  The developers had moved on and the adopters of ODMA-based integrations were now making their problems known.  The concerned parties had changed.

Fortunately, the last release of the ODMA Connection Manager contained a logging option.  I could talk users and system administrators through the capture of logs that I would then interpret via e-mail.  I could confirm that ODMA was working correctly enough (and I found bugs, thankfully never found to be the causes of difficulties users encountered).  I could see where connecting software (usually the desktop application) went off the rails, but I had no way to troubleshoot the proprietary applications on both sides of the middleware.

That experience completely altered my priorities among DMware activities.  Users with problems always came first, and there had been no support mechanism.  I did what I could, with AIIM sponsorship.  There was always more that could be done.  

Welcome to the Long Niche

Today, problem reports have dwindled.  Announcement of new ODMA-aware applications and compliant document-management systems is rare.  I have no way to know how many PCs are still using ODMA for document-management integration on the desktop in 2005.  I am certain this is a shrinking niche.

I learned some valuable lessons.  First, it is extremely important to look at the lifecycle of integration solutions and plan for sustained troubleshooting and support down the road.  Secondly, I like to think that we now know more about establishing end-to-end scenarios that confirm the proper behavior and failure-modes of this kind of integration.   This wasn’t anticipated in 1995 before the low-hanging fruit began to suffer the blight of bit rust.

Ultimate Student Project

I had always wanted to create something more for ODMA, especially around expanding the forms of integration that were supported.  I had even established a SourceForge project as a haven for any new development.

When I needed to find a software development activity for a project-oriented M.Sc in IT dissertation, it was natural to fix on ODMA as a vehicle for prototyping ideas around open-system trustworthiness.   Although I abandoned the dissertation, I still wanted to carry out the project, and I have announced its formal initiation (after several false starts) at NuovoDoc, my business site.

Although I am completely willing to uncover a hidden pocket of interest, I have no illusions that anything I do will reverse dwindling interest in and use of ODMA.  I am as responsible as anyone for its neglect.  It is more like my safe laboratory for learning how to put the lessons into practice and then adapt them to new settings.  It’s a little as if ODMA has donated its body to science and now researchers will get to know the creature in a new way.

As a ODMA user in 2006, I must ask what if any technology has risen to replace ODMA as an efficient conduit between the desktop application and the managed document repository?

I cannot seem to find a replacement for ODMA...
Good comment. There really isn't anything that provides for cross-vendor desktop integration that is the ODMA sweet spot.

I thought that WebDAV would encroach into this area, especially with integration into the common file dialogs. But it hasn't happened that way.

I also thought that the rotting of the bits in various desktop applications (especially in Microsoft Office) would eventually make ODMA unusable. That doesn't appear to be the case, with Office 2007 reportedly preserving what support there is for ODMA.

I was also heartened that there is an experimental implementation for OpenOffice.org, except it doesn't seem to work and there is not much energy invested in getting it working (the OpenOffice.org integration model for alternative data sources strikes me as a bit of a nightmare, actually).

There is a possible remedy on the horizon, but I can't tell if it will address desktop integration in a way that works at least as well as ODMA (and similar approaches, like TWAIN). That is the iECM Consortium, which is focused on Enterprise Content Management Interoperability. This is a major undertaking and it will likely focus on service integration. It also strikes me as far more ambitious than DMA, although there is strong participation in the industry (they even had a meeting in Redmond). I don't expect early technology, and it may be more like Sharepoint for the rest of us.

So, my commitment is to keep ODMA functioning, at least, so that remaining integrations can be confirmed and tested, as long as there is continued interest. It's a niche, but in the world of the long tail, niches are perfectly acceptable.
Post a Comment
Construction Zone (Hard Hat Area) You are navigating Orcmid's Lair.

template created 2002-10-28-07:25 -0800 (pst) by orcmid
$$Author: Orcmid $
$$Date: 06-07-25 8:28 $
$$Revision: 2 $