Not many people think about the topic of interoperability between information systems/ networks–how it comes about and what influences its form.  How do I know?

Since my Ariba days, and even more so lately, I’ve been studying the topic of interoperability.  I’ve learned three things:

  •  The topic really is fascinating
  • There are at least 31 flavors (hence the Baskin Robbins analogy) of interoperability. It is a highly nuanced subject with many layers.  God–and the devil–are in the details.
  • Interoperability does not come about in any one way in different systems.  It is not always the natural result of the free market, nor does it always require government intervention.  In the US, more often than not, the private sector just muddles its way through, perhaps with a nudge from government or an NGO.

With respect to the 31 flavors, treatises could be written on interoperability in the systems listed below.  From the list, consider the examples you interact with directly (or know the history of) and you will immediately grasp the nuances involved in the concept:

  • Rail systems
  • Currencies
  • Macs and PCs
  • Word processing, spreadsheet, and presentation formats
  • Social networks
  • Credit Card Networks
  • UPC/Barcodes
  • EDI VANs
  • Bank ATM networks
  • E-invoicing networks
  • Airline reservation systems
  • Cloud services (PAAS)
  • Shipping containers
  • Pallets
  • Instant Messaging
  • USB 2.0
  • Cell phone chargers
  • To name just a few!

I could name 20 more, but you get the idea.  Each has its own history, “level” of interoperability and on-going cost of achieving interoperability.  No one size fits all.

With respect to how interoperability evolved in each of these markets, the stories are fascinating and varied.  The authors of the book cited above have a great graphic to show the different forces that often drive interoperability:

Diagram of private and regulatory approaches to interoperability

The diagram shows a variety of private actions, as well as regulatory approaches, may drive interoperability between systems.  In the cases in the list above, some achieved this state through governmental responses, some private action, some trade associations, and many a combination.  Some systems never became interoperable or did so only on a minimal basis.

None of this complexity means it hopeless for a private player to think about how to drive interoperability and whether it would be beneficial in their market.  It just means that company needs to consider the options depicted above and needs to think carefully about the right levels and amount of interoperability.  When done correctly, interoperability drives lower costs and seamless usage, without eliminating diverse competition.

Trains, for instance, had to interoperate based on the same width of track and distance between the rails, but almost everything else could be left alone for differentiation.   There is a great deal of diversity in how train cars are designed, what they carry, and what speeds they go (i.e., slow and slower in the US).  As Interop: The Promise and Perils of Highly Interconnected Systems  points out, all great examples of interoperability achieve this balance.  Bad examples, for which the authors cite the air traffic control system, become too closed and too restricted to build upon.  Some might argue that the ACH system and EDI system are such examples in B2B.  But I think it may just be that they are old!!

If you are interested in the topic, check out the resources section of my website for a downloadable presentation on the subject with more detail on these examples.

Like what you are seeing?

Signup today for free, and receive email notifications about Bob's new insights.

I will not sell or share your information with anyone.

You have Successfully Subscribed!