Realities and Opportunities
In its purest form, the objective of standards in the Information and Communication Technology (ICT) area is to establish a common mechanism for two systems to interoperate through the implementation of a technical specification. The specification can cover data formats, protocols or other interfaces and practices, but the objective is essentially the same in each case. While standards can in some cases fulfill this objective, this is not an automatic, mechanical process guaranteed to succeed, and there are usually many challenges to achieving interoperability between different implementations of an ICT standard. Once these challenges are fully understood, the collaborative efforts of different implementers can often navigate these challenges and enhance interoperability.
Interoperability between Implementations of an ICT Standard is Inherently Difficult
The Basic Case. Even in the most straightforward case, interoperability between different implementations can be quite difficult. There are a number of reasons for this. First, the standard may have gaps, leaving it up to each implementer to choose how to enable a missing feature, which can result in conflict between approaches. Second, the standard could be written vaguely or have other errors that would lead implementers to take different approaches to a particular element of the specification. Third, the standard could offer multiple choices as to how to approach an element that could cause conflict between different implementations. Fourth, implementers could choose to take different technological approaches to implementing a particular element, causing subtle (or not so subtle) conflicts between the different implementations. Fifth, there could be bugs in different implementations that impair interoperability between them. Sixth, implementers may choose to implement different parts of a standard based on different views as to what is going to be appropriate in the marketplace, which can lead to interoperability gaps between implementing products. And seventh, there is often asynchronous evolution of standards and the products that implement them.
It is worth exploring a couple of these points further. As noted in the first and third points above, specifications often give implementers choice with respect to different elements, and the ability to extend the specification in their products to incorporate additional functionality. By incorporating such additional functionality, extensions can often enable a better user experience. However, because different implementers may incorporate different extensions, there is a risk that extensions may not interoperate with one another. For implementers, this trade-off between functionality and interoperability is often a difficult one, and it is driven primarily by marketplace needs and demands.
Another key point is that standards change over time as proposals are made and adopted to fix errors, fill gaps and evolve the specification as the broader technology landscape evolves. At the same time, products that implement a standard are evolving and changing, sometimes by extending the standard to reflect new innovation ( extensions are sometimes proposed as evolutionary modifications of the standard). The cycles of evolution of the standard and the products that implement it are rarely in sync, leading to different products implementing different aspects of different generations of the standard at different times, in turn leading to interoperability challenges between applications. This is particularly challenging in rapidly evolving areas of ICT, where difficult choices need to be made about what will be successful in the marketplace.
In some markets, interoperability means that all products have passed some external conformance test, usually against some “reference” software.
The typical case.
The challenges noted above are compounded in the ICT area because in many cases ICT standards are interdependent and nested. ICT standards often incorporate other ICT standards by reference, which could in turn reference other ICT standards, and so on. This leads to a significant increase in complexity and the risk of interoperability challenges arising. For example, in the relatively straightforward case of one standard incorporating three other standards, there are risks that the primary standard may interpret those referenced standards differently from other implementations, that it will be out of sync with the evolution of those referenced standards and the products that implement them, and that it will introduce errors into the implementation of the referenced standards. As a result, interoperability between different implementations of ICT standards is usually quite complex and difficult to achieve because of the typical interdependency between different standards.
The network environment factor
The ICT area is increasingly characterized by the interconnectedness of products and services. This creates a challenging environment for interoperability because a significant number of connection points between a technology and other parts of a network or ecosystem increases the number of tradeoffs and choices that implementers must make. Any single choice has the risk of creating interoperability challenges in the marketplace.
Customers are Looking for Real World Interoperability
Customers for most part look beyond all this complexity and demand that products and services in the marketplace work well together, regardless of how that interoperability is achieved. They look to vendors to navigate these challenges and deliver the level of interoperability demanded by customers between implementations in the marketplace, without necessarily needing to know how it is done.
Enhancing Interoperability between Implementations with Multiple Tools
As customers become more focused on and vocal about interoperability, many vendors are trying to determine the best way to achieve this objective. While there are tools to do so, there is no sure-fire or automatic way of achieving interoperability, and each possible path has its benefits and limitations. Two important tools include:
Conformance tests. Standard setting organizations sometimes develop tests (or recognize third party tests) that try to verify whether an implementation of a standard conforms to the requirements of that standard. Conformance tests usually include test specifications for a test harness (hardware and software used to run the tests), test cases (inputs and expected outputs), and/or test procedures for running the tests. While they can be helpful, there are limitations in this approach. Conformance tests may (a) test only a subset of the elements of a standard, (b) vary because of gaps or flaws in a standard, (c) interpret parts of a standard differently, (d) contain bugs, (e) reflect the commercial or technical motivations of their creators, and (f) be out of sync with the evolution of the standard or the products that implement it. Each of these may mask differences in implementations or create false conflicts. Put another way, products that interoperate in practice don’t always show up as conforming in tests and products that are determined by a particular test to be conforming don’t always interoperate. So, while conformance tests can be helpful in driving interoperability, they are not a panacea and their shortcomings must be recognized and addressed.
Interoperability testing. Vendors also look to “plugfests”, “labs” and other practical mechanisms to achieve interoperability. These efforts may be more labor intensive than conformance tests, but they are typically more effective in driving real-world interoperability between implementations. These usually involve different vendors coming together to test whether their respective implementations interoperate in practice. This can take many different forms depending on the technology involved. In the case of document formats, for example, it would typically involve multiple vendors testing their implementations against a common library of documents. The goal is to identify where there are differences in behavior, identify why they are occurring, and then determine how best to address them.
At the end of the day, achieving interoperability in practice requires a good faith effort on the part of all relevant implementers. Also, it is worth recognizing that interoperability often involves trade-offs with respect to functionality. Thus, while plugfests can result in important improvements to interoperability, they are part of a dynamic process, the goal of which is real-world interoperability in important areas. For the reasons noted above, perfect interoperability is rarely achieved at any point in time.
“It should be noted that interoperability means different things to different people. In some markets, interoperability means that all products have passed some external conformance test, usually against some “reference” software. This type of testing, however, usually doesn’t bring much value to the customer because the tests are usually for a small subset of features that everyone who has paid for the testing can pass. Testing a product against reference software instead of competing products also leads to pairs of products that both pass the test but do not interoperate.”
Customers want interoperability between different implementations of standards in the marketplace. Achieving this is difficult given the complexity and ever evolving nature of technology in the ICT area. Nevertheless, vendors have tools at their disposal to enhance the level of interoperability between implementations.
Director of Public Policy for Asia Pacific, CompTIA