Implementing ITIL Configuration Management: Determining Scope, Span, and Granularity
This chapter is from the book
This chapter is from the book
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.
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, 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."