Home    ITIL  Index

Configuration Management, Without The Agony

Groups working on Configuration Management need to start simple and learn in order to be successful.
Sep 12, 2008
By

George Spafford





Organizations seeking to implement Configuration Management spend a great deal of time agonizing over how to begin. In fact, some organizations have spent years and millions of dollars without ever actually placing a Configuration Management database (CMDB) into production because they are stuck in the details. To avoid this, instead of going for the ultimate perfect solution, groups working on configuration management need to start simple and learn in order to be successful.

Objectives

During the initial design effort, understanding the objectives associated with the process is critical. It can be useful to think in terms of phases. What needs to be done as soon as possible, in six months, in one year, and so on? The idea is to quickly establish a process and data design that supports the needs of the organization short-term with a longer-term perspective also.

One group I worked with simply identified classes of configuration items (server, network device, operating system, application, etc.). For each configuration item they only recorded the unique identifier and the necessary parent-child data that is so very important for mapping out relationships. That was it. They got up and running very quickly, at a low cost and learned a lot along the way. Their objective was to understand dependencies as they often had problems planning changes and responding to incidents because they didn’t have an enterprise view to how the various component configuration items in a given IT service related.

Scope of systems

The next critical element is to decide where to start. A big bang approach can be a nightmare. Instead, start with a class of systems that is relatively controllable in a central location. This is really a pilot approach wherein the initial process and data model are developed and tested. The scope is slowly increased and corrections made if needed.

One area I tend to actively recommend against are desktops. They tend to be the least controlled and most political. Furthermore, if something is going to be in Configuration Management, it really needs to be governed by Change Management. The volume of the desktop changes could derail efforts.

As just alluded to, there is another important element when determining scope and that is politics. There are groups that will be more willing to work with a nascent Configuration Management process and the team working on it than others. It is wise to determine the scope based on this as well.

Management Information

When determining what data is needed, it is critical to understand what management information is needed at a bare minimum for each process to be successful and what senior management needs to understand how IT is performing.

This means holding process design meetings and actively identifying what is needed at the time of initial launch and then over time as updates to the process are released into production. Again, design for what is needed versus everything that is technically possible.


    1 2 >> Last Page


Comments  (click to add your comment)

Comments

    Name or nickname

    Email address

    Website

    Write comment
    You have characters left. (Maximum characters: 1200).

     


    IT Management Daily Newsletter




    Related Articles

    Most Popular