Service Transition

1Introduction 2Serv. Mgmt. 3Principles 4Processes 5Activities 6Organization 7Consideration 8Implementation 9Issues AAppendeces

4. Service Transition Processes


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:

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.

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:

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:

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. 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: Basic Concepts
The Configuration Model
Figure 4.7 Example of a logical configuraiton 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.:

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. Configuration Management System
Figure 4.8 Example of a 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:

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:

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:

4.3.5 Process Activities, Methods And Techniques 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. 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.


  • Applicable services
  • Environments and infrastructure
  • Geographical locations.


  • 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. Configuration Identification
When planning configuration identification it is important to:

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

Figure 4.11 (b) Example configuration breakdown for a Managed Virtual System
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

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

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
Portfolios - service contract, customer Service Strategy requirements, Service lifecycle model R C C R C
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 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 model, Service support model, Service desk, User assets, User documentation, Operations documentation, Support documentation I C C A/R R
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 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...

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:

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:

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

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. Status Accounting And Reporting
Figure 4.14 Example of asset and configuration item lifecycle
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:

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:

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:

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:

Status reports of assets for a business unit or software licence holdings are often required by financial management for budgeting, accounting and charging. Verification And Audit
The activities include a series of reviews or audits to:

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:

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

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:

Other measures include:


4.3.9 Challenges, Critical Success Factors And Risks
Challenges to SACM include:

Critical success factors include:

Risks to successful SACM include:

Supporting Material
  1. Video - CSU - Configuration Item
  2. MS Word - Config Mgmt Plan
  3. HDI - Config Mgmt
  4. HP - Activating Config Mgmt
  5. CMDB as Meta Data
  6. Config Mgmt Book of Knowledge
  7. LH - Justice CMDB Presentation
  8. MOF - Change and Configuration SMF

[To top of Page]

Visit my web site