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).
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)