Service Transition

4. Service Transition Processes

^4.1PLAN/SUPPORT

^4.2CHANGE

4.3 Service Asset And Configuration Management

This section addresses the process of Service Asset and Configuration Management (SACM) within IT Service Management. No organization can be fully efficient or effective unless it manages its assets well, particularly those assets that are vital to the running of the customer's or organization's business. This process manages the service assets in order to support the other Service Management processes.

4.3.1 Purpose, Goals And Objectives

The purpose of SACM is to:

Identify, control, record, report, audit and verify service assets and configuration items, including versions, baselines, constituent components, their attributes, and relationships
Account for, manage and protect the integrity of service assets and configuration items (and, where appropriate, those of its customers) through the service lifecycle by ensuring that only authorized components are used and only authorized changes are made
Protect the integrity of service assets and configuration items (and, where appropriate, those of its customers) through the service lifecycle
Ensure the integrity of the assets and configurations required to control the services and IT infrastructure by establishing and maintaining an accurate and complete Configuration Management System.

The goals of Configuration Management are to:

Support the business and customer's control objectives and requirements
Support efficient and effective Service Management processes by providing accurate configuration information to enable people to make decisions at the right time, e.g. to authorize change and releases, resolve incidents and problems faster.
Minimize the number of quality and compliance issues caused by improper configuration of services and assets
Optimize the service assets, IT configurations, capabilities and resources.

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.

4.3.2 Scope

Asset Management covers service assets across the whole service lifecycle. It provides a complete inventory of assets and who is responsible for their control. It includes:

Full lifecycle management of IT and service assets, from the point of acquisition through to disposal
Maintenance of the asset inventory.

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.

4.3.3 Value To Business

Optimizing the performance of service assets and configurations improves the overall service performance and optimizes the costs and risks caused by poorly managed assets, e.g. service outages, fines, correct licence fees and failed audits.

SACM provides visibility of accurate representations of a service, release, or environment that enables:

Better forecasting and planning of changes
Changes and releases to be assessed, planned and delivered successfully
Incidents and problems to be resolved within the service level targets
Service levels and warranties to be delivered
Better adherence to standards, legal and regulatory obligations (less non-conformances)
More business opportunities as able to demonstrate control of assets and services
Changes to be traceable from requirements
The ability to identify the costs for a service.

4.3.4 Policies, Principles And Basic Concepts

In distributed environments and shared services, individual service components exist within many different services and configuration structures. For example, a person may use a desktop computer that is on the network for a building but may be running a central financial system that is linked to a database on the other side of the world. A change to the network or the financial system may have an impact on this person and his/her business process. In web-based services, there may be data feeds and interfaces from and to services owned by other organizations. Changes at these interfaces need to be managed and it is important to identify the interface such as data feeds and the owner/custodian of these. Changes to any interface items need to be managed through Change Management.

4.3.4.1 Service Asset And Configuration Management Policies

The first step is to develop and maintain the SACM policies that set the objectives, scope and principles and critical success factors (CSFs) for what is to be achieved by the process. These policies are often considered with the change and Release and Deployment Management policies as they are closely related. The policies will be based on the organization's business drivers, contractual and Service Management requirements and on compliance to applicable laws, regulations and standards.

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:

Ensuring that Asset and Configuration Management operations costs and resources are commensurate with the potential risks to the services
The need to deliver corporate governance requirements, e.g. software asset management, Sarbanes-Oxley
The need to deliver the capability, resources and service warranties as defined by the service level agreements and contracts
The requirement for available, reliable and cost effective services
The requirement for clear economic and performance criteria for interventions that reduce costs or optimize service delivery, e.g. lower maintenance costs
The application of whole-life cost appraisal methods
The transformation from 'find and fix' reactive maintenance to 'predict and prevent' proactive management
The requirement to maintain adequate asset and configuration information for internal and external stakeholders
The level of control and requirements for traceability and auditability
The application of continual improvement methods to optimize the service levels, assets and configurations
Provision of accurate asset and configuration information for other business and Service Management processes
Integration of Asset and Configuration Management with other processes
Migration to a common asset and CMS architecture
Level of automation to reduce errors and costs.

4.3.4.2 Basic Concepts

The Configuration Model

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.:

