In-Depth

Reader Mail: Fear and Loathing in SMI-S

Readers sound off about recent comments from previous columns

• By Jon William Toigo
• 02/12/2004

Two columns, one on January 8 covering New Years Resolutions for the Storage Industry, and a second from January 15 covering Systemic Storage Problems and the failure of the industry to address them, prompted a slew of responses. Most had to do with my generally critical commentary about the Storage Network Industry Association’s Storage Management Initiative Specification (SMI-S).

In response to the January 8 column, a Chief Technologist for a leading banking conglomerate wrote:

I agree that the re-branding by SNIA [of Common Information Model (CIM) and "BlueFin" as SMI-S] is humorous, and even the creation on SNUGs (Storage Networking User Groups) can make one laugh. [Having a common model for managing everything] from device to application is a good idea, however. Even if we don't actually manage all that from within an application, hopefully the applications we do choose will pass information between them so we can better understand the complexities and requirements each application may pose on a given platform.

For instance, if we have an MS SQL Server running 100 Access-converted databases each with a light (10) user load, but on a different box, we have 1 MS SQL database with a 1000 users against 1 instance, then the load characteristics of each box and the data accessed would be different. If we can use CIM to extrapolate that unique information and provide a better understanding of each system, we may be able to better utilize each system.

These comments hit on a key requirement for storage management: the need to characterize applications by their unique data generation, access, security, retention, and recovery requirements. We need three things: a way to discern data attributes on a application-by-application basis, a labeling schema to standardize these common data attributes, and a way to tag data with these attributes. Theoretically, CIM could do the job—if it were developed by a real standards body and had the backing not of the storage companies but of the operating system and business application software vendors.

This view is echoed by another Storage Strategies reader who wrote after the January 15 column, in which I discussed his difficulties in obtaining funding to develop the software to extrapolate storage requirements from apps themselves (the first requirement above).

Bob, as I called him in that story, notes:

SNIA would claim that the API swap you mentioned in your story is already happening, and they call it SMI-S. Both you and I know that is not it, but until reality starts to intrude, that is going to be the perception.

I'm convinced that the work I'm doing on discovery and classification is going to require a standard of some sort if it is going to be successful because ISVs have to be able to use the discovered and classified information. It is no good if I'm the only one who can use it. The information has to be available to backup/recovery tools, archival tools, mirroring tools, and who knows what else. I'm pedaling as fast as I can to get traction for a standardized way to represent applications, data objects, and their service requirements. For Information Lifecycle Management to work, that standard is not just a nice thing, but a requirement.

Most of the customers I talk to see this as a revolutionary change in management: A single, comprehensive method for looking at business-related issues, and applying policies to manage resources. The problem that people have now is that keeping up with applications and business processes is almost impossible unless they are static and nobody has anything nearly that simplistic [for] an environment.

By the way, I've taken on some difficult projects in the past, but this is one gnarly mother because if you don't get it right, when you do discovery, everything is related to everything else.

I couldn’t have said it better, Bob. To my other readers, I would be interested in knowing what you think of SMI-S. Is it the panacea for management that SNIA says, or just another instance of vendor API swapping that is doomed to fail once important vendors find other proprietary management approaches they prefer? Does SMI-S factor into your purchasing today? If so, how? Please let me know: jtoigo@intnet.net.