CHAPTER 1. Overview of Configuration Management

This book will help you make better information technology (IT) decisions. That’s a big promise, but it’s not my promise. 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 reengineering your process to fit the ITIL model, involves a long and often confusing journey. That’s where this book comes in. It will help clarify the jargon, establish the roadmap, and warn of the pitfalls along the way. Rather than a generic work that repeats much of what is already documented in the IT Infrastructure Library, this book focuses specifically on configuration management and helps you to implement this core discipline, which will enable the rest of your ITIL journey. By focusing on configuration management, we enable you to build the critical set of information that will be the foundation for better decision making.

Figure 1.1 shows the four areas we cover in this chapter. We’ll get a basic understanding of ITIL and configuration management. Then we’ll look at the benefits and challenges of implementing a configuration management service. Throughout this chapter and all those that follow, we’ll focus on practical experience rather than memorized theories.

Figure 1.1. Implementing ITIL configuration management involves both benefits and challenges.

ITIL Background

ITIL implementation is one of the hottest topics in IT today. In order to gain a good understanding of the value of configuration management, we must clearly understand what ITIL is and what it is not. Fundamentally, ITIL is exactly what its name implies—a collection of books. The common theme of the library is that all of the books provide guidelines that can help organizations implement the best practices that have been learned the hard way by the pioneering few. There is a volume about security, one about planning, one about software assets, and one about managing applications. The library continues to grow as more successful techniques are documented and guidelines established for what can make others successful.

The latest information on ITIL comes from the UK Office of Government Commerce (OGC) through its web site at http://www.best-management-practice.com/. Be sure to visit the “Terms and Conditions” link at the bottom of the page for the appropriate uses of that web site.

This book focuses on two volumes of the library: “Service Support” and “Service Delivery,” the combination of which is called “IT Service Management.” Together these two volumes form the core of ITIL—the piece with which most enterprises begin their implementations. Collectively, the service support and service delivery volumes describe the collected best practices in these IT disciplines. Five processes are described in service support:

• Incident Management
• Problem Management
• Change Management
• Release Management
• Configuration Management

Five additional processes are defined in service delivery:

• Capacity Management
• Availability Management
• Service Continuity Management
• Service Level Management
• Financial Management

The guidelines offered for these ten process areas cover what any IT shop, large or small, must do to effectively provide service to the enterprise it supports. Figure 1.2 shows this categorization of the ITIL service management processes.

Figure 1.2. ITIL categorizes service management processes into two groups.

As this book is being written, the next release of ITIL is being readied for release. This book assumes the reader is familiar with ITIL Version 2, but where significant differences exist in the next release (Version 3), they will be pointed out. The structure of the library is different in Version 3, with the assumption that all books focus on service management, and the underlying organization is based on the service life cycle.

So rather than service delivery and service support, ITIL Version 3 contains volumes on service strategy, service design, service transition, service operation, and service improvement. By adopting this life cycle-based approach, the library becomes more useful to organizations at various stages of the journey. This book focuses on organizations that are actively implementing configuration management, and thus elaborates on the guidance that will be found in the Version 3 Service Transition book.

This isn’t a book about ITIL, but it is important to understand the high-level purpose of each process area to better understand how configuration management relates to each process. The service delivery processes are those that directly impact the running of servers and software.

• Capacity management— Aims to understand how much capacity (measured in memory, bandwidth, storage, and variety of other units) is currently available, how much will need to be available in the future, and how best to manage so that capacity shortfalls don’t occur and excessive capacity isn’t acquired.
• Availability management— Deals with maximizing the availability of the IT infrastructure through trend analysis and proactive elimination of single points of failure.
• Service continuity management— Proactively plans for component outages and includes everything involved in ensuring the business keeps getting the IT services it needs despite the lack of one or more IT components. It consists of disaster recovery and contingency planning.
• Service level management— Defines and monitors the value which IT is providing to the business through setting and reporting on targets called service levels.
• Financial management— Deals with understanding the costs of IT and appropriately funding the IT infrastructure in the most efficient way.

The service support processes are centered on the record keeping, tracking, and process improvements that make IT successful.

• Incident management— Captures the details associated with a service outage, communicating those details to the appropriate parties so that service can be restored as quickly as possible.
• Problem management— An information analysis function that determines the root cause of any highly impacting or frequently recurring outage and then tracks corrective actions to correct that root cause.
• Change management— A critical discipline that controls and communicates the changes occurring in the IT environment.
• Release management— A disciplined approach to organizing changes to make better use of the resources involved.
• Configuration management— Fundamentally the science of tracking the exact state of the overall IT environment at any point in time.

