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: itil information technology infrastructure library sla helpdesk cmdb incident management itsmf
—–