1Introduction | 2Serv. Mgmt. | 3Principles | 4Processes | 5Activities | 6Organization | 7Consideration | 8Implementation | 9Issues | AAppendeces |
![]() | 4.1PLAN/SUPPORT | 4.2CHANGE | 4.3ASSET/CONFIG | 4.4RELEASE/DEPLOY | 4.5 VALIDATE/TEST | 4.6EVALUATE | 4.7KNOWLEDGE | ![]() |
The goals of Configuration Management are to:
The objective is to define and control the components of services and infrastructure and maintain accurate configuration information on the historical, planned and current state of the services and infrastructure.
Configuration Management ensures that selected components of a complete service, system or product (the configuration) are identified, baselined and maintained and that changes to them are controlled. It also ensures that releases into controlled environments and operational use are done on the basis of formal approvals. It provides a configuration model of the services, assets and infrastructure by recording the relationships between service assets and configuration items. SACM may cover non-IT assets, work products used to develop the services and configuration items required to support the service that are not formally classified as assets.
The scope covers interfaces to internal and external service providers where there are assets and configuration items that need to be controlled, e.g. shared assets.
SACM provides visibility of accurate representations of a service, release, or environment that enables:
Asset policies may be applicable for specific asset types or services, e.g. desktop. There are significant costs and resources implications to implementing SACM and therefore strategic decisions need to be made about the priorities to be addressed. Many IT service providers focus initially on the basic IT assets (hardware and software) and the services and assets that are business critical or covered by legal and regulatory compliance, e.g. Sarbanes-Oxley, software licensing.
Service Asset and Configuration Management principles
The main policy sets out the framework and key principles against which assets and configurations are developed and maintained. Typical principles include:
![]() |
Figure 4.7 Example of a logical configuraiton model |
Configuration Management delivers a model of the services, assets and the infrastructure by recording the relationships between configuration items as shown in Figure 4.7. This enables other processes to access valuable information, e.g.:
The real power of Configuration Management's logical model of the services and infrastructure is that it is THE model - a single common representation used by all parts of IT Service Management, and beyond, such as HR, finance, supplier and customers.
'Danish clock' There is a traditional Danish proverb that runs 'When you have a clock in your house, you know the time - once you get two clocks you are no longer certain.' SACM delivers that one clock for all processes and so glues them together, delivers consistency and helps achieve common purpose. (From Hans Dithmar) |
The configuration items and related configuration information can be at varying levels of detail, e.g. an overview of all the services or a detailed level to view the specification for a service component. Configuration Management should be applied at a more detailed level where the service provider requires tight control, traceability and tight coupling of configuration information through the service lifecycle.
Configuration Items
A configuration item (CI) is an asset, service component or other item that is, or will be, under the control of Configuration Management. Configuration items may vary widely in complexity, size and type, ranging from an entire service or system including all hardware, software, documentation and support staff to a single software module or a minor hardware component. Configuration items may be grouped and managed together, e.g. a set of components may be grouped into a release. Configuration items should be selected using established selection criteria, grouped, classified and identified in such a way that they are manageable and traceable throughout the service lifecycle.
There will be a variety of CIs; the following categories may help to identify them.
![]() |
Figure 4.8 Example of a Configuration Management System |
To manage large and complex IT services and infrastructures, Service Asset and Configuration Management requires the use of a supporting system known as the Configuration Management System (CMS).
The CMS holds all the information for CIs within the designated scope. Some of these items will have related specifications or files that contain the contents of the item e.g. software, document or photograph. For example, a Service Cl will include the details such as supplier, cost, purchase date and renewal date for licences and maintenance contracts and the related documentation such as SLAs and underpinning contracts.
The CMS is also used a for wide range of purposes, for example asset data held in the CMS may be made available to external financial Asset Management systems to perform specific Asset Management processes reporting outside of Configuration Management.
The CMS maintains the relationships between all service components and any related incidents, problems, known errors, change and release documentation and may also contain corporate data about employees, suppliers, locations and business units, customers and users.
Figure 4.8 shows how the CMS covers the data and information layers of the knowledge/information/ knowledge hierarchy explained in section 4.7, Knowledge Management. At the data level, the CMS may take data from several physical CMDBs, which together constitute a federated CMDB. Other data sources will also plug into the CMS such as the definitive media libraries. The CMS will provide access to data in asset inventories wherever possible rather than duplicating data.
Example of multiple Configuration Management databasesIn the commonly encountered partially outsourced service provider, some elements of the Service Management will be outsourced while others will remain in house, and different elements may be outsourced to different external suppliers. For example the network and hardware support may be handled by supplier A, environment and facilities management by supplier B, and multiple applications suppliers and incident management handled internally. The service desk will access information to assist them from the CMS, but that system will derive its data input from discrete repositories - each one a CMDB - owned and maintained by the three parties but working together to supply a single consistent information set. |
Configuration information evolves as the service is developed through the service lifecycle. Often there are separate mechanisms for managing different service lifecycle stages as well as different means of managing different applications and platforms.
The CMS typically contains configuration data and information that combined into an integrated set of views for different stakeholders through the service lifecycle as illustrated in Figure 4.8. It therefore needs to be based on appropriate web, reporting and database technologies that provide flexible and powerful visualization and mapping tools, interrogation and reporting facilities.
Many organizations are already using some elements of SACM, often maintaining records in documents, spreadsheets or local databases, and some of these may be used in the overall CMS.
Automated processes to load and update the Configuration Management database should be developed where possible so as to reduce errors and optimize costs. Discovery tools, inventory and audit tools, enterprise systems and network management tools can be interfaced to the CMS. These tools can be used initially to populate a CMDB, and subsequently to compare the actual 'live' configuration with the information and records stored in the CMS.
Secure Libraries And Secure Stores
A secure library is a collection of software, electronic or document CIs of known type and status. Access to items in a secure library is restricted. Libraries are used for controlling and releasing components throughout the service lifecycle, e.g. in design, building, testing, deployment and operations.
A secure store is a location that warehouses IT assets. It is identified within SACM, e.g. secure stores used for desktop deployment. Secure stores play an important role in the provision of security and continuity - maintaining reliable access to equipment of known quality.
The Definitive Media Library
The Definitive Media Library (DML) is the secure library in which the definitive authorized versions of all media CIs are stored and protected. It stores master copies of versions that have passed quality assurance checks. This library may in reality consist of one or more software libraries or file-storage areas, separate from development, test or live file-store areas. It contains the master copies of all controlled software in an organization. The DML should include definitive copies of purchased software (along with licence documents or information), as well as software developed on site. Master copies of controlled documentation for a system are also stored in the DML in electronic form.
The DML will also include a physical store to hold master copies, e.g. a fireproof safe. Only authorized media should be accepted into the DML, strictly controlled by SACM. The DML is a foundation for Release and Deployment Management (see section 4.4 on the release and deployment process).
The exact configuration of the DML is defined during the planning activities. The definition includes:
![]() |
Figure 4.9 shows the relationship between the DML and the CMDB. |
Definitive Spares
An area should be set aside for the secure storage of definitive hardware spares. These are spare components and assemblies that are maintained at the same level as the comparative systems within the controlled test or live environment. Details of these components, their locations and their respective builds and contents should be comprehensively recorded in the CMS. These can then be used in a controlled manner when needed for additional systems or in the recovery from incidents. Once their (temporary) use has ended, they are returned to the spares store or replacements are obtained.
Configuration Baseline
A configuration baseline is the configuration of a service, product or infrastructure that has been formally reviewed and agreed on, that thereafter serves as the basis for further activities and that can be changed only through formal change procedures. It captures the structure, contents and details of a configuration and represents a set of configuration items that are related to each other.
Establishing a baseline provides the ability to:
Snapshot
A snapshot of the current state of a configuration item or an environment, e.g. from a discovery tool. This snapshot is recorded in the CMS and remains as a fixed historical record. Sometimes this is referred to a footprint. A snapshot is not necessarily formally reviewed and agreed on - it is just a documentation of a state, which may contain faults and unauthorized CIs. One example is where a snapshot is established after an installation, perhaps using a discovery tool, and later compared to the original configuration baseline.
The snapshot:
The activity model illustrated in Figure 4.10 is often used where there are many parties or suppliers and activities need to be established to obtain the configuration information and data from third parties.
An example of the contents for an Asset or Configuration Management Plan is shown below.
![]() |
Figure 4.10 Typical Configuration Management activity model |
Example Of Asset And Configuration Management Plan ContentsContext And Purpose.
Scope:
Requirements:
Applicable policies and standards:
Organization for Configuration Management:
Asset and Configuration Management System and tools.
Selection and application of processes and procedures to implement Asset and Configuration Management activities, e.g.:
Reference implementation plan, e.g. data migration and loading, training and knowledge transfer plan.
Relationship management and interface controls, for example:
Relationship management and control of suppliers and sub-contractors.
|
The configuration identification process activities are to:
Configuration structures and the selection of configuration items
![]() |
Figure 4.11 (a) Example configuration breakdown for an end-user computing service |
![]() |
Figure 4.11 (b) Example configuration breakdown for a Managed Virtual System |
The configuration model should describe the relationship and position of CIs in each structure. There should be service configuration structures that identify all the components in a particular service (e.g. the retail service). Figure 4.11 (a) Example configuration breakdown for an end-user computing service An important part of Configuration Management is deciding the level at which control is to be exercised, with top-level CIs broken down into components which are themselves CIs, and so on.
CIs should be selected by applying a top down approach, considering if it is sensible to break down a Cl into component CIs. A CI can exist as part of any number of different CIs or CI groups at the same time. For instance, a database product may be used by many applications. Usage links to re-usable and common components of the service should be defined - for instance, a configuration structure for a retail service will use infrastructure CIs such as servers, network and software CIs. The ability to have multiple views through different configuration structures improves accessibility, impact analysis and reporting.
Configuration Management of work products and service components from the service lifecycle may be performed at several levels of granularity. The items placed under Configuration Management will typically include service bundles, service packages, service components, release packages and products that are delivered to the customer, designated internal work products, acquired services, products, tools, systems and other items that are used in creating and describing the configurations required to design, transition and operate the service.
Figure 4.11 (a) and (b) gives an example in schematic representation of how a Cl structure for an end-user computing service and a Managed Virtual System might be broken down.
Choosing the right Cl level is a matter of achieving a balance between information availability, the right level of control, and the resources and effort needed to support it. Information at a low Cl level may not be valuable - for example, although a keyboard is usually exchanged independently, the organization sees it as a consumable, so does not store data about it. Cl information is valuable only if it facilitates the management of change, the control of incidents and problems, or the control of assets that can be independently moved, copied or changed.
Factors that influence recording level of configuration items The factors that affect choice of lowest CI level are not just financial. As mentioned above most organizations do not store data on keyboards, because they consider them consumables, to be thrown away when not working, as one would a broken pen. However, some organizations find it worth retaining data on keyboards - for example in the United Nations, which supports many different languages within its office building, recording the specific language keyboard used is an important factor in speedy incident resolution when keyboards fail, i.e. they know which kind of replacement keyboard to send to any given user. |
The organization should plan to review the CI level regularly - to confirm (or otherwise) that information down to a low level is still valuable and useful, and that the handling of changes and problems and the management of assets are not deficient because the CMDB does not go down to a sufficiently low level.
Each asset and CI needs to be uniquely identified, whether it is generated inside or outside the organization. The identification should also differentiate between successive versions and should enable the items under control to be unambiguously traceable to their specifications or equivalent, documented descriptions.
Configuration descriptions and data should conform, where possible, to service, product or technology standards. Configuration data should permit forward and backward traceability to other baselined configuration states, where required.
Naming Configuration Items
Naming conventions should be established and applied to the identification of CIs, configuration documents and changes, as well as to baselines, builds, releases and assemblies.
Individual CIs should be uniquely identifiable by means of the identifier and version. The version identifies an updated instance of what can be regarded as the same Cl. More than one version of a Cl can coexist at any given time. The naming conventions should be unique and take into account the existing corporate or supplier naming/numbering structures. The naming conventions or information management system should include the management of:
Configuration Management should arrange for a naming convention to be established for all documents, e.g. RFCs. Document templates are a good method for standardizing configuration documentation. Without templates there are often far too many documents generated with overlapping content that can make executing changes extremely difficult.
Each type of template and form should be uniquely identifiable with a version number. A typical method of identification is