Project Management

ITIL and Configuration Management: Where to begin

An IT Service Management consultant walks you through the steps he took to help one county implement Configuration Management.

By Hank Marquis

With all the hype and press currently surrounding the IT Infrastructure Library (ITIL) Configuration Management Database (CMDB), it's no surprise that practitioners are confused about how to implement Configuration Management.

I've worked with many such companies. Most often the main issue they face is "where to begin." Establishing a starting point for Configuration Management is difficult since the idea of a CMDB system can be hard to grasp. The challenge is all the greater because ITIL's definition of configuration management requires documenting and validating a broad range of interdependencies that stretch far beyond what most people mean when they hear the term. So Configuration Management becomes a foundation for virtually all ITIL processes with the CMDB at its heart.

Simply put, a CMDB is a meta-database, or a database of databases. In fact, it may not be a traditional database at all in some initial CMDB implementations, but simply a registry for accessing other sources of information relevant to first-phase CMDB objectives. In other words, a CMDB contains data about other databases and how they interrelate. This single point is what causes much consternation over establishing a CMDB and the Configuration Management process.

The CMDB journey: An example

Here's the story of establishing Configuration Management at a county government IT department. The county is significant, and has an annual IT budget of about $35,000,000. They decided to embark on the ITIL journey in order to "do more for more with less" -- a very common mandate from all IT sectors, not just government. The lessons presented in this story are appropriate for any IT organization embarking on the ITIL CMDB journey.

As the county marched on toward their ITIL implementation, they hired consultants for maturity assessment and trained dozens of their staff in ITIL Foundation and Practitioner certification. They assigned process ownership and management to senior managers throughout their existing organization. They hosted workshops to learn how to organize for ITIL workflow, and establish management controls. They engaged senior management. After almost a year of working with the county, they felt ready to embark on their own.

After several months, I got a call on behalf of their IT Director asking for some help with Configuration Management. They had made great strides with Incident, Service Desk, Problem, and Capacity and Availability Management, but Configuration Management was not going well.

I met with the Configuration Manager and heard a very familiar story -- the idea of identifying, tagging, and logging all Configuration Items (CI) was overwhelming. Aside from this staggering task, they could not pin down how to organize CIs into services. In short, they could not determine "where to begin." I suggested to the Director that we host a workshop with all the functional and process managers with the goal of developing and defining what ITIL refers to as a Configuration Management Plan connected to a Continuous Service Improvement Program (CSIP).

A workshop

At this workshop, I asked the managers to define the top issue facing IT. You see, to succeed with Configuration Management and a CMDB system you have to begin with the end in mind -- in other words, you have to identify the ultimate goal or output required, and then work backwards through Configuration Management (and the CMDB) to arrive at your starting point. Of course, as far as ITIL is concerned, all IT work should be in direct alignment with business need, so simply saying "we need a CMDB to speed trouble resolution" or "we need a CMDB to help our internal change management process" is not good enough. To succeed you really need to know what business/customer problems you're going to address with your ITIL endeavor -- specifically what you expect to resolve, how to measure it, and to whom to show the results. This is real business-IT alignment. This fact (often overlooked or minimized) is what makes the creation of effective CMDB systems so difficult for many.

At the workshop the team came to the conclusion that the single greatest issue facing IT was quality of service to end users. The issue was that when high-profile users called for support, the Service Desk had no way to relate the user's application to a specific server. In turn this frequently resulted in misrouted trouble tickets (aka Incidents.) The follow-on issue to misrouted tickets was that a ticket would get bounced around the IT organization and age (rot is more appropriate.) As the ticket aged and remained unresolved, the user would escalate to senior IT management and IT then had no choice but to apply maximum organizational force to resolve the issue. This is the classic challenge that most IT organizations call "fire fighting." Of course, the problem is that working in such a mode, the IT organization had no time to improve its efficiency or become proactive.

The resolution was easy once the team and I understood the main business/customer issue facing the IT organization (misrouted tickets due to a lack of awareness of infrastructure configurations that resulted in prolonged customer outages and downtime.) We now knew "where to begin" and we had the end clearly in mind -- the goal of the initial CMBD project was to provide the Service Desk with information that showed which application ran on which server, and then indicated where to route the ticket.

As with most CMDB implementations, the data required is usually already in the IT organization somewhere already. The issue isn't lack of data; most IT organizations have plenty of Management Data Repositories (MDR). In fact, they often have far too many unreconciled sources spread across multiple IT domains and often distributed across separate regions. This proliferation of "warring sources" is actually one of the primary drivers for value in creating CMDB systems, just as it presents one of the toughest challenges. IT organizations just don’t know where critical management data is and have a hard to locating it when they need it. This is why the ITIL describes the CMDB not as a monolithic entity, but rather as a "database of databases."

