Home | Featured | Why SMI-S Doesn’t Work
In a recent post (this one on SRM), Wayne M Adams from SNIA took the time to comment as to why he believed SMI-S is alive and well. Rather than simply reply on that comment thread, I thought I would take the time to put together a summary of why SMI-S (in my opinion) hasn't worked and will never work in the current incarnation.

Why SMI-S Doesn’t Work

0 Flares Twitter 0 Facebook 0 Google+ 0 StumbleUpon 0 Buffer 0 LinkedIn 0 Filament.io 0 Flares ×

In a recent post (this one on SRM), Wayne M Adams from SNIA took the time to comment as to why he believed SMI-S is alive and well. Rather than simply reply on that comment thread, I thought I would take the time to put together a summary of why SMI-S (in my opinion) hasn’t worked and will never work in the current incarnation.

So let’s start with what SMI-S means.  Here’s the official definition from the SNIA website:

“The Storage Management Initiative-Specification (SMI-S) is a standard designed with the purpose of standardizing and streamlining storage management functions and features into a common set of tools that address the day-to-day tasks of the IT environment.” – source http://www.snia.org/forums/smi/tech_programs/

So it’s all about standardising and streamlining storage management.  This makes perfect sense in some environments but not others, for example:

  • Single Vendor, single product – where an organisation uses a single vendor and a single product (i.e. one type of storage device) then SMI-S provides no value as the user is almost certainly going to be using the vendor’s management tool.  This will have been provided free (or most likely bundled in the price).
  • Single Vendor, multiple products – where an organisation takes more than one storage device from a vendor, then SMI-S is still going to be of limited value.  The customer will use either the individual management tools for each platform or a product from the vendor that supports multiple products, such as EMC’s ControlCenter or Hitachi HiCommand.
  • Multi-vendor, multiple products – this scenario is where SMI-S is most useful.  In large, complex environments, there will be a range of different products with multiple management tools.

If SMI-S worked successfully, the complex multi-vendor infrastructures, would be the best fit.  Unfortunately by their very nature they have issues which prevent SMI-S working successfully.

Speed to Market

