An Approach to Availability Management, Part 3

Posted by Scott Braden
on February 12, 2006
Category: ITIL Implementation

It’s a very snowy weekend here in the mid-Atlantic region of the U.S., which for us is home base. They say that the storm is supposed to be worse right along the ocean beaches than inland, where we are. So, since we won’t be sunbathing on the snowy white sands of Our Dear Jersey Shore this weekend, what better to do than to blog about ITIL? Clean house, perhaps? Tackle that painting job in the basement? We think not.

Therefore, welcome back to another episode of Real World ITIL, where this week we’ll conclude our casual 3-part series on Availability Management.

Before we get started, though, let us send a hearty thank you out to Aaron who reads our blog over at newScale, Inc. Thanks for your helpful e-mail, Aaron, we’ll respond shortly. We’ve been interested in newScale’s Service Catalog products for a while now, so we’re happy to mention them here.

We respond to all reader comments and inquiries of a thoughtful nature, so we invite you to join the discussion by clicking the Comment link below. We hope to hear from you soon. Now, on to our story:

The week before last, we attended a presentation given by a prominent IT executive of a global investment house. In his talk, he made the interesting observation that (paraphrasing) ‘Availability is the price of entry for IT’. He continued by noting that infrastructure teams must do everything possible to guarantee effective delivery of services to their customers before even thinking about doing anything innovative.

Could his message have possibly been any clearer or simpler? We should be cautious about investing in innovation until we obtain maximum performance and value out of our infrastructure’s basic operations. So, if we aren’t doing an effective job in managing our existing infrastructure for appropriate levels of availability, we might as well stay home and shovel snow.

Inspired by this important but simple thought, the Real World ITIL team was further energized to build a great foundation for Availability Management processes at this company. So, as we noted in Part 1 of this series, we started by defining a clear, achievable scope, approach and organizational design. In Part 2, we described developing an Availability Plan and the need to coordinate our preventative maintenance windows with the usual downtime windows required by Change Management (on behalf of the applications group).

Having discussed all of that, what’s left to discuss? Process design! (what else?)

At the highest level, the practice of Availability Management has two, distinct branches as depicted in the following diagram:

Naturally, we have to create processes to support each of these functions, then figure out how to link these designs into the company’s existing organization. One way to accomplish this is to create an input/output table to identify how to hook AM into the organization (this isn?t the real table but a simple example):

TRIGGERING INPUT

INTERNAL AM PROCESS

DELIVERABLE OUTPUT

-SLA Change
-New Platform
-New Service from SLA

Need new process

-A.M Specifications
-Updated A.M Plan
-Risk Assessment to SLM

-Incidents

-Problems from I.M

Use existing Incident & Improvement process

-Improvement Records/Documents
-Revised AM Plan

-Periodic reporting

Use existing Monitoring & Reporting process

- Reports to stakeholders and interested parties

-Retirement of old services

Need new process

-Updated AM Plan to interested parties

-Early tech adoption

Need new process

-A.M Specifications

-Readiness Review

-Audit and Regulation

Ad-hoc – no formal process needed

-Ad-hoc

-Vendor negotiations

Ad-hoc – no formal process needed

-Recommended OLA terms

-Change in capacity target

Need new process

-Updated AM Plan
- Advice to C.M

-Security requirement

Ad-hoc – no formal process needed

-Ad-hoc (Related to IM & PM)

The relatively low level of detail here reflects the modest scope of the deliverables for Phase 1 of our project. This modest scope was determined by several factors, including time pressures on project staff, organizational ability to absorb change, etc.

As a result of this ?analysis?, our AM process ended-up having these general parts, each box of which required the creation of detailed supporting workflows:

Of course, there is much more detail to what we actually created for this company than what we?ve written about here, but by now the concepts and approach should be clear enough.

So, to sum up this three-part series in one thought, Availability Management is all about doing the basics of IT right, all the time, in a thorough manner, and then continuously improving. We should focus first on solidly delivering basic services on a continuous basis and then work to improve them. Only then should we consider getting aggressive about innovation.

Thanks for sticking with us through this series, which we enjoyed writing. We would appreciate hearing your feedback, so please share your thoughts by clicking on the Comment link below.

Until next time, thanks for reading along, and we wish you fair weather & fine processes!

Regards,
Scott (your moderator)

Technorati Tags:

—–

No Comments »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a comment

© 2005 - 2008 Evergreen Systems, Inc, a provider of ITIL consulting and other IT process improvement services for Fortune 500 clientele. All rights reserved.