Making sense of IoT interoperability
In the beginning, we had M2M. Then came IoT. With the industrial IoT and challenges around IT/OT integration, we see terms like cloud, edge and fog computing.
Now, the hot-topic term is interoperability. Interoperability appeals to a technology industry that routinely churns through new buzzwords and value propositions. There is also a willing audience among adopter organizations. Many of them are starting to see a diversity of application opportunities within their everyday operations. At the same time, they fear the economic and technical pitfalls of building a whole string of disconnected, siloed IoT applications.
In the context of IoT solutions, interoperability has little meaning without the use of a qualifier, such as the word “between.” Consider the phrase, “I have a solution that provides data interoperability.” This means little until one adds the words “between your sensor and my application,” for example.
Interoperability in horizontal and vertical dimensions
In practice, the complication with interoperability is that there are several permutations for its use in the IoT context. Just consider the following block diagram representation of a pair of IoT solution stacks:
One IoT application (App#1) can communicate with a related sensor (Sensor#1), via a middleware platform (MP#1). It might even act on sensor data to send a command to an actuator (Actuator#1). There is a similar arrangement for the second IoT solution, on the right-hand side of the illustration.
Now let’s say there is a way to improve the performance of App#1 by using data from a sensor associated with App#2. This might be possible if there is interoperability between App#1 and App#2, either via an external data exchange (over-the-top interoperability) or through their respective middleware platforms. Alternatively, App#1 might be able to access Sensor#2 because of an interoperability capability between their respective middleware platforms. This scenario helps us think about horizontal interoperability in terms of applications being able to discover resources (e.g., other applications, other middleware platforms, other sensors/actuators, etc.), to recognize the services they offer (e.g., published data streams, remote actuation, etc.) and to make use of these services through transactions (e.g., publish-subscribe to solution-stack data, usage tracking for charging and settlement, etc.).
In this scenario of any-to-any interactions, there will be situations where the solution owner finds a better sensor (higher performance) or one that delivers the same level of performance for lower cost or with greater reliability. The owner of App#1 might wish to switch vendors or operate a multivendor solution by replacing Vendor A’s Sensor#1 with a better offering from Vendor B. This example offers another perspective on technology and vendor interoperability, in a vertical sense up and down the value stack.
The discussion so far considers block-diagram constructs in a two-application scenario. The physical implementation of this arrangement involves hardware and software from different vendors. If a solution owner wishes to change out a gateway and use one from a different supplier, it would value gateway to middleware (and gateway to sensor) interoperability to minimize custom systems integration work. This kind of interoperability is akin to computers connecting to the internet or mobile phones being able to roam internationally.
In today’s cloud computing world, one example of supporting physical interoperability might involve an application (and its data) hosted on Amazon Web Services collaborating with another application hosted on Microsoft Azure. Does this arrangement deliver bidirectional interoperability (covering communications, service levels, data semantics, etc.) between two cloud infrastructure services or would it depend on an intermediate translator?
Strategic implications of IoT interoperability
Given these different perspectives, why is it important for organizations to think strategically about IoT interoperability? There are at least three reasons why. Firstly, organizations need to decide about investing in single or silo applications. Are they just looking to apply a condition monitoring application on a factory machine with a largely unchanging operational life of many years, for example? Or, will they want to support other applications with the same connected device and therefore find themselves supporting multiple potentially cross-silo or cross-vendor applications in the future? This is a matter of product roadmap planning.
Secondly, are users of IoT technologies locking themselves into a single technology or single vendor solution set? There is a way around this dilemma. Many telecommunications operators, for example, deploy multivendor infrastructure in their networks by relying on standards-based interoperability. Other industries can learn from this strategy. Factories, offices and homes are places that house machines and appliances from multiple suppliers which are the conditions that will call for interoperability between devices (endpoint actuators, sensors and gateways) and applications at some point in the future.
And thirdly, users of IoT technologies need to recognize the constant evolution in technology and its impact higher up the solution stack. While today’s interoperability debate focuses on communications and hardware compatibility, tomorrow’s solutions will shift the interoperability challenge higher up the value stack.
Consider a scenario involving multiple interacting systems which attribute the same meaning to an exchanged piece of data. This ensures consistency of the data across systems regardless of individual data format. In practical terms, this might be a stream of numbers from a temperature sensor supplying multiple IoT applications; each application would apply the correct meaning to the stream of numbers (i.e., recognizing them as temperature data, either in Celsius or Fahrenheit format without needing configuration parameters to be hardcoded in the application) because of semantic interoperability between the sensor and applications.
The issue about technology evolution is that it has long-term timing and investment implications. There are long-term consequences for investment decisions and the option-value inherent in wanting to support new applications and business models in the future.
All IoT Agenda network contributors are responsible for the content and accuracy of their posts. Opinions are of the writers and do not necessarily convey the thoughts of IoT Agenda.