Standards Compliance versus Interoperability

Pitting standards compliance against interoperability at first glance seems contradictory. After all, standards are created to insure interoperability of products and applications. If multiple vendors engineer products to the same standards, the prospects for interoperability are greatly enhanced, reducing the customer's exposure to being locked into a proprietary solution. That customers appreciate this relationship is shown by the long lists of standards checkboxes that must be filled before an RFP for new product acquisition is awarded. No vendor wishing to compete in the marketplace can ignore the importance of standards compliance. Nor can any customer wanting to maintain vendor independence and flexibility in product selection.

Standards compliance, however, does not guarantee interoperability. Once standards are formalized through the appropriate standards organization, the guidelines for product design are clearly drawn. The problem is that vendors may interpret these guidelines differently, or the standards themselves may lack sufficient definition in some areas to insure compatibility. The result is that two products can be fully standards compliant, and yet fail to interoperate. Standards development thus requires periodic interoperability testing to verify the integrity of the standards themselves and to surface variances in vendor interpretation. The iSCSI standards initiative within the IETF, for example, has been accompanied by interoperability plugfests held at the University of New Hampshire. Additional iSCSI interoperability testing will occur at the SNIA Storage Networking World conference in Orlando in October. Without practical validation of both standards compliance and interoperability, the goal of standardization cannot be met.

Likewise, interoperability in itself does not guarantee standards conformance. Vendors often have their own interoperability labs which are used to craft multi-vendor solutions. A storage vendor, for example, may configure a tape backup solution that includes their own storage products, SAN switches, Host Bus Adapters, routers, tape subsystems and application software. The prime directive for such affinity group configurations is to debug any problems and to produce an interoperable and supportable solution. Although some level of standards compliance may be assumed, if the intention is to produce a working solution that can be taken to market, interoperability typically takes precedence over standards. As a consequence, a multi-vendor interoperable solution may perform flawlessly until the customer plugs in a third party standards compliant product. Unfortunately, this is too often the case for packaged SAN solutions. Solution providers may tweak microcode to enhance performance or functionality and in the process make it impossible for customers to add other products into the configuration. Whether intended or not, this binds the customer to a particular vendor and defeats the purpose of open systems standards.

Since enforcement of both standards compliance and interoperability is essential for the long term viability of the customer's storage network, customers themselves must encourage their vendors to provide solutions that are both interoperable and standards based. In support of this goal, the SNIA Interoperability Committee is producing standards compliance test suites that will assist vendors in meeting their dual responsibilities for standardization and interoperability. This effort will hopefully remove some of the contradictions that currently exist.