ITIL & CMDB (Logical Model)
This article focuses on how an organization makes better information technology (IT) decisions especially relating to assets. The IT Infrastructure Library (ITIL) is a compendium of best practices from many companies in many industries. It represents the best thinking of thousands of people about how IT should be run, what impact IT can have on the business it supports, and how to gain the most value from your IT investments. One of the stated goals of ITIL is to help decision makers make better decisions by ensuring that adequate IT information is available to support those decisions. Configuration management is the discipline of identifying, tracking, and controlling the various components of the IT environment, and it is this information that enables decision making. As you can imagine, however, making better decisions does not come without some hard work. Implementation of the full set of ITIL best practices, or re-engineering your process to fit the ITIL model, involves a long and often confusing journey. Figure below shows the four important areas for an IT organization with respect configuration management.
Configuration Management
Why focus on configuration management? Honestly, one of the major focuses for any IT organization should be on configuration management. Not many organizations have successfully implemented this central process discipline. It is proving to be one of the more challenging processes to do well. First, it is important because it is the center of the ITIL information universe. It attempts to build a process to gather, manage, and link information vital to every other ITIL process discipline. Second, it is challenging because it is often a new way of thinking for IT groups. Traditionally IT has been much more concerned with the financial value of the environment than with the operational value of information about the environment. It is true that technical teams have often felt the need for better data, but the resulting mixture of spreadsheets, tribal knowledge, and incomplete databases simply adds to the challenge rather than providing a useful base to build on. Technicians have a vague notion of “IT infrastructure,” but seldom do they have a complete and accurate picture of what the infrastructure consists of outside the silo in which they operate. Finally, while configuration management is a familiar term, the definition outside of ITIL has been very vague at best. Outside of software development and mainframe data centers, configuration management has never been standardized in any meaningful way. So, what is meant by configuration management specifically in an ITIL context? According to the ITIL, “Configuration Management covers the identification, recording and reporting of IT components, including their versions, constituent components and relationships.” In other words, anything that makes up the IT environment should be recorded as part of configuration management. Most importantly, the physical relationships and logical dependencies between components, sub-components, applications, servers, networks, documentation, and the myriad of parts of the IT environment must be tracked. It wouldn’t be unusual in a fairly large organization for the IT environment to be made up of millions of individual items to be tracked. Of course, with several million items to be tracked, it shouldn’t surprise anyone that there could be five million or more relationships to be tracked. While this sounds like a tremendous amount of effort, remember that your existing staff is trying to track this information in their heads today! Configuration management is intended to take away the burden of mental tracking and with it the mistakes that can cost time and extra effort.
Perhaps the best way to understand the centrality of configuration management in the ITIL process framework is to walk through concrete examples of the ways the ITIL processes interact with the Configuration Management Database (CMDB). Anyone who has used a computer has felt the pain associated with incident management. A router goes down, and suddenly you have a storm of frustrated users calling the service desk, lights flashing on the monitoring consoles, and executives calling the IT managers demanding to know what’s happening. Incident management in ITIL terms is about restoring service, and the key metric is how quickly service can be restored.
The CMDB provides information to help the incident management team isolate the source of the problem more quickly. The better system administrators or application managers track some pieces of the information, or recall the last time this incident occurred, but they still don’t have the complete picture that enables them to deal with new kinds of incidents. With configuration management data, the same IT manager simply looks at a few servers and/or applications that are down, and quickly sees that they are all related to the same router. With an accurate CMDB, the source of the incident can be isolated quickly, and then details about the failing component, such as software and firmware levels, can be viewed. Having configuration data in place can literally cut hours off the time it takes to resolve a complex incident. The CMDB - or more specifically, the information it contains—is equally important to change management. A change review board might be reviewing tens or even hundreds of potential changes in a meeting. On the surface it might look like approving two changes for two separate business applications would be unrelated tasks, and both might get approved. By looking at an accurate CMDB, however, the change board can quickly see that both applications depend on the same database server, and one change record has asked to have the server backed up while the other change record has asked to have the same database server taken out of service.
Clearly both changes cannot be implemented at the same time; but without configuration management data, these conflicts can be all too common. In the security domain, when vulnerability is uncovered, it becomes vital to understand exactly what applications and infrastructure components are exposed. If the IT manager needs to go through an inventory exercise to find the affected components, the company is left vulnerable far too long, and even then some significant relationships might be missed. Accurate configuration data allows everyone to understand exactly how serious the vulnerability is and quickly plan the level of effort required to secure the environment. Or consider the application software manager who is tasked with platform conversion. All Visual Basic applications must be converted to C# to meet new corporate standards. But this task is impossible without an accurate inventory of which applications exist, and details about which of these are written in Visual Basic. Many key decisions in the release management domain are affected by configuration management information.
The Technical and Business Challenges
So given all of the many benefits and advantages, why doesn’t every organization have a complete and accurate CMDB? Because it’s hard! There certainly are challenges associated with implementing the organization, the process, and the tools needed to achieve all these benefits. Technical and business challenges can be overcome, but if there are political barriers outside of direct project control, you need a strong sponsor who can sweep those barriers away before they block the project.
Benefits and Advantages
- Clerical Errors, Process Errors and Programming Errors will be reduced
- Breaks down the barriers between IT and the business—A CMDB removes IT silos and helps people, processes and technologies work more efficiently together. That’s because knowing what technology components you have, where they are and how they’re connected will let you better manage and improve your IT services.
- Provides more proactive management—A CMDB allows organizations to better manage change in their IT environments. As the complexity of a organization’s IT infrastructure increases, a central database containing information about all the CIs and how they work together will help you avoid downtime by more efficiently planning and better appreciating how those changes affect the IT environment.
- Helps better assess risk, improve security—IT organizations can use CMDB data to assess the risks to the business associated with known vulnerabilities on servers. That means your IT team can prioritize patches and secure the most critical vulnerabilities first.
- Helps keep track of any changes in software—Data from the CMDB lets organizations know if there is any unauthorized or illegal software being used.
- Makes compliance easier, more accurate—Using CMDB data, IT organizations can make sure that the information about their assets is accurate and up to date in order to comply with such initiatives as Sarbanes-Oxley and HIPAA. By keeping a close eye on CIs and their relationships and continually monitoring them to make sure they’re accurate, your IT organization can better ensure that your systems and their components comply with legislative mandates.
_______________________________________________________________________________
Author - Vijayakumar Reddy, CTO & Lead Trainer, A2A IMTCS Pvt. LTD.
© Copyright 2015 A2A - IMTCS. All rights reserved. www.iimtcs.in
The Swirl logo is a trade mark of AXELOS Limited.
Author - Vijayakumar Reddy, CTO & Lead Trainer, A2A IMTCS Pvt. LTD.
© Copyright 2015 A2A - IMTCS. All rights reserved. www.iimtcs.in
The Swirl logo is a trade mark of AXELOS Limited.
ITIL® is a Registered Trade Mark of AXELOS Limited.
PRINCE2® is a Registered Trade Mark of AXELOS Limited.
MSP® is a Registered Trade Mark of AXELOS Limited.
Copyright © AXELOS Limited 2011. Reproduced under license from AXELOS
_______________________________________________________________________________
PRINCE2® is a Registered Trade Mark of AXELOS Limited.
MSP® is a Registered Trade Mark of AXELOS Limited.
Copyright © AXELOS Limited 2011. Reproduced under license from AXELOS
_______________________________________________________________________________