After determining where and why to begin, we next had to locate where the MDR was currently residing within the IT department, which like most, is composed of workgroups organized by technology (e.g., siloed). Since we had all process and functional managers at the workshops, I next asked the question, "Who knows what application runs on which server?" and nearly instantly got the answer. It turns out the MDR to solve this issue was located in the server storage backup group -- they had an Excel spreadsheet they maintained showing each server and its operating system, software, database, etc. This is why I requested all functional and process managers be at the workshop.

I then pointed to the Configuration Manager and told him to broker access to the Excel spreadsheet MDR maintained by the server storage backup group with the Service Desk. They decided to publish the MDR via a web page available at the Service Desk. Thus was born true business aligned, ITIL-based Configuration Management and a real CMDB at a real company. Approaching Configuration Management and CMDB creation in this fashion ensures visible quick wins by improving IT service quality in ways measurable and demonstrable to customers. It provides IT with a means to measure and justify the ROI associated CMDB establishment. It also helps establish an understanding of the TCO -- the cost or process, workflow and resource utilization over time -- required to maintain the CMDB and the Configuration Management process.

Over time, the nascent Configuration Management process can now grow the CMDB with firm metrics, in lock-step with business benefits. IT at the county is now well on the way to being a business partner instead of a perceived impediment to business.

Hank Marquis is Director of IT Service Management Consulting, Enterprise Management Associates (www.emausa.com)

8 comments
pschoorl
pschoorl

A story easy to relate to because it gives a real life recognizable example.

jmw
jmw

I have seen people hit the CMDB wall as well. Since service definition should be driven by SLM, some thought to including SLM early in the journey is warranted. In fact, SLM can and should take a leadership role in stakeholder and services targeting which seems to be what (eventually) took place here. In a siloed environment, SLM is often missing or not positioned where it should be. Front and center, leading the CSIP.

ITILfriend
ITILfriend

One of the biggest problems our organisation has faced is where to start with Configuration Management, exactly what this article is all about. Everybody is jumping up and down about the wonders of ITIL and it's components, but this is the first article that gives practical advice aboutwhere to start with CoM. I'll definitley waving this article under the noses of the powers that be.

Peter Marshall
Peter Marshall

You have hit the nail on the head with this article. The information is always available if only we can find it. Too often all of our Department is involved in Firefighting, or at the management level, in Crisis Management. All IT Departments need to be proactive in configuration management. The challange is to make the time available to start, and I agree that the only place to start is with a goal of what needs to be achieved. Thanks for your insights.

Dr Dij
Dr Dij

SMBs in particular often don't have any coherent policy in regards to configuration management. And I find this is a major source of downtime. Our PC dept replaces a workstation and doesn't configure the needed programs. I have to go over what needs configuring with the PC guy, only after we find that it is not working or not installed. And changes to configs in routers, etc can leave your system open to attack. I've seen where these systems pay off in real life, and (admittedly biased) webinars for products such as Mercury's offerings and Skybox for network security configuration automatic monitoring. While some downtime is caused by hardware failures or bugs, a large percent of it is caused by authorized or unauthorized changes. Which systems like these let you pinpoint. Including changes by third party providers such as data lines. And this doubles as unified documentation source for a good chunk of your systems.

robin.yearsley
robin.yearsley

Great article by Hank - who always provides the insiders view of what the real issues and challenges are. I just wanted to let you know that a brand new 2 track ITIL Podcast entitled, "How To Implement the CMDB" will be launched this coming Friday (27th April). You can listen or subscribe to it for free. What's different about this Podcast from the many others that are available right now? Well, I've interviewed a CMDB expert (he hates me calling him that!) for a whole hour on the real world challenges involved in actually planning, designing, building, testing and running the CMDB. He covers some brand new content and presents some fascinating insights into what's REALLY involved. I also make sure we covered the 'human element' too which is generally forgotten. To listen and learn simply visit: - http://www.ITServicePodcasts.com There are many other ITIL and ITSM Podcasts with other 'expert' interviews available for free too! Best Regards, Robin.

GeoNaw
GeoNaw

I've listened to Robin's podcasts and they are very real world and to the point. As in the above CMDB article, we need more 'hands on' articles that can show current and future ITIL implementation teams how to roll out this process to our corporate Business Units. Doing this and showing the benefits (financial, customer sat) will only solidify the relevance of ITIL.

robin.yearsley
robin.yearsley

Hi GeoNaw, Many thanks for your positive comments. As you point out I'm only interesting in ITSM driving improvements and delivering real world results. I judge this by what my clients and customers tell me about their business success and the results they achieve by leveraging ITSM and ITIL best practices. You may be intersted in two more that I did recently that have also received great feedback, again based on what works in the real world: - Implementing ITIL: http://www.AskTheServiceExpert.com Introducing ISO/IEC 20000: http://www.AskTheISO20000Expert.com Best Regards, Robin.

Editor's Picks