To assess the impact and cause of incidents and problems
To assess the impact of proposed changes
To plan and design new or changed services
To plan technology refresh and software upgrades
To plan release and deployment packages and migrate service assets to different locations and service centres
To optimize asset utilization and costs, e.g. consolidate data centres, reduce variations and re-use assets.

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.

Service lifecycle CIs such as the Business Case, Service Management Plans, service lifecycle plans, Service Design Package, release and change plans, and test plans. They provide a picture of the service provider's services, how these services will be delivered, what benefits are expected, at what cost, and when they will be realized.
Service CIs such as:
- Service capability assets: management, organization, processes, knowledge, people
- Service resource assets: financial capital, systems, applications, information, data, infrastructure and facilities, financial capital, people
- Service model
- Service package
- Release package
- Service acceptance criteria.
Organization CIs - Some documentation will define the characteristics of a Cl whereas other documentation will be a Cl in its own right and need to be controlled, e.g. the organization's business strategy or other policies that are internal to the organization but independent of the service provider. Regulatory or statutory requirements also form external products that need to be tracked, as do products shared between more than one group.
Internal CIs comprising those delivered by individual projects, including tangible (data centre) and intangible assets such as software that are required to deliver and maintain the service and infrastructure.
External CIs such as external customer requirements and agreements, releases from suppliers or subcontractors and external services.
Interface CIs that are required to deliver the end-toend service across a service provider interface (SPI).

4.3.4.3 Configuration Management System

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 databases

In 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:

Medium, physical location, hardware and software to be used, if kept online - some Configuration Management support tools incorporate document or software libraries, which can be regarded as a logical part of a DML
Naming conventions for filestore areas and physical media
Environments supported, e.g. test and live environments
Security arrangements for submitting changes and issuing documentation and software, plus backup and recovery procedures
The scope of the DML, e.g. source code, object code from controlled builds and associated documentation
Archive and retention periods
Capacity plans for the DML and procedures for monitoring growth in size
Audit procedures
Procedures to ensure that the DML is protected from erroneous or unauthorized change (e.g. entry and exit criteria for items).

Figure 4.9 shows the relationship between the DML and the CMDB.
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:

Mark a milestone in the development of a service, e.g. Service Design baseline
Build a service component from a defined set of inputs
Change or rebuild a specific version at a later date
Assemble all relevant components in readiness for a change or release

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:

Enables problem management to analyse evidence about a situation pertaining at the time incidents actually occurred
Facilitates system restore to support security scanning software.

4.3.5 Process Activities, Methods And Techniques

4.3.5.1 Asset And Configuration Management Activities

High-level activities for Asset and Configuration Management are shown in an example of an activity model in Figure 4.10.

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.

4.3.5.2 Management And Planning

There is no standard template for determining the optimum approach for SACM. The management team and Configuration Management should decide what level of Configuration Management is required for the selected service or project that is delivering changes and how this level will be achieved. This is documented in a Configuration Management Plan. Often there will be a Configuration Management Plan for a project, service or groups of services, e.g. network services. These plans define the specific Configuration Management activities within the context of the overarching Service Asset and Configuration Management strategy.

An example of the contents for an Asset or Configuration Management Plan is shown below.

Figure 4.10 Typical Configuration Management activity model
Figure 4.10 Typical Configuration Management activity model

Example Of Asset And Configuration Management Plan Contents

Context And Purpose.

Scope:

Applicable services
Environments and infrastructure
Geographical locations.

Requirements:

Link to policy, strategy
Link to business, Service Management and contractual requirements
Summarize requirements for accountability, traceability, auditability
Link to requirements for the Configuration Management System (CMS).

Applicable policies and standards:

Policies
Industry standards, e.g. ISO/IEC 20000, ISO/IEC 19770-1
Internal standards relevant to Configuration Management, e.g. hardware standards, desktop standards.

Organization for Configuration Management:

Roles and responsibilities
Change and configuration control boards
Authorization - for establishing baseline, changes and releases.

Asset and Configuration Management System and tools.

Selection and application of processes and procedures to implement Asset and Configuration Management activities, e.g.:

Configuration identification
Version management
Interface management
Supplier management
Configuration Change Management
Release and deployment
Build management
Establishing and maintaining configuration baselines
Maintaining the CMS
Reviewing the integrity of configurations and the CMS (verification and audit).

Reference implementation plan, e.g. data migration and loading, training and knowledge transfer plan.

Relationship management and interface controls, for example:

