Wednesday, February 29, 2012

Interoperability vs Intraoperability

Grahame talked about the two very different approaches to get system exchange data - Interoperability vs Intraoperability. The Interoperability approach focuses on agreed model to exchange information and leave system designers the flexibility in how the system internally handles it, where the latter focuses on the agreed system internal design to make the external exchange easy and straightforward as quoted below,
In this other approach, everybody sits down around the table and agrees how the systems should work, and then everybody goes off and makes their systems work that way – they rework the core of the systems to function in the agreed way.

This argument is a bit loose, the "core of the system to function in the agreed way" itself is about the externally manifested behaviour of the core system, it is not necessarily the internal design of the core system.

Secondly, this probably can happen within the organization if everything solution is greenfield development, and the organization has very strong architecture competency and architecture governance discipline. But is it feasible when it is put in front of the whole world - vendors, customers, solution integrators, etc. What's the incentives for the whole community to agree and subscribe to the same design? Let the community and market speak for itself.

Have been working in Java since 1995, I have not seen any Java spec/standards mandate the internal design of the spec implementers, it is all about the external behaviour/functions - the contract. How is the contract executed is completely left to the vendors to decide, and that's the place where the innovation occurs.

If we take away the opportunity for IT to innovate, IT is going to turn away from us.

1 comment:

  1. It's also a function of industry maturity. In a very major space, I guess it may be possible for everyone to agree on the "best" way to do something. I think Health IT is far from it...