By: Ultan Mulligan

Think of the last time you bought a new electronic communications device, expecting it would save you time and make life so much more pleasant. Perhaps it was a new Internet-connected television or smart-lighting system. Maybe you remember the thrills of trying to connect your phone to a new car, or a new phone to an old car. Was it easy? Or did you spend hours failing to make it work with all your other time-saving, life-fulfilling devices?

Isn’t everything interoperable now?

We all recognize the frustration of interoperability problems. We quickly forget when things work as they should. Thankfully, we do have to think back to find the worst cases of poor interoperability, like before global mobile roaming or before the widespread adoption of short-range wireless connectivity technologies. Manufacturers are now taking the user experience more seriously and we find it easier to integrate our collection of devices into our networks and our lives. 

Interoperability, however, doesn’t come free. There are good business reasons for taking interoperability seriously. Lack of interoperability can be expensive. In an industrial context, interoperability problems can mean lost business: consider halted production lines or the collapse of telecom networks, for example. At the consumer level, brand reputation and brand equity can be negatively affected. The inverse is also true: some brands stake their reputation on interoperability and offer a complete ecosystem of devices and software all designed to work together. They can charge premium pricing because consumers place a value on things just working as they should.

Some are tempted to treat interoperability as an additional feature, something to be sorted out at the end of product development. But true interoperability is designed in from the beginning and is easier and cheaper to achieve this way. Systems should be designed to use standardized, secure interfaces and connections. These standards must be designed to enable interoperability. In product development and implementation, the standards used must be followed, without shortcuts, deviations or second-guessing the standard.

Achieving interoperability is one thing. Maintaining it is quite another. The environment for which a product is designed may evolve over time, such as with the introduction of new technologies in our networks. In a world defined by software, there will be a need to not only provide updates to fix errors and to enhance security, but also to maintain interoperability. Standards and technologies should not be used outside the context or purpose for which they were developed. They might work, but for how long?

Testing, testing, testing

One of the most important keys to enabling interoperability is testing. Multiple levels of testing are required, at multiple stages in the development cycle. Let’s set aside the testing steps that should be part of any product development cycle: software unit tests, functional testing, performance, safety, usability and quality testing in general. Instead, we will look at testing focused on interoperability.

Testing can never be a substitute for designing for interoperability—they go together. Having designed for interoperability, and having chosen to follow communication standards that enable interoperability, it is essential to verify that a product conforms to those standards. Failure to follow the standard may result in interoperability issues. Pay particular attention to “failure states” or exception handling; steady state operation may be interoperable but what happens when something unexpected occurs? If the standard specifies a particular behavior, follow it. Often standards bodies will publish standardized tests used to verify compliance with a standard. Where they exist, use them.

Interoperability testing is an equally important second step. Where conformance testing will test for compliance to a specific communication standard or technology, interoperability testing takes an end-to-end view of the complete system. Specific components or technologies may work well in isolation but, when combined to interact