With financial Asset Management With projects
With development and testing
With customers
With service provider interfaces (SPI)
With operations including the service desk.

Relationship management and control of suppliers and sub-contractors.

4.3.5.3 Configuration Identification

When planning configuration identification it is important to:

Define how the classes and types of assets and configuration items are to be selected, grouped, classified and defined by appropriate characteristics, e.g. warranties for a service, to ensure that they are manageable and traceable throughout their lifecycle
Define the approach to identification, uniquely naming and labelling all the assets or service components of interest across the service lifecycle and the relationships between them +
Define the roles and responsibilities of the owner or custodian for configuration item type at each stage of its lifecycle, e.g. the service owner for a service package or release at each stage of the service lifecycle.

The configuration identification process activities are to:

Define and document criteria for selecting configuration items and the components that compose them
Select the configuration items and the components that compose them based on documented criteria
Assign unique identifiers to configuration items
Specify the relevant attributes of each configuration item
Specify when each configuration item is placed under Configuration Management
Identify the owner responsible for each configuration item.

Configuration structures and the selection of configuration items

Figure 4.11 (a) Example configuration breakdown for an end-user computing service
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:

Hierarchical relationships between CIs within a configuration structure
Hierarchical or subordinate relationships in each CI
Relationships between CIs and their associated documents
Relationships between CIs and changes
Relationships between CIs, incidents, problems and known errors.

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

_nnnn where nnnn is a sequentially assigned number for each new instance of the form.

When the naming convention is being planned, it is very important that sufficient account is taken of possible future growth. Identifiers should be relatively short, but meaningful, and should follow existing conventions wherever possible. For hardware, if the Cl naming conventions are not based on suppliers' device names and models, a mechanism should be set up to relate Configuration Management and suppliers' identifiers to each other, for example, for the convenience of procurement staff and hardware engineers. Standard terminology and abbreviations should be used throughout the organization as far as possible (e.g. NYC rather than sometimes NY or N York). Failure to do so will result in an inability to match common incidents, problems etc. Attributes that might change should never be used as a part of CI naming.

Labelling Configuration Items
All physical device CIs should be labelled with the configuration identifier so that they can be easily identified. Plans should be made to label CIs and to maintain the accuracy of their labels.

Items need to be distinguished by unique, durable identification, e.g. labels or markings that follow relevant standards where appropriate. Physical non-removable asset tags (labels) should be attached to all hardware CIs; cables/lines should be clearly labelled at each end and at any inspection points. It is advisable to use a standard format and colour for all such labels, because this makes it easier for users to identify and quote from them, for instance when telephoning the service desk to report a fault. Barcode-readable labels improve the efficiency of physical audits. A standard policy on labelling hardware is similarly beneficial at the service desk, e.g. if all hardware is labelled in the bottom left-hand corner of the left side, it is much quicker and easier to explain to the user where they will find the required information.

Attributes For Configuration Items
Attributes describe the characteristics of a Cl that are valuable to record and which will support SACM and the ITSM processes it supports.

The SACM plan references the configuration information and data architecture. This includes the attributes to be recorded for each type of asset or CI. Typical attributes include:

Unique identifier
CI type
Name/description
Version (e.g. file, build, baseline, release)
Location
Supply date
Licence details, e.g. expiry date
Owner/custodian
Status
Supplier/source
Related document masters
Related software masters
Historical data, e.g. audit trail
Relationship type
Applicable SLA.

These attributes will define specific functional and physical characteristics of each type of asset and CI, e.g. size or capacity, together with any documentation or specifications.

Defining Configuration Documentation
The characteristics of a CI are often contained in documents. For example, the service definition, requirements specification and service level agreement for a service describe the characteristics of a Service CI. Many organizations specify mandatory and optional documents that describe a Cl and use document templates to ensure consistent information is entered. Table 4.7 is a RACI (Responsible, Accountable, Consulted, Informed) chart, which illustrates the types of documentation of service assets or configuration items that are the responsibility of different service lifecycle stages and typical documentation.

Collecting CI attribute data can facilitate use/reuse/reference to existing documents, data, files, records, spreadsheets etc. This will help users implementing this to determine a good approach to collecting data.

