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. 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.
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.
CIs and Attributes

Two confusing terms that routinely have to be explained are Configuration Items (CIs) and Attributes. CIs are like data tables and are structured with the necessary fields, which are the attributes, necessary to adequately describe the CI. CIs are things like hardware, software, documentation and so on. An example of attributes for a server CI include model, processor type, vendor, amount of RAM, and so forth. They describe the CI in greater detail.

Figuring out how many CIs and the requisite attributes for each CI is the hardest part of the journey. Information technology professionals often want to track everything possible in case that data may be useful at some point in the future. That mindset, if left unchecked, will result in extremely complex table designs that are costly to implement and even more costly to sustain.

Imagine creating a CMDB that has five tables with 10 fields each vs. one with a 1,000 tables with an average of 50 fields each. Now, think about all the data entry, controls and auditing necessary to keep that data accurate. Some firms genuinely believe they need to go for the ultimate solution at the outset. Experience shows that going for the end all be all solution at the start isn’t a sound approach.

Instead, care must go into designing a data model that supports the process and objectives of the effort. Literally, chant “meaningful and manageable” over and over. The data must provide clear value and be manageable, or sustainable, on a day-to-day basis over time. To look at it another way, the value of the configuration data must merit the initial and ongoing costs of maintaining the data.