I have recently been reading about the caBIG project sponsored by the US National Cancer Institute. The aim of the project is to enable the sharing of medical tools and data among hospitals and other medical health organisations through a sharable and interoperable infrastructure.
The really interesting part about the project is based on voluntary participation, so caBIG does not have any control of the participating systems. So how do they manage to build a single software platform supporting 40+ independent organisations?
Their (technical) approach is roughly (as there are many legal and other types of challenges):
- A common communication infrastructure – the caGrid. This is basically a large-scale Enterprise Service Bus – in itself a very interesting undertaking, but for another blog post.
- Compatibility guidelines to ensure certain levels of interoperability. In essence, the guidelines are a set of testable rules ensuring a certain level of interoperabilitybetween systems covering four areas:
- Information models of the system interfaces,
- Controlled vocabularies providing a common semantic model for the utilised terminology,
- Common data elements defining a standard for the data structure, and;
- Programming and messaging interfaces.
The key to this is interoperability.
The caBIG project define interoperability as: ‘The ability of a system to access and use parts of another system’ – and by now you probably think: “That’s what Service Oriented Architecture are about!”
But the act of integrating is not the same as interoperability.
Australia’s NEHTA defines interoperability in their Interoperability Framework, as the ability to support integration over time with the least amount of effort despite changes to or replacement of the communicating systems. Similarly, the Webster Dictionary offers the following two definitions:
- Integration: The act or process of making whole or entire.
- Interoperability: The quality measure of the ability to use or operate reciprocally.
In other words, one can create (integrate) a whole using parts that may or may not have interoperability as a one of their qualities.
What do we really mean by ‘interoperability’?
A clever person once explained the concept of interoperability using audio hi-fi systems. A micro system is an integrated system as all the functioning parts reside within the same physical box. A life style system is an interoperable system, where one can mix and match each functioning unit (e.g., amplifier, tuner, CD etc). Both type of systems are extensible, as they both support audio input from, say, an mp3 player. The integrated system offers benefits such as reduced physical size and a unified remote, whereas the interoperable system offers flexibility in choice – both now and in the future (e.g., tuner versus a digital tuner).
I own a mini system (too big to be micro – it is almost 18 years old), where I have replaced the CD player, but at the cost of an additional remote. The original system had one remote for all functions. I’m able to connect an mp3 player using the ‘video’ socket on the stereo, although the intent differed from the original design. The radio is a separate unit to the rest, but I am not able to replace it, as it utilises a special adapter to connect to the rest of the stereo. I could utilise the ‘video’ plugs, but then I’d not be able to utilise my mp3 player, and I’d be lumbered with yet another remote. A life style hi-fi system wouldn’t have the same constraints, but I’d most likely suffer from remote control overload.
What enables the interoperability for hi-fi systems is the red and white audio sockets on the back of the units, but it also brings the challenge of a unified view (the remote) of the whole system, as they were not part of the functional scope. Remotes aren’t compatible with the audio sockets.
It’s all about communication…
Software architecture (especially caBIG’s) are about communication – and communication implies an ability to exchange and understand information. And information is interpreted data within a certain context.
The architectural process is therefore primarily a process of continuous integration while ensuring interoperability as a quality attribute possessed by all parts. The sustainability of the architecture is directly dependent on the integration effort – i.e., good system interoperability is a key quality for large-scale inter-connected systems – whether or not SOA is utilised.
[post edited 12th June, 2011]