This Blog
Syndication
Recent Posts
Tags
Calendar
Archives
Iterating on IT Service
December 2007 - Posts
-
Happy Holidays from down on the farm
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
-
CMDB Dilemma: Authorized versus Observed Configuration
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.
-
DMTF Accepts New CMDBf Specification
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.
-
The Unified Service Model and the CMDB
In an article in CIO entitled "Why IT Needs a Blueprint: The Case for a Unified Service Model," my colleague, Helge Scheil, wrote the following:
"A Unified Service Model provides insight into the service definition--that is, the assets, people and processes that support each service--and key information about each service such as costs, service levels, problems, incidents, events and projects related to the service. A Unified Service Model is typically implemented via a CMDB with significant integration to other management tools that provide deeper insight into service attributes."
A business example in the article does a good job of demonstrating the real value to be gained from a well-implemented and well-utilized CMDB. As the basis of a Unified Service Model, which in turn is the basis for the IT blueprint that Helge advocates, the importance of the CMDB can not be overstated.
-
You Got Some Service Catalog in my Service Desk
Like peanut butter and chocolate, service catalog and service desk are quite good alone, but even better together. Always closely related, the products have gone through a curious evolution since I first worked on developing service products--years before those products were entrusted to CA's care.
My first exposure to the two applications came when I was working for Boeing as a development lead engineer in a little internal phone department that provided POTS (Plain Old Telephone Service) to a large multi-site enterprise. My team was tasked with building two applications: a trouble ticketing system (service desk) and a service request system (service catalog). We started on trouble ticketing and the whole team was spun off into a start-up before we got around to finishing the service request system.
And that was kind of the way it went for a long time. It was always clear that the two applications were similar--they were both driven by end users asking for something--and sites were always trying to shoehorn both incidents and service requests into the same service desk application. The service desk team kept trying to supply features that would make service desk work better for handling service requests, but the service request side was always secondary to the main event--incident handling.
But it all came out right in the end. Service catalog has matured greatly and is now a vigorous contender in the marketplace. The recent launch of ITIL® version 3, with its increased emphasis on Service Catalog, can only add to the application's staying power.
Service Catalog and Service Desk now work together to provide the kind of complete and efficient service that the little POTS department could only dream of years ago.
If you are interested in exploring the intermingling of Service Catalog and Service Desk, you may be interested in my recent technical brief and webcast. Let me know what you think.
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.
Print
Email
Rate