This article can also be found in the Premium Editorial Download "Storage magazine: Tips for unifying storage management."
Download it now to read this article plus other related content.
|The capability maturity model|
The Software Engineering Institute's capability maturity model (CMM) can be adapted to many fields. Here, we are applying the CMM levels to storage management to better understand the process of managing storage. More information about the CMM can be found at: http://www.sei.cmu.edu/cmm/cmm.sum.html.
Even with the most developed technologies, your ability adapt to the changes they bring is more a reflection on your organization's maturity and flexibility than it is on the technology itself. IT managers see the shortcomings of current products, but some fail to consider their own readiness to change. Is your organization ready to absorb another new technology?
Most successful IT shops are now oriented toward service, but that isn't enough. You have to be able to back up your positive approach with solid processes. It has been said that customers judge a business by its latest transaction. To an internal service provider, this means that there's a constant risk of alienating the user community with a breakdown of process. Keeping ahead of the game is hard enough without trying to change the underlying infrastructure.
Organizing for service
Many new products hitting the market now look attractive. Most have compelling financial return stories and claim to enable unprecedented levels of service and flexibility. What vendors are reluctant to mention is that reaping the benefits usually requires a massive restructuring of your storage architecture.
Whether you intend to build an internal storage utility, complete with chargebacks and SLAs, or just want to improve your level of service, the time has come for reorganization. Most IT shops grow organically, taking on only the responsibilities that are demanded of them, even if those tasks don't make sense strategically. That leads to a firefighting mentality that focuses more on remediation and configuration than on operations and management. An ideal organization would place equal emphasis on all of the following areas: technical competency, service orientation, financial responsibility and process maturity.
The best way to ensure technical competency is through standardized services. One frequent focus is on the amount of storage a person can administer, but that metric is misleading. The same person who could manage hundreds of terabytes of identical storage systems might have trouble keeping up with a dozen different ones. Clearly, standardization is the key to scalability and reduced management expense. That's why service-oriented storage shops are adopting a role as a service provider with a few standard technical offerings.
While standardizing and centralizing resources will improve the level of service offered, it's not enough for a real service organization. A service provider should have an SLA with each consumer of services, and this SLA should specify all of the characteristics of the services provided.
In my experience, developing an SLA format can be tricky, but extremely valuable to the organization. Once all the expectations of the customers are negotiated and spelled out, service improves dramatically.
Still, a service provider that doesn't account for financials is bound to fail. One client I worked with had a remarkable utility-model organization, but they were lacking any sort of cost accounting. This led to the collapse of the model because every customer demanded the top tier of service. For this reason, cost accounting must include data identification and classification. The cost model should reflect the total cost of delivering storage services, including the cost of disk, backup and disaster-recovery (DR) infrastructure as well as expenses such as pagers, support contracts and training.
But even if a service organization has these things, it will still fail without mature management processes. Even the best staff can't always deliver peak performance, and customers lose faith in an organization when management gaffes occur. The best way to ensure consistent delivery of service is with clearly-stated policies and documented processes.
Policies and procedures
Policies and procedures become more important as the number of people involved increases. And they are indispensable in fluid organizations where people can come and go without being acclimated to the accepted practices. But writing policy documents and standard operating procedures (SOPs) can be daunting. The primary reason for this--apart from a lack of time--is that the people charged with writing them aren't always sure where one task ends and another begins.
To succeed as a service-focused organization, it's critical to take a step back from daily operations and take stock of the tasks you are asked to perform. As I discussed in the October 2003 issue of Storage, (see "Making sense of the storage software landscape") coming up with a list of management tasks allows you to better understand how to use of new technologies. This list can also serve as a set of potential SOPs, and can be divided up to become a list of job responsibilities.
How can you build your own task list? Simply write down what your organization does. Break things down atomically: Try to minimize the number of tasks, but split them apart wherever necessary.
Remember to include all the responsibilities of your organization. Planning tasks such as defining high-level storage architecture and defining a DR policy can get overlooked. Remember, too, the critical role served by computer operators. Monitoring, escalation and maintenance are some of the most visible tasks an IT organization has. Finally, put in some tasks for customer service, e.g., reporting and satisfaction surveys.
I've been working with many GlassHouse employees on just such a framework of storage management tasks. Our storage management life cycle is broken down into four high-level phases: planning, provisioning, maintenance and customer care. Below this are more than 50 different management tasks. We use this framework to objectively assess the maturity of customer processes and identify gaps. The adoption of a framework such as this contributes to a client's ability to adopt a service focus.
How ready are you?
Process maturity may sound like a subjective matter better suited to an academic philosophy department than an IT shop, but it's actually concrete. Simply put, a process is judged to be mature if it is repeatable, documented and measured. It could be taken up by others if needed without affecting operations (see "Are you mature enough for new technology?" in the August 2002 issue).
A few years back, the people at Carnegie Mellon University came up with a way to measure process maturity that really works. Their capability maturity model (CMM) allows you to quickly understand how defined a process is and make a judgment about how defined it really should be. It ranks process maturity on a scale of one to five. The beauty of this approach is that just a few questions can lead to an understanding of a process. (See "The capability maturity model" on this page.)
When it comes to process maturity, three is the magic number. That's because level 3 requires a written SOP, and SOPs reduce an organization's reliance on individuals. Not that relying on talented individuals is bad, but everyone gets sick sometimes.
So, walk through the list of tasks your organization does and rate them on the maturity scale. Not every process needs to be highly mature, but some do. And the CMM allows you to identify those processes that need help.
Putting all of this together yields a dramatically changed organization, and it will alter the perceptions of your customers as well. This kind of mature organization can also look dispassionately at new technologies and determine whether they fit with its strategic direction.
I'll be speaking in more depth on this topic at Storage Decisions 2004, which will be held in New York in April. I hope to see you there!
This was first published in February 2004