Service lifecycle stage Examples of service lifecycle assets and CIs impacted Service
Strategy Service
Design Service
Transition Service
Operation Continual
Service
Improvement
Service
Strategy Portfolios - service contract, customer Service Strategy requirements, Service lifecycle model R C C R C
Service
Design Service package (including SLA), Service Design package e.g. service model, contract, supplier's Service Management Plan, process interface definition, customer engagement plan Release policy Release package definition I A C R C
Service
Transition Service Transition model, Test plan, Controlled environments, Build/installation plan, Build specification, Release plan, Deployment plan, CMS, SKMS, Release package, Release baseline, Release documentation, Evaluation report, Test report I C A R C
Service
Operations Service Operations model, Service support model, Service desk, User assets, User documentation, Operations documentation, Support documentation I C C A/R R
Continual
Service
Improvement CSI model Service improvement plan, Service reporting process A/C A/C R R A
R=Responsible, A=Accountable, C=Consulted, I=Informed
Table 4.7 Configuration documentation for assets and responsibilities through the service lifecycle

Relationships
Relationships describe how the configuration items work together to deliver the services. These relationships are held in the CMS - this is the major difference between what is recorded in a CMS and what is held in an asset register.

The relationships between Cls are maintained so as to provide dependency information. For example: a CI is...

a part of another CI, e.g. a software module is part of a program; a server is part of a site infrastructure - this is a 'parent-child' relationship.
connected to another CI, e.g. a desktop computer is connected to a LAN.
uses another CI, e.g. a program uses a module from another program; a business service uses an infrastructure server.
installed on another, e.g. MS Project is installed on a desktop PC.

Although a 'child' Cl should be 'owned' by one 'parent' ci, it can be 'used by' any number of other CIs. If a standard desktop build is supplied and installed on all PCs within a division or location, then that build, including all the software CIs included, will be a CI that is linked by a relationship to the PCs. The software included will be 'part of the build. This can considerably reduce the number of relationships that are needed, compared with when individual software CIs relationships are used.

Relationships are also the mechanism for associating RFCs, incident records, problem records, known errors and release records with the services and IT infrastructure CIs to which they refer. All these relationships should be included in the CMS. RFCs and change and release records will identify the CIs affected.

Some of these relationships were shown in Figure 4.11. For example, EUC is the parent Cl of EUCI to EUC5 and EUCI is in turn the parent of three CIs, EUCI 01 to EUCI 03, shown as the next level in the hierarchy. EUCI uses the DML and Internal Application (IA) service.

Relationships may be one-to-one, one-to-many and manyto-one. Placing portfolios under the control of the CMS provides a good example. The combination of Service Portfolios and customer portfolios generates the contract portfolio. In other words, every item in the contract portfolio is mapped to at least one item in the Service Portfolio and at least one item in the customer portfolio.

Types Of Configuration Item
Components should be classified into asset or CI types because this helps to identify and document what is in use, the status of the items and where they are located. Typical Cl types include service, hardware, software, documentation and staff.

Identification Of Media Libraries
Physical and electronic media libraries should be uniquely identified and recorded in the CMS with the following information:

Contents, location and medium of each library
Conditions for entering an item, including the minimum status compatible with the contents of the library
How to protect the libraries from malicious and accidental harm and deterioration, together with effective recovery procedures
Conditions and access controls for groups or types of person registering, reading, updating, copying, removing and deleting CIs
Scope of applicability, e.g. applicable from environment 'system test' through to 'operation'.

Identification Of Configuration Baselines
Configuration baselines should be established by formal agreement at specific points in time and used as departure points for the formal control of a configuration. Configuration baselines plus approved changes to those baselines together constitute the currently approved configuration. Specific examples of baselines that may be identified include:

A particular 'standard' Cl needed when buying many items of the same type (e.g. desktop computer) over a protracted period; if some are to include additional components (e.g. a DVD writer), this could correspond to 'baseline plus'; if all future desktop computers are to have features then a new baseline is created
An application release and its associated documentation.

Several baselines corresponding to different stages in the life of a 'baselined item' can exist at any given time - for example, the baseline for an application release that is currently live, the one that was last live and has now been archived, the one that will next be installed (subject to change under Configuration Management control), and one or more under test. Furthermore, if, for instance, new software is being introduced gradually regionally, more than one version of a baseline could be 'live' at the same time. It is therefore best to refer to each by a unique version number, rather than 'live', 'next' or 'old'.

