Interoperability vs. intraoperability: your open choice

In mathematics the phrase “by abuse of terminology” is sometimes used in advanced books and lectures. There is no dishonesty intended, it’s just a simple way of saying “I’m omitting some of the details and it’s not quite exactly what I mean, but close enough for us to talk about.” Since we are discussing mathematics, you can always follow up with a more complete treatment where everything is proved before you agree to the conclusion. That is, no one is getting fooled.

In the same way, some words such as “normal” are used in many different areas of mathematical study. At first it seems almost random, but the more you learn about the subjects, the more you realize that you’re really talking about the same things, just through a different lens, if you will.

Alas, if this were only true in IT. There, we should be saying “the terminology is being abused” when appropriate, but rarely do. Similarly, what is “normal” to a market leader might not be at all normal to everyone else. Luckily, things are starting to change, particularly as communities rise up and start fighting for proper behavior and description.

In 2005 we saw this around the word “open.” I started to see a real change of direction in the industry where it no longer became appropriate for a single vendor to declare something open because 1) they created it, and 2) they’re going to call it anything they want. This might have been accepted behavior in 2004 or before, but it is not now, nor will it be in the future. Unfortunately, the growing indignation on the part of a lot of people in industry and in governments around the world was not enough to fix the title of at least one badly named specification last year that was, and is, anything but open.

I think the word “interoperability” is being similarly abused. When a single vendor or software provider makes it easier to connect primarily to his or her software, this is more properly called intraoperability.

intraoperability diagram

In the intraoperability situation, one product is somehow central and dominant, either by marketshare, attitude, or acquiescence. The connectivity is supported by protocols and data formats that favor the central software, and those are often prescribed by the provider. The goal is to suck all important data and processing into the central software ecosystem, and it is in this sense that we use the prefix “intra.”

So when the software provider comes out and says “we just created a consortium to provide interoperability with our products,” he or she is really saying “we want you to help us keep our product at the center of the world, and help us increase sales.” Nice deal if you can get it.

And a deal it is, when we are talking business and financial arrangements. The protocols and formats somehow always work best with the central software and aren’t really conducive for others to use when the central software is not being accessed. That’s why in the diagram I have the heavy lines when they go into the center and the lighter lines otherwise.

You may need special licensing to use the protocols or formats, and the central vendor may even try to standardize the specifications with weird rules stating that you can’t break compatibility with their products. The licensing might even prevent the use of the formats, protocols, or even a user interface by competitors or creators of open source software. It may be in the immediate economic interest of the other players to participate, but they do so with the tacit agreement that they are agreeing to play in an asymmetric environment where the primary advantages go to the one in the center.

Compare this with real interoperability:

interoperability diagram

In this situation, we use truly open standards that do not favor any one software provider. They work to allow two pieces of software to work together as they do any two others. Certainly one of the providers might have a superior market position, but it is not given or maintained by the asymmetrical intraoperable situation.

Software succeeds because the application or service is faster, more reliable, more secure, more scalable, has a better user interface, or, more generally, provide a better quality of service. It does not succeed because a provider abuses the word “interoperability” and convinces others that they play on a field that is level.

Interoperability driven by open standards increases competition, provides more choice of applications to customers, and drives down prices. Customers can interchange, or substitute, one piece of software from one provider for another. The central provider in the middle of an interoperability situation hates this true, open interoperability. Customers love it.

The next time you hear about interoperability, ask yourself if this isn’t really intraoperability. If so, further ask yourself if this is best for you or best for that provider in the middle. It doesn’t have to be that way. Do your part to force software providers to stop abusing terminology. Require the use of truly open standards and may the best software, and provider, win.

Also see: “Compatibility, interoperability, and interchangeability”


This entry was posted in Document Formats, Open Source, Software, Standards and tagged , , , , . Bookmark the permalink.

3 Responses to Interoperability vs. intraoperability: your open choice

  1. joel says:

    My thoughts exactly. Thank you.
    Where I grew up (Tennessee) several decades ago, we considered everyone who engaged in deceptive practices to be dishonorable, and had nothing to do with them. I still do.

  2. Marbux says:

    Excellent article, Bob. The only thing missing is a link to one of your earlier posts, a deficiency now rectified by this comment.

    What some in the industry have either missed or chosen to ignore, I think, is that “open” and “interoperable” are now law. Check Article 2 of the Agreement on Technical Barriers to Trade and Article VI of the Agreement on Government Procurement.

    As you graphically demonstrate, interoperability and openness are key to the substitutability of software products, the very floor of a competitive market. Closed and intraoperable (as you term it) software systems create “unnecessary obstacles to international trade” within the meaning of those two treaties.

    Those who pursue intraoperability strategies are leading their customers into violations of international law. That is not a long-term plan for economic survival.

    Best regards,

    Marbux

  3. Bob Sutor says:

    Thanks for the addition and further comment!

    Bob

Comments are closed.