Home > Articles > Software Development & Management

Implementing ITIL Configuration Management: Determining Scope, Span, and Granularity

After gathering and documenting effective requirements, you have a solid foundation on which to build a configuration management system. Some of those requirements most likely deal with the data you will put into the Configuration Management Database (CMDB). This chapter explores that topic in much more depth.
This chapter is from the book

After gathering and documenting effective requirements, you have a solid foundation on which to build a configuration management system. Some of those requirements most likely deal with the data you will put into the Configuration Management Database (CMDB). This chapter explores that topic in much more depth, recommending that you look at the shape of the CMDB as a three-dimensional matrix.

The first dimension of the matrix is called scope. Scope indicates what the potential contents of the CMDB will be—that is, the categories of objects that will be included and what kinds of relationships you can capture between those categories. Scope provides the general outline of your database schema and is easiest to think of using object-oriented terms. Scope indicates the object classes that will be included.

Span is used to indicate which specific groups will be tracked within each object you've defined in the scope. We'll learn that span is a necessary dimension because there are many cases where you want to track some members of a group, but not all of them. A classic example is documentation, where you certainly want to track some very important documents as configuration items, but it would be outrageously expensive to track every single document that the information technology (IT) organization produces.

The third dimension of the matrix is called granularity. While scope indicates what will be contained, granularity determines what will be known about each configuration item or relationship. Most people relate to a computer screen, so think of the granularity as a definition of which specific fields will be on a screen whose purpose is to show a single configuration item (CI) or relationship. If you are familiar with object-oriented programming terms, the granularity indicates the attributes of each object.

We cover scope and granularity in separate sections in this chapter, and then pull together some thoughts on the entire CMDB schema at the end of the chapter.


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, and is discussed later in this chapter.

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.

Examples of Included and Excluded Scope

As a further illustration of choosing the appropriate scope, let's look at some broad categories that are most often included or excluded. This is not meant to be a comprehensive list of possibilities, but a starter list to provoke some thoughts around what is appropriate for your organization.

