ODMA FAQtip

Q000900: Why So Many Defects?

Version 0.10  InITIAL Draft Last updated 2002-11-22-15:18 -0700 (pst)
The latest version of this information is available at the AIIM DMware ODMA site.

Content

1. Overview

2. Comparing Incomparables

3. Getting What You Measure For

4. Why the Change?

5. What You Can Expect


1. Overview

Since May, 2000, a number of defects, errata, irregularities, and questions have been recorded against the ODMA 2.0 Specification and ODMA software, especially the Connection Manager implementations.  This is reflected in the "box score" on the ODMA Support page.

We are now (September 2000) part way through a full and systematic audit of the ODMA materials.  Based on experience so far, it is easy to predict that more defects will be uncovered.  The defect population will grow, taper off, and decrease as repairs and updates are made.

I am concerned that developers of ODMA-compliant products, and users of ODMA-enabled DMS integrations will assume too much about the condition of ODMA because of the highly-visible compilation of these statistics and the supporting defect analyses.  

This ODMA FAQtip presents my perspective about fully-open and public defect analysis for ODMA:

  1. ODMA is stable and successful.  There's no question about that.  Most of the defects that have been uncovered through auditing have not disrupted or damaged the use of ODMA "in the wild."  Nevertheless, they present pitfalls to maintainers of the ODMA software.  They provide potential distractions and discouraging experiences for people using the software in a development setting.  

  2. ODMA is middleware.  This implies a greater level of accountability and stability than is imposed on standalone, easily-substitutable products.  In particular, any question about the integrity of ODMA software inserts spurious concerns in the troubleshooting of integrations, even when ODMA has nothing to do with it.  (See the laborious history of incident report X000500.)  It is not unusual for experts on newsgroups to point to the use of ODMA when someone reports an application difficulty, even though all known cases have been unfounded.

  3. We are raising the bar.  I stand for ODMA software being impeccable.  The Connection Manager and other fixtures are now readily open for inspection, with audit results and test results openly-available.  There are to be sufficient test fixtures to readily troubleshoot and confirm integrations involving ODMA.  We will be able to make future upgrades without ever destabilizing ODMA or giving anyone reason to lose confidence in its reliability and stability.  To achieve that level, we must be unflinchingly objective about where we are starting from.  When a defect is uncovered, it will be repaired quickly and thoroughly without introducing new problems.

  4. It will look painful.  I am reminded that there is no reason why a journey must resemble the outcome. Getting to a higher-level of support and reliability will look messy.  There are few contributors involved so far.  Auditing and stabilization of ODMA is happening retroactively in the midst of sustaining support for ODMA and promotion of improvements to ODMA, along with migration to AIIM DMware.  There will be on-going construction and re-organization of materials for some time, and we can't stop the clock to do it.

That's the basic idea.  The following sections elaborate on some key ideas that may help in any appraisal of what you are seeing as ODMA support continues:

Dennis E. Hamilton
AIIM DMware Technical Coordinator
Renton, Washington
September 24, 2000

 

2. Comparing Incomparables

It is inappropriate to assume much about the quality of ODMA based on the support statistics and incident reports.  I notice that I use many software products for which I have no idea what their non-disclosed (and perhaps unmeasured) support statistics might be.  How about you? (Section 2).

3. Getting What You Measure For

If there is no actual confirmation and measurement of specific software qualities, there is no basis for expecting to find them satisfied.  ODMA was developed under a particular model of what was appropriate.  It was successful in that regard.  (Section 3).

4. Why the Change?

We now know that middleware adds more uncontrolled variables to integration situations.  This makes it easy for middleware to be suspect in any difficulties that occur in that integration.  Developers can even be discourage from pursuing use of middleware if there is anything to stumble over.  Especially since there's always someone with a better idea.  We too could just move on to greener pastures.  Or we could take the opportunity to raise the bar and see what that provides.  (Section 4)  

5. What You Can Expect

It is probably a good thing that I didn't fill this in when I could have in September, 2000.  Looking back today, from November, 2002, I am no longer confident about predicting future developments for ODMA and the stabilization of the software and, most importantly, the ongoing improved usage of ODMA for integration between desktop applications and document-management systems.

There are also some lessons that have been learned in the past two years about why ODMA is difficult and how something so simple is deteriorating in terms of use and successful integrations. That's without any change to the ODMA specification and the supporting software.

This will be good to review another time.  


Version 0.10: Initial Draft (orcmid)
Choose an outline and create an overview of the ideas I want to explore here.  Get review of this much from contributors that I have been working with.

created 2000-09-18-17:25 -0700 (pdt) by orcmid
$$Author: Orcmid $
$$Date: 07-07-28 11:15 $
$$Revision: 7 $