Pigs might fly. A generally usable storage management standard has been a long time coming. There is only one storage networking industry association - SNIA, and it has the only storage management interface specification - SMI-S. It had its origination in a concept labeled Bluefin.

Bluefin was created by a group of vendors, including Brocade, Computer Associates, EMC, Emulex, Gadzoox (which now doesn't exist), HP, IBM, Qlogic, StorageTek, Sun and Veritas. The SNIA launched SMI-S to develop the Bluefin specification. The aim was to produce a storage management standard to promote interoperability among inter-vendor storage area networks - SANs.

For customers it means that they can use one storage management product to manage SAN components: drive arrays; fabric directors; fabric switches; and host bus adapters - HBAs.

However, for suppliers this represents a threat. If, because of SNIA standards, I can take out my Cisco director and replace with a McDATA director then Cisco would not be best pleased. Multi-vendor SAN component manageability is good.

However, the ability for customers to freely change one supplier's SAN component for another is not something an entrenched SAN component vendor would look forward to. Certainly not when they are used to having a virtual monopoly of a customer's business following the initial purchase, because of the difficulty of switching suppliers.

Interface standards
Vendor members of computing industry standards bodies are happy with nuts and bolts interface specifications. Anything bigger than that runs the risk of opening up competition with products from other vendor members.

Look at it like this; Fibre Channel interface standards and message-passing standards for a SAN fabric are contention-free because they allow Emulex HBA to talk to Brocade switch and it to talk to EMC array.

Our storage industry has no soup-to-nuts supplier. There is no one supplier producing everything from HBA, through fabric components to drive arrays. Instead we have multiple levels of suppliers at each level and they need inter-layer interface standards because, without them, SANs would be unworkable.

But as soon as storage management standards come to the fore and multi-vendor interoperability becomes a coded way of saying inter-vendor switching, the entrenched vendors are then inclined to object.

Storage management products
Vendors produced management products for their own products. These couldn't manage other vendor's products because managing software can't talk the 'language' of the product. Users made it clear they needed multi-vendor management software and the SNIA set up its SMI-S workgroup.

Vendor members of this group came to it with their own different products and technologies. The SMI-S concept developed and some products were instrumented such that a properly formulated SMI-S query to them would produce a formal response as to their state and situation.

It is an obviously good thing, mirroring the situation in networking. Software suppliers like AppIQ developed products based on the SMI-S premise. Established storage vendors then had a conundrum. Should they take their existing storage management product and strategy and embrace SMI-S and the SNIA path or should they go their own way?

If they embraced the SMI-S way, then they gave market credibility to competitors who were more advanced than they were in developing SMI-S-compliant storage management products.

The SMI-S effort stuttered and development slowed.

Facts of storage management supplier life
Where vendors faced competition from another vendor they feared that adopting a position that favoured their competitor was hard to do.

Take EMC, IBM, Hewlett Packard, Hitachi Data Systems, Network Appliance and Sun (then led by Scott McNealy). By August, 2005, they were all OEM'ing AppIQ's storage management product, and therefore had a more or less equal interest in AppIQ and in the SNIA's SMI-S standard developing smoothly. But there was the latent wish all of them shared not to help their competitors at their own expense. We had stability because their wishes and fears were in balance.

Then Mark Hurd's HP blew this consensus to smithereens by buying AppIQ. Suddenly EMC, HDS, IBM and NetApp were selling HP's storage management product and exposing their customers in the future to competitive overtures from HP.

It was too much to take. In October IBM led a breakaway group, called Aperi, which would produce its own storage management code, be compliant with SMI-S, and compete with HP. But IBM couldn't resist taking a step further. It managed things in such a way that EMC didn't join, neither did Symantec.

Thus Aperi set itself up with three enemies: HP obviously; EMC; and Symantec. It must have seemed a stroke of genius by the IBM camp to make Aperi an open source group. How could it be an IBM lock-in if it was open source code?

Nevertheless the general industry view of Aperi was that it was an IBM-led group which would use predominantly IBM code and not be interoperable with the AppIQ product even though both would be SMI-S-compliant - in the same way that ANSI-compliant Cobol compilers produce incompatible code.

The Aperi vendors: IBM, Sun, NetApp, McDATA, Cisco, Brocade, and others then went into what appeared to be a winter hibernation. No Aperi website appeared, nor any Aperi organisation apart from the odd IBM Aperi program manager. It was then revealed that Aperi had talks with the SNIA about being formally recognised. It's cold out in the cold.

HP hit back. In a concerted move Sun, now led by Jonathan Schwartz, left Aperi and joined with HP, EMC and Symantec to form an anti-Aperi group (AAG) that emphasised the primacy of the SNIA.

IBM reacted quickly by sliding Aperi under the umbrella of the respected Eclipse Foundation and re-iterating its support for the SNIA. The SNIA put out a statement emphasising its respect for the passionate involvement by SNIA members in storage management standard developments.

Underneath this emolient cream there are strong tensions between the IBM Aperi group of SNIA members and the AAG. To have driven EMC into the same camp as HP and Sun is something of a miracle. It's hard not to see the Aperi group as becoming an irrelevance. Apart from IBM, which member has a strong commitment to open source? Sun had. It's gone.

NetApp, McDATA, Cisco and Brocade are all among the last suppliers on earth to believe in open source code; much of their profits come from their proprietary code and they're not about to open source their profits down the drain.

The suspicion must be that they only went into Aperi because it wouldn't cost them anything significant, didn't represent a threat, removed their subsidising of HP profits through OEM'ing or reselling the AppIQ product, and/or strengthened a relationship with IBM.

Now the AAG members have stronger ties binding them: they like using the AppIQ software or aren't bothered; they are really irritated by IBM's arrogance and railroading tactics; and they actually believe that customers deserve a properly specified and SNIA-standards-led storage management product.

Of course no members of the Aperi group, not least IBM, will say they oppose this last sentiment. But then, apart from Sun which has seen the light and recanted, they are still out there in the IBM-developed Aperi outer darkness.

From one point of view the Aperi group comprises IBM and a few close suppliers. It's obvious. The amount of mutual suspicion inside the SNIA has risen tenfold and it is all the fault of IBM. As a consequence the SMI-S standard will now take longer to come to fruition.

From another point of view IBM has performed a useful service. It has got the other SNIA members to think seriously about getting SMI-S developed and usable far more quickly.

Where do we go from here?

The SNIA could reaffirm its status as a standards-specifier and leave code-production to others. The others agree to be compliant with and co-operate with the SMI-S workgroup standards and activities. In other words back to square one with polite words across the table masking increased hostility and decreased trust.

Will the SMI-S pig be given wings and fly or will there just be a lot of flapping at SMI-S workgroup meetings? Join the SNIA and lend your help to knock heads together.