Musing about the scope of IT infrastructure, it is easy to come up with broad categories such as hardware, software, networks, and documents. These are all included in the scope of configuration management, but are still too broad. Under hardware, there are workstations, servers, network equipment, telephony equipment, personal devices (PDA's, cell phones, pagers), and perhaps even process control equipment. All these categories are commonly included in the scope of configuration management. In the software realm, scope probably includes categories such as operating systems, business applications, desktop productivity software, database management systems, web application server software, transaction processing middleware, and even embedded software.

Relationships categories are not as easily identifiable. In most cases, you can define the types of relationships you want to maintain by looking at the list of configuration items. Are you keeping track of operating system software? If so, you'll want a category for describing the relationship between an operating system and a computer. If you decide to track logical network concepts like IP subnets or security zones, you will want to create a category for tracking hardware relationships to those logical networks, and perhaps even the relationships between logical networks and physical network devices. Throughout this book you'll see many other ways to leverage the exciting possibilities of relationships, and this may give you ideas of categories you want to use in your own scope.

On the other hand, some items are clearly out of the scope of your configuration management system. Incident records, change records, and similar kinds of information may be stored in the same physical database as your configuration management data, but they are not configuration items in and of themselves. Likewise, many documents such as business continuity plans and change back-out plans are not configuration items, even though they likely reference configuration items. Relationships between a printer and the workstations configured to use it are an example of an association that is probably out of scope for most configuration management systems.

Perhaps the most unclear aspect of choosing scope concerns documents. One reason documentation is a difficult category is that few solid relationships to documentation can be tracked easily. ITIL is clear that documents should be referenced in the CMDB. Documents that substantively help define the IT environment should definitely be included in scope. Some examples are the document describing how to perform change management, the list of all software installed on a standard Linux® server, and the installation guide for a custom-developed business application. But it is clearly ridiculous to store every document that describes some aspect of the IT configuration. You wouldn't, for example, store the standard installation manual for Microsoft Office, but you would most likely store a document that one of your people wrote describing how to quickly roll out Microsoft Office across your network domains. Think carefully through the issues surrounding the scope of documentation and especially the relationships you want to define for documents.

Another often-debated area of configuration management is the role of people and organizations. Some organizations choose to manage these expensive IT resources just like any other resource and thus decide that people and organizations are two of the categories which are part of the scope of configuration management. Others decide that the intricate relationships between people, organizations, and IT are best managed in a dedicated human resource system and would be too costly to also try to track in the IT configuration management system. There are advantages and disadvantages to both approaches, so the decision is never an easy one. Follow the guidelines in the next section to make the best decision for your organization.

Complex decisions clearly must be made around the scope of configuration management. Rather than proscribe exactly what should be in your CMDB, I'll provide a set of guidelines you can use as you make these decisions. By starting with the model proposed by the DMTF and following the outlined criteria, you can establish a scope that will be perfect for your organization.

Criteria Used to Determine Scope

You can use the following criteria to determine the scope of configuration management for your organization. Like all criteria, they must be used with a good knowledge of how your organization works and a dose of common sense. But used correctly, they can help guide you to a good scope for your CMDB.

Start Simple

As with most complex problems, the way to start is the simplest way possible. Simplicity of scope typically involves going after those things that can be quickly learned and easily maintained. If you already have an IT asset management system, for example, you probably have existing processes for gathering and maintaining asset data. Use the same scope for your configuration management efforts, even though in the long run asset management and configuration management serve different purposes. Simplicity might also be geographic, involving only one or two of your locations in the initial scope.

This guideline of simplicity also can be applied to the depth of your coverage. For example, you might want to include business applications that you've developed yourself in the CMDB. That's a good, simple thing to do. But undoubtedly some of these applications consist of a back-end database component, a web or other presentation component, and maybe an application layer component. Tracking each application as a single entity simplifies both the configuration item scope and the set of relationships that must be created, but your approach needs to be balanced between simplicity and the needs of the organization. One of my favorite sayings is "Keep it as simple as possible—but no simpler!"

Consider the Cost

As illustrated earlier, the scope of configuration management should be determined largely by what you can afford to manage and what you can afford to ignore. On one end of this spectrum is mainframe equipment, which is relatively expensive and changes only after very careful deliberation. In almost all cases, this is well worth tracking. On the other end of the spectrum are cell phones, which are relatively inexpensive and very difficult to keep track of. This is not to say that cell phones cannot be part of your configuration management scope—just that you would want to have a very strong reason to expend the energy and money to keep track of them.

Remember that the cost of managing a configuration item over its lifetime is almost always more than the cost of gathering information about it in the first place. What drives up the cost is the degree to which the relationships change. It is amazing that the actual CIs don't change very often, but it sometimes seems that the relationships can change daily. As you develop your scope, consider the relationship model carefully and be sure that you don't add relationships that would be nice to have but will also be very expensive (or technically impossible) to maintain.

Score Easy Victories

Much of the success of your configuration management effort will be determined by how much confidence your entire organization puts in the database. Choose your scope in order to build confidence early. Include only those items you can track with a high degree of certainty, and leave out those things you are less sure of. Adding data to your scope that just ends up being incorrect later will bring your entire project under suspicion. It is possible to institute processes and tools that improve the quality of data, but consider how effective those are likely to be and how much extra risk your project must manage to put that extra process and tooling into place. If you decide the risk is worth managing (based on other criteria here), then go ahead and include the scope; but if not, then leave out the risky parts of the scope. The entire configuration management program can be killed if data is incorrect early on, so you may not get a chance to recover later.

After you've begun to track configuration items and their relationships, you should ruthlessly eliminate other sources of that information. This may seem like strange information, but experience shows that information stored in two separate places is automatically assumed to be incorrect in both of them. Your entire organization will begin to depend on the configuration management database only if they see it has content nobody else can give them. This isn't to say you should dismantle genuinely useful systems like your asset management database or software license management servers, but as part of your scope decision you should carefully consider whether you are setting up duplicate sources for the same records. You can often score a quick victory by simply referencing those other data sources rather than replicating their full content.

Look Ahead to Value

In thinking about the scope of your efforts, consider the future value of having accurate information. Experience shows that there is a class of IT projects which fail for lack of accurate information. Look forward to projects your organization is likely to tackle in the near future, and structure your configuration management database to provide the information that will be needed. Are you going to consolidate servers? Servers should be a key category in your configuration management scope. Need to roll out the next desktop operating system? Then make sure desktop systems and their current operating system are in your configuration management system. Ultimately every element you add to the scope of the database should be driven by some business value you can gain by tracking that element.

Of course, it is impossible to predict every possible need for information in the future, but it is remarkable how often looking at past projects will reveal a pattern of missing data. Think just of the large IT projects your organization has conducted in the past two years, whether those were successful or not. How many of them would have cost less or been done faster if accurate data had been available at the onset? Thinking along this line will often reveal some very obvious additions to your scope, which will add significant value to future projects.

Reduce Your Risk

Configuration management systems fail because of erroneous data. The best scope for configuration management is one that reduces the risk of errors. It is critical to plan ahead for not only how you will gather the data on all items within your scope, but how you will manage that data. Proper management involves accounting for all changes to the configuration item, whether they are planned or unplanned. You must consider carefully what will happen as configuration items break, are retired from service, are enhanced, become obsolete, and many other things that can happen to technology. Remember that each of those events is more than a simple change to one record—all of the relationships involved need to be changed as well, and this could be extensive. The more completely you have planned for every possible event in the lifecycle of your configuration items, the lower will be your risk of erroneous data. Similarly, if there are lifecycle events that you know you'll never be able to track, you will want to think twice about attempting to manage the CIs that participate in those events. For example, maybe your management team interacts directly with a supplier to request the latest model of cellular phone whenever they like. You would have no chance of tracking which phones are in your organization or which person has which phone. If that is your situation, simply don't include cell phones in your scope.

Expand Slowly

Your initial scope will not be your final scope. This shouldn't discourage you from carefully considering your scope at the beginning of your effort to implement configuration management, but it should make you realize it doesn't need to be perfect. As your configuration management efforts mature and prove their worth, you will want to expand your scope to cover a broader range of IT infrastructure. If the value is proven, it should be easy to get additional funding to implement additional processes and tools to expand to a wider scope.

Please be aware, however, that you can jeopardize your initial success if your scope outpaces the maturity of your process. Consider again the criteria provided in this section and decide which items are prudent to allow into your scope, and which ones you're still not ready to tackle. Slow and steady growth will increase your business value and keep your risk to a manageable level.

Documenting Scope

All the thought involved in determining the scope of configuration management needs to be captured somewhere. You could simply take a piece of paper and try to write out every decision you've made and why you made it. But by far the best way to document the scope is to create something that will be needed later anyway—a category structure.

The category structure is simply a hierarchical way to organize all the elements that will be included in the scope of your configuration management efforts. Start at the top with a broad category like "IT Infrastructure" or "ABC Company IT Environment." Then break that into discrete pieces that make sense given the scope you've chosen. For most people, hardware, software, and documentation will be categories at this first level. There may be others like "networks" or "telephony." Continue down the structure, going to as much detail as you've determined you need. When you've run out of new subcategories and levels to create, you'll have two very important items—the complete scope of your configuration management system and the "authoritative" name of each kind of configuration item. This set of categories will serve as the basis for working with and reporting on your configuration management system, so it is worth taking some time to consider what the categories will be and what they will be called.

As much as possible, use terms that your organization will be familiar with. If you routinely group your servers into midrange and mainframe servers, don't get formal now and call them Complex Instruction Set and Reduced Instruction Set computers in your hierarchy. On the other hand, if there is confusion among different groups or business units in your organization, try to use a name that everyone will relate to. The name will show up in change and incident tickets, reports, and of course the configuration management database itself, so make them as usable as possible. If you've adopted the CIM, you'll find that you already have the hierarchy defined. You simply need to make sure that you keep all of the parent classes to every child that you've adopted in your model.

In your scope document, draw the categorization hierarchy using a drawing tool, and then describe each class that you intend people to use. Where confusion will be possible, give explicit instructions such as "This category is for network routers that operate at network layer 3. For switches and other devices that operate at layer 2, use the network hub category." Most implementation projects choose to document the scope, span, and granularity together in a single document called the "Configuration Management Plan" or the "CMDB Schema."

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020