All of these process areas will be referenced frequently in examples throughout this book.

Although it is easiest to consider ITIL as made up of separate process areas, real life isn’t always that simple. In many cases a particular activity will encompass more than one process area, and the interplay between processes is at least as important as understanding any single area. For example, suppose a server is supporting a major business application, and the server suffers a catastrophic failure. The incident management process comes to the forefront by attempting to restore service. But at the same time, availability management is invoked in an attempt to maximize the availability of the overall service, and service level management tracks the impact to both operations level and service level agreements. As part of restoring the service, changes may need to be managed, the service continuity plan may need to be invoked, extraordinary costs might need to be tracked, and it might be desirable to check capacity plans to find another server capable of picking up at least part of the load

Along the way, configuration management provides information about the impact of the service interruption, including whether there will be a complete failure of a service or simply a degradation, and also provides options for restoring service. Thus, a single IT event (the crashing of a server) actually involves many of the ITIL defined process areas. It is exactly this interplay between processes that makes configuration management and the information it provides so important, as we see repeatedly in the chapters that follow.

Configuration Management

Why focus on configuration management? Honestly, this book focuses on configuration management because not very 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 Service Support book, “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, subcomponents, 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. Fortunately, this book describes a way to build up to this kind of complexity without having to tackle all those details at the very beginning.

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.

And on it goes. Every process defined by the ITIL framework gains concrete benefits from accurate and timely configuration management data, and those other processes will never function effectively without configuration data. These key dependencies are facilitated by relating the configuration items (CIs) to key concepts in other processes, as shown in Figure 1.3. Once populated, your CMDB will be the most frequently accessed set of tables in the entire systems management solution. Because configuration data is so vital and used for so many purposes, it is critical that it be accurate and complete—a recurring theme in this book. Many more examples of the interlocking of configuration management and other ITIL disciplines will be presented in the chapters that follow.

Figure 1.3. Each other process interacts with configuration management.

The Business Value

Beyond the operational processes, however, there is a significant business value to having complete and accurate configuration management data. The old saying “time is money” was never truer than in systems management. Having timely and accurate data at the point of resolving an incident or considering a change will result in huge savings. As everyone knows, having information is critical to making good decisions, and this is certainly the case with configuration information.

Making Good Decisions

Consider, for example, the many decisions that are made around the cost of support. Should we outsource our IT support? Perhaps we can move some of the support off shore to leverage lower labor rates. How much longer should we support those old dot-matrix printers? Is the value of the redundancy really worth the cost of supporting the load balancer? These are just a few of the many questions that come up around support costs in IT shops every day. In an era of global economic competition, making wise decisions can be a matter of survival. But wise decisions are fueled by adequate information. Having an accurate CMDB allows the IT manager to understand which components of the infrastructure fail most often, how much change activity is occurring to antiquated equipment, and when to drop support of certain applications or types of equipment.

Although configuration management should never be confused with IT asset management, there is certainly value to having more information as part of the IT purchase cycle. The CMDB can help determine when it’s appropriate to refresh hardware sooner than expected, or when it is acceptable to let the refresh cycle lag behind the original schedule. If a server is hosting business-critical applications and has had a whole series of minor incidents reported against it, it might be time to escalate the refresh time of that server, or perhaps swap it into a less critical part of the environment. But rather than simply deciding based on the annoyance of the most recent incident, you can have concrete information from the CMDB on which to base this kind of decision.

On the other hand, if a router has been running perfectly for four years, and it supports only a handful of user networks, it probably doesn’t make sense to replace it with a newer model just because policy says that four years is long enough for routers. Of course, none of these decisions can be made without good data on the environment, including relationships of components to applications and users, and a good track of the incidents and changes by component. Without configuration management information, you won’t have solid information on when to shift your IT policies, and you will have to rely on instinct or emotion.

If your organization has adopted grid computing to any extent, you already understand the significant decisions around this utility-based computing model. Because the basic tenet of grid computing is massively parallel computing, you must have an easy way to understand the configurations available for use. Accurate configuration information will allow for rapid decisions about how much work can be directed to the overall grid, and which potential hosts can support the additional workload. Without having adequate information about the configurations involved, it would be virtually impossible to make workload decisions for the entire grid.

