Interoperability: What it is and what users really want

Interoperability encompasses many layers, including conformance to standards, component-level interoperability, and end-to-end system interoperability.

Scott Robinson
Click here to enlarge image

By Scott Robinson

The great thing about standards is that there are so many to choose from...and, if you don't like any of the ones available, you can create your own.

That adage sums up users' feelings toward standards across the board and holds true for the storage industry. John Webster, senior analyst at Illuminata, explains those feelings, saying, "Users have no direct control over setting the storage networking standards agenda. Clearly, they are not comfortable with the process as it is now practiced, and they fear that the strongest vendors will ultimately take control over the agenda."

To deal with these user concerns, the Storage Networking Industry Association (SNIA) last year created the Supported Solutions Forum to "promote customer adoption of storage networking solutions by providing assurances of working configurations supported by vendors."

But what does this announcement mean to end users who are concerned about interoperability? First, let's take a look at what is meant by the term "interoperability."

What is interoperability?

One definition of interoperability is "the ability of a system or product to work with other systems or products without special effort on the part of the customer." But a simple definition provides only the overall picture. A closer look at interoperability reveals that there are different layers to the discussion. The first layer is simply conformance to standards. While this is the foundation for interoperability, it is only the first step. Vendors may interpret standards in a way that makes their products incompatible, and vendors routinely add functionality outside the scope of the standards.

The second layer is component level interoperability. At this level, pairs or groups of devices are tested to ensure they work together. This assumes that the products adhere to standards in a compatible way and that functions and features work seamlessly across the products.

The third layer, end-to-end system interoperability, is what the Supported Solutions Forum (SSF) and its members-now numbering more than 30-are beginning to address. At this level, the overall hardware infrastructure and the software applications running within a storage area network (SAN) interoperate. In an SSF environment, the vendors must also agree to work together to provide support across product boundaries.

In the SAN Migration and Management Strategies study published by Enterprise Management Associates, 70% of the end-user respondents indicated that compatibility certification was "critically important" to them, with the other 30% stating that it was "somewhat important."

In the same study, 22% of the respondents felt that interoperability certification testing was not a criterion for product selection. Reasons for this included the belief that vendor interoperability testing is biased, not extensive enough, and too slow. Why would end users give such contradictory responses? On one hand, interoperability certification is important, but on the other hand, it is not a criterion for product selection. Basically, interoperability in the traditional sense is not what concerns end users.

Standards compliance is only a starting point for interoperability. Products may fully conform to established standards yet not work together. Illuminata's Webster calls interoperability a "red-herring issue" when cited as an impediment to SAN adoption by end users, believing that more-compelling barriers are high cost and staff inexperience.

What do users want?

So what are end users really looking for when they talk about interoperability? In our experience, customers want an end-to-end solution-an open architecture that allows the flexibility to choose between best-of-breed products. Users also want someone to take ultimate responsibility for supporting a multi-vendor environment -"one throat to choke," so to speak.

Support is a major, often overlooked, hurdle for multi-vendor configurations. When a support issue arises in a multi-vendor environment, finger pointing can send an end user from one vendor to the next, trying to determine who is responsible for fixing the problem.

For end users looking to implement a multi-vendor SAN infrastructure, there are several key factors to consider. First of all, choosing a partner that has integration experience with multi-vendor technologies is key to ensuring interoperability. The partner should have an interoperability lab to do its own testing. The company should also be able to outline its process for certifying interoperability between products and to provide references from customers who have implemented the type of architecture that is being considered.

According to Janet Waxman, program director at IDC, "SANs are complex, with many components supplied by a variety of different companies. Each SAN is also relatively unique, as it must fit the customer environment. This combination requires interoperability testing and also provides a key driver for channel participation."

What does the future hold?

The SNIA Supported Solutions Forum and its Cooperative Support Agreements are a good start to developing a foundation for better vendor interoperability and support. This announcement can help to build momentum to pursue interoperability for a broader umbrella of products.

However, seamless interoperability will never happen in an industry driven by innovation. There will always be tension between conformance to standards and addition of new features. Vendors have to add features to differentiate their products. These new capabilities cause interoperability issues, which, in turn, will lead to the creation of new standards. For rapidly evolving technology, it's critical to strike the right balance between innovation and interoperability.

Scott Robinson is chief technology officer at Datalink (www.datalink.com) in Chanhassen, MN.

This article was originally published on February 01, 2002