I appreciate your comments and I understand your point of view. Admittedly there will be customers who don’t want to change and there are customers who are convinced they are managing their equipment efficiently. Unfortunately many of those customers aren’t using their resources effectively and they could make considerable savings. Agreed, working with the business customer is tough, but we can’t go on simply putting bigger, faster storage in and not address how/why it is being used.

Thanks again for the comments; opposing views certainly generates food for thought.

I respectfully disgree with most of what you are saying.

From a technical perspective first:

WMI – last time I looked, WMI had no ability beyond reporting on used/available capacity of filesystems. There were no hooks that allowed you to look at the logical volume manager nor file-level details of those filesystems. So I don’t think WMI was very useful. I have not looked at it in over a year so maybe that has changed.

On arrays and their details, the typical response from f500 customers was, so what? They already had their element tools providing that info. What they wanted to know was how the server admins were using the storage from the arrays. Again, w/out the server side perspective, there was no way to identify storage hidden in the Volume managers, orphaned storage or any other stranded storage out there.

As far as script collection, that’s exactly what my customers wanted to avoid back then. Perhaps the scripts are much easier to write and keep updated these days.

The second point, and probably the more salient point is that of the end-users demeanor. They don’t want to change, they don’t want new processes and procedures and they don’t want the hassle of dealing with their customers (business units, end users etc) about storage reclamation. I remember scanning a very large filer w/ home directories on it and I found terabytes of contraband and useless files they could have deleted. They didn’t…they are probably still there Until the customers change, SRM will never be relevant.

Good points:

1. Time/Money/Effort. SRA needs no deployment of hardware or software onsite. Configuration is collected by simple script and emailed/uploaded to a secure website. Results are available in minutes – and the charge is per TB analysed. Want to use it once and see what wasted resources you could reclaim? Fine.

2. All arrays have element managers which provide sufficient data. Same applies for fabric switches which can be collected by command line. Windows provides everything you need via WMI with a simple scripts. Other O/S can be collected in a similar manner.

What’s changed? Nothing. Customers still want to save money and do it easily. SRA does exactly that, with the minimum of effort and cost. No CapEx, all Opex.

If you want more details, let me know.

As a former SE Director at Storability Software (first purchased by STK and then SUN) I’m curious as to why you think the customers are any more willing to spend the time, money and the effort for SRM reporting? When we were in business, we got killed over the fact that we didn’t really do “management” which was fundamentally about provisioning. The fact that when STK was purchased by SUN and we sold AppIQ along with GSM didn’t make any difference.

The second thing we got beat up on was the deployment of agents. We got a lot of push back. And of course the “agent-less” approach couldn’t give file level details nor could it see into the vol managers to correlate what was allocated from the array to how is was actually dpeloyed in the vol manager to seeing what was on the file systems themselves.

But maybe the most significant issue was that customers resisted change, didn’t want to establish broad-reaching policies and procedures to take advantage of the tons of data that were being collected by the SRM solution.

What has changed? (and don’t say the economy because we were selling back when the bubble burst in 2001)

Its an interesting idea, but it makes no incentive for vendors to open up their APIs – in fact it does the opposite.