Throughout my time at Nexor, a common thread of all the products and projects I have worked on has been interoperability – how do you get System A to exchange information with System B? You would have thought after 30+ years the problem would be solved, but it keeps making an appearance.
You may have seen a recent press release from Nexor about the MDIS project, which, from my perspective, is all about interoperability between systems to form a Single Information Environment (SInfoE). MDIS brings together many threads of research. In this blog, I explore one such research thread looking at the challenges of interoperability.
What do we mean by Interoperability?
We might be dealing with different protocols. An early career example is email messages using the X.400 protocol rather than SMTP.
We might be dealing with different data formats – for example, JSON or XML.
How about we produce a gateway for the protocols and produce a set of data transformations, are we done?
No. This approach only deals with the first two levels of interoperability. ETSI describe Interoperability in a four-level hierarchy:
Technical Interoperability – Data can be exchanged between systems;
Syntactic Interoperability – The format and structure of the data is recognised;
Semantic Interoperability – The meaning of the data is understood;
Organisational Interoperability – The data can be used across organisational boundaries in automated processes.
As an example of semantic interoperability issues, consider a message that communicates information about an event that occurred in the past, and that the communication includes a data and time. Syntactic interoperability allows me to recognise it as a data and time. But only semantic interoperability allows me to determine if this is the time the event occurred or the time the message was sent.
Organisation interoperability takes this further, by recognising what the message means and triggers a business process to deal with it. For example, understanding a flight plan and ingesting it into an air traffic control system.
These last two levels are crucial to understand. All too often engineers connect systems and achieve technical and syntactic interoperability but overlook Semantic and Organisational. This can be the result of using Open APIs or standards, which very often enable technical and syntactic interoperability, but can lead to engineers blindly using the API without considering the wider aspects of interoperability. An often-quoted example is the crashed Mars lander where an API expected a distance to the surface measurement to be supplied, but the measurement was supplied using the incorrect units.
The recent UK air traffic control issue is a good example of a semantic interoperability failure – the data was syntactically correct, but logically not something the system could deal with, triggering a system shutdown.
Nexor’s own research suggests that Organisational Interoperability is very broad when dealing with interoperability between systems of systems, as seen in the military. We prefer to expand this level into:
System Interoperability – The data can be accessed, verified and used by different systems, across system and organisational boundaries.
Business Interoperability – Trusted Information is available to business decision makers, anytime, anyplace, anywhere, irrespective of the source.
This approach brings in the dimension of security. The ability to share information is compromised if the information cannot be trusted. In the next blog in this series, I will discuss the challenges of secure interoperability.
So, what does the interoperability hierarchy mean if you have systems which need to interoperate? Our interpretation is you need a robust process that starts with the information exchange requirements and puts them firmly in the context of the business need. Only then can you start to understand what data needs to flow around the system and design how you are going to exchange that data (securely) between dislike systems. That’s what I’ve spent, one way or the other, 30+ years at Nexor doing!
To answer the question “Interoperability - Are we there yet?”. No, and never will be, but if we think about all five levels of interoperability at the outset, for today and any future interoperability needs, then this will help.
Innovation and system evolution will bring a greater need to share greater volumes of data, in application-optimised formats which are increasingly untrustworthy. Interoperability and secure interoperability will be on the agenda for a long time, so why don’t we start by designing it in!
The Interoperability Series
This is part 1 of a 4 part series on Interoperability explore the full story:
About the author
Colin Robbins is a Principal Security Consultant, leading customer-funded research activities in secure interoperability and information exchange. He has specific technical interests in the Single Information Environment and Data Centric Security, as well as the processes of security, such as Secure by Design and Information Security Management Systems (ISMS). He is a Fellow of CIISec, and a former NCSC certified Security and Information Risk Adviser (Lead CCP).