Welcome to Orcmid's Lair, the playground for family connections, pastimes, and scholarly vocation -- the collected professional and recreational work of Dennis E. Hamilton

Recent Items
 
Interoperability by Regulation: The Glass Half Ful...
 
Transparency Causes Performance?
 
Dreaming in Code: Going Native by the Bay?
 
Microsoft, Interoperability, and Open Source
 
Reality Is the Model
 
Trust but Demonstrate
 
Chatting with a Spacecraft
 
OOXML: Excel2007 versus IS 29500? The Fun Begins
 
ODF1.2, My Movie Plot Defanged
 
ODF 1.2, Hijacked by OO.o?

Interoperability: The Experience of It

It strikes me that interoperability is a lower-level technical quality that impacts the higher-level undertakings of people, groups, and organizations.  The connection between interoperability as a technical achievement and how its absence or limitation comes to be noticed is indirect.  I wonder how important it is to sort that out.  Here are my exploratory thoughts.

cross-posted to the Interoperability Forums

Having Interoperability Conversations

In April, on the Interoperability Conversations Forum, I asked:

Who is dropping in here to discuss interoperability?

At what level of detailed concern?  The general level of the Interoperability Principles, the Document Interoperability Initiative, or some narrower or broader (industry level, even) focus.

Also, at what level of "system" is interoperability of interest?  The kind of technical interoperability that programmers deal with when integrating software, the interoperability that IT infrastructure and systems integrators are concerned with, or the broad level of interoperability between individuals and groups within, across, and between enterprises and communities?

The people who mention that forum thread to me echo the reply from N. Gregg Brown:

"I would invert the levels of interest that you gave at the beginning of your note to represent the topics we hope to discuss. First, I’d like to see us discuss the scenarios that people want (are itching) to accomplish so they can collaborate “between individuals and groups within, across, and between enterprises and communities.” From that will flow the issues for IT and Web that providers will have to deal with and, inevitably, specific issue that programmers will have to address. ...

"If we can discuss how these things raise the issue of interoperability, we can make better judgments about the requirements that need to be fulfilled, the standards that need to be adopted, and the stuff that needs to be fixed."

I hadn't meant to suggest a sequence.  I am inclined to begin with how interoperability serves the activities of individuals and groups in their mutual endeavors.  I will go so far as to claim that it is all about serving people in their endeavors and removing those barriers that lack of interoperability represents.  There are some problems with that, though.

How Is Interoperability Experienced?

I don't think people experience interoperability or its absence in those terms.   I think people experience the conceptual integrity of computer-based systems;  they experience the coherence with which the elements of a system are familiarly usable; and, more likely, they experience frustrating absence of those qualities.  And people do not identify and report their experiences in those terms.

I think that what people stumble over is, among other defects, an absence of interoperability.  It shows up as being frustrated in some task that interoperability is expected to enable.

The arrangements for interoperability are subordinate to and invisible at the level where most of us interact with computer-based systems.  The use of standard document formats is an easy example.   When I am creating a document, my attention is not on the the digital representation of the document, it is on what the application allows me to do, how the document is presented to me, and what happens when I and others use the resulting electronic document.   Even when there is a problem exchanging the document with someone else, I don't go digging into the format as a way of resolving the situation.  And for most people, examining the digital format is out of the question.  Digging into the computer software that is involved is more unlikely even if possible.  Most of us are similarly unlikely to examine the communication protocols our computers are employing to connect and interact over the Internet.

I think that interoperability is known to us mostly as an expected check-off item; it is not something we think about.  Unless it doesn't work.  At that point, the breakdown might be identified as an interoperability failure or not. 

Recognizing Layers and Flavors of Interoperability

I do think there are layers of interoperability.  When we talk of interoperability, it is important to be clear what the layer and the context are.  I think we also must be clear about what aspect of interoperability matters.  For example, are we after substitutability in the same layer or are we interested in substitutability above or below a layer.  Is it ever not about substitutability?

I also think that there are interoperability-related limitations that are experienced at a higher level where the (non-) interoperability contribution is not apparent.

For me, this means that I must listen carefully for stories about interoperability.  I must be careful in identifying the different layers or levels that are involved and where the interoperability matters.  There's a lot of trial and error in sorting that out.

The nagging question that remains is: how can interoperability be demonstrated in a way that is relevant at the other levels where its achievement (or failure) will be felt? 

Labels: interoperability

posted by orcmid at 7/07/2008 12:24:00 PM