This chapter is from the book
This chapter is from the book
This chapter is from the book
Granularity
Scope and span determine which items you will track, whereas granularity determines what you'll track about each item. While scope describes the breadth of the configuration management effort, granularity describes the depth. Just like scope and span, granularity is determined by trading off the value of information against the cost of discovering and maintaining that information.
Granularity is best defined as the set of attributes you want to understand about each of your configuration items. As an example, let's assume you've decided that network hubs are part of the scope of configuration management for your organization. To determine granularity, you need to decide what information you will maintain about each network hub. Some obvious examples are the location of the hub, the person who is responsible for supporting the hub, and the serial number on the device. But perhaps there would be value in knowing other details, such as SNMP community string, the management IP address of the hub, and even the backplane speed. If these details are of importance to your organization, you would include them as part of your configuration management database. If you're never going to use them, it would be useless to include them and add extra cost and complexity to your project.
The three dimensions of your CMDB are described in this chapter in the order that you must define them. It would be very difficult to describe span without first understanding what the universe of all possible types of configuration items and relationships will be. Likewise, it is difficult to assign specific granularity before you know what the scope and span dimensions look like. Granularity is typically defined for each individual category from your scope, but often the attributes that you need will be changed by the span you've agreed on. Going back to our example of the executive workstations, if your span includes all workstations, you might want to include an attribute that indicates whether the workstation belongs to an executive. Of course, if you choose to disregard all other workstations, you wouldn't need this attribute as part of the granularity definition.
Setting the granularity is by far the most complex of the three dimensions. This section will help you understand granularity better and choose the right level of configuration granularity for your organization.
Fixed or Variable Granularity
One of the key decisions to be made is whether all configuration items will have the same attributes. If you insist that all configuration items and relationships share the same set of attributes, you've chosen a fixed granularity. If you allow the category to determine which attributes are present, you're setting up a system with variable granularity. This section describes the benefits and drawbacks of each scheme.
Fixed Granularity
Whether talking about a network router or a custom-built business application, you could store the exact same set of attributes. This is called fixed granularity, and it makes your configuration management efforts much simpler. The thought is that you can define a fixed set of attributes that is wide enough so that all configuration items can be fit into this single set. Fixed granularity is most often used by organizations very comfortable with IT asset management systems and choose to convert their asset management system into a configuration management system.
The benefit of a fixed granularity system is that data collection and maintenance are greatly simplified. You can create a single spreadsheet template and fill in every configuration item as a row using the same template. Just add another template for relationships, and you have described the complete CMDB granularity. Tool implementation, reporting, and even data collection are greatly simplified using a fixed granularity.
The drawback of fixed granularity is that you must choose between two inconvenient options for things that don't fit the model. The first option is to add extra attributes and simply make them optional. For example, you could add a CPU speed attribute, and then just leave that value empty for configuration items that represent documents or software. The other option is to store detailed configuration data in another system and simply use the CMDB as an index or card catalog to point to those external sources. This can be useful if you already have all of the configuration items documented in other tools, but you want to use a centralized configuration management system to track relationships between the CIs.
There are a couple of interesting variations on fixed granularity that attempt to achieve some of the benefits of variable granularity, but without all the costs. The first option is to define a set of "extra" attribute fields that are fixed. These fields are often called "Custom1," or "Variable1," or something similar. The intent is that these fields might have different values depending on the category of the configuration item. So if the configuration item is a server, you might use the first field for the server name and the second for the main IP address of the server. If the configuration item is a software application, you might use the first field for the software version and the second field for the type of license. This represents fixed granularity because all configuration items have the same number of attributes and the same types of attributes, but it simulates variable granularity by overloading the definition of some fields. The downside of this scheme is that anyone wishing to search on or report on the configuration data will need to know the mapping of fields to categories so they know what type of data to expect in these variable fields.
Another variation of fixed granularity is the attachment of an XML document to each configuration item record. The content of the XML document can then contain additional fields and values, which represent additional attributes that are category specific. This is really just another means of representing a variable granularity in a system that doesn't natively support variable field structures. These attached XML files really represent what you would have put in as fields given another system.
Although fixed granularity seems very logical, it is seldom practical. If you're putting effort into implementing configuration management in the first place, you've already signed up for a series of challenges. Working with variable granularity is another challenge, but one worth pursuing.
Variable Granularity
What is variable granularity and why would you want to use it? This simply means that the set of information you track differs based on the type of configuration item. So, if you're tracking a PDA, you might want to have attributes about its screen size and whether it can connect to wireless networks, but those attributes wouldn't be any part of the attribute set describing a process document. Being able to describe each type of configuration item and relationship in separate terms allows much more flexibility to store information.
Variable granularity generally is defined following the hierarchy indicated in the scope definition. Consider the very simple scope described in Figure 3.1. For all the hardware devices, you've decided you want to capture the manufacturer. But documents and software don't have a manufacturer—they have a publisher instead. So manufacturer becomes an attribute only of the hardware node. By putting manufacturer there and not at both the servers and network nodes, you don't have to repeat, and you don't have to remember it if you add additional nodes (like workstations) under hardware. You can add more specific attributes, such as an SNMP community string, to leaf nodes like network. That indicates an attribute which applies only to that specific node. In defining granularity this way, you're leveraging a very powerful capability of object-oriented programming, called inheritance. Essentially, each category or "object" inherits all the attributes from its ancestors.
)
Figure 3.1 A simple scope to illustrate variable granularity.
This brings us to the most important feature of variable granularity. Attributes defined at the top impact every category in the CMDB. In other words, if you confined yourself to defining attributes only as this top level, you would be back to a fixed granularity. But why would you?
Although the discussion of attributes is largely around CIs, don't forget that relationships can also have attributes. In a variable granularity system, different kinds of relationships might have different attributes. For example, the relationship between a server and a network might include a "how attached" attribute, whereas the relationship between a business application and a server might have a "date deployed" attribute.
The downside of variable granularity is cost. It is more complex to define which attributes will be tracked for each category. This extra complexity will be reflected directly in the cost of data gathering. Having to stop and think about what to gather based on the type of device adds significant cost to your data gathering efforts. Variable granularity will also add to the costs of implementation, maintenance, and reporting. Clearly having more data will make your project more expensive over all.
Criteria Used to Define Granularity
You have to decide whether the extra cost of variable granularity is worth the extra value earned. The following criteria apply to either fixed or variable granularity; but as you read through them, you will most likely get a picture that variable granularity is almost always worth the extra costs. But whether you use fixed granularity or variable, these criteria can be combined with your business sense to settle on the best definition of granularity for your CMDB.
Get the Essentials
The first rule is to make sure that your granularity includes the essential elements that are critical to know about each configuration item. For many organizations, this will be the candidate list for a fixed granularity. The essentials will always include a unique identifier or name for the configuration item, the status of the item, who owns the item, where the item is located, and the category of the item. Your organization might also include other essentials, such as the organizational owner of each configuration item or the support person for each configuration item. The key is to determine which pieces of information are absolutely critical for your organization to accomplish the business goals defined for configuration management.
Remember that you must also define the attributes of relationships. Beyond the two configuration items participating in the relationship, the essential attributes might include a status indicator, a date the relationship was formed, and the name of the person or system that created the relationship.
Understand the Source
After the essentials, you begin working on what other data is available. In many cases, this involves looking at many potential sources for data. Do you have an existing asset management database? If so, this is an obvious source for data. How about IT inventory systems that automatically scan for hardware and software data? That can be an excellent source for configuration information. You will need some source for information about the people in your organization so that you can capture both owner and organizational information. Understanding which sources are available helps in determining which attributes you want to track. It makes perfect sense to track attributes that have a conveniently available source. If you can't think of how you would be able to get a data element, it might be best to leave it out of your plans. This is especially true in terms of relationships. It might be great to assign a "Date updated" attribute to the relationship between a workstation and its memory, but how will you find out the installation date of the memory on all your workstations?
Know Your Needs
When considering the level of granularity you need, consider what will be needed to convey configuration management information adequately to all of your stakeholders. If nobody needs to know whether the user is right or left handed, you won't need to gather and maintain that data element. But if your organization deals with highly classified data or government contracts, you may need to know the security classification of every configuration item. Careful consideration of your data needs will lead to the correct granularity for your efforts. If you have decided that granularity does not need to be fixed, you can then make the secondary decision concerning which set of configuration items you need any given data element to cover. It might be appropriate to know the support person for every shared printer, for example, but not necessary for each process document. Build your granularity based on what is needed by your organization.
This is another reminder to look at past projects and potential future projects to help you define the CMDB. What information would have made your recent projects more successful? Where has lack of information availability put projects in jeopardy? What upcoming projects will need specific pieces of information? Questions of this type will help you think more deeply about what attributes your configuration items and relationships should have.
Balance Knowledge and Effort
After understanding the needs of your organization, you need to balance those needs with the effort required to both initially gather and later manage the information. Some pieces of information are so important that they need to be managed at any cost. Other pieces of information are so costly to maintain that they are not worth managing. Although you may not be able to avoid the need to gather and maintain security classifications for every item, you should at least be able to understand what the cost will be to keep that information. A pharmaceutical company, for example, may have IT equipment connected to laboratory devices. Because of the oversight involved in drug testing, it may be necessary to have attributes describing those connections in great detail, even if it means a physical inspection of the interface on a regular basis.
In some cases, you can make trade-offs in precision to save cost. A perfect example is location—it might be very expensive to track each configuration item down to a specific room or grid location, but much less expensive to simply assign each item to a building. Determine whether the extra cost of adding attributes for floor, room, or grid is worthwhile. Organization can be another example where tracking to the division might be easy whereas tracking down to a department level might be very difficult and thus expensive. Use your knowledge of the organization to achieve the best balance between detailed knowledge and expensive effort, and then hold the line against "feature creep" by reminding your stakeholders that you've made the decision based on cost.
Avoid Dead Weight
The tendency in configuration management systems is to include too much detail. Just because you have scanning software that can get the speed at which your hard disks spin doesn't mean that you need to store this information in the configuration management system. Avoid choosing data items that simply add mass to the CMDB without adding value to your configuration management service. Each data source should be filtered before flowing across an automated interface into the database, and those filters should be created carefully to avoid keeping data that you haven't specified. Resist the strong temptation to include data items just because you can easily discover them. Keeping this kind of dead weight in your system leaves the impression that you're running a curiosity shop for technicians rather than a business information system.
Caution: Manual Attributes
At the opposite extreme, avoid using attributes that are too difficult to maintain because the only way to keep them is with manual effort. Of course, there will be cases where the information contained in the attribute is worth maintaining. But be aware that any time you have to gather and validate data manually, you are open to a whole set of errors that are difficult to detect. All attributes that are maintained manually should be flagged as suspect, and audits of your configuration management system should pay special attention to understanding how accurately those data items are being kept.
The procedures used to maintain the manual attributes must be flawless and reviewed frequently. The single largest cause of inaccuracy in the CMDB is attributes that are maintained by some person who is supposed to be following the right procedures. You can avoid this problem altogether by minimizing the manual attributes in your granularity definition.
Documenting Granularity
While a simple tree structure is sufficient for documenting the scope of configuration management, getting all the attributes documented requires a bit more complexity. The best way to capture your granularity decisions borrows from object-oriented programming and uses a class diagram. To create an effective granularity diagram, begin with a single box at the top, and include in this box the essential attributes that all configuration items will share. Remember that an attribute definition usually includes a type, a length or maximum value, and could include some validation criteria like a set of valid values or a minimum value. At this point, you have a simple list of attributes, and if your granularity is fixed, you are finished documenting all of the attributes.
If you have opted for variable granularity, however, your work is just beginning. Next, you list all categories that will have additional attributes beyond the essentials. If this involves many categories, you probably want to use the hierarchy that you determined in analyzing scope. For each second level box, put only the attributes that are incremental—don't repeat the common attributes in each box. Also, add only those attributes that will be common to every subcategory into this second level box. Remember the principle of inheritance. Continue to define attributes at the second level until you've finished. Move down to the next level and repeat the cycle until you've completed all attributes at all levels. A useful exercise is to double check that attributes make sense by starting at the bottom of the tree and listing all the attributes of a category by working up the tree to the top. If all of those attributes make sense for the category you're looking at, you've defined a reasonable granularity.
As an example of documenting attributes, let's consider a very simple hierarchy that has a root called configuration items with branches for hardware, software, people, documents, and intangibles. Under hardware you're going to have servers, workstations, network devices, and components. You've decided that all elements will have attributes for unique ID, name, description, status, and criticality, so those attributes are listed in the box for "Configuration Items" at the root of the tree. You next decide that hardware will also have manufacturer, model, and serial number fields, so those go in the "Hardware" box. Finally, you've decided to record physical memory, number of processors, and purpose for each server, so those attributes get listed in the "Servers" box. They key to this exercise is to make sure everyone understands that for each server entered into the CMDB, the full set of attributes is the union of all 3 boxes in the tree—so the total server has 11 different attributes, not just the 3 that are specific to the server class of CIs.
Defining the overall schema for your CMDB should be an iterative exercise. As attributes are defined and documented, you might find that it is more convenient to reorganize the hierarchy, thus changing the scope slightly. This may generate some new thoughts about span, and will certainly make you think about new relationship types. Also as new classes of CIs are defined, you might want to change the attribute list of parent classes to include more detail at a higher level of the tree. In general, you'll find that pushing attributes as high up the tree as possible will simplify both data collection and data maintenance as you go forward.
Don't be afraid to let the definition of the CMDB schema take a while. In practical terms, it can run in parallel with requirements gathering, and may take just as long. Just like requirements, scope, span, and granularity are best defined by teams of stakeholders, project team members, and sponsors. Documents should be reviewed, questioned, rewritten, and reviewed again to make sure that they are accurate and your organization is comfortable with the design that is taking form.
Having a documented schema is a major step toward implementing configuration management. In documenting requirements, you defined what would be implemented; but in working through this chapter, you have begun to define how it will be implemented. You'll recognize, however, that the schema is essentially static at this point. In the next chapter, we'll work on the process and see how the process sets the static structure in motion.