Archives


Atom Feed

Associated Blogs
 
Edge City
 
Numbering Peano
 
Praxis101
 
Prof. von Clueless in the Blunder Dome

Recent Items
 
What Programmers Do
 
The Comfort of Open Development Processes
 
Abandoning an M.Sc
 
Relaxing Patent Licenses for Open Documents
 
Windows Media Center's Been Good To Me ...
 
Responding to Hurricane Katrina
 
Consigning Software Patents to the Turing Tar Pit
 
Merchants of Attention
 
Symbols of Trust
 
The Passing of Salvatore Lombino: Farewell, 87th Precinct

ODMA: The Little Middleware That Could

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.