ITIL for Storage

A bit of commentary has been floating around blogland about the increased need for trained, certified storage administrators.

I thought I'd use this post to share EMC's views on this problem, and what we've been trying to do about it.

Context

If you take three steps back and look at the problem, there's no wonder why this is becoming an increasingly hot topic.

Hmmm. 

On the average, storage capacity grows at least 60% a year -- with some companies experiencing triple-digit growth year after year.

And, in the context of that growing mountain of data, every year, there's increased pressure to find new ways to save money, make money or stay out of trouble.  Yes, there's lots of cool technology, but that's only half the equation -- you need someone to use the tools effectively.

Inside EMC's customer base (which includes some pretty heavy-duty IT organizations) we started to notice this as a Big Problem about four or five years ago.

We had the tools (e.g. ControlCenter et. al.) but they didn't seem to always solve the problem. 

And we noticed a wide disparity between companies that had big problems, and those that had it under some sort of control.

What We Learned

So, as we spent time with the Haves and the Have Nots, we found some common themes among the people who were doing this well.

First, the people who had the beast under control recognized the need for a dedicated storage team. 

Rather than have everyone manage storage, or simply bury the poor storage administrator, they had built a separate storage team to focus on strategy, process and architecture, rather than just administration tasks.

Second, they used the same methodologies and processes that were well developed for other IT disciplines (e.g. networking, servers, applications) and applied it to storage.

Call it ITIL, call it whatever -- they had grown-up processes and metrics that were already in place, and could logically be applied to the storage domain.  The tools could be put to use effectively, because there were people there to use them effectively.

Beneath that was a quiet yet important process of role definition: if you're going to be world-class at managing storage, what were the roles and required skills?  And, if you were short of the skills, where did  you get them?

What We Did

I'd like to think there was some sort of master plan to all this as to how we responded at EMC, but in reality, it was more like a fast evolution, driven by our desire to be responsive to our customers.

And now, as we look back at that journey, we've amassed an impressive set of capabilities in helping customers to do better with storage, regardless of what storage they've chosen.

I think the first real breakthrough was that we saw this as a professional services problem, and not a product/technology problem.  We had to engage in a vendor-neutral manner, and focus on organizational transformation.

We kind of backed into this, at least as I see it. 

At the time, we were offering service level catalog engagements as a prelude to tiering storage.  Of course, when we did this, we'd want to work with the storage team.

And, more often than not, we'd find that there was no sufficiently strong storage team to work with. 

Yes, the people involved were trying hard, but IT often hadn't recognized that this storage stuff was becoming really important, and to organize around it.

We found ourselves building scorecards and organizational assessments. 

We found ourselves doing organizational design around roles and skills. 

We found ourselves adapting ITIL to the challenge of storage management. 

We found ourselves creating certification courses that, while they used EMC technology as an example, taught process and skills that could be applied to most any environment.

And our customers started to find big pots of gold at the end of the rainbow.

Dramatic reductions in amount of storage used, and slashing of storage growth rates.

Improved responsiveness and better SLAs from the storage team, which meant happier IT users.

And, ultimately, storage people who were happier at work, and as a result did better as employees.

And, over the years, we've done this hundreds of times.

What We Learned

We learned that big problems sometimes take a long sequence of activities to reach a goal. 

We'd get a customer who'd say "I've got a storage problem, can you fix it?", and the natural tendency was to propose something quick and easy.

The quick and easy solutions (e.g. a new tool, or a quick engagement) almost never produced lasting results, and often resulted in more frustration all around.

We learned that we had to be honest with people -- there's a journey involved, and it will take a lot of work on both sides, and we don't think there's any shortcut. 

Not the most popular sales pitch.

We also learned that, after looking at what's required, some customers came to the decision that they really didn't want to invest in learning to manage storage effectively, at least, not right away.  They wanted EMC (or someone else) to bring someone in to do it for them.

Thus was borne our residency programs -- an EMC employee who's part of your IT staff.  In many cases, they play two roles: manage the day-to-day of storage administration, but also drive the transformational processes required to help an IT organization get good at this stuff.

We also learned that the consulting engagement isn't really done until the customer is satisfied with the results.  That means focusing on such thorny topics as org design, roles and responsibilities.  Skill set transfers with associated certifications.  Metrics coupled with a closed-loop process for continual improvement. 

None of it particularly glamorous, but heavy lifting seldom is ...

If you're interested in how this looks from a brochure perpective, take a look here.

Distilling It Down

If you look at what we did, we took a nasty, complicated customer problem, and created methodologies that produced organization transformation.  What started as a liability for the customer was now a strength.

The ability to engage on this type of problem -- methodologies, best practices, managing the engagement, driving towards results, etc. -- is transportable in its own right to other problem areas.

As an example, EMC is now very focused on BuRA (backup, recovery and archiving).  The key, as we've found, is to link isolated problems together into an integrated approach.  And, not surprisingly, when you really start to engage, there are organizational alignment issues, new skills and roles, and so on.

Different movie, same plot.

Another hot area is server consolidation with VMware.  I've written before about how server consolidation is about a lot more than just servers.  Same skills and tools, different problem domain areas.

I'd think before long, information security would be a candidate.  Or compliance.  Or information governance.

ITIL For Everything?

There's a part of me that recoils a bit when everyone latches onto the latest buzzword, and misses why the concept is so important.  The important part of ITIL (for me) is the structured approach.

Put differently, *any* structured approach is better than none at all.  It could be branded ITIL, or something else.  And the ITIL library is as good as any starting point.

But behind this is intent: a certain IT problem area is becoming increasingly imporant, and no quick fixes are available.   And sometimes there's serious intervention work that's required at an organizational level.

And I think we'll be seeing more of that in the future.

Comments

[ITIL]

Very interesting article on an increasingly important area of data management. Version 3 of ITIL has a bit more to say about these considerations with its new Demand Management process - previously an activity of Capacity Management but now a process in its own right.

[Jacob]

Could you please help with the questions of how to orgnize these activities within a bit Tier 1 IT organization ?
I mean: Processese, skills set, teams, IT process responsibale, organization structure and reporting.

[Chuck Hollis]

Hi Jacob

Two problems with this, one, it's beyond the scope of a few blog posts, and -- more importantly -- I'm not anything close to an expert on this.

But other people at EMC do this for a living. Perhaps the best thing is to get you in touch with one of our consulting people on this topic?