CHAPTER 4. Customizing the Configuration Management Process
In a configuration management project, you can easily focus on data, schemas, tools, and techniques, but forget the most important piece of the foundation—the process work. By process, I mean the documented set of defined inputs, workflows, and specific outputs for each activity involved in the configuration management program. The configuration management process must define how the data will be gathered, and more importantly, how it will be maintained accurately. Tools will sit idle if the process does not define when and how they are to be used. Organizations will be inefficient if they don’t have a reliable process to follow. Every organization has a configuration management process of some kind, but if you don’t consciously customize and document it, your organization is not likely to have an effective process.
I haven’t always been a process zealot. My career started as a technology person, so I was much more comfortable deploying tools and letting others worry about process. It’s actually much easier to simply configure the latest tool and put it into place.
Of course, I kept getting frustrated when people told me the tools were too hard to use or didn’t accomplish the whole job. And every time we deployed a tool, the support costs were more than double what we projected they should be.
The reason, of course, is that tools can automate only a known process. By ignoring the process, I was implementing tools without context and causing people to find their own way to make sense of what I had given them. A tool deployment will be successful only within the overall context of a business process.
Although the IT Infrastructure Library (ITIL) does provide guidance, it does not contain a complete configuration management process. Instead, it gives you a set of categories that you can use as a framework to build a process. This is more than a semantic distinction—those looking to directly implement the ITIL process will be disappointed. The outline provided by the library is extremely useful, however, because it provides the groundwork which ensures that the process definition will be complete and in line with the best practices of those who have gone before.
It is important as we work through this chapter that you realize your process work will mature along with the rest of the configuration management program. You don’t need to develop a perfect process as part of your first project, but you do need to have a complete process. This is where the ITIL guidance can be extremely helpful to ensure that you haven’t skipped anything others have discovered shouldn’t be skipped.
This chapter describes how to use the standard framework to customize a complete configuration management process that will work for your organization. We look at some of the issues likely to come up in your process engineering efforts and describe ways to make your process fit the business goals of your organization.
The Standard ITIL Framework
Figure 4.1 depicts the standard ITIL configuration management framework. ITIL doesn’t provide a beginning-to-end flow of activities, but rather a set of coordinated tasks that happen mostly at the same time. For example, you don’t identify configuration items (CIs) and then move on to controlling them. Instead, you begin controlling as soon as a CI is identified, and you continue to identify new CIs as they become part of your information technology (IT) environment. Each step gets revisited as your environment changes. These steps are not specifically called a process. That would imply you could pick up the ITIL books and follow them directly. Instead, the steps tell you what elements should be in the process without specifying exactly what that process must be. The phrase often heard in service management circles is “descriptive but not proscriptive.”
Figure 4.1. ITIL provides an outline of the configuration management process.
Planning
The first pillar in the ITIL process framework is planning. Planning always starts the configuration management process, but good planning never ends. Key elements of planning include determining your scope and granularity, customizing your process, determining your project parameters and requirements, and all the other steps described in Part I of this book. Planning should result in a document called the configuration management plan. You know you are ready to move past the planning phase of the process when you have version one of that document approved. You should expect that over time, however, you will be generating many follow-up versions. In all cases, be open to changes in the plan as you implement and operate your configuration management service.
Don’t confuse configuration management planning with project planning. It is quite likely that you will implement configuration management in several steps or phases, each of which will require a project plan. Regardless of the number of projects that get run, however, you will have only one configuration management plan. As described in Chapter 3, “Determining Scope, Span, and Granularity,” this is the document that defines the scope, span, and granularity of your Configuration Management Database (CMDB). Each subsequent project might impact the one configuration management plan, but only before the first project commences do you actually create this document. If you create an overall roadmap, indicating a set of projects that will be used to implement the complete configuration management service, it is wise to hold the milestones of that roadmap in your configuration management plan.
Planning is not a one-time activity, either. Although you certainly must have a configuration management plan early on, it should be maintained as a living document throughout the life of your overall program. Changes to span happen as new phases occur. Changes to granularity and scope can happen as new requirements are identified. You should be sure to include in your process work a process for updating the configuration management plan in an ongoing way.
Identifying Configuration Items
The second part of the configuration management process is always identification of CIs and the relationships between them. Just as you can’t identify anything without a plan, you can’t control what hasn’t been identified yet. Depending on the data sources your organization already has at hand, this identification process could be very complex and lengthy, or just moderately complex. If you already have a strong inventory or asset management system with reliable data, that will jump-start the identification of CIs. Remember, however, that documentation, processes, and standards might well be part of your scope for configuration management and probably will not be part of an existing inventory system.
While it seems like completing one pass across your organization will complete the activities required to identify CIs, this isn’t true. New technologies will continue to be acquired, new documents to be written, and whole new categories of things might be added. Identification of specific CIs will be an ongoing activity, and the processes that you define for identification should never assume they will be used only once.
Controlling Configurations
By far the most important part of the standard ITIL configuration management framework involves putting adequate controls in place. Controls are like fences that keep your data between the boundaries of accuracy you’ve set—the more fences you have, the better your accuracy and the more you’ll work at maintaining the fences. These fences might be dictated by external regulatory groups, your organization’s business rules, or just common sense. But in any event, they will provide a degree of control over what can and cannot be done with CIs.
The control part of the process is where you’ll be doing the most customization because the controls that might be adequate for another organization probably won’t fit yours. Defining and implementing adequate controls requires maturity, so don’t worry about being perfect at the start. As your organization better understands and leverages configuration management information, your set of controls can be refined to strike the right balance between being too restrictive and too lax. The most common way to tell if your controls are adequate is by using the results of an audit process, another key element of the best practice framework.
As an example of a control mechanism that might be documented in your process work, think of the interaction of the service desk with the CMDB. You might, for example, define a control procedure that provides for the service desk to validate the workstation configuration whenever a user calls. The procedure would cover how to do that validation, and what steps to take if a discrepancy is found. Documenting controls such as this will help to keep the data in your CMDB accurate.
Status Tracking
The next area ITIL describes is tracking the status of configuration items. Most organizations that have considered the topic have some notion of the lifecycle for an asset. The lifecycle normally begins with acquisition, and goes through testing, installation, operations, maintenance, decommissioning, and disposal. Each phase represents a value in the status attribute of the CI. The set of status values you use for configuration management will be somewhat narrower than those for asset management because you’re not concerned with what comes before deploying something into the production environment. You probably already have a process for promoting software into production, for example, but as part of the configuration management process set you’ll want to define where in that process the CMDB gets updated with the new version. The status accounting set of process elements helps your organization understand and implement the steps needed when a CI moves from one state to another, and normally are interlocked closely with the control processes.
Versions are very important in accounting for the status of CIs. Unfortunately, this is a somewhat vague concept in the ITIL documentation. You want to document a policy that describes exactly which changes create a new version of a CI and which create a brand new item. For example, if you replace the system board of a computer, have you created a different version of that computer that can be tracked by the same CI? Or, by replacing the system board, have you created a completely different CI? Your policies dictate which case prevails for your organization.
Auditing
Inaccuracy is a death knell for a CMDB. There is no measurement quite as important for the configuration management service as the accuracy of the database. Because of the importance of accuracy, a set of procedures to audit your CMDB is critical. The procedures should document the following:
- How often audits will occur
- How the set of data being audited will be selected
- What data will be compared for the audit
- How discrepancies will be resolved
- How you will know when an audit is completed
In a sense, the audit steps are the last in the overall configuration management process because they validate that the other parts of the process are working well. But never let the audit steps be the least steps in your process, or you run the risk of executing the other steps to no purpose.
Auditing typically is done by comparing two things. One of the critical policies you need to define sets the scope for this comparison. Assume that you are tracking documents in your CMDB, and the document CI has attributes for version, author, and date of last update. In conducting a CMDB audit, you look at the actual document in a word processor and find that the author name listed in the document is different from the value in the author attribute of your CMDB. Your policy dictates whether this is an inaccuracy, and if so, what the severity of the error is.
The five pillars of the ITIL process framework are planning, identification, control, tracking, and auditing. If your desire is to implement configuration management that is in accord with the best practices defined by ITIL, you need to document processes in each of these areas. The rest of this chapter describes specific issues to consider in building out your processes.
Common Process Customizations
As we’ve seen, there really is no “out-of-the-box” ITIL process. Everyone must build a process, and the library offers advice on what areas the process should cover. But building the process can be confusing because configuration management represents a new way of thinking for many people and because the configuration management discipline intersects with so many other process areas. The following paragraphs describe some of the facets of the process and the most common procedures that need to be considered and documented.
Top Down Process
Good process engineers normally work from the top level of detail down to the bottom. They start with a single flow that describes the entire set of process steps, albeit at a very high level. Then each nontrivial step is defined in a more detailed flow, which may also include steps that are still too high level to be practical. The exercise continues until each process step at the lowest level can be accomplished by a single person in a reasonable amount of time.
At a top level, the process includes the five areas provided by ITIL and described in the previous section. It isn’t necessary, however, to follow the ITIL guidance slavishly. If your organization is just beginning to explore and deploy configuration management, it might make more sense for your high-level process to combine control and status tracking into one top-level process. These two areas are so intertwined that the distinctions might wait until later. You also might want to use different names in some of the areas to relate better to your organization. For example, many organizations use “configuration discovery” instead of configuration identification. At the very minimum, you need to create a single top-level process document that captures the end-to-end scope of your configuration management process.
Planning Procedures
Inside the planning set of processes, there are many lower-level procedures that must be defined for your organization. While defining the schema may seem like a one-time event, you want to document a procedure that can be used for considering changes to the schema. These procedures should include both adding content and retiring pieces of the schema that are no longer used. The planning process set should also include policies that document naming conventions and other data standards because consistency of data greatly enhances accuracy. At a minimum, you should document how CIs will be uniquely identified. It also makes sense to include a general change-control mechanism for changing policies, standards, and procedures in the future. The following list indicates some of the procedures you should document as part of this first process area:
Potential Procedures to Document for Planning
Manage configuration management plan changes
Naming standard for configuration items
Standard values for key attributes
Procedures for CI Identification
If your organization already has inventory management practices in place for your IT environment, you already have most of the procedures defined for identifying configurations. If not, it is critical to define how data will be collected, and especially how disparate sources will be reconciled. One of the most difficult pieces in inventory management or configuration management is to marry the correct demographic data, such as user name, location, organizational ownership, and asset tag number, with the technical data, such as CPU speed, installed software, and network address. Consider carefully where each piece of data is coming from and how to match it up with data from other sources. Don’t forget to document how disputes will be handled when different systems store contradictory data.
The most challenging procedures in configuration identification are not identifying the actual CIs, but in discovering and documenting the relationships between those CIs. How will you capture which applications run on which servers or which servers sit on which network segments? Your procedures should document who is responsible for discovery of each type of relationship, and how those relationships will be captured and maintained.
Potential Procedures for Identification of Configuration Items
Identifying computer workstations
Importing data from a scanning tool
Preparing for and conducting a wall-to-wall inventory at a site
Conducting a data center inventory
Registering application CIs as part of the development cycle
Creating a policy for registering documents as configuration items
Establishing relationships in the workstation space
Establishing relationships in the data center space
Establishing relationships in the network space
Procedures for Control of CIs
By far the majority of your process customizations will occur in the area of controlling CIs. This is where the integration with change management comes into play in determining when the CMDB gets updates as the result of each enterprise change. But you will quickly discover that control is a matter of considering every exception. Most organizations begin with the notion that every CMDB update must happen as a result of an enterprise change record. Unfortunately, there is some level of change, either explicitly documented or tacitly understood, that your organization doesn’t choose to capture in a request for change.
For example, many implementations of configuration management choose to associate a person with each hardware device as the owner or administrator of that device. When that person leaves the organization, the association needs to be updated, but seldom is an enterprise change record used. To cover situations where enterprise change doesn’t reach, you need to define procedures for administrative updates of the CMDB. You also might want to consider special controls for project work where hundreds of configurations are being changed as part of a coordinated roll out. If your organization is medium to large size, you also need procedures for “discovered” configurations—things that have been running in production for a while, but which someone just noticed are not part of the CMDB. The control procedures will be the most volatile set for most beginning configuration management programs.
Potential Control Procedures
Integration of configuration management with change control
Administrative updates to the CMDB
CMDB usage in a compliance audit
Standards of access to CMDB data
Discovery of unregistered configuration items
Handling registration errors in configuration data
Status Tracking Procedures
Status accounting procedures are perhaps the most simple. Here you document the set of statuses that are possible and define procedures for transitions from one status to another. For example, what is the effect on your CMDB when an application moves from development to test and from test to production? Do you choose to ignore the development and test environments because they are not part of your production environment? If so, you can simplify your status accounting for applications, but you need a more robust procedure for promoting that application into production. What about decommissioning servers? You need to define which statuses are “terminal” in the sense that you expect CIs in that status to no longer participate in enterprise changes or incidents. CIs in a terminal status normally can be archived after some defined retention period, and those procedures must be defined in this category.
Potential Procedures to Track CI Status
Definition of CI lifecycle
Procedure for managing relationships at each lifecycle change
Managing versions of a CI
Recording and using CI history
Audit Procedures
In the audit and validation category are all those procedures about how to verify the accuracy of the CMDB. This could include cross checks between the inventory discovery tools and the CMDB. It might include a physical inventory of some part of your organization compared against the CMDB representation of that same group. The procedures for audit should include how a sample set is selected, how people will be notified of the audit and their responsibilities, how audit data is to be collected, what criteria will be used to conduct the audit, how discrepancies in the data will be identified and recorded, how those discrepancies will be resolved, and how the results of the audit will be published. In addition to formal audits, there is great opportunity to validate configuration data within other process areas as that data is needed. For example, service desk agents could ask callers to read the asset tag on their workstation while the agent validates that the tag is the same as found in the CMDB. Release managers could validate that the architecture of an application is consistent with the CMDB representation of that application. All these procedures should be customized as part of the configuration management effort.
Potential Procedures for Auditing the CMDB
Frequency of CMDB audits
How to select an auditable sample
Criteria to be used to determine sample accuracy
Handling discrepancies discovered in audits
Reporting on audit outcomes
Return audits and handling of repeated failures
Modifying the Process to Fit Business Goals
While working methodically through the process customizations that must be done, it is very easy to forget the purpose of the customizations. Remember that the entire purpose of configuration management is to help the business make better decisions. With this in mind, let’s consider some possible goals of the business and how you can accommodate those goals by modifications to the configuration management process. Of course, which of these you actually use will depend heavily on the requirements you documented for your project.
Perhaps your organization is interested in deciding whether to continue building custom applications or to invest in an off-the-shelf solution such as SAP or Siebel. To help make those kinds of decisions, you want to focus your procedure work on areas that will help make better decisions about business applications. Your planning procedure should consider where in the development cycle the architecture of the application will be captured as a set of configuration items. In the identification procedures, you want to carefully consider the linkage between your source code control system (often called the software configuration management system) and your ITIL-based configuration management tool. You should plan on accounting for the status changes between versions and how to handle major releases and maintenance releases. Your auditing procedures can have special emphasis on ensuring that the proper relationships are maintained between business applications and their component pieces. All of these customizations will help answer questions about the cost and capability of current applications to help make better investment decisions.
By focusing specifically on the areas of the process that most impact application development, you will be able to gather data on the business applications and their entry into production. By mixing this with project management data from the development projects, you should get a very clear picture of the impact that development of your own applications is having on the overall IT environment.
On the other hand, perhaps your organization is interested in ensuring availability of your infrastructure and eliminating single points of failure. Then your planning procedures are likely to include how to get accurate data from network and server discovery tools into the CMDB. You definitely want to customize controls that tie service continuity testing results to CMDB accuracy. To focus on eliminating points of failure, you want your audit system to frequently validate the technical, discovered data about your environment to its representation in the CMDB. This kind of process focus will give your organization the information it needs to make better availability plans and to respond to outages that detract from overall availability.
Perhaps your organization is worried about software licensing and wants to make sure that you haven’t purchased too few (or too many) licenses for your needs. To accomplish this business goal, you can customize the configuration management procedures to focus on ways to help make these decisions. Your procedures for identifying configurations should include great detail on keeping track of each individual license, while your procedures for control should show the strong tie between purchase and deployment of licenses and include details about what to do about downloaded software. Your audit procedures should focus on comparing the software loads of servers and workstations with the configurations that have been recorded in the CMDB. By doing so, you can control the actual licenses used in your environment so that you can compare them with data from asset management on the purchases that have been made.
There are probably a hundred such scenarios. Each scenario shows how you choose to focus your process customizations on areas that are of interest to your business. The key lesson here is that although it’s a noble idea to build a general process that will cover all of configuration management equally well, the reality is that projects get funded if they meet business goals. You can help to achieve the goals of your sponsor and stakeholders with the emphasis you place in your process efforts.
Of course, it would be rare to implement your configuration management service focusing on just a single business need. In most cases, you will have multiple points of emphasis to help guide your process customization. Your requirement set should help guide you to the process areas that need the most customization. If you don’t have enough requirements to indicate which process areas need the most work, go back and interview more business leaders and update your requirements appropriately. Don’t stop working on getting more process definition (and requirements, if needed) until you see a strong indication that you are going to meet business needs and not just have a process because ITIL says you should have one.
The Appropriate Level of Process Detail
Interestingly enough, one of the most difficult parts of process customization is deciding when to stop. Stopping too early will leave your configuration management team confused and without sufficient direction or consistency to perform their jobs well. But the opposite extreme is also possible—too much process and procedure detail can be stifling and cause your team too much “busywork” and limit their creativity and skill. Experience shows that defining the process to the lowest possible level of detail wastes money and discourages the IT professionals who must follow those processes. This section considers this important question of “how much is too much.”
One rule of thumb for process customization is that you need to leave room for tool user guides. If your procedure says things like “fill in field A,” “press button B,” or “scroll to tab C,” then you’ve gotten too detailed. You should rewrite the procedure to be more business related with instruction like “fill out the CMDB update form.” Try to keep the procedures at the level of business activities without getting into exactly how those activities would be accomplished with a specific tool. A good test is to ask how much the procedures would have to change if you switched to a different tool set. If you find that the procedure would need to be mostly rewritten, it is probably too detailed. The difference between procedures and tool user guides may seem irrelevant, particularly if the same people in your project team are responsible for writing both kinds of documentation. But the more you can isolate the tools from the procedures, the more ready you’ll be when you change tools, or even upgrade to the next release. By keeping the procedures separate, you also allow improvements to be made to the process and procedures without having to rewrite a lot of tedious tool-oriented documentation.
The guiding principle at the other end of the spectrum is that each procedure should get consistent results despite who is executing it. If the procedure leaves room for different outputs from different people, it is too vague or general. The entire purpose of documenting a procedure is to ensure that the best practices and corporate knowledge that your most skilled people apply to their work can be used by the newest members of the team. If you find that two different people can do their best to follow the procedure, but end up at different places, you have not yet finished customization in that area. Further detail should be added to the procedure to ensure consistent outputs are defined and that the steps in the procedure lead regularly to those outputs. It should never be left to the imagination of your staff to decide what the outcome of a procedure should be, or you will have disconnects between the end of one procedure step and the beginning of the next, leading to inefficiencies in work and inconsistencies in the resulting data.
One more general rule is that procedures aren’t finished if they are too costly to implement. Consider, for example, a control procedure which dictates that every configuration database update requires a separate request for change. This might seem like a good level of detail until you try to implement the procedure and realize the volume of Requests for Change (RFCs) demanded will quickly overwhelm the change management process. Reworking change management to accommodate this detailed configuration management would most likely prove to be costly. A more detailed configuration management procedure might help determine the correct times to match up with an RFC and when it is appropriate to make an administrative update to the CMDB without a corresponding change record. Process customization shouldn’t end if some of the process or procedure steps are too costly to implement. Instead, keep working on finding different, more efficient ways of doing things until the implementation and execution of the process are optimized.
The best way to understand when the configuration management procedures are finished is to evaluate the business value of the procedures. When the set of procedures is sufficient to get the work accomplished, and detailed enough to accomplish all tasks consistently, stop refining them. Further refinement will cost more money to accomplish without really adding more value to the service you can provide. Remember that process improvements are always possible, but not every improvement will turn out to add significant value. As the organization matures in its understanding and execution of configuration management, you’ll be in a much better position to determine which process customizations will add more value.
Of course, the process work is much like every other part of the configuration management project—it will get perfected through a series of projects as your organization matures. Keep track of process versions, and make additional improvements as business needs dictate. Changes should never be made just for change sake, but when significant new business value can be added, don’t be afraid to produce a new version of the processes and procedures. This is another reason to keep the process documentation separate from the tool documentation. Not every project will need to improve both at once.
By following the ITIL framework of planning, identification, control, tracking, and auditing, you can ensure that your configuration management process will be complete. By driving down to the appropriate level of detail, you can be sure your process work will be effective. In achieving a complete and effective process, you have the information you need to educate your organization and begin managing your configuration items and relationships. Although process work is not usually the favorite activity for IT people, it should not be omitted or slighted in any way. The process truly allows the organization to be successful—without it, no one will be able to accomplish their role effectively.