Process 1: Baseline the Configuration

  • Article

Published: April 25, 2008   |   Updated: October 10, 2008

 

As you begin the process of initiating and implementing a change, your first process should be to baseline the configuration so that the starting configuration is known. This baseline may be needed for rollback, disaster recovery, and understanding the impact of the proposed change.

Cc543241.image3(en-us,TechNet.10).jpg

Figure 3. Baseline the configuration

Activities: Baseline the Configuration

In order to successfully manage change, an organization must also manage the configuration of the production environment. The most effective way to do this is to baseline the configuration before and after each change.

A configuration baseline is a snapshot of the IT environment that identifies its structure and underlying dependencies. The data from this snapshot should be captured and recorded in a configuration management system (CMS). A CMS can be as simple as a spreadsheet or as complex as an integrated set of tools that includes a database.

A CMS provides:

  • A way to understand, control, and predict the consequences of change.
  • An accurate and comprehensive representation of the state of the production environment.
  • A history of previous states to support efforts to analyze and remedy problems.

IT professionals can use the CMS throughout the change process by:

  • Reviewing it as part of evaluating a new request for change (RFC) in order to understand the impact of the proposed change.
  • Updating it with approved RFCs so that this knowledge can be used in evaluating other RFCs.
  • Updating it with released changes so that this knowledge can be used in troubleshooting any problems that arise after the change.
  • Using it to confirm a known good state for rolling back any changes that have unexpected negative impacts.

A CMS contains information about configuration items (CIs), which are IT components that are important in understanding the state of the production environment. Each CI may be composed of other CIs and can vary widely in complexity, size, and type—from an entire system (including all hardware, software, and documentation) to a single software module or a minor hardware component. All versions of software CIs that the change advisory board (CAB) has approved for deployment should be contained in their definitive, quality-controlled form in a definitive software library (DSL). This is a secure software library that provides a known good source of the software used in production.

Baselining configuration can be a major undertaking. One option is to baseline as you make changes so that eventually the entire production configuration is known.

The following table lists the activities involved in baselining the configuration. These include:

  • Defining and collecting the configuration data to track in the CMS each time a new type of CI is added to the configuration.
  • Auditing the CMS content.

Table 4. Activities and Considerations for Baselining the Configuration

Activities

Considerations

Define and collect the configuration data to track in the CMS

 

Key questions:

  • What information should be captured?
  • Which users need access to service and/or system component information?
  • In what format would the information be most useful to each user?
  • Does any information in the CMS need to have restricted access?
  • How often does data need to be updated?
  • How will this data be used?

Inputs:

Best practices:

  • Define both business (services interdependencies) and technical (system components) use of data.
  • To obtain the most complete idea of needs, involve all relevant people in assessment and planning. This group might include individuals from Solution Development, Enterprise Architecture, Operations, Service Desk, and the business.
  • Start by tracking as little data as possible, and add more as needed. Keeping configuration records up-to-date takes resources. Be sure the return on the additional data collected is worthwhile. Know why you are tracking the data you are tracking.
  • When you add a new type of CI, re-evaluate the configuration data to be tracked.

Audit the CMS content

Key questions:

  • Are audits mandated by regulatory compliance requirements or policy? How often should audits be done?
  • How will CMS information be confirmed? Who will confirm it?
  • Will access restrictions need to be enforced?

Inputs:

  • CMS
  • Access restriction requirements
  • Policy and regulatory requirements
  • Production environment

Outputs:

  • Current state accuracy report
  • Remediation plans for inaccuracies

Best practices:

  • Don’t let your CMS go too long between audits. Smaller corrections are much easier to do than larger remediations.
  • If the CMS frequently gets out of date, consider your processes and adjust them to improve accuracy.