Almost every tender I have read in this field contains some version of the same sentence: the solution shall be interoperable. It sits in the requirements, everyone agrees with it, and nobody can be held to it, because the sentence leaves out the two things that would make it testable. Interoperable with whom? And for what?
The omission looks small. In practice it shapes how whole programmes are run, because a goal that has no referent can only be pursued indirectly. If nobody has said who must understand whom, the programme falls back on what it can count: standards adopted, vocabularies published, mappings delivered. All of that is real work, and none of it tells you whether the parties who need to exchange data are getting any closer to doing so.
The definitions were relational from the start
The odd thing is that our own definitions never allowed interoperability to float free of the parties. The IEEE glossary of 1990 describes it as the ability of two or more systems or components to exchange information and to use the information that has been exchanged. The European Interoperability Framework speaks of the ability of organisations to interact towards mutually beneficial goals, by sharing information and knowledge through the business processes they support. Both definitions name parties, and both name a purpose. Interoperability is something that happens between someone and someone else, for a reason.
Somewhere between those definitions and day-to-day practice, the parties dropped out of view. We started to describe a vocabulary as interoperable, or a standard as an interoperability asset, as if the quality lived inside the artifact. A vocabulary can certainly make interoperability easier. Whether it does depends entirely on who else uses it, for which exchanges, and how.
Naming the parties changes the question
Once you write down the parties, the conversation shifts. A pension administration that calculates entitlements for people who have worked in several countries needs to be interoperable with a known set of peer administrations, for one kind of transaction. A wholesaler handling a recall needs to exchange information with the manufacturers whose batches it carries, about those batches. An enterprise needs its finance and logistics functions to agree on what a customer and a shipment are.
In each case the circle is finite and identifiable, and so is the cost of getting it wrong. That is what makes these settings governable. When a modelling decision in one organisation forces a mapping project in another, both organisations can be named, and the cost can be traced. Open communities on the web work differently, with no fixed membership and no assigned roles, and that is exactly why the methods that suit them, counting adopters or waiting for a winner to emerge, translate poorly into programmes with a defined set of participants.
Naming the purpose bounds the work
The second question, for what, does a different job. It tells you where the modelling effort ends. Practitioners have a good instrument for this already: competency questions, the questions a model must be able to answer. In an illustrative case from our research, an automotive parts exchange is bounded by questions such as whether part X can be substituted in assembly Z without triggering re-qualification, or which drawing revision governs open orders. The agreed unit price under a blanket order falls outside that scope, however important it is elsewhere.
A scope written this way lets anyone decide, for any concept, whether it belongs in the exercise. That sounds modest. It is also the condition for measuring anything at all, because convergence only means something when you can say on what.
What a named circle makes possible
With the parties and the purpose written down, interoperability stops being an aspiration and becomes something you can observe. You can look at what your peers have already published for that scope and see where they have settled on a shared model, where they map to one, and where they run one in production. You can see which choice would bring you closer to the partners who matter most to you, and which would push you further away. And you can see it before you decide, which is the moment when changing course costs nothing.
This is why I think the most useful thing a programme can do in its first month is unglamorous: write two lists. One names the parties. The other names the exchanges and the questions they must answer.
Questions to make “interoperable” testable
- Who are the parties? Name the organisations, or the business units, whose systems must understand each other. If the list is open-ended, the requirement is too.
- Which exchanges matter, and which first? Rank them by the cost of their failing.
- What must each exchange be able to answer? Write the competency questions, and mark what falls outside.
- Who among the parties has already modelled this scope? Look at what they have published before you start your own model.
- Whom do you most need to be closer to? When the evidence is split, that partner decides.
Keeping the word honest
“Interoperable” is a good word, and it is worth keeping. It just needs its two companions back. Once a programme says with whom and for what, its reports can show whether the parties are converging on the exchanges that matter, and its modellers can see where their peers stand before they choose. That relational view of interoperability is where our work at METALEVELS, and the EVIDENT framework we are developing, begins.
If you would like to test your own programme against these questions, start a conversation with us.