Published: December 21 2007, 11:19 AM | no comments
by Robert Stroud

I'd like to welcome Kirk Holmes of Holms and Associates, Inc., Sallie Kennedy of Kennedy & Kennedy, Inc., and Lisa Schlaf of Econ Global Services to the itSMF USA board. You can read the press release here.

I've been involved with the itSMF USA since 2001. Currently, as a director, I serve as the chair of the events committee, which runs the annual itSMF Fusion event, arguably the largest IT Service Management (ITSM) event in the world.

itSMF USA and its umbrella organization itSMF International, are instrumental in driving the awareness and acceptance of ITSM globally. If you are interested in learning more about, or contributing to the growth of, ITSM, I strongly encourage you to check out an itSMF USA Local Interest Group.   

Share this post:  Email

Share

Published: December 21 2007, 08:35 AM | no comments
by Marvin Waschke

I thought you might enjoy a glimpse of our farm in the snow. Forty years ago, my father raised calves in this small barn that my grandfather built around 1900. It was the first barn built on the farm. He later erected a much larger hay barn, but I don't have a picture I like as well as this one my wife took last winter. Happy Holidays, Marv

Share this post:  Email

Share

Published: December 18 2007, 01:25 PM | 2 Comment(s)
by Marvin Waschke

I've been watching a battle between two opposing schools of thought in the CMDB world. One says that a CMDB represents the authorized configuration of the IT Service environment. Not the real configuration, not the way the system is working now, but the authorized configuration as determined by the change board and the planning groups. The other school wants a CMDB to be as accurate a reflection as possible of the way the system is configured--right now. Not what it is supposed to be, what it is. Which is correct?

Both schools have good arguments. ITIL v2 emphasized the authorized configuration school. Clearly recording the authorized configuration is the basis for rational configuration management. You can't manage what you can't measure. (The IT Skeptic had an interesting discussion on measurement and key performance indicators (KPIs) a week or so ago: "Great myths of ITIL #1: "You can't manage what you can't measure".) Further, you can't manage what you have no record of.

On the other hand, if I am an analyst on the service desk, the first thing I want to know is how the system is configured now--not the way it is supposed to be configured. The authorized configuration might give me a clue as to why an incident occurred and restoring the authorized configuration might be a perfect resolution, but if I don't know what is actually going on, I am shooting in the dark. And that's dangerous!

Stop arguing already!! ITIL v3 very clearly distinguishes baselines from snapshots. A snapshot is the observed configuration of the IT service environment at a given instant. I like to call snapshots the "as-is" configuration. That is exactly what the poor service desk analyst needs. A baseline is the result of planning and authorized changes. Just what the configuration manager needs to manage. Both can be accommodated in a single CMDB, as long as baselines and snapshots are clearly distinguished.

Too often, I have seen CMDB practices that muddle together baselines and snapshots, trying to meet the needs of both the configuration manager and the service desk. When this happens, the service desk analysts are never quite sure if what they see in the CMDB reflects reality, and the configuration managers are never quite sure what they are managing.

Occasionally, a snapshot can be used to set a baseline. If a system is working as well today as it ever has, the IT organization may make a conscious decision to authorize the snapshot as a new baseline. But this is the exception, not the rule. Most snapshots are not baselines and baselines are not necessarily derived from snapshots.

When deciding what to house in your CMDB, you do not need to choose between snapshots and baselines. The answer is not either-or. Acknowledge that baselines and snapshots are different and serve distinct purposes. A snapshot is for troubleshooting and historical analysis, while baselines come from authorization, not observation.

Both snapshots and baselines have their roles to play and neither can do the whole job. Both sides are right.

ITIL® is a Registered Trade Mark, and a Registered Community Trade Mark of the Office of Government Commerce, and is Registered in the U.S. Patent and Trademark Office.

Share this post:  Email

Share

Published: December 14 2007, 10:57 AM | no comments
by Robert Stroud

Poor change. Bad enough that people resist change, but, in IT, change is unjustly accused of causing problems and may be unable to defend itself of the charge. I'll explain.

I spoke with an IT exec from a retail organization recently about the absolute importance it places on the holiday shopping season. During this period of high transaction volume, his IT department has a critical responsibility to ensure system availability. The company's financial future depends on it.      

To prevent any IT changes from affecting this crucial two month window, the organization routinely implements a change freeze on ALL their systems from the middle of November until the middle of January. The freeze is in place to eliminate the potential for any IT change to introduce problems that could negatively affect business systems.

While a bit like using a jack hammer to crack a walnut, this drastic measure is the only way the organization can guarantee that IT will not introduce change that can result in diminished infrastructure performance and reduced profits. Such procedures are routinely employed in companies that freeze all changes to ensure problem-free month-end or year-end processing. 

These extreme measures would not be necessary if ITIL® change and configuration management processes and a configuration management database (CMDB) or, as I blogged, a configuration management system (CMS), were in place. Strong processes could mitigate risk associated with change. With relationships between IT infrastructure configuration items (CIs) captured in the CMDB or CMS, decisions as to what changes should and shouldn't be made can be based on reality, not the fear of the unknown.

Without change and configuration management processes in place, organizations cannot confidently predict the impact of change, nor defend a change that is blamed for the latest system hiccup. Change is guilty until proven innocent, but without a CMDB or CMS, proving innocence is difficult. By the time a change has been cleared of all wrongdoing, its name has been tarnished, a rash of emails about it have flown around the company, the damage to IT's reputation is done, and its time to look for another job.

ITIL® is a Registered Trade Mark, and a Registered Community Trade Mark of the Office of Government Commerce, and is Registered in the U.S. Patent and Trademark Office.

Share this post:  Email

Share

Published: December 14 2007, 10:50 AM | 1 Comment(s)
by Marvin Waschke

If you've been following the progress of the CMDBf spec through my blog postings, you understand how proud and happy I am at the news that the DMTF (Distributed Management Task Force), the "the industry organization leading the development, adoption and promotion of interoperable management standards and initiatives" announced that it "accepted a draft specification that will facilitate the sharing of information between Configuration Management Databases (CMDBs) and other management data repositories (MDRs). The new spec, which was submitted by the CMDB Federation (CMDBf) working group, aims to enable organizations to federate and access information from complex, multi-vendor IT infrastructures."

As I described in my blog posting "The remarkable tale of the birth of a standard," acceptance by a standards body is the next logical step that a specification takes on its way to providing value as an accepted public standard. You can read the full DMTF press release here.

Share this post:  Email

Share