By consolidating the evolving configuration states of configuration items to form documented baselines at designated points or times the Configuration Management will be more effective and efficient. Each baseline is a mutually consistent set of Cls that can be declared at key milestones. An example of a baseline is an approved description of a service that includes internally consistent versions of requirements, requirement traceability matrices, design, specific service components and user documentation.

Each baseline forms a frame of reference for the service lifecycle as a whole. Baselines provide the basis for assessing progress and undertaking further work that is internally self-consistent and stable. For example, the Service Portfolio and the Business Case for a Service should present a consistent and clear definition of what the service package is intending to deliver. This may form the 'scope baseline' for the service(s) and give internal and external parties a clear basis for subsequent analysis and development. An example of the baseline points is shown in Figure 4.12.

Figure 4.12 Example of service lifecycle configuration levels and baseline points, represented by the
numbered triangles

Baselines are added to the CMS as they are developed. Changes to baselines and the release of work products built from the CMS are systematically controlled and monitored via the configuration control, Change Management and configuration auditing functions of SACM. In configuration identification, define and record the rationale for each baseline and associated authorizations required to approve the configuration baseline data. As a Service progresses through the service lifecycle, each baseline provides progressively greater levels of detail regarding the eventual outputs to be delivered. Furthermore, this hierarchy of baselines enables the final outputs to be traced back to the original requirements.

It needs to be kept in mind that earlier baselines may not be totally up to date with changes that have been made later, e.g. 'course corrections' to requirements documentation may be reflected in the release documentation.

Identification Of Release Unit
'Release unit' describes the portion of the service or infrastructure that is normally released together in accordance with an organization's release policy. The unit may vary, depending on the type(s) or item(s) of software and hardware.

Figure 4.13 Simplified example of an IT infrastructure
Figure 4.13 Simplified example of an IT infrastructure

Figure 4.13 gives a simplified example showing an IT infrastructure made up of systems, which are in turn made up of suites, comprising programs, which are made up of modules. Release information is recorded within the CMS, supporting the release and deployment process. Releases are uniquely identified according to a scheme defined in the release policy. The release identification includes a reference to the Cl that it represents and a version number that will often have two or three parts. Example release names are:

Major releases: Payroll System v.1, v.2, v.3 etc.
Minor releases: Payroll System v.1.1, v.1.2, v.1.3 etc.
Emergency fix releases: Payroll System v.1.1.1, v.1.1.2, v.1.1.3 etc.

4.3.5.4 Configuration Control

Configuration control ensures that there are adequate control mechanisms over CIs while maintaining a record of changes to CIs, versions, location and custodianship/ ownership. Without control of the physical or electronic assets and components, the configuration data and information there will be a mismatch with the physical world. No CI should be added, modified, replaced or removed without an appropriate controlling documentation or procedure being followed. Policies and procedures need to be in place that cover:

Licence control, to ensure that the correct number of people are using licences and that there is no unlicensed use and no wastage
Change Management
Version control of service asset, software and hardware versions, images/builds and releases
Access control, e.g. to facilities, storage areas and CMS
Build control, including the use of build specification from the CMS to perform a build
Promotion, migration of electronic data and information
Taking a configuration baseline of assets or CIs before performing a release (into system, acceptance test and production) in a manner that can be used for subsequent checking against actual deployment
Deployment control including distribution
Installation
Maintaining the integrity of the DML.

Often there are many procedures that can change a CI. These should be reviewed and aligned with the Cl types where possible as standardization prevents errors. During the planning stage it is important to design an effective configuration control model and implement this in a way that staff can easily locate and use the associated training products and procedures.

If many Configuration Management tools are used there is often a control plan for each tool that is aligned with the overall configuration control model.

Control should be passed from the project or supplier to the service provider at the scheduled time with accurate configuration information, documentation and records. A comprehensive checklist covering the service provider information requirements, Supplier information and organizational information required can be made and signed off. Provisions for conducting SACM need to be established in supplier agreements. Methods to ensure that the configuration data is complete and consistent should be established and maintained. Such a method may include baseline on transition, defined audit policies and audit intervals. It is important that the need for this information and control method is established as early as possible during the development lifecycle and incorporated as a deliverable of the new or changed service.

4.3.5.5 Status Accounting And Reporting

Figure 4.14 Example of asset and configuration item lifecycle

Each asset or CI will have one or more discrete states through which it can progress. The significance of each state should be defined in terms of what use can be made of the asset or Cl in that state. There will typically be a range of states relevant to the individual asset or CIs.

