Compatibility, interoperability, and interchangeability

I often find it amusing when people pull out a very significant sounding, obviously committee-written definition of “interoperability.” If I didn’t know better, I would have thought that the definition was written and then delivered on a stone tablet. Is this necessary, or is interoperability one of those things that you know when you see it?

Three words that are often tossed around when talking about how one piece of software can talk to another are “compatibility,” “interoperability,” and “interchangeability.” Let me talk about them in order.

In my opinion, the phrase “software compatibility” is very fuzzy and therefore useless. Does it mean that both pieces of software can run on the same operating system without having one or the other explode? (In olden days it might have meant that they didn’t overwrite each other’s DLLs.) I do think it connotes some sense of their co-existing peacefully, but not really doing more than that.

More dangerously, I think it’s a term used by some who don’t want to sign up to some idea of strong interoperability, in the sense that open standards are used to specify how the systems should talk. “I don’t want you to hold me to being interoperable, so let’s just say we’re compatible. That way I can just keep building my systems the way I want to do so.”

So don’t use “compatibility,” or else understand that you are probably using someone else’s key word with a tainted meaning.

“Interoperability” is the real term here, meaning that two different pieces of software can exchange information and the meaning of that information within a larger document or process is well understood by both. Of course, ultimately the information may move among more than two pieces of software. This software might all be on one device or one computer, one or more may be a desktop or server application or a remote service, and they may be geographically close or distant.

Let me use the phrase “weak interoperability” to mean that software systems can work together because they share proprietary or non-publicly controlled data formats, and the exchange of that data is similarly done using proprietary or non-publicly controlled protocols. A typical case is “You want interoperability? Buy all your software from me. Don’t worry, I’ll guarantee that it will all just work.”

For discussions of interoperability, the software systems we are talking about should be considered black boxes. That is, data goes in and data goes out, but we should not really care about how the applications or services are implemented. You might be worried about aspects of software such as open source, patents, or trade secrets, but for interoperability it is the flow of information back and forth with which we concern ourselves.

First, then, we care about about the format of the information as it is externalized from the software and made available to others. In this area, standards like XML, HTML, the OpenDocument Format, and many XML-based standards for particular industries are good examples. This interchange format might be static, that is, pre-generated, or it might be dynamically generated from user input, a database, or some computation. The technical quality and implementability of the formats are very important. Having a “standard” that only one party can fully implement will not lead to general interoperability.

Protocols are the second area of interoperability that you need to know and care about. It’s one thing to have information, but how is it wrapped up and sent securely and reliably from one place to another? The protocols might be very simple or they might be very complicated, involving encryption, transactions, guaranteed delivery techniques, and other aspects that we might attribute to the qualities of service between the software.

So now we have our information, we have it nicely wrapped up for delivery, but how do we know how to get it into the other application? As a somewhat contrived example, if I were to send

Account number: 745690555121200099
Amount: $1000000

to a bank, I might want to know if I’m talking about a deposit or a withdrawal. There are various ways of doing this, but the essential idea is that you need to understand the interfaces into an application or service. The common term is “API,” for “Application Program Interface.” That bank might have just one interface and I would put the “withdrawal” instruction in with the data, or it might have separate “deposit” and “withdrawal” APIs and I invoke the one I want for a specific action. As I said, this is over simplifying, but you get the idea.

When we have open standards used for information formats, protocols, and APIs, we have what I’ll now officially term “strong interoperability.” The specifications used thusly are “software interoperability standards.”

There are those who do not feel that software APIs need to be open for interoperability and there are others who feel that strong interoperability means that open standards must be used for the description of the business processes under which the information is flowing from one application or service to another. I think the debate will continue for several more years, and all that I’ll add to that now is that the recent trend in the IT industry is to become more and more open.

The final term I want to discuss is “interchangeability.” To what degree can I take out one software application or service and replace it with another? Here the concern might extend beyond formats, protocols, and APIs into the areas of user interface and support on multiple operating systems.

