Configuration management fits between change management and release management. It ensures that assets of the IT group are recorded, change is done with minimal risk, and data integration is maintained.
To account for all IT assets and configuration within the organization and its services. To provide accurate information on configuraiton sand their documentation to support all other service management processes. To provide a sound basis for incident management, problem management, change management, and release management. To verify configurationr ecords against the infrastructure and correct any exceptions.
Service level management and SLAs are the customer facing part of the IT department. The configuration management organizes this data and allows us to organize and present this data. This correlates to asset management and relationship management with the user community. Some companies keep asset management in spreadsheets that are used for taxes and depreciation tracking but not for asset tracking. It typically is an afterthought or something that is done once a year. This is a bad practice that is typically driven by the accounting department. It should be driven by the IT department on a daily basis, not yearly.
The configuration information should be stored in the configuration management database. It should include hardware, software, peopleware, and documentation. It should also include services and the relationships between configuration items as well as incident, problems, and known errors. It should also include a history of all changes and releases. Historically this has been kept in a journal or notebook and done in different formats based on the note keeping ability of the administrators. This format and repository needs to be standardized and centralized. Deployment of an asset management package typically does not include hooks into the help desk, request for change requests, and release announcements. It does, however, typically resolve accounting issues that upper level management has and gets funded easier than a configuration management system.
The configuration management system should have linkages into the definitive software library (typically CVS or Subversion) and the definitive hardware store (typically the enterprise management interface in the IT organization).
The first of configuration management process is planning. This should include strategy, policy, scope and objectives. It should also include processes, procedures, guidelines, and responsibilities. It also includes relationships with other ITIL processes and relationships with other parties as well as tool and resource requirements. The objectives should be simple, measurable, achievable, realistic, and timely. Many of these categories should be boilerplate items because processes, procedures, and guidelines should not change very much between projects.
The second part of configuration management is identification. It is important to define what level of detail is needed to identity an item. The level of detail is what differentiates companies from each other. Higher levels of detail requires more time and typically more cost. Less detail typically leads to differentiation of services and non-uniformity between systems. In defining relationships it typically helps to define the composition, connection, and the usage relationships. For example a workstation typically is composed of a keyboard, processor unit and monitor. It is typically connected to a network hub, network server, file server, and print server. It is typically used by a user but could be time shared at night for batch processing of jobs.
The third part of configuration management is control. The subcomponents of this is register, update, archive, and protection. When we receive new equipment, we need to register this equipment. If this equipment is changed it should be updated. For example, if we get a computer and install new memory in the system we need to register the computer and update the definition when we add memory to it. Archiving is backup of the CMDB to a backup repository and might or might not involve pruning of data as the backup is done. Protection of the data keeps changes being made to the repository without proper authorization. It also keeps the data from being stolen or corrupted.
The fourth configuration management activity is status accounting. This is reporting of all current and historical data concerned with each configuration identifier throughout its lifecycle. It helps create configuration baselines as well as analyze risk and cost that changes create in an organization.
The fifth and final element is verification. This is to verify that the data in the CMDB and make sure that it is accurate. This is typically done on a regular basis and not done once a year as is required by accounting. It is important to make sure that verification is done before equipment is moved or new software releases are made. It is also important to verify configurations after disasters since changes can be made in times of emergency and not recorded.
Change management is the next major component of ITIL. Change is the process of moving from one defined state to another. It us used to ensure that standardized methods and procesures are used for efficient and prompt handling of all changes, in order to minimize the impact of any related incidents upon service. It is responsible for implementing changes in the orgznization with the minimum of disruption. This also allows for announcements of what changes will be made, when the changes will happen, and a definition of when and where a backout plan should be implemented when problems occur. This helps maintain a good balance between the benefits of change as well as the risks associated with change. Layered on top of this is an approval process that tracks and manages change requests. It typically involves some type of review, a go-no go selection, and resource commitment before a change is begun. It typically is integrated with capacity management, availability management, and configuration management. When a change is proposed to a system it is moved from configuration management into change management. When the project is approved it is moved into the release management process so that it can be rolled out as a new configuration. The capacity and availability management systems are also integrated into change management so that existing operation parameters can be analyzed to figure out if the changes will positively or negatively impace the service.
A typical trigger that initiates change management is a request for change that comes from the service desk, problem management, or changed CIs made by engineering. New business requirements can also generate change requests. Legislation and corporate changes typically mandate change requests as well.
Changes are typically categorized as urgent, minor, significant, and major. Urgent requests are typically handled by an emergency group that handles change requests quickly. Minor changes are typically approved by a larger group and done through collaboration tools like email or shared files. Significant change requests typically require discussion and reviews of the changes. Major changes usually requires higher levels of management to get involved because it has a larger impact on the organization and typically requires more resources and assets to be involved.
Typical metrics for change management are number of changes, number of changes backed out and why, cost per change vs estimaged cost, and number of urgent changes. Other items that need to be measured are time from RFC to release, number of items reviewed by review board and items handled by change manager.
Release management is the final component of support services. This is defined as a way of taking a holistic view of a change to an IT service and ensure all aspects of a release, both technical and non technical, are considered together. It includes software, hardware, and documentation required.
Release management typically incorporates processes in the development, test, and production environments. Release management typically manages the definitive software library and definitive hardware hardware store. It is also important that the release manager be integrated with compliance checks as well as license agreements.