Standards Compliance Versus Interoperability

At first glance, a conflict between standards compliance and interoperability seems contradictory. After all, we create standards to ensure that product and application interoperate. By designing products to a set of standards, vendors greatly enhance the prospects for interoperability and reduce customers' chances of being locked into proprietary solutions—customers rely on standards to ensure interoperability; when considering a new product acquisition, most companies send out a Request for Proposal (RFP) that contains a long list of standards with which any potential product must comply. No vendor that wants to be competitive can ignore the importance of standards compliance—nor can any customers who want to maintain vendor-independence and flexibility in product selection.

Standards compliance, however, doesn't guarantee interoperability. Even after the appropriate standards organization's committees formalize standards, those standards might lack sufficient definition to ensure compatibility, and vendors might interpret guidelines differently. As a result, two products can comply fully with the same set of standards yet fail to interoperate. Standards development requires periodic testing, both to verify the integrity of the standards and to discover variances in vendor interpretation. For example, interoperability "plug fests" at the University of New Hampshire accompanied the Internet Engineering Task Force's (IETF's) SCSI over IP (iSCSI) standards initiative. Additional iSCSI interoperability testing will occur at the Storage Networking Industry Association (SNIA) World conference in Orlando in October 2001. Without practical validation of integrity and interpretation, we haven't met the standardization goal.

Conversely, interoperability doesn't guarantee standards conformance. Vendors often have their own labs in which they craft multivendor solutions. A storage vendor, for example, might configure a tape-backup solution that includes storage products, Storage Area Network (SAN) switches, host bus adapters (HBAs), routers, tape subsystems, and application software. The prime objective for such affinity group configurations is to debug any problems and to produce an interoperable and supportable solution. Although we might assume some level of standards compliance, if the vendor's intention is to produce a working solution for the marketplace, interoperability typically takes precedence over standards. Consequently, a multivendor solution might perform flawlessly until the customer plugs in a third-party standards-compliant product. All too often, packaged SAN solutions fail at that point. Solution providers might tweak microcode to enhance performance or functionality, making it impossible for customers to add other products to the configuration. Whether the vendor intended to restrict the customer's options or not, the customer is then bound to a particular vendor, which defeats a basic goal of open-systems standards.

Because standards compliance and interoperability are essential for the long-term viability of customers' storage networks, customers must insist that storage products provide both. The SNIA Interoperability Committee is producing standards-compliance test suites to help vendors meet these dual responsibilities. Such efforts can help eliminate the existing conflicts between standards and interoperability.