Another kind of decision that is enabled by configuration management data is investment decisions. By looking at the data available, and particularly at the relationships between IT components as captured in the CMDB, it’s possible to isolate single points of failure and see redundancies. Examining the number and criticality of applications related to a server can show potentially under- or overutilized servers. Seeing the links between routers can show where additional firewalls might improve IT security. This type of information helps to determine which projects are worthy of funding and which projects can safely be delayed until the following year. In this way, the CMDB and discipline helps to support the decision making around your IT investments.

Process Effectiveness

The business value of configuration management is not limited to making decisions. Configuration management is truly a service support process. It supports all other processes by helping them meet their goals more easily. As an example, consider again the incident management process. Typically during a service disruption, information is in short supply and demands for action are frequent and loud. Knowing which applications run on the downed server, which LAN segments are supported by the failing hub, or which business processes depend on the bug-ridden application can be the difference between a temporary inconvenience and a prolonged, revenue-losing outage. When the organization trusts the CMDB and can rely on its accuracy, every incident will be understood and repaired more quickly. This more rapid understanding allows technicians to recover service instead of trying to discover (once again) how things are pieced together.

The key to really understanding how things are pieced together is a complete business service model. In such a model, IT infrastructure components such as servers, routers, and operating systems are linked to the business application software they support. This application software, in turn, is linked to the specific function or process within the wider organization that uses those applications.

As a simple example of a business service model, consider the payroll function present in most organizations. The business functions of payroll are to compensate employees, make sure taxing authorities get paid, and record disbursements to various insurance, pension, and charitable causes made on the employees’ behalf. Assume that the payroll function uses a primary payroll application, as well as a health insurance application that links via EDI with an insurance company. The payroll application runs on a set of UNIX-based servers, including a database server, several web servers, and an application server. Each of these servers runs an operating system and one or more middleware products. The health insurance application can be similarly broken down, and here we even include the direct network links that support the EDI transactions. A simple schematic might look like Figure 1.4. By linking all these individual IT components together with the payroll business functions, we have created a service model that demonstrates directly how IT supports payroll. Service models will be a recurring theme throughout this book, but it is easy to see how the existence of such models, and gathering them together into a services catalog, can be a key enabler to make all IT processes more effective.

Figure 1.4. A simple example of an environment to be recorded in configuration management.

Release management can also be made more effective by accurate configuration management data. Imagine a major application consisting of a database, an application server tier, and a web-based presentation tier. Each piece of the application may run on one or more servers, and all those servers might host other applications beyond the one being considered part of the release. A release manager needs complete and accurate information about this entire environment, including the dependencies of one part of the application on another, before scheduling the series of changes needed to put a new release of this application into production. On a much smaller scale, consider the release of a new security patch to Microsoft^® Windows^®. Without adequate and near real-time configuration information, it is extremely difficult to determine where the patch has been installed and where it is still needed. Inadequate data could lead to a continued security exposure as well as embarrassing and expensive security breaches.

As another example of the support that configuration management gives to all other process areas, consider service continuity management. Being proactive, a continuity planner could look through the CMDB for likely points of failure by navigating the relationships between IT components. Seeing those potential failures allows the continuity plans to include redundancy or hot standby spares as appropriate. In addition, when a disaster does happen, if the CMDB can be restored in the recovery environment, it can serve as a valuable double check that all critical components are indeed restored to service after the plan is invoked.

Finally, consider the significant advantage that configuration management data provides in making outsourcing more effective. In the simplest case where a single outsourcing vendor is involved, configuration information provides a solid baseline for understanding the services being provided. In a more complex situation where multiple vendors provide different services, configuration management can enable the communication between vendors. Rather than pointing fingers or placing blame, each vendor can take responsibility for specific configuration items, and the scope of duties can be very clear. For such multivendor environments, configuration information is critical.

The Technical 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. But don’t despair—this book will guide you through the challenges and show how you can achieve the benefits of configuration management for your organization.

An underlying assumption throughout this book is that you have the sponsorship of key decision makers for your organization. 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. We’ll return to the theme of sponsorship many times in the chapters that follow.

Data Overload

The single largest obstacle to creating a CMDB is the sheer volume of data that can be collected. Even a relatively small organization must track thousands of individual items, and in larger enterprises the number can quickly grow to more than a million. The challenge is exacerbated by the variety of items that need to be counted, and the technical knowledge needed to understand what to count and in what order.