To pick a specific application area, many people are asking how interchangeable are office suites like Microsoft Office, OpenOffice.org, IBM Lotus Symphony, Corel Office, and KOffice. Given Microsoft Office’s past and current dominant market position, there has been significant debate around standards for document formats.

To avoid retraining costs, many are concerned about how similar the user interfaces are. Of course, that has also been a concern between versions of the same product, as when Microsoft Office 2007 introduced the new ribbon interface. I would argue that innovation suffers if you always restrict yourself to copying the user interface of the current market leader, no matter the software category.

The office category is interesting because it also includes things like spreadsheet macros and formulas. Can one spreadsheet application run the macros and understand the formulas in a document created by another application? Is this true across operating systems, even for software from the same vendor?

So software interchangeability goes beyond formats, protocols, APIs, user interface, and operating system support, and also includes in-application programmability. Note that these issues apply not just to standalone desktop applications but also to software delivered through a web browser.

For software services that are only accessed programmatically, pure interchangeability is often more possible. Banks and financial institutions, for example, could use very standardized formats, protocols, and APIs to deliver the same services, for example, credit card approvals.

With cloud computing becoming more and more important, people are correctly asking questions about standards. My sense is that virtually none of the cloud environments are interchangeable and that interoperability among them is sketchy, at best. Unless one provider ends up being overwhelmingly dominant, interoperability will need to be improved.

Also see: “Interoperability vs. intraoperability: your open choice”


5 Comments

  1. As I said in “Freedom to Leave”[1] back in 2006, I think that the substitutability of applications – especially programs that act as service endpoints – is the key differentiator for thoughtful customers. The first services to promote their freedom to leave ought to clean up.

    [1] http://blogs.sun.com/webmink/entry/freedom_to_leave

  2. I’d say that it’s best defined by example.

    There is no way that everyone will buy phone service from the same provider. Even when ATT was the monopoly provider in the USA, they were not a siginificant operator in the UK.

    So if we have a variety of providers, and we want to be able to make phone calls to each other, then the telephone service infrastructure had better be interoperable. It is incumbent on the service providers to agree standards, implement them, etc. for the benefit of their customers.

    It is so now with the Baby Bells, and the cellphone operators.

    E-mail systems are another example. With the best will in the world, not everyone is going to buy IBM Lotus Notes. We had better be able to interoperate with others, even with email systems from our biggest competitors. Who would they be, I wonder ? Who sells all the XBox360’s ?

  3. Thank you for this very clear description of networked systems. I hope we can take what we learn from two large systems — the internet and the digital financial markets — and apply the best standards to building the smart energy grid.

  4. Wow, great post, and I appreciate the last paragraph on cloud computing. If, of all places, we can’t fully interoperate in the cloud, then we’re all taking a big step backwards that makes the cloud as useless and irrelevant as MS-OOXML in my world.

  5. 1. Freedom to leave: is a test of the market (do interoperable products for the product class exist), not a test of interoperability. Substitutability is yet another social engineering response to to a computer science requirement. It hides more costs than it reveals.

    2. Exchange of information: hazy at best because it classically obscures the semantics of syntax, data and operations.

    Systems interoperate (in the sense that sent a command/verb, the system will react as expected with the explicit requirement that in some form, even natural text, there is a sharable declaration of expectation).

    Data is portable (in the sense that there exists sufficient computable data declaration to enable exchange of values with a sharable definition of the range of information required to support the exchange ranging from syntax to data type).

    There is no such thing as blind exchange because the system of exchanges must itself be exchangeable.

    No Free Lunch. The cloud is largely a marketing myth promoted to give false hope to customers who will only later discover that implementations, not standards, dictate costs. Otherwise it is a gazelle race where the fastest gazelle is not permitted to outpace the slowest gazelle or the gazelle with the deepest pockets that can give away the most services dominates the market until their pockets are empty. See Sun.

Comments are closed