Vendor Accent

Demystifying Interoperability

By Vijay Kapur, National Technology Officer, Microsoft India

Information Systems are today seen as critical to government and business productivity and growth. One of the keys to success in the IT era is the seamless exchange of information across heterogeneous IT infrastructure. As systems connect to each other the issue of interoperability assumes increasing significance and is a ‘top of mind’ issue for technical and business leaders and policy makers. This article attempts to demystify and clarify some of the grey areas around this subject.

Imagine a hypothetical scenario of a business transferring funds from an overseas bank account to their supplier in India. The transfer takes place without the appropriate conversion between the foreign currency and Indian Rupees. Or a landlord, dealing with two different municipal departments, suddenly finding his property tax rates shooting through the roof because one department’s system recorded the extent of his property in square meters whilst the other ‘sent’ the value in square feet! Though these examples are hypothetical, they illustrate the consequences of IT systems failing to ‘communicate’ or ‘interoperate’ with each other.

For the government defining interoperability roadmap assumes greater significance as it’s currently in the phase of building a robust IT infrastructure to support the elaborate e-governance initiatives. Here are some aspects which the government and businesses should be mindful of while outlining an interoperability strategy:

What is Interoperability

While there could be many meanings of interoperability depending upon various contexts, from an IT perspective it could be defined as: “The ability of disparate IT products and services to exchange and use data and information (that is, to ‘talk’) in order to function together in a networked environment.” Simply put, interoperability is about ensuring systems work together.

Two aspects need to be addressed by systems in order to be interoperable – the first is the ability to exchange data, often called technical interoperability, and second to correctly interpret the data or semantic interoperability.

Technical interoperability deals with the linking up of computer systems for transporting, exchanging, collecting, processing, and presenting data. It spans infrastructure, such as network protocols, and system level interoperability, such as using Web services. One of the means of achieving technical interoperability is by the use of standards or ‘standards-based’ protocols for example conforming to the TCP/IP stack protocols for network interoperability or using XML for transfer of data between systems.

Semantic interoperability, on the other hand, is about making sure that the systems exchanging data share the same meaning for the data exchanged. Very frequently systems can technically exchange data but do not correctly interpret it in the absence of a shared meaning for the data.

In addition to technical and semantic interoperability, there are also organisational and Process Interoperability to be considered - the organising of business processes and organisational structures, including process restructuring, doing away with duplication, and the development of interoperability ‘frameworks’ for better exchange of data within and with other organisations. These also deal with cultural issues, such as inter or intra departmental ownership of information, perception of loss of control and power due to the creation of shared assets. All of these impinge upon the achievement of interoperability.

As systems and organisations become more complex, the relevance and importance of semantic and process interoperability increases sharply. Unfortunately most of the organisations prefer to follow a ‘bottom-up’ approach of focusing just on technical interoperability which has serious consequences giving rise to prescriptive guidelines and ‘brittle’ systems that emphasise technical requirements rather than architecture. Interoperability becomes difficult to achieve or breaks down for want of semantic and process consistency. The silos tend to remain silos!

Conversely, organisations that choose to adopt a ‘top-down’ approach to interoperability concentrating on semantics and process definition avoid brittleness in their systems. A top down approach leads to the development of implementation guidelines driven by business requirements which can keep pace with market evolution rather than a set of straight-jacketed rules. Projects are personified by business value rather than technical requirements; real interoperability becomes feasible and silos disintegrate.

Standards and their relevance: de facto and de jure standards

As mentioned earlier, adherence to standards is one way to facilitate technical interoperability. However, simply adhering to standards does not guarantee interoperability as the mere existence of a formal standard does not automatically imply it will achieve great market adoption or usage. A case in point here is the widespread adoption of the TCP/IP networking stack. This become the de facto standard for the Internet rather than the ISO developed Open Systems Interconnect (OSI) networking model which many expected would become the dominant standard across governments and industry.

A specification is unlikely to achieve broad market support and adoption if it is not good enough or does not fulfil the requirements. The fact that it was developed by a Standards Organisation (de jure standard) is moot. Experience confirms that other standardisation methods are equally relevant and can help achieve technical compatibility. For instance, the emergence of a widely used software specification or product (a de facto standard!) can often induce widespread compatibility more effectively than formal de jure standards. These de facto standards come into being because innovation in technology, especially IT, does not always march in step with the development of de jure standards by Standards Organisations. When technology innovation outpaces the development of standards, and as that technology is absorbed by users and the market, the vacuum gets filled by it becoming a de facto standard. Examples of such successful de facto standards include PDF as well as XML standards.

When most users deploy products based on de facto standards, compatibility, and interoperability, comes into play naturally. In fact, it is the diffusion and ubiquitous use of certain technologies that simplify the interoperability processi. And companies offering such de facto standards can further encourage them by publishing and licensing (often on royalty free terms!) their proprietary technologies and intellectual property (IP) to other market players so that more users have access to them to achieve free information exchange across platforms. Microsoft’s publication of the XML Reference Schema for Microsoft Office and the recent submission of Microsoft Office Open XML Formats to ECMA for standardisation are examples.

Open Source is not an Open Standard (or vice versa!)

People often use the phrases “Open Standard” and “Open Source” synonymously. While this is a widely held misconception; they are not the same. Open Source software (OSS) is an implementation; a type of software described by its development and licensing model. An Open Standard, on the other hand, is a technical specification, a set of technical instructions and procedures to ensure that a product meets its purpose and consistently performs to its intended useii. The open-standards process is neutral with regard to software development models, and so it is equally possible for an open standard to be implemented in proprietary software as it is in OSS.

Another fallacy is the erroneous equation of Open Source software with interoperability itself - that is, the use of OSS will ensure interoperability. Quite the opposite could result depending upon the circumstances. Because all OSS source code may be modified by anyone, an OSS product initially standards-conformant and/or interoperable may be rendered non-conformant or incompatible due to subsequent modifications made to it. At the very least, the freedom to modify code and the lack of market incentives to maintain backward compatibility and fidelity encourages the creation of many permutations of the same type of software application, which can add a significant implementation and testing overhead to interoperability efforts.

Towards Interoperability

The proliferation of standards that exist today can confuse and actually hinder interoperability. A good strategy to achieve interoperability is to apply widely accepted de facto standards and open standards based on pervasively used technologies. TCP/IP and HTML, for example, are among the most common open standards that allow users to use the Internet for information exchange irrespective of the source and destination platforms. On the other hand, although PDF, Microsoft Office formats, Java, and Win32 APIs are proprietary, they have, due to their wide adoption become de facto standards widely accepted among mass users.

And finally, remember that interoperability is not guaranteed just by adopting a standard. Building complex systems that interoperate is as much about semantic and process interoperability as it is about technical.