For example, suppose a server cluster has four physical boxes and runs twelve virtual operating system images along with a cluster control program that manages swapping resources like memory and CPU power among the virtual images. It takes a technically adept person to recommend how to account for that cluster in the CMDB. It might be described as 4 servers, 12 servers, or perhaps 1 server. The number of items to be cataloged multiplied by the difficulty of determining what to track results in a very large obstacle to correctly creating and maintaining a CMDB.

The key to overcoming data overload is to break down the environment into manageable pieces and decide that it’s better to have good information about some things than no information about everything. The key to breaking down any IT environment is in understanding the appropriate scope and granularity for your needs. Scope involves deciding which IT objects to manage in the configuration database, whereas granularity involves determining how much and what kind of information will be maintained about each of those objects. Chapter 3, “Determining Scope, Span, and Granularity,” provides details of how to determine the appropriate scope and granularity.

Dynamic Environments

A second technical hurdle is the frequency of change in most IT environments and the fact that many changes are decentralized. Individual users can install programs on their PC, and sometimes on shared spaces of servers; business needs drive the maintenance and upgrade releases of all business applications; technical obsolescence dictates that hardware be refreshed constantly; and ongoing projects introduce new levels of automation and new layers of complexity. All of these sources of change may be controlled to a greater or lesser extent by formal processes, but each results in changes to the IT environment that must be recorded into the CMDB. Sometimes it seems that you need an army of record keepers just to keep the data up to date with all these changes going on. Many configuration management projects have a solid plan for getting all the data populated, only to find out that what they populated in the first days of the project has turned to hopelessly out-of-date garbage by the time the project ends.

Change management provides the freedom to make all of the required and requested changes to the IT environment without worrying about losing control of the situation. The key to long-term success of the configuration management process is the linkage between that process and change control. The linkage must be established so that every change record results in at least one update to the CMDB, and every update to the CMDB can be traced back to at least one change record.

When this linkage is in place, you can be confident that every change will be well understood and can be executed with full knowledge of its impact on the environment. Without that strong linkage, and all of the audits and controls that should be inherent in the change management process itself, maintaining accurate configuration control will be extremely difficult. Chapter 4, “Customizing the Configuration Management Process,” has much more to say about integrating the configuration management process with other ITIL process areas.

Many organizations are experimenting with autonomic computing or other means of dynamically installing technology. In its simplest form, this involves setting up a controlling system that will deploy standardized software packages quickly to other computers. While this deployment technology can greatly reduce costs, it introduces a new technical challenge for configuration management. Unless the automatic process includes some way to read from the CMDB prior to taking actions and update the CMDB with the results of the actions taken, the accuracy of configuration information can be jeopardized. This kind of automatic provisioning makes an environment even more dynamic and tracking of configuration information even more challenging.

Failures in Tool Integration

Another technical challenge for those wishing to implement configuration management is the immaturity and especially the lack of integration between tools in this arena. There are strong discovery-type tools that can scan a network to find hardware devices and scan storage media to find software programs. There are integrated suites of tools that allow incident and change records to be tied to configuration records. There is even a developing class of tools that claim to be able to detect the relationships between some of these entities. But the challenge is to find or build a complete end-to-end tool set that will discover data, move it to a repository, link in with data about other ITIL processes, and allow strong capabilities to retrieve and visualize that data in necessary ways. The problem is confounded greatly by the need to both filter discovered data and marry it to undiscoverable data, such as the business unit associated with a piece of software or the physical location of a server. Even the best tools available today need to be heavily modified or programmatically integrated with other tools in order to meet the needs of a complete configuration management process.

The tools problem becomes even greater when organizations are focused on necessary security problems. In the most extreme cases, tools that automatically discover configuration information over the network aren’t even allowed. Even where discovery tools are supported, they are often located behind firewalls that cannot transport their data to other parts of the enterprise. An integration strategy is needed to define how data from different network security zones can be combined and transferred to the enterprise CMDB. This adds a new dimension of complication to the overall tool integration exercise.

Choosing the correct combination of tools becomes a matter of understanding exactly which roles those tools will play. Chapter 2, “Gathering and Analyzing Requirements,” helps you define good requirements—not just for tools, but for your entire configuration management program. And in Chapter 7, “Choosing the Right Tools,” you learn much more about the types of tools available and how to assemble a complete system to accomplish your objectives.

The Journey to Maturity

