First of all, before I get into anything else, let me start by offering what I believe to be a highly useful definition of interoperability, one that has prevailed following eight years of work on the O.K.I. project:

Interoperability - “The measure of ease of integration between two systems or software components to achieve a functional goal. A highly interoperable integration is one that can be easily achieved by the individual who requires the result.”

Which, of course begs a definition of integration:

Integration - “The act of making two systems work together to achieve a functional goal, regardless of how difficult or expensive that task might be.”

Why offer a definition of Interoperability?  Why not simply go with the prevailing definitions available from the usual sources  Well let’s look at them.

The IEEE defines interoperability as: “the ability of two or more systems or components to exchange information and to use the information that has been exchanged.”

The Oxford English Dictionary similarly defines the word “interoperable” as: “(of computer systems or software) able to exchange and make use of information.”

The IEEE definition  is now over 16 years old, and pertains to a field of study, computer systems design and engineering, that even today is still in a state of relative infancy.  So the hole that I would like to poke in this elderly definition, as well as the similar OED one, is that today, as a field of practice, we generally understand that there is more we would like to see systems and software do together than just exchange information.  We would like to see them also share functionality, and this is becoming a primary goal for much of the work our community is currently embarking upon.

But expanding the IEEE and OED definition to simply include the broader kinds of “making things work together” does not support another aspect of the idea of interoperability that is beginning to prevail: that systems and software should “just work” with each other.  That we would like to bring ourselves closer to the vision of “plug-and-play” for software, systems and information.  This is where making a distinction between “interoperability” and “integration” also becomes important.

As far as the word “integration” is concerned, the current Wikipedea definition is actually pretty good and deserves a thorough read, but in short it talks about the act of “gluing” together components of software systems to achieve some “overarching” functional goal.  It is defined as an act as well as a state, and it is very well aligned with the definition I suggested above.  The added point I make is to emphasize that the act of integration is something that can be achieved through any level of cost and effort that one is willing to invest.

Systems can be integrated though data exchange, over space and time, or through real-time access and manipulation of each other’s functionality.  The particular approach to integration will be driven by a number of things, most important of which being the “goal” that is to be achieved.

Interoperability is really only about making these kinds of integrations as simple and cost effective as technologically possible in pursuit of that goal.

Using this thinking, Microsoft Word(tm) and Apple’s Pages(tm) can be considered integrated in their ability to exchange content using an agreed upon format, RDF, and interoperable to a degree that a non-technical end user can actually achieve this task with a relatively easy set of user gestures.  Of course this kind of interoperability revolved around a very narrow goal of content exchange, and there are many other dimensions of integration and interoperability that Word(tm) and Pages(tm) fail to achieve. 

So as we look at use cases from the perspective of interoperability it is valuable to ask two questions:

1) what is the integration goal that is being described? and
2) to what extent is a highly interoperable approach to achieving that goal of value?

Consumers and Providers:

With respect to interoperability and integration it is usually helpful to categorize software as either a consumer of things or functionality, or a provider (supplier) of things or functionality. A particular software application or system may be both a consumer and provider, but its helpful to keep these "hats" straight when discussing integration, and interoperable approaches to integration. 

In the example of RDF exchange Microsoft Word(tm) is a provider when the user “Saves As” and selects the RDF format.   Pages(tm) is a consumer when its user selects the same RDF file from the file browser using the “File - Open” command

In the case of the kinds of things that the IMS community is hoping to achieve through the Tools Interoperability activity, a VLE/LMS might be a consumer of user functionality provided by a remote provider application, but in turn might be a provider of low level services to be consumed by that same remote application, like exposing its grade-book services.

Goals of Interoperability:

It is also helpful to think about “functional goals”, relating to functional requirements which truly benefit from highly interoperable approaches. Talking about interoperability in general usually does not move the conversation forward effectively. Here are some example interoperability goals with corresponding, admittedly highly generalized, scenarios:

