Interoperability as a worldview

When my friend, colleague, boss and mentor, John Palfrey, introduces the topic of his new book—interoperability—he acknowledges that it sounds like it should be really dull. But it's not. In fact, John adds that when you've been thinking about the topic long enough, just about every issue begins to look like it's about interoperability. The book that he has written with my friend and colleague Urs Gasser bears this out. It's a broad, provocative work that raises questions on many levels.

Usually when you hear someone use the word "interoperability," you should prepare to be pulled into a discussion about highly technical issues about the protocols by which electronic systems communicate, or, if you're very lucky, about the way in which data can be formatted for use across multiple systems. This actually can be quite fascinating if it's the sort of thing you care about, but in my experience, many such discussions move down further and further into technical details, only occasionally coming up for the sort of air most of us need to live. And frequently when the discussion does move up the stack, it's because those who are attempting to interoperate are in an unpleasant struggle over political semantics. After all, when two independent systems are trying to collaborate, each starts off with a well-formed idea of how its data ought to be represented. Discussions about how to resolve the differences can lead to arguments about the hidden metaphysics and politics of each party's domain. Fascinating but often not exactly fun.

And often not exactly resolvable. I well remember negotiations in the late 1980s and early 1990s about electronic document interoperability that foundered on questions such as whether it's best to represent tables as rows and columns or as arbitrary collections of boxes. This is as close as hardheaded technologists get to religious debates.

Four-layer approach

So, it's a pleasure to read Interop: The Promise and Perils of Highly Interconnected Systems, if only because it always keeps in mind that interoperability is about more than getting two systems to talk the same language. It's about enabling enough sameness that we can live in the world efficiently, but enough difference that the world remains interesting enough to be worth living in.

Interop analyzes interoperability problems into four layers: technology, data, humans and institutions. The tech and data layers are well trod, and the book goes lightly on them. It's much more interested in the human elements that have to work together if systems are going to be interoperable, and the institutions that sometimes have to fiddle with things to get the other three layers working smoothly. Because of this, the book proceeds mainly by giving us interesting and often unexpected case studies that show how all four levels have to interoperate. For example, the air traffic control system needs more than technology that knows how to work with all the tech used by every airline, and more than common ways of representing data so that planes don't send data in kilometers while control towers interpret them in miles. The human pilots also have to have a shared set of rules and norms. And over time the aircraft control system has required them to speak a shared language. To make all this happen required the intercession of governments through the cooperation of their agencies, the creation of rules and the making of laws. Take away any of these, and you don't have an interoperable air control system. You have a set of intersecting planes.

The value in difference

The other big point I very much like in Interop is its recognition that interoperability isn't always a good thing. Of course there are privacy and security concerns about making it easy for one system to get at the data in another. But the book also talks about the problem of locking a complex system into a particular set of technology, data formats and rules that works well today but that may be very hard to dislodge when a better system comes along tomorrow.

Even more important, Palfrey and Gasser are constantly aware that interoperability bought at the price of homogeneity is often too expensive. As they say, the concept of interoperability itself implies that two different systems are able to work together while remaining different. There is value in that difference, even if it impedes the perfect interlocking of gears. That's true, the book says, whether we're talking about the different ways computer operating systems think about files or about the richness of native languages that cannot be perfectly translated. In every case, Interop tells us, we need to think through the costs of interoperability, even as we pursue it vigorously.