The one thing to take away from this chapter is that configuration management is a significant business advantage, but one that presents significant obstacles. Always bear in mind that configuration management, like all the ITIL disciplines, is not a binary entity. You don’t either have it or not have it. Everyone does some kind of configuration management, even if it is only remembering where you left the server after you installed it. Rather, there is a continuum from the organization which has only the faintest notion of what their environment looks like to the highly disciplined enterprise that closely controls all configuration items and uses the information mined from their CMDB to make significant business decisions.

Experience shows that there are four milestones of maturity in the configuration management discipline. Of course, like any good continuum, the stages blend together and it’s sometimes difficult to discern one stage from another as you’re doing your best to progress through them. But most organizations will recognize one of these milestones as the “good enough” point—that place where the value gained from the configuration management work is sufficient and further effort doesn’t produce commensurate business value. Although this book provides advice for reaching all these milestones, each organization must assess for itself the value it gains against the effort needed to get that value. This is another point at which your key decision maker can help. Your sponsor will determine whether to expend the additional energy to gain the next maturity level or to be content with the gains already achieved.

The first stage of configuration management is characterized as an inventory exercise. Data is gathered and categorized into a CMDB. At this stage, the organization defines some kinds of configuration items—usually servers, business applications, commercial software packages, and workstations—and goes about collecting the information about those types of things. The information may be collected afresh with inventory techniques and tools, or it may be gathered from diverse existing systems that each contain part of the data. The key milestone for this first stage is in classifying the data that will be gathered and starting the data-gathering activities. The classification scheme is important and will generate a lot of healthy discussion, even in the smallest organizations. This is as it should be because the classification is ultimately more important than the actual data gathered. Changing the types of data gathered after the configuration management process has begun is extremely difficult.

The second stage is characterized by the documentation of dependencies between the configuration items. This is a major step because these relationships hold the real power of the CMDB. Although IT asset management systems typically relate hardware to software or users to workstations, a mature CMDB will hold a richer set of relationship types that can be used to really understand the full operational picture. Building this richer set of relationships shows that your organization has moved beyond the first stage and is really beginning to understand the uses of configuration management. Relating CIs to one another will require an entirely new way of thinking for any organization that has not been doing configuration management before.

Relationships offer a very rich and flexible way to describe the IT environment, just as relational databases opened up a much more flexible way of storing data. But just like the change from the old indexed databases to the more modern relational schemes, using relationships to describe an environment requires new techniques and thought processes. You will find much in this book to help you make that shift in the way your organization thinks.

The third milestone along the configuration management journey is one in which the organization finds itself maturing and perhaps even reengineering its processes. Accurate configuration data, including relationships, will help align other IT processes with the industry best practices which ITIL represents. Systems monitoring tools can relate events directly to specific configuration items to help technicians more quickly find failing components. Rather than classify the incident with a product type classification scheme, the service desk can depend on the CMDB to populate the categorization of the incident. Similarly, in stage three, the change management, capacity management, and even service level management processes can be reworked to leverage the configuration information that is available. Rather than have service levels on items with somewhat random names, services levels are based on specific configuration items, and outages to those configuration items can immediately trigger the service level managers to know that their targets are in danger. When you look at the other ITIL process areas and realize that they depend heavily on configuration management data, you’ve reached the third milestone along your journey to maturity. This maturity of process is where the most significant benefits of the configuration management discipline are measurable, and many organizations decide this is the end of their investment in configuration management.

For the organizations that choose to go forward, the fourth milestone empowers business decisions. Specific projects are executed to enable business transformation based on IT knowledge. Such a project might be to create business processes in your CMDB, and link together groups of business applications into a business process. Using an appropriate indicator of the relevance of each application to the overall process, you could create business value chains to show the impact of any IT component on the overall business it serves. As another example, the organization can establish capacity plans that reflect the real importance of a component rather than simply assuming any device running near its capacity must be augmented. The configuration management information and mature processes present at this stage allow for clear planning of IT projects and a proactive analysis of those projects real impact on both the IT environment and the overall capability of the business. Reaching stage four will help you make the better decisions I promised at the beginning of this chapter. These four stages are displayed in Figure 1.5.

Figure 1.5. Maturity is reached through a series of phases.

So while configuration management is not easy, it is worthwhile and has proven to be cost effective for hundreds of organizations. This book leads you through the key decision points and helps you to understand some of the lessons that others have learned about implementing this key ITIL discipline.