Wednesday, December 26, 2007 - Posts

Definition of Interoperability

What does the term 'interoperability' really mean? What does it mean to 'interoperate' or be 'interoperable' when designing solutions? A number of definitions are available depending upon whom you speak to or where you search. Some define interoperability in terms of relationships; others have a much more specific view based on the technology that they are describing.

To define this term, as per Simon Guest, there is a three-part explanation: one formal, one pictorial, and one comparitive.

1. Formal: Interoperability enables communication, data exchange, or program execution among various systems in a way that requires the user to have little or no awareness of the underlying operations of those systems. Interoperability is about connecting and building applications that work with each other to such an extent that the presentation to the user is seamless.

2. Pictorial: When describing interoperability, think of it as making reference to a popular lake-dwelling species, the duck. As a duck is seen swimming across a lake, only the top half of the duck looks very serene. The duck appears to glide across the lake with little or no effort. Despite this calm exterior, the duck’s legs are frantically kicking in all directions to get to the other side of the lake. Such is the way of interoperability. A well –designed solution that interoperates among many diverse systems should appear “calm and serene” to the user – the user should have no awareness that a click of a button or a switch of a page might create many calls to various systems throughout the enterprise, somewhat akin to the frantically kicking legs of our feathered friend.

3. Comparative: Comparative draws upon the previous two but offers a slightly different slant which is the following:

• Migration: Opportunities exist in the migration space. Customers do have code that can benefit from running on the .Net framework, and some of this code already exists within J2EE applications today.

• Portability and Interoperability: Portability is the notion of running a single component or piece of code on platforms based on multiple implementations from various vendors. The point isn’t to detail the sustainability of either the Java or the .Net platform for developing applications. The success lies in the operability between the two platforms.

• Reuse of existing systems: Most established companies have a number of legacy systems. The term legacy is meant technology that’s not being actively developed upon today. For example, a system located in the data center that’s still in production but no longer offers a strategic advantage to the company is a legacy system. A plan to move these systems to a new platform might be a longer-term strategy. A solution that has the ability to interoperate with these systems has the potential to extend the life of these systems and more importantly, the knowledge of the developers who work with them.

• Delivery based on technical merit: Designing an architecture that can enable interoperability promotes the selection of platforms based on technical merit. One could argue that every platform and technology—whether it’s .Net, J2EE, or anything else – has its own merits for deployment. This could be maturity, reliability, scalability, security, technical advancement, and so forth. An approach to developing applications and services that have the ability to interoperate with one another allows platforms to be selected based on their merit and applicability to the job, allowing greater choice regardless of the vendor.

• Pilot for adoption: When organizations want to deploy a new technology such as the .net framework, it’s rare that they simply rip and replace an entire application or system. In many cases, a replacement is normally triggered by a pilot, or proof-of-concept, project. Such a pilot tends to be a short-term project with an aim to prove that the technology can work well with existing systems and applications. The ability for this pilot or proof-of-concept project to interoperate with existing production systems is imperative, and in many cases, can often determine its success.

• Migrations: Even if a system will be replaced or updated, it’s rare to find a case where this can be done with a single “flick of a switch” – many migrations have to be well planned and carefully executed, and often involve moving an application a few parts at a time. This way of dividing a system for migration purposes often creates a demand for interoperability (because some parts that have been migrated still might need to communicate with others that have not).

Obi Oberoi