A simple example of a lifecycle is:

Development or draft - denoting that the Cl is under development and that no particular reliance should be placed on it
Approved - meaning that the Cl may be used as a basis for further work
Withdrawn - meaning withdrawn from use, either because the Cl is no longer fit for purpose or because there is no further use for it.

The way CIs move from one state to another should be defined, e.g. an application release may be registered, accepted, installed or withdrawn. An example of a lifecycle for a package application release is shown in Figure 4.14. This will include defining the type of review and approval required and the authority level necessary to give that approval. In Figure 4.12 the role that can promote the CI from Accepted to Installed is 'release management'. At each lifecycle status change the CMS should be updated with the reason, date-time stamp and person that did the status change. The planning activities should also establish any attributes that should be updated at each state.

Configuration status accounting and reporting is concerned with ensuring that all configuration data and documentation is recorded as each asset or CI progresses through its lifecycle. It provides the status of the configuration of a service and its environment as the configuration evolves through the service lifecycle. Status reporting provides the current and historical data concerned with each CI that in turn enables tracking of changes to CIs and their records, i.e. tracking the status as a Cl changes from one state to another, e.g. 'development', 'test', 'live' or 'withdrawn'.

The organization should perform configuration status accounting and reporting activities throughout the lifecycle of the service in order to support and enable an efficient Configuration Management process. Typical activities include:

Maintaining configuration records through the service lifecycle and archiving them according to agreements, relevant legislation or best industry practice, standards, e.g. ISO 9001, Quality Management System
Managing the recording, retrieval and consolidation of the current configuration status and the status of all preceding configurations to confirm information correctness, timeliness, integrity and security
Making the status of items under Configuration Management available throughout the lifecycle, e.g. to ensure appropriate access, change, build and release controls are followed, e.g. build specifications
Recording changes to CIs from receipt to disposal
Ensuring that changes to configuration baselines are properly documented. This can be achieved by consolidating the evolving configuration states of configuration items to form documented baselines at designated times or under defined circumstances.

Records
During the configuration identification and control activities, configuration status records will be created. These records allow for visibility and traceability and for the efficient management of the evolving configuration. They typically include details of:

Service configuration information (such as identification number, title, effective dates, version, status, change history and its inclusion in any baseline)
The service or product configuration (such as design or build status)
The status of release of new configuration information
Changes implemented and in progress
Capturing the results from quality assurance tests to update the configuration records.

The evolving service configuration information should be recorded in a manner that identifies the cross-references and interrelationships necessary to provide the required reports.

Service Asset And Configuration Reports
Reports of varying types will be needed for Configuration Management purposes. Such reports may cover individual configuration items, a complete service or the full Service Portfolio. Typical reports include:

A list of product configuration information included in a specific configuration baseline
A list of configuration items and their configuration baselines
Details of the current revision status and change history
Status reports on changes, waivers and deviations
Details of the status of delivered and maintained products concerning part and traceability numbers
Revision status
Report on unauthorized usage of hardware and software
Unauthorized CIs detected
Variations from CMS to physical audit reports.

Status reports of assets for a business unit or software licence holdings are often required by financial management for budgeting, accounting and charging.

4.3.5.6 Verification And Audit

The activities include a series of reviews or audits to:

Ensure there is conformity between the documented baselines (e.g. agreements, interface control documents) and the actual business environment to which they refer
Verify the physical existence of CIs in the organization or in the DML and spares stores, the functional and operational characteristics of CIs and to check that the records in the CMS match the physical infrastructure
Check that release and configuration documentation is present before making a release.

Before a major release or change, an audit of a specific configuration may be required to ensure that the customer's environment matches the CMS. Before acceptance into the live environment, new releases, builds, equipment and standards should be verified against the contracted or specified requirements. There should be a test certificate that proves that the functional requirements of a new or updated Cl have been verified, or some other relevant document (e.g. RFC).

Plans should be made for regular configuration audits to check that the CMDB and related configuration information is consistent with the physical state of all CIs, and vice versa. Physical configuration audits should be carried out to verify that the 'as-built' configuration of a Cl conforms to its 'as-planned' configuration and its associated documents. Interrogation facilities are required to check that the CMDB and the physical state of CIs are consistent.

