The Interoperability Files: Defining Interoperability and Integration Part 2

Ah Mr Nanni,

I am indeed humbled and excited at reading your reply to my posting on Defining Interoperability and Integration and for highlighting the apparent paradox in my definition. However, as to whether this leads us back to using the original definitions I am not sure I agree. It is not that I disagree with your points or that I think our views are that far apart but that this represents an opportunity for us to move the definition forward rather than to settle for second best with the current version.

On first glance, I think our differences can be explained by the fact that we are approaching the problem from different starting points. For my part I was viewing the problem from a System Integrator (bespoke development) perspective where as I think you are taking a particularly product centric view. This is not to indicate a flaw in your thinking but more in mine, for which I thank you greatly. In order for the requirement of integration to exist then there must exist at least two different ‘systems’ (immaterial of whether they were bought from a vendor or built in-house) that need to be integrated together in the first place. Therefore, taking a product centric position (irrespective of the source vendor or bespoke) does indeed make sense and I would agree that “interoperability is a quality of the system” and not of integration itself.

However, I think the fact that we started from these two different perspectives highlights a significant feature of interoperability that your definition does not capture. Taking the System Integrator view there is still much work to do to ensure that one system interoperates with the other even if the originator (vendor or in-house) of each system believes that each system is interoperable in of themselves. This ‘glue’ that exists to broker this integration must therefore be classified as a ‘system’ itself and therefore exhibits some quality of interoperability as do the systems themselves, that are being integrated. I think it is too easy to assume that by a product being to some level “interoperable” solves all the problems.

I think this is an important factor that should be reflected and while I agree in essence with your redefinition “Interoperability [of systems] is a condition sine qua non to achieve system Integration” I think it needs further extending to ensure the notion of “quality” is maintained. With this in mind I propose the following definition for interoperability, with the changes to my original as listed.

- As discussed interoperability now relates to the system (or organisation).

- Quality Attribute is a common architectural term that I have decided this time round to introduce and to replace the word “property”. 

- “facilitates” to replace “ensures”

- “a level of independence” removed from definition.

As for the definition of integration, there may be a “temporal dichotomy” but if this is the case then surely that is true of the original definition. Therefore, it is clearly not right for us to revert back to the original. Perhaps I do not fully understand the dichotomy you talk of here so until I receive further clarification I recommend the use of my original definition.

This now brings me to your final Zen comment. I am unfortunately not one for remembering quotes however, one that does come to mind given we share the name which (and please do not read too much into this) is a quote from Matthew 15:14:

”If the blind lead the blind, both shall fall into the ditch.”

Ok, so now I got to hunting around so how about these pearls of wisdom from Isaac Asimov:

“If knowledge can create problems, it is not through ignorance that we can solve them.”

I guess what I am thinking here is that it is a good idea to try and get some definition here …

Matt