Why interoperability isn't as important as you think it is

Often when I'm discussing communications services or applications with clients or online, I end up debating  "interoperability", sometimes along with "federation".

Especially around the areas of SIP, IMS and sometimes WebRTC, I'll frequently hear comments that "interoperability is essential" as otherwise we risk ending up with lots of "silos", "walled gardens" or "islands".

I think the discussion needs to be a bit more forward-thinking, and also more critical, aware of implicit assumptions. I hear a lot of confirmation bias, rooted in old - and crumbling - views of what "voice" or "messaging" are about.

Firstly, there are two main types of interoperability here:

• UNI or user-network interop. Basically this means that the device or application needs to work with reliably the server. Often, it is used to mean that there's a standard, which means any client can work with any server, for a given service or function.
• NNI or network-network interop. This relates to the standardisation of interconnection of different services, managed by different service providers. The classic example is being able to make phone calls or send SMS's between two telcos' networks, because the numbering and signalling is all common.

There's also a number of critical subtleties here that are often overlooked:

• Interoperability on the access network is clearly important for public networks - it's almost always good to have a choice of end-equipment (think phones, tablets, set-tops, routers) to work with a given cellular radio network or fixed broadband system. The costs of building an infrastructure are so high that it makes sense to allow a diversity of things to connect to it easily - especially as there's an ever-wider range of "things" for customers to choose from.
• NNI is actually mis-named. Increasingly it's really just SSI, service-service interop. The service provider doesn't need to own or operate a physical access network - it might just own switches or routers or web-servers, which may increasingly be running in software, or "in the cloud". The service provider themselves might be an MVNO, or a competitive fixed carrier using another telco's wholesale infrastructure for transport and/or switching.
• NNI/SSI only makes sense for services that are functionally similar - and which can be described fairly simply. A standalone phone call fits this description, as does a basic SMS or email. But increasingly, communications is going "in context" and so this concept will often not make sense in future. There's no value having "context-context interop" between in-game chat, and a doctor's remote MRI-scan video tool. And I really don't care if my mobile karaoke app can connect to your WebRTC banking call centre or not.
• Unlike access connections, there is an ever-lower barrier to entry to offering or obtaining communications services or features - and no limit to how many you can get. If a friend or business contact is using a new comms app or services, I can download the app in 20 seconds. Or connect via a WebRTC-enabled site and let Javascript sort it out in 20 milliseconds. You don't need Twelephone or TUMe to connect with Skype - it's a nice-to-have, not a must-have.
• In fact, often interop is nice-not-to-have. The benefit of silos/islands/walled-gardens is a lack of spam. And more control over how you define connections, friends or equivalent metaphor. You're not "reachable" by everyone, unless you want to be. You can force people to use *your* preferred service. For example, I'm starting to insist on doing vendor briefings via Skype - unless you're a paying client in which case it's your choice, as the power dynamic shifts. Less interop can also mean more security and privacy - and also much more control and monetisation potential for the service provider, if there is one.

In the past, telephony and SMS have been integral parts of the network so conflating NNI and SSI made sense. Phone numbers in particular still link to both Access-NNI and Service-NNI (and via the SIM card, to UNI). But over the last 20 years, various new services and products have evolved that don't require that link - the most important being email and HTTP.

Email is interoperable, clearly. But for most people, it's not tied to an access line. Yes, I've got @BTinternet and @vodafone addresses, but I don't use them. 

We're already seeing the ancient practice of tying phone services to an access line starting to break down - various telcos allow you to access your E164 phone number and its services from another access connection, as a Telco-OTT extension such as Telefonica TUGo or Rogers OneNumber. The NNI in those cases is done via normal Internet peering (and probably an IPsec tunnel for security), but the SSI remains traditional phone-style SIP or SS7. More recently, MetroPCS has done the same for RCS, launching an OTT version for other devices, and more importantly also accessible to your friends on other networks.

I've written before about the difference between interoperability and federation, and why an email-style model makes more sense. (You can have multiple accounts, running on the same device/access). At the moment we see Internet players selling E164 phone numbers decoupled from access (eg SkypeIn numbers) but I'm not aware of any telcos doing the same. I ought to be able to buy an AT&T number, plus AT&T phone service, without an AT&T SIM or home broadband, while I'm sitting here in London.

Although it's inelegant, it's becoming ever more possible to do interop via gateways, SBCs and other middle-points. Moore's Law is making the availability of "glue" and "welding-torches" much easier. We no longer have to beat out a single panel slowly, with a standards "craftsman" meticulously bending over his anvil with a hammer. In particular, we can develop silos rapidly and inexpensively, and then bolt them together afterwards only if and when it makes sense.

I still hear people saying "SMS only took off when all the networks interconnected". That's often wrongly interpreted to mean "interoperability is obviously always valuable", when actually it means that "services tied to specific network IDs are very constrained in value, although interop can sometimes help".