Achieving Interoperability is Difficult

Defining Information Technology (IT) interoperability and the roadmap to achieving this goal remains a difficult endeavor as it varies with the industry, the technology and the final purpose under discussion. Basic interoperability can be defined as two or more IT systems intercommunicating with security, timeliness, and compliance to their designed purpose. This usually comes down to the execution of a common business or technical process among the interoperable systems with adherence to the stated goal of the process. However, the techniques on how that “interoperability” is accomplished among different commercial software products are where the misinterpretation or confusion lies.

The United States Government has been buying, promoting and using the phrase Commercial Off the Shelf (COTS) products for the past 20 years to reduce the associated implementation, integration and support cost in IT projects with great success. If we are talking about interoperability across Internet/supply chains then the only definition that makes sense is a community of COTS Interoperable products. Note that the word interoperable has no real usefulness without “COTS” or “community” in the context of wide scale implementation. All three are necessary to accomplish the goal – the goal of providing the end-user community of software purchasers with a set of known products that are COTS interoperable among themselves that may be installed and will intercommunicate in an interoperable manner with little or reduced requirements for costly professional services to implement.

There are many nuances on how to accomplish a community of COTS interoperable products depending on technologies under test, the target market place for the products, the end network configurations the products must operate within and whether the market place is composed of early or late adopters. Since all of these factors cannot be dissected here, I’ll focus on three case studies of attempts to develop a community of COTS interoperable products. One of these is very successful, one of these is partially successful and one has not lived up to its potential. The different outcomes have less to do with the technical details of the standard, but rather on the test methodology, test environment and the degree to which the end-user community chose to support the certification programs.

The Three Standards

The three standards are RFC4130, RFC3335, and the set of RosettaNet standards.

1. Very Successful: RFC4130 is a secure, reliable messaging standard based on HTTP which is heavily used across the world in a variety of industries including retail and financial services.

2. Partially Successful: RFC3335 is a secure reliable messaging standard based on SMTP which is less used, across the world primarily in retail.

3. Not Met Potential: RosettaNet standards have two components secure messaging and document. The standard is used in the Pacific Rim and the USA in the computer and consumer electronic industries.

Factors for Success

Although there are many differences in the above three cases of how the interoperable products were developed, there are three major factors which I strongly believe, having been involved with each of these, determined the degree of success:

The Techniques: The techniques used to achieve the technical “interoperability” between the products. There are various techniques for achieving technical interoperability depending on whether one is dealing with communications technologies, syntax, semantics, or business process standards to name a few. However, regardless of which of the above one is dealing with, the two most common methods are:

• The conformance engine technique – one-to-many testing.
• The other is the full matrix interoperability technique – all-to-all testing.

The Testing Environment: The testing environment and setting for the interoperability tests. Interoperability provides little benefit to the end-user community if it only works in a laboratory test environment, which I’ll refer to as “product interoperability”. It also must translate into interoperability in the production/ real life environment in order to provide a major cost saving to the end-user companies – ROI, of course being the key driver.

End-user Support: The degree of support and adoption of COT interoperable products by the end user community is critical. Undergoing software certification testing requires an investment of both time and money from the software vendor. Unless there is unified industry support among end-users to only purchase certified software products, there is little incentive for software companies to invest the time and money for interoperability certification testing.

Standards Success Analysis

RFC4130 (AS2):

1. Was tested in a full matrix interoperable test environment – all products to all products,

2. The test was not conducted in a laboratory, but over the live Internet simulating the a live implementation environment and finally

3. A major group of end users committed to only using certified interoperable products. These three things developed a highly success full set of over 50 COTS products that were implementation ready, that is “a community of COTS interoperable products.”

Users report that they can install products and start communicating within a few hours if certified products are used versus days or weeks when using non-certified products. This saved the industry tens of millions of dollars by avoiding the need for professional services.

The end result was:

• Reduced the cost to operate Reduced capital IT cost
• Reduced installation cost
• Reduced upgrade cost
• Better security management
• More choice in products
• More price points & features

RFC3335 (AS1):

1. Was tested in a full matrix interoperable test environment – all products to all products, over Internet to simulate a live production environment, but

2. Did not have a group of users commit to implementing only interoperable certified products in their supply chains.

These products install as easily and quickly as above RFC4130 (AS2); however there are a little more than 10 of these products offerings world wide. A community of COTS products developed, but a successful marketplace did not and hence little ongoing investment by the software community for implementing additional bells-and-whistles.

The set of RosettaNet Standards:

1. Used the conformance engine technique – one-to-many testing

2. They were tested over internet but in a partially sequestered test lab environment and finally

3. No set of end-users committed to using only certified products in their supply chains.

These products are time consuming to install at the messaging level. Since the conformance engine had bugs requiring ongoing fixes, that meant that Product A may have tested against a different code base version of the reference product than Product B. In a one to many testing scenario, if the reference or conformance engine code base is changing on an ongoing basis, then interoperability becomes an elusive, constantly moving target.

RosettaNet has expanded messaging options by adding RFC4130 and ebXML which will greatly enhance the message level COTS. However this will not solve the ongoing problems associated with the document types that are still tested in a one to many manner. This is a nice standard which did not live up to its potential because the wrong means of technical testing was chosen and no end-users committed to using only certified products in their supply chains.

Conclusion

The lessons learned from above are straightforward:

1. Interoperability testing should reflect the production environment of the products. Conformance testing does not imply interoperability and should be thought of as a pre-stage event to prepare for full product-to-product testing.

2. The production of a community of COTS interoperable products, that is implementation ready products, is much more than a technical effort. It requires a marketing and business plan to educate the market on the value of certified products and the endorsement and support of the end-user community to support the purchase of certified COTS interoperable products.

Other Posts by: Rik Drummond

Related Posts