Example Functional Goal: Content Exchange
Scenario: "We have identified a number of content authoring tools that look like they could be potential sources of content for a number of learning management systems."

Example Functional Goal: Modularity
Scenario: “We have identified a number of functional components that we want to insert into a number of larger systems, perhaps learning management systems, and take advantage of some core systems functionality of those larger systems”

Example Functional Goal: Risk Mitigation
Scenario: “We have a number of choices today and into the future of systems or software applications to achieve a particular goal. We want to be able to make a choice today and know that it will be easy and cheap to swap out for something better or more cost effective later on.”

Many to Many, etc:

Note that "a number of..." is a key aspect of the above example scenarios as an indicator for the value to be gained by taking a highly interoperable approach. If there is "only one" imaginable consumer of a thing or functionality AND "only one" imaginable provider of that thing or functionality, then perhaps there is no need for a highly interoperable approach. A one-time integration achieved through a more straight-forward software development techniques (like defining and consuming a locally defined Web Service) may be sufficient.  We often call this approach “binary integration”, because it focuses only on the requirements of integrating two and only two things.

If there is "only one" imaginable provider of a thing or a service, and a number of potential consumers then that provider will likely drive the particular interoperability approach. The same can be said for the only one imaginable consumer and many providers – the consumer will drive the approach. This often leads to an acceptable level of interoperability for the average user.

However, we usually find that over time we can identify "a number of..." on both sides of the equation for a particular goal, and there is usually somebody who finds themselves in the middle wishing for a higher level of interoperability, and this is where standards begin to become important.

For instance: I sometimes use Photoshop for post-processing my photographs. There are a growing number of third-party modules that I can "plug" into Photoshop to edit my photos in creative new ways. This is great for me and I can plug these together myself, without calling a software developer.  To me this has appeared highly interoperable particularly because I can do it myself.  Adobe dictates the standard, but that’s been OK up until now because all I was using was Photoshop.

I have now discovered Apple's Aperture(tm) and wish those same modules could plug into that application.  I have also found another neat little photo editing application called Pixelmator(tm) . That would make me even happier. As it stands now I would have to call the developers of my favorite modules and/or the developers of Aperture(tm) and Pixelmator(tm) and try to convince them to integrate. Not so easy for me. An interoperability standard in this space begins to look attractive.

Value Proposition, “Precarious Values”:

For software developers and project managers, building highly interoperable software is often harder than not doing so, and usually more expensive.  Doing so involves understanding a standard, engaging with a community, potentially of competitors to develop, refine or profile that standard, and likely have to support a number of additional functionalities or data descriptions that I otherwise wouldn’t worry about. The immediate value to a project of easing future integration is usually not highly regarded.

Open Source projects and communities often assume that ease of integration can be achieved simply through providing source code to the community, regardless of design considerations. Unfortunately this assumes that the person or organization requiring the integration goal will have at hand the software development expertise necessary to achieve it.

Binary integration, using commonly available technologies is often easier for developers and is therefore the most common approach to getting two things to work together. It is significantly more difficult to follow a highly interoperable approach, since the standards/specifications/best practices that are designed to achieve high levels of interoperability present a greater hurdle, and for the early adopter this effort comes with little immediate apparent value. (The term “precarious value” [Klausen, 2002] was identified at the Andrew W. Mellon 2007 RIT/SC Retreat to describe this issue for open software projects)

So other, more global questions include: How can open source projects or commercial products be incented to follow an appropriately interoperable approach when there may be no immediate benefit to the developers or even to project/product stakeholders? The benefit is usually clearer for the next project, or the one after that, or for the eventual end users. How and why do we move from mere integration to interoperability?

Fundamentally, this becomes a user experience issue, as the benefit is ultimately achieved when the user themselves can, though UI gesture, configuration, etc, achieve the results THEY want.   As with any marketplace of activity, it is up to the consumers themselves to drive market change through demand.  It is up to those of us promoting interoperabiltiy to provide compelling examples of the value of interoperability that will help to grow a more discerning consumer community