Another Voice from the SMI-S Trenches

Was development of the SMI specification by the SNIA usurped by a small group of vendors? A developer provides his real-world experience.

My column of two weeks ago—"The Little Guy: Squeezed Out of SMI-S Land?" (see—led to a deluge of e-mail from vendor-employed technologists who shared the view of the anonymous storage industry insider quoted in the piece. After reading through a bunch of these messages, I could not help but form the impression that serious cracks exist in the foundations at Storage Networking Industry Association that the organization would be wise to address before its entire house crumbles into dust.

As one writer observed, “I can really relate to what your acquaintance said in his e-mail. I'm glad you didn't mention his name. It would be sort of like divulging the name of a CIA agent just because the spouse didn't fall in line with a particular agenda.”

The writer’s take on the Common Information Model/Web Based Enterprise Management (CIM/WBEM) development effort was the story of “a noble effort to manage all devices in a heterogeneous network” that was hijacked by a few, large, self-serving vendors.

“[Early on], I was working along with [several others] on developing CIM providers and trying to evangelize the use of the SNIA CIM model to the industry. I thought it was a noble cause since there's no easy way to manage all devices in a heterogeneous network. We knew it was a chicken-and-egg issue, where either developers were going to start developing providers or customers would eventually demand CIM support. So, we as developers took up the cause.”

The writer says that he was initially concerned “because the entire CIM schema was extremely unwieldy.” A large and growing number of classes were being developed to describe the discrete characteristics of products as well as customized processes in the absence of a true Common Storage Model that described how all storage worked in a concise and consistent way. (This columnist had frequently wondered aloud how CIM could work in the absence of such a common storage model.)

“How could anyone get a handle on what it takes to support all of those classes?” asked the e-mail writer. “Eventually the use of profiles was created to be able to implement a subset of classes for a defined set of uses. Implementing profiles seems to be a bit more manageable. I'm now defining what it would take to implement the NAS head profile at my current company.”

What soured the writer on the effort was its “usurpation” by certain vendors with the introduction of the SMI specification. “In one particular meeting at SNIA in Colorado Springs, [a well known CIM evangelist representing a major vendor] was there with a few other people I've never seen at theses meetings before and introduced the SMI Specification. I felt that we were actually blind-sided by this [event] since [no one had ever] mentioned this spec before.”

In the words of the writer, SMI-S was developed outside of the proper channels by a few large vendors working in secrecy at an external company. When it was presented to the working group as a fait accompli, a lot of jaws dropped. The writer conceded that this practice was not unprecedented. The same thing had happened before, in his work with Fibre Channel standards development efforts at ANSI. When B-channel fabric registration protocols were being developed, recounted the writer, several big name Fibre Channel vendors participating in Fibre Channel standards development efforts at ANSI did an end run around the normal standards-making process to create an approach, eventually approved by ANSI as a standard, that effectively prevented small-fry vendors from competing in market dominated by big companies.

Lamented the correspondent, “This came to be another time in my life where I would just have to wait until the old men died off in order to get a bit of justice and tolerance in the world, but I'm getting older now myself.”

The alternative for the small fry, like the company for which this correspondent works, has been to seek shelter in the shadow of Microsoft. He reports that his company is developing management applications using C# and .NET and has largely dropped out of JAVA-based SMI-S development efforts at heavily politicized SNIA. (The writer says that JAVA is preferred at SNIA because of its leading members’ bias against all things Microsoft.)

There is pushback at his company regarding the decision not to develop SMI-S providers for products—but mostly from the executives at the company, who are being courted and cajoled for the moment by SNIA. The writer says, “I still haven’t heard actual end users asking for SMI-S, so I am holding my management at bay. If you think end users are starting to ask for or will ask for SMI-S support in the future, please let me know.”

I promise to do just that. To readers of this column, if you believe that SMI-S support is an important option that will guide your selection of storage products going forward, please drop me a line at

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.