A specification meant to bring together storage device management under one umbrella instead continues to be criticized for its innate inability to enable interoperable functionality.

The Storage Management Initiative Specification (SMI-S) is a lightning rod for controversy among both its supporters and detractors. It has been approved by the ISO international standards organization and the International Electrotechnical Commission (IEC) as a standard for interoperable storage management technologies. Yet detractors say SMI-S was overhyped and will never fulfill its original promise of integrating storage device management across the industry. Supporters continue to say SMI-S is opening storage resource management (SRM) doors that were previously locked by proprietary vendors.

SMI-S, now in Version 1.02, grew out of the Storage Management Initiative (SMI), which was created by the Storage Networking Industry Association (SNIA) in 2002. SMI-S is criticized for not being more open to smaller SRM vendors and failing to help end user IT organizations establish centralized control over their heterogeneous storage infrastructures because larger vendors will not port the most sophisticated application programming interfaces (API) to the standard's framework.

That criticism is countered by SNIA and many large members of the vendor trade group who say that even though SMI-S implementations have lagged behind the rapidly evolving standard, both vendors and users are benefiting from it.

The basic concept behind SMI-S is simple: Vendors translate product specifications into XML code for their specific storage management software, which creates a universal API that can be accessed by any other SMI-S-compatible products. SNIA says that about 450 products from 30 vendors have so far passed the SNIA Conformance Testing Program for SMI-S. Product types include storage networking components (such as arrays, switches and host bus adapters) and their associated management software, as well as client software.

Slowing down the development process?

Marty LeFebvre, Nielsen Media Research's vice president of technology and a member of the SNIA End-User Council governing board, says the problem with SMI-S is broad and one of vendor reluctance for interoperability.

"There's a certain amount of feeling among end users that if we had a more direct conduit to [vendor] product managers, we might be able to make more progress toward that," he says. "But part of it also is [that] instead of each vendor trying to solve the whole thing front to back, if there was a little of collaboration to where individual vendors could solve a pieces of it and then there was interoperability between the software, just as we're talking about interoperability between hardware, that might help advance that."

LeFabvre said when end users talk about SRM, it encompasses a broad range of functionality, such as provisioning, capacity planning, automated response to performance issues and load balancing. "To try to solve that front to back is a tall order," he recognizes.

Jon William Toigo, chairman of the Data Management Institute and CEO of Toigo Partners International, is a frequent critic of SNIA and its SMI-S standard. He refers to SMI-S as a "golden dream" that will never come to pass and says that it is only being implemented on a small percentage of the 15,000 new storage systems released in 2006. According to Toigo, the unwillingness of vendors to share their most sensitive APIs is a major stumbling block to SMI-S.

Toigo also believes that smaller storage management software vendors in particular are feeling the lack of cross-platform functionality as they try to plug their products into larger vendors' consoles. Other industry observers have said this problem is so bad that up to 50% of the capacity-related fields in the SMI-S framework are empty because vendors have not filled them.

"That's absolutely true," Toigo says. "They tried to come up with a much more complicated version of the Storage Management Initiative, and major vendors balked because they did not want to reveal that much of the internal goings-on inside their platforms, so what they did was create a generic, very inconsequential amount of status monitoring that would go into every SMI implementation and then opened the door to do customized additional builds."

Bob Laliberte, an analyst at Enterprise Strategy Group, agrees that SMI-S has put restrictions on smaller SRM vendors, saying the situation slows down the development process and forces them to only support one or two vendors to start. They are continuing to add more vendors as they get access to APIs and test equipment, he says.