Here’s the timeline of SMI-S releases (source: http://en.wikipedia.org/wiki/SMI-S):

    • 2004 – SMI-S 1.0.2 (2 years to develop)
    • 2006 – SMI-S 1.0.3
    • 2007 – SMI-S 1.2.0
    • 2009 – SMI-S 1.3.0
    • 2010 – SMI-S 1.5.0

In this 8 year timeline, vendors have released whole families of new products, as well as multiple code updates and releases.  However, as this link shows, there are no storage array providers supporting SMI-S 1.5.0 and of the 27 vendors listed, only 9 have been confirmed as tested with version 1.4.0.  Netapp have no products tested higher than version 1.2.0.  Cisco have nothing higher than 1.1.  As for client software, no testing has been performed past version 1.1 (link).


It’s clear from some of the information presented above that not all vendors are participating fully in SMI-S, Netapp being a prominent example.  In addition, the client software certification, probably the most relevant part to end customers looking to use one single management “pane of glass” shows vendors aren’t putting forward their latest products.  For example:

  • HDS’s latest version of HiCommand listed is 5.0 (v7 is already available)
  • EMC’s latest version of ControlCenter is 6.0
  • CA’s latest version of Storage Resource Manager is 11.6 (latest release is 11.8)

As soon as a dependency is put in place between the management software and the storage array, restrictions apply when deploying new products.  Customers want the confidence that when a new hardware product is released, the software support will follow quickly.  New hardware implies new features, likely to be only described in latest SMI-S specification releases.  If the software vendors aren’t supporting these, then the “single pane of glass” approach is flawed as the customer has to fall back to the management tool that shipped with the product.

The Message

Now of course the SNIA website could be out of date and in itself that is an issue if true.  However I think SNIA fundamentally has a problem with the message.  SNIA is an Industry Association and so is surely dedicated to improving the industry on behalf of their members – the vendors.  Where is the customer community participation?  On the technical council, all the members are vendor representatives (bar one).  Unfortunately SNIA doesn’t list the membership of the Technical Working Groups on their website but I suspect that customers are not well represented.  SNIA should have a clear and well documented process for engaging customers and conveying the message on what SMI-S actually does. Look at this definition of SMI-S from the SNIA website:

“SMI-S defines a method for the interoperable management of a heterogeneous Storage Area Network (SAN), and describes the information available to a WBEM Client from an SMI-S compliant CIM Server and an object-oriented, XML-based, messaging-based interface designed to support the specific requirements of managing devices in and through SANs.”

But what does this mean for me as a customer?  What functions can I do?  Reporting?  Provisioning?  Management of replication and snapshots?  What additional software to I need?  Is SMI-S supported using the same security model for each vendor?  Does it use the same access protocol for each vendor?  SNIA and their members need to provide clear and concise information on exactly what customers can expect, rather than having to wade through pages of specifications.


Today I still see the large, complex clients using the command line to do their storage management.  There’s still a dependency on spreadsheets for reporting and the “normalisation” of capacity data isn’t well presented.  Rather than having a common management model, we’re seeing the hardware vendors developing their own plug-ins for the virtualisation layer, something that should be unneeded if SMI-S support is truly ubiquitous.  The truth is that it isn’t and the industry will never adopt a common management framework anytime soon.

About Chris M Evans

Chris M Evans has worked in the technology industry since 1987, starting as a systems programmer on the IBM mainframe platform, while retaining an interest in storage. After working abroad, he co-founded an Internet-based music distribution company during the .com era, returning to consultancy in the new millennium. In 2009 Chris co-founded Langton Blue Ltd (www.langtonblue.com), a boutique consultancy firm focused on delivering business benefit through efficient technology deployments. Chris writes a popular blog at http://blog.architecting.it, attends many conferences and invitation-only events and can be found providing regular industry contributions through Twitter (@chrismevans) and other social media outlets.
  • http://markcarlson.info Mark

    “The truth is that it isn’t and the industry will never adopt a common management framework anytime soon.”

    I fear that customers that have a heterogeneous set of storage just are not willing to pay enough or are not numerous enough to make this “single pane” management software market viable. If have seen a number of companies come and go in this space: Prisa, Highground, AppIQ and most recently Akorri. Mostly being absorbed into large storage vendors.

    The one thing that might be the compelling reason to have an SMI-S interface on your storage might be a storage orchestration layer for cloud storage that works across heterogeneous storage devices. If you could buy a private cloud storage management application that took your existing storage and data and provided a seamless pool of cloud storage and managed the data services as well, customers would demand support from their existing storage vendors.

    • http://www.brookend.com Chris Evans


      You forgot to mention Creekpath. I had experience with that software. There were major flaws in the thinking on how it worked that also contributed to its downfall.

      There’s one other thing to bear in mind too. Having a consistent reporting interface is easy. If you get it wrong, so you report the figures incorrectly. If you get provisioning/decommissioning wrong, you take someone’s service out. You would want to be 100% certain your interface worked correctly. Consistent reporting seems like an easy first step.

      Regarding the idea of private cloud, I wonder if we’re really going to see a large number of heterogeneous cloud orchestration companies. I mentioned that fact here:


      The industry is trying to push for single vendor solutions rather than support multiple storage vendors in a single stack, so surely this is even more likely to make SMI-S less relevant?


  • Julie Herd

    In my view, AppIQ was the only company that was really positioned to make the SMI-S vision a reality. They were just starting to make great strides in getting major vendors to cooperate with them for development and reporting, largely because they weren’t one of the big 5. Creekpath was a far second.

    That hope died the moment HP acquired them. None of the big vendors will ever do anything that can benefit the market share of the competition.

    • http://www.brookend.com Chris Evans


      That’s absolutely true; there’s no vested interest in HP enabling easy management of EMC arrays, for example. It’s another reason why this kind of stuff shouldn’t be driven by an industry association as they can easily do lip service to what customers (think they) want, rather than actually doing what they want. In reality the requirements should be generated by the customers.


  • http://markcarlson.info Mark

    Ah.. Creekpath, another HP management software acquisition (via Opsware) – another heterogeneous single pane company being usurped to run a homogeneous stack.

    I agree that most storage vendors are quickly trying to figure out how to turn their homogeneous management software into private cloud orchestration for their own set of products. It’s a great way to demonstrate the value to customers of “just buy *my* stuff”.

    But I do think there is a window of opportunity to also demonstrate the value of vendor independence in the private cloud management software business – use your vendor specific management software to manage the resources, they will orchestrate a self service API (CDMI for example) using those management silos on the back end.

    Time will tell whether there is a market for this, and again will customer’s see enough value to sustain a market for these companies?

  • http://www.brookend.com Chris Evans


    I think your last question is a good one. Perhaps the subject for another blog post.


  • http://www.snia.org Wayne M. Adams

    Hi Chris,

    Storage and IT management has moved on from the vision of a single pane of glass with a single interface to solve everything. Specific to storage, a range of solutions are typically deployed to configuration, provisioning, data protection, DR, health and monitoring, eventing, etc…
    Engineers who develop the storage arrays and management solutions for many of the data center class understand the value SMI-S provides for reducing the number of interfaces to be supported and saving engineering development time.
    The old belief that SMI = single pane of glass and only interface is long past. SMI is one interface of several storage interfaces, that is a common building block for many tools, for the many tools in a toolbag to manage storage, data, and IT.
    Agreed, spreadsheets are a mainstay management tool, but not the only management tool. As anything predicted to die out, be it tape, mainframe, or simple file formats —- there is a place and value for everything.
    SNIA can host you at the SNIA Technology Center to see the SMI-lab and can time it such as to be part of a SMI-lab plugfest. The technology works and it has value. If it didn’t, then vendors would have moved on several years ago, after 1.1 or 1.3 . Not every new feature added to SMI-S is required/supported by every device type or management tool in the market. The value proposition for vendors has moved onto rich functionality based on the solutions their market customers desire. Not every vendor with every SMI-S feature. However, if this is your bar for what is successful or not successful, you’ll have a lot more articles to write to detail other mainstay standards that are not fully implemented by every vendor in the market segment. In the meantime, many data centers are being run with SMI-S under the covers and they are not aware of it, nor is it very important that they know. IT is concerned about entire solutions with full vendor support. SMI has delivered value to vendors to build better SRM and data management solutions.

    Wayne M. Adams
    SNIA Chairman

  • http://www.hp.com/storage/blog Calvin Zito

    Hey Chris – you guys were at #vBeers tonight and wish I was too!

    One HP organizational point I’ll make and direct to Mark’s comment (hey Mark – long time no see!!) HP Storage Essentials (as noted, it’s roots are AppIQ) was moved into HP Software a few years ago. HP software is not, and I repeat, is NOT focused on HP homogeneous environments. Like Network Node Manager and other heterogeneous management products, they don’t focus on HP infrastructure. I dare say that some non-HP kits get integrated before our own HP storage kits. Storage Essentials has not been usurped to run a homogeneous stack.

    There is one very large service provider type customer that comes to mind who has a heterogeneous storage environment and have standardized on HP Storage Essentials to manage it.

    That said, you do raise some good points. There are certainly challenges around implementation – there are a lot of moving parts for storage vendors and the SRM vendors along with new releases of the standard to make it all work. Originally, SNIA was releasing new versions of SMI-S ever year – they are slowing that down a bit to help address the issue.

    Our HP SNIA board member Doug Voigt noted that your title implies that something is broken with the SMI-S standard itself – but your post describes the real challenges of adoption rather than defects in the standard. There’s nothing wrong with the SMI-S standard.

    Doug pointed me to a very good paper that the SNIA had written talking about SMI-S: http://www.technologywriter.com/indassess/iasmis.pdf. Many of the points made in the paper are similar to what you said. I think it’s worth a read. My hope is that instead of giving up and calling SMI-S dead, that between array vendors and SRM vendors, we do a better job of addressing the challenges you’ve exposed. They are not simple challenges!

    Thanks – Calvin Zito, @HPStorageGuy

  • Boblog

    As a user spending my day in storage interfaces i can say why pay for third party software when even the OEM can’t make the software work good?

    With high upfront cash cost of pretty java interfaces management dares not get anything but the software from the storage vendor.

    These softwares always look good in the demos in the labs but when you get them in your own datacenter they suck and have more bugs than windows 95.

    Buying a thirdparty storage software like that for $$,$$$$ would be a career ender. This is why i think SMI-S is of limited value.

  • @zaxstor

    SMI-S is near impossible for end users to script and code against in a reasonable amount of time. That leaves its only real use, to buy a software package that uses SMI-S as the primary mechanism to communicate with multiple storage platforms. SMI-S is most useful to storage vendors wishing to sell heterogeneous management tools, not end users.

    I much prefer Xiotech’s approach using REST as the primary mechanism for communicating with storage. It’s simple, elegant, and standard. Administrators can crank out scripts in minutes to control or report against storage. It can be easily orchestrated and fits into the cloud model well.

    It’s also interesting to look at VAAI’s potential impact in this space. The market is driving storage vendors to support a common set of commands to support extended feature integration with VMWARE. If VAAI is adopted as a standard, these features may become accessible to operating systems and other virtualization platforms, essentially forcing continued commoditization of the storage infrastructure.

    Users want standard and simple mechanisms for communicating with storage. SMI-S completely misses the boat for end users.

  • Pritam Bankar

    Is it true that SMI-S only manages cluster of SAN devices and not NAS devices? I have read many articles of SMI-S, all says it manages multivender SAN.

0 Flares Twitter 0 Facebook 0 Google+ 0 StumbleUpon 0 Buffer 0 LinkedIn 0 Filament.io 0 Flares ×