These audits should verify that correct and authorized versions of CIs exist, and that only such CIs exist, and are in use in the operational environment. From the outset, any ad-hoc tools, test equipment, personal computers and other unregistered items should either be removed or registered through formal Configuration Management. Registration or removal will be via the Change Management process and has to prevent the authorization of non-acceptable CIs or the removal of CIs that may be supporting business processes. Unregistered and unauthorized items that are discovered during configuration audits should be investigated, and corrective action taken to address possible issues with procedures and the behaviour of personnel. All exceptions are logged and reported.

Configuration audits check in addition that change and release records have been properly authorized by Change Management and that implemented changes are as authorized. Configuration audits should be considered at the following times:

Shortly after changes to the CMS
Before and after changes to the IT services or infrastructure
Before a release or installation to ensure that the environment is as expected
Following recovery from disasters and after a 'return to normal' (this audit should be included in contingency plans)
At planned intervals
At random intervals
In response to the detection of any unauthorized CIs.

Automated audit tools enable regular checks to be made at regular intervals, e.g. weekly. For example, desktop audit tools compare the build of an individual's desktop to the master build that was installed. If exceptions are found, some organizations return the build to its original state.

A rolling programme of configuration audits can help use resources more effectively. The service desk and support groups will check that CIs brought to their attention, e.g. the software that a caller is using, are as recorded in the CMS. Any deviations are reported to Configuration Management for investigation.

If there is a high incidence of unauthorized CIs detected, the frequency of configuration audits should be increased, certainly for those parts of the services or IT infrastructure affected by this problem. Note that unauthorized installations are discouraged when the Configuration Management team is seen to be in control and to carry out regular and frequent audits. If an epidemic of unauthorized CIs is detected, selective or general configuration audits should be initiated to determine the scale of the problem, to put matters right, and to discourage a proliferation of unauthorized CIs. Publicity will help to reduce further occurrences. Service Design and Service Operations staff need to be notified and involved in the investigation of unauthorized CIs.

4.3.6 Triggers, Input And Output, And Interprocess Interfaces

Updates to asset and configuration information are triggered by change requests, purchase orders, acquisitions and service requests.

4.3.6.1 Process Relationships

By its very nature - as the single virtual repository of configuration data and information for IT Service Management - SACM supports and interfaces with every other process and activity to some degree. Some of the more noteworthy interfaces are:

Change Management - identifying the impact of proposed changes
Financial management - capturing key financial information such as cost, depreciation methods, owner
and user (for budgeting and cost allocation), maintenance and repair costs
ITSCM - awareness of assets the business services depend on, control of key spares and software
Incident/problem/error - providing and maintaining key diagnostic information; maintenance and provision
of data to the service desk
Availability management in detection of points of failure.

The relationship with change and release and deployment is synergistic, with these processes benefiting greatly from a single coordinated planning approach. Configuration control is synonymous with change control - understanding and capturing updates to the infrastructure and services.

4.3.7 Information Management

Backup copies of the CMS should be taken regularly and securely stored. It is advisable for one copy to be stored at a remote location for use in the event of a disaster. The frequency of copying and the retention policy will depend on the size and volatility of the IT infrastructure and the CMS. Certain tools may allow selective copying of Cl records that are new or have been changed.

The CMS contains information on backup copies of CIs. It will also contain historical records of CIs and Cl versions that are archived, and possibly also of deleted CIs or Cl versions. The amount of historical information to be retained depends on its usefulness to the organization. The retention policy on historical Cl records should be regularly reviewed, and changed if necessary. If the cost to the organization of retaining Cl information is greater than the current or potential value, do not retain it, taking note of relevant regulatory and statutory requirements in relation to retention of records.

Typically, the CMS should contain records only for items that are physically available or could be easily created using procedures known to, and under the control of, Configuration Management. When Configuration Management has been operating for a period of time, regular housekeeping should be carried out to ensure that redundant Cl records are systematically archived.

4.3.8 Key Performance Indicators And Metrics

As with all processes the performance of SACM should be monitored, reported on and action taken to improve it. SACM is the central support process facilitating the exchange of information with other processes and as such has few customer facing measures. However, as an underlying engine to other processes in the lifecycle, SACM must be measured for its contribution to these parts of the lifecycle and the overall KPIs that affect the customer directly.

In order to optimize the cost and performance of the service assets and configurations the following measures are applicable:

