Email This Author

Comment On Article

About The Author

More Articles By This Author

Interested in this topic? Need more information? Energy Central has created a complete information service focused only on Infomation Technology. There is no better way to stay informed. Get more information on Infomation Technology today!

Software buyers wish to purchase Commercial Off The Self (COTS) products for their networks and supply chains that are reasonably priced, have appropriate functionality and solid support, integrate to their existing systems with as little in-house development as possible, and intercommunicate with their business partners in a straightforward manner. These attributes are often associated with “interoperable” products.

As a result, you would expect all testing agencies to certify a set of interoperable products that communicate with one another in a straightforward manner, and do not require burdensome installation and interconnection issues with additional professional services required to ensure interoperability. The interoperable group should be error-free with respect to what was tested.

But What Does “Interoperability” Mean?

However, because of the current state of the testing art, there is often significant misunderstanding by the software purchasing community on exactly what interoperable means and what they should expect from certified interoperable products. The meaning of “interoperable” may vary depending on the testing agency certifying the product. Until the testing agencies start conveying a standard meaning for “interoperable product” -- like a universal brand -- the software buyers must be wise as they select products and further analyze what they are purchasing when they buy a certified “interoperable product” to interface to their trading partners.

The lack of clear branding for interoperability and a missing shared understanding of interoperable products creates problems for networks supply chain users. How do CIO staffs determine whether COTS products are interoperable and thus choose those that are appropriate for use in their value and supply chains and networks? If the CIO organizations is a leader in their supply chain or network, they must account for an even bigger picture of what testing methodology they will depend upon for the purchase of “interoperable products” for all members of their supply or value chain or network. In this case, the lead organization often requires participants in their supply chain or network to only purchase products from this select group of known “interoperable products” using one agency’s testing methodology.

Thus because the brand “interoperable products” is not yet jointly well-defined from us as a testing authority to the buying organizations, there are several points of common misunderstanding on what the brand “interoperable products” means to the CIO organizations. There are four common fallacies about product interoperability. The first two common fallacies should only pertinent to testing authorities. The consumers of interoperable products and they need not really worry about these. However, since we do not have a uniform meaning for interoperable product at this time the buying community should be well educated on all four. The last two are critical to how the consumers, the purchasers of interoperable products; understand the meaning of the brand.

The common fallacies are:

1. Fallacy: Interoperability is Transitive – We know that interoperability does not act like the “=” mathematical equal. A=B, B=C, does not always imply that A=C. This is why Conformance Testing does usually work for interoperability. This is a critical issue for a consumer of interoperable products, if the testing is done ‘only’ in this manner, it is generally (not specifically) probable that the products will NOT be interoperable as they are implemented in the network without additional costly effort.

2. Fallacy: Interoperability is Commutative – We know that interoperability des not act like the “=” mathematical equal in that A=B does not imply B=A. We may say (1) A and B are interoperable, (2) A is interoperable to B, or (3) B is interoperable to A. For (1) interoperability is commutative, but not for (2) and (3). In other words, we can say “A and B are interoperable if and only if A is interoperable to B and B is interoperable to A. This one is less important than Transitive, but still important, in that two products could only be interoperable in one direction.

3. Fallacy: Interoperability is All Inclusive – Just because two products are designated as interoperable on the same standard does not mean they are inclusive to the same test group. Only products that have been tested together and have demonstrated interoperability within the same test event are interoperable. The testing should be between all products to all products – as they will be finally implemented in the final networks. Any other method assumes and does not demonstrate interoperability.

4. Fallacy: Interoperability is perpetual for the life of the product - Interoperability among products expires as the interoperable products within the initial test group change version or implements patches to their code base. Just because product A has not changed does not mean it is still interoperable with the remainder of the interoperable product group. Interoperability expiry happens normally about every 12 to 18 months. Product interoperability has a “shelf life” like food or medicines.

What does this mean to me as a corporate CIO staff and as buyers of these products? Until testing agencies decide to have a uniform meaning for interoperability, the consumers of these produces should be well educated and use the above list to evaluate interoperable products they are purchasing as to the degree of interoperability they possibly may have. Products that are not fully interoperable cost the end user time and money as they attempt to make them work in the value and/or supply chain and/or network.

• Have they been tested in a full matrix – ever product to every product – manner and not just using a conformance methodology?

• Is the product I am purchasing part to of the same ‘test group’ of products that I will be communicating among?

• Is the product’s interoperability seal or badge’s shelf life still good with respect to versioning among the other products?

These are the minimum questions corporate IT and the purchasing departments should be asking before they purchase an ‘interoperable product’ for use in their organization.

We know you have something to say!

Contribute Today!

Do you agree or disagree with this article? Send in your own article.