The Little Guy: Squeezed Out of SMI-S Land?

Can smaller vendors still have a voice in an organization designed to develop hardware standards for the entire industry?

Following up on our previous columns about SNIA’s Storage Management Initiative Specification (SMI-S), announced at Storage Networking World a few weeks ago, I received an e-mail that would have struck me as a bit of conspiracy theory-silliness had I not known the source personally.

The e-mail’s author, a senior engineer for a storage product manufacturer, asked not to be quoted directly both because his views did not necessarily reflect the position of his company with respect to SMI-S and because attribution might make him persona non grata among some of his industry peers. Despite all of these caveats, I am electing to record his thoughts here because they reflect similar views and experiences of many smaller companies within the SNIA organization and illuminate a rarely publicized perspective on SMI-S and SNIA generally.

The central thesis of the e-mail is that SMI-S is a “thinly-veiled attempt by big players to shut out the mid-tier and small fry” in the storage industry, reflecting a powerful union of UNIX-oriented hardware companies with the support of a couple of other firms tagging along. Said the author, “Only big players with deep pockets can afford to effectively participate in and develop hardware providers to the horribly complex SMI-S document.”

He supported his thesis by recounting how a number of smaller companies, including his own, had been excluded from membership in the SMI Working Group at SNIA. In his view, several companies—both directly and via their surrogates (i.e., strategic partners and OEMs)—have come to dominate all of SNIA and have wrapped themselves in the flag of heterogeneous storage management, provided it keeps their products on top. Supporting this conclusion was the fact that seven of 12 SNIA directors are either working for or tied to just three major players.

The fellow goes on to charge that the big players in SNIA and SMI-S have “seeded” (read “paid”) analysts “to pontificate to their fat cat user clients that SMI is a mandatory RFP checkbox”—producing a fait accompli designed to exclude non-SMI-S products from lucrative opportunities.

The RISC/UNIX crowd needs SMI-S, he argues, to compensate for their own poorly designed element managers and “monster storage refrigerators that are so complex and difficult to use and administer.” He calls SMI-S “lipstick on the pig.” “Shove a common specification down everyone’s throat, get the SNIA to hype/endorse/fund it, throw it across to ANSI, arm-twist the chosen few analysts into thinking it is necessary, and voilà, a standard is born.” The disinterest of Microsoft and the Linux camp in the technology is taken by the writer as additional proof of the bent of the authors of the specification. These vendors don’t see the need for SMI-S.

While there are many reasons for smaller vendors to get their underwear in a twist about SMI-S—the cost of implementing SMI-S providers in their hardware being at the top of the list—the author’s position should not be discounted simply as just so much sour grapes. His words reflect a significant and growing disenchantment among many SNIA members who do not find their own product roadmaps—or their development and engineering budgets—to be in alignment with the organization’s stated directions.

Apparently what pushed this writer’s button was my earlier statement that SMI-S reflected an unprecedented level of cooperation within the industry. To him, the specification is less a reflection of industry-wide cooperation than a deliberate and concerted effort by market share leaders to retrench and to work together to protect their collective market positions against a crop of newcomers who are threatening with techniques and products that are fresh and innovative.

Options for Smaller Vendors

His e-mail is a cautionary tale. In any business, good guys don’t always win, especially when the institutions of the industry (including SNIA, the analyst community, and a huge, well-moneyed marketing machine) favor incumbency and are aligned against them.

One option, of course, is to opt out. Work outside the system (or in line with its fundamental precepts, depending on your perspective). Build plug-and-pin compatible replacements for the big guys that deliver the same or greater value at lower cost – sort of the way that EMC got started with memory cards in an IBM-dominated world. Build a class of products that features heterogeneous management support as an integral feature, rather than a bolt-on. Find those analysts and writers who will cover your initiatives despite the size of your bank accounts—there are many of us out there—and prove your value proposition with open testing.

As for SNIA, maybe what is needed instead is a democratic storage industry association—like what my kids read about in civics class—the kind that features one company, one vote. SNIA was never conceived as a democracy, an issue that has proven to be an impediment to their goal of becoming a standards body. INCITUS would be much more amenable to associating standards body status to a group that elected its board and put its specifications to a general referendum.

More importantly, make the development of storage standards a true partnership with the end-user community. It should come as no surprise that consumers are jaded about industry associations generally and have received generous dollops of prevarication and doublespeak at the hands of vendors for years. So, don’t be surprised if your initial traction is weak. Engaging the consumer in the process may require dividing the board of directors equally between vendors and users and ensuring that the organization is founded on a consumer bill of rights.

The other option is to reform things from within. From the e-mail, it would seem that there might be the necessary ingredients present to check the power of the alleged Troika. IBM is not on the list of RISC/UNIX guys cited in the correspondence, and the power of Big Blue, combined with Microsoft, Cisco, Red Hat, SuSE, and hundreds of other medium- to small-fry disenfranchised hardware vendors might make for a formidable power block if properly orchestrated.

SMI-S stands out because it is an approach to common management in a technology field (storage) that is pretty much devoid of common approaches to anything. If you have a better idea, let me know. This analyst will give you the ink it deserves. Write me at jtoigo@intnet.net.

About the Author

Jon William Toigo is chairman of The Data Management Institute, the CEO of data management consulting and research firm Toigo Partners International, as well as a contributing editor to Enterprise Systems and its Storage Strategies columnist. Mr. Toigo is the author of 14 books, including Disaster Recovery Planning, 3rd Edition, and The Holy Grail of Network Storage Management, both from Prentice Hall.