Percentage improvement in maintenance scheduling over the life of an asset (not too much, not too late)
Degree of alignment between provided maintenance and business support
Assets identified as the cause of service failures
Improved speed for incident management to identify faulty Cls and restore service
Impact of incidents and errors affecting particular Cl types, e.g. from particular suppliers or development groups, for use in improving the IT services
Percentage re-use and redistribution of under-utilized resources and assets
Degree of alignment of insurance premiums with business needs
Ratio of used licences against paid for licences (should be close to 100%)
Average cost per user for licences (i.e. more effective charging options achieved)
Achieved accuracy in budgets and charges for the assets utilized by each customer or business unit
Percentage reduction in business impact of outages and incidents caused by poor Asset and Configuration
Management
Improved audit compliance.

Other measures include:

Increased quality and accuracy of asset and configuration information
Fewer errors caused by people working with out-ofdate information
Shorter audits as quality asset and configuration information is easily accessible
Reduction in the use of unauthorized hardware and software, non-standard and variant builds that increase complexity, support costs and risk to the business services
Reduction in the average time and cost of diagnosing and resolving incidents and problems (by type)
Improvement in time to identify poor-performing and poor-quality assets
Occasions when the 'configuration' is not as authorized
Changes that were not completed successfully or caused errors because of poor impact assessment, incorrect data in the CMS, or poor version control
Exceptions reported during configuration audits
Value of IT components detected in use
Reduction in risks due to early identification of unauthorized change

4.3.9 Challenges, Critical Success Factors And Risks

Challenges to SACM include:

Persuading technical support staff to adopt a checking in/out policy - this can be perceived as being a hindrance to a fast and responsive support service; if the positives of such a system are not conveyed adequately then staff may be inclined to try and circumvent it; even then, resistance can still occur; placing this as an objective within their annual appraisal is one way to help enforce the policy
Attracting and justifying funding for SACM, since it is typically out of sight to the customer units empowered with funding control; in practice it is typically funded as an 'invisible' element of Change Management and other ITSM process with more business visibility
An attitude of 'just collecting data because it is possible to do'; this leads SACM into a data overload which is impossible, or at least disproportionately expensive, to maintain
Lack of commitment and support from management who do not understand the key role it must play supporting other processes.

Critical success factors include:

Focusing on establishing valid justification for collecting and maintaining data at the agreed level of detail
Demonstrating a top-down approach - focused on identifying service CIs and subsequently the CIs that support those services, thereby allowing a rapid and clear demonstration of potential points of failure for any given service
Setting a justified level of accuracy, i.e. the correlation between the logical model within SACM and the 'real world'
Making use of enabling technology to automate the CMS practices and enforce SACM policies.

Risks to successful SACM include:

The temptation to consider it technically focused, rather than service and business focused, since technical competence is essential to its successful delivery
Degradation of the accuracy of configuration information over time that can cause errors and be difficult and costly to correct
The CMS becomes out of date due to the movement of hardware assets by non-authorized staff; half-yearly physical audits should be conducted with discrepancies highlighted and investigated; managers should be informed of inconsistencies in their areas.

Supporting Material

Video - CSU - Configuration Item
MS Word - Config Mgmt Plan
HDI - Config Mgmt
HP - Activating Config Mgmt
CMDB as Meta Data
Config Mgmt Book of Knowledge
LH - Justice CMDB Presentation
MOF - Change and Configuration SMF

Service lifecycle stage	Examples of service lifecycle assets and CIs impacted	Service Strategy	Service Design	Service Transition	Service Operation	Continual Service Improvement
Service Strategy	Portfolios - service contract, customer Service Strategy requirements, Service lifecycle model	R	C	C	R	C
Service Design	Service package (including SLA), Service Design package e.g. service model, contract, supplier's Service Management Plan, process interface definition, customer engagement plan Release policy Release package definition	I	A	C	R	C
Service Transition	Service Transition model, Test plan, Controlled environments, Build/installation plan, Build specification, Release plan, Deployment plan, CMS, SKMS, Release package, Release baseline, Release documentation, Evaluation report, Test report	I	C	A	R	C
Service Operations	Service Operations model, Service support model, Service desk, User assets, User documentation, Operations documentation, Support documentation	I	C	C	A/R	R
Continual Service Improvement	CSI model Service improvement plan, Service reporting process	A/C	A/C	R	R	A
R=Responsible, A=Accountable, C=Consulted, I=Informed
Table 4.7 Configuration documentation for assets and responsibilities through the service lifecycle