How to manage CMDB Scope

Although a CMDB can be extremely complex, it is built of only two elementary constructs, called configuration items and relationships. Configuration items represent static portions of the IT environment, such as computers, software programs, or process documents. Relationships, as the name implies, track how these configuration items are related to one another, and are much more dynamic because these relationships can change frequently. Given these simple building blocks, defining the scope of a configuration management system is as simple as deciding which types of configuration items you want to track and which relationships will be important.

Note that we define scope as which types of configuration items will be tracked, not which configuration items. Once we decide that a particular type of thing is going to be tracked, it becomes part of our scope, even if we choose to track only a single instance of that type of thing. The choice of how many of each type, and exactly which ones, is part of the span of the CMDB

Although scope is a very simple concept, it can be extremely difficult to define for your organization. Because scope gives the CMDB its shape, you should choose a set of categories that are easy to understand and demonstrate complete coverage of the IT space. You will certainly want to include types of objects from the different areas you manage—servers, mainframes, data networks, telephony, packaged software, developed software, and whatever else is part of the purview of your organization. Additionally, you may want to consider a set of categories for documentation because IT Infrastructure Library (ITIL) best practice describes configuration management as including control of the user guides, process documents, and other artifacts that are part of the operational space.

Fortunately, help is available in determining which categories to use. The Desktop Management Task Force (DMTF) has created a standard called the Common Information Model (CIM), which conveniently enough is a set of categories for describing an IT environment. If you would like to see the full standard, visit the DMTF web site at www.dmtf.org/standards/cim/. The standard can be somewhat daunting because it covers a very wide range of situations and is necessarily complex, but it is well worth considering. Increasingly, tool vendors are adopting the CIM as the basis of their “out-of-the-box” database, which can greatly reduce your implementation time if you adopt the model. Most organizations will not select a scope that covers the entire standard but will choose a subset of the available categories from the model. One very good aspect of the DMTF standard that should be part of your configuration management scope is the inclusion of what the DMTF calls associations, and what we’ve been calling relationships. It is hard to overemphasize the role that these relationships between configuration items play in the overall CMDB. A beginner’s mistake would be to focus on the configuration item scope but overlook the importance of defining which relationship categories will be used. Be sure to carefully consider which kinds of associations you will include.

Let’s consider some specific examples of scope decisions. Some obvious configuration items to include are UNIX servers, licensed software packages, and your organization’s key process documents. In the relationship area, you will most certainly want to include relationships

between software and hardware and between servers and the networks they reside on. But there is also plenty of gray area. Take, for example, the hard disk that comes in each personal computer. You could call this a separate configuration item and potentially get important information about which machines will need to have more disk space to accommodate the latest operating system. On the other hand, do you really want the complication and expense of tracking every disk replacement done throughout the organization? A cost analysis might show it is less expensive to just bump up the size of ALL disk drives purchased than it would be to track all the change records needed to replace workstation disks. It is easy to see that setting the scope of the configuration management process can involve hundreds of business decisions.

One distinct possibility to keep in mind is that you might have a multi-tiered CMDB system—that is, you might have a CMDB dedicated to each smaller domain of information such as servers, business applications, network equipment, and others. These “sub-CMDBs” could then have a much lower level of scope than is needed or wanted at the enterprise CMDB. This kind of model requires that you think about cross-CMDB relationships as well as those relationships that fit neatly within a single sub-CMDB, requiring a much more elaborate scope definition.
[Implementing ITIL Configuration Management, Larry Klosterboer, IBM 2008]