Policies

The first step is to develop and maintain the SACM policies that set the objectives, scope, 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 because they are closely related. The policies will be based on the organization’s business drivers, on contractual and service management requirements, and on compliance to applicable laws, regulations, and standards.

Principles

The main policy sets out the framework and key principles against which assets and configurations are developed and maintained. Some of the typical principles include ensuring that service asset and configuration management operations costs and resources are commensurate with the potential risks to the services. Also included is the need to deliver governance requirements, such as software asset management, Sarbanes-Oxley, ISO/IEC 20000, ISO/IEC 38500, or COBIT, and the need to deliver the capability, resources, and warranties as defined by SLAs and contracts. Services provided must be available, reliable, and cost-effective. Adequate asset and configuration information must be provided to internal and external stakeholders and to other processes. The need for traceability and auditability must also be supported by this process.

Another principle is that there is a requirement for clear economic and performance criteria for interventions that reduce costs or optimize service delivery. An example would be specifying the age at which PCs should be replaced based on cost of maintenance of older models. Also included is the application of whole-life cost appraisal methods and moving from “find and fix” reactive maintenance to “predict and prevent” proactive management. Other common principles are using CSI to optimize the service levels, assets, and configurations; migration to a common CMS architecture; and using increased automation to reduce errors and costs.

Basic Concepts

Let’s take a few minutes to remind ourselves of some of the basic concepts and definitions for this process. You should remember these from your Foundation level course.

• A service asset is any resource or capability that could contribute to the delivery of a service.
• A configuration item, or CI, is a service asset that needs to be managed in order to deliver an IT service.
• All CIs are service assets, but many service assets are not CIs.
• A configuration record contains the attributes of a CI, including the relationships between it and other CIs.
• Configuration records are stored in a configuration management database (CMDB) and managed with a configuration management system (CMS).
• The service knowledge management system (SKMS) is a set of tools and databases that are used to manage knowledge, information, and data. We cover the SKMS in the chapter on knowledge management, Chapter 26, “Service Transition Processes: Change Evaluation and Knowledge Management.”

The Configuration Model

Service asset and configuration management delivers a model of the services, assets, and the infrastructure by recording the relationships between configuration items, as shown in Figure 24.1.

The configuration model enables other processes to access valuable information, as in these examples:

• 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 a technology refresh or a software upgrade or to migrate service assets to different locations and service centers
• To optimize asset utilization and costs and reuse assets by understanding which CIs make up each service

As we said previously, a configuration item (CI) is a service asset that needs to be managed in order to deliver an IT service. Configuration records should hold useful details of the attributes of the CI. Maintaining such information can be a significant administrative overhead, so care should be taken to include only information for which the value provided by the information is greater than the cost of gathering and maintaining it. 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; for example, a set of components may be grouped into a release.

Examples of Different CI Types

We usually think of CIs in terms of hardware, software, and network components, and indeed, the majority of CIs will fit into these categories. Configuration items include anything we want to manage and control, so we may also include other CI types:

• Service lifecycle CIs, which could include plans, business cases, service design packages, and so on.
• Service CIs could describe the following items:
  • Capability assets such as management, organization, processes, knowledge, and people
  • Resource assets such as financial capital, systems, applications, information, data, infrastructure and facilities, financial capital, and people
  • Service models and service acceptance criteria
• Organization CIs would include items such as business strategy documents or statutory requirements.
• Internal CIs may refer to tangible (data center) and intangible assets such as software that is required to deliver and maintain the service and infrastructure.
• External CIs would refer to external customer requirements and agreements, releases from suppliers, and external services.
• Interface CIs could be, for example, an escalation document, specifying how two service providers will work together.

Service asset and configuration management uses the configuration management system (CMS) to manage the CI data. (Chapter 29, “Technology Considerations for Service Transition,” discusses the use of tools in this area in more detail.) The CMS holds all the information about CIs within scope. A service CI will include attributes such as supplier, cost, purchase date, and renewal date for licenses and maintenance contracts; the related documentation, such as SLAs and underpinning contracts, is held in the SKMS.

Figure 24.2 shows the relationship between configuration records, stored in the CMS, and the actual CIs, which may be stored in the SKMS or may be physical assets outside the SKMS.

All CI changes must be authorized by change management, and all updates must include updates to the relevant configuration records. The CMS is also used for a wide range of purposes outside of service asset and configuration management, such as fixed asset financial reporting. It maintains the relationships between all service components and may also include records for related incidents, problems, known errors, changes, and releases. Alternatively, these may be held in the SKMS, but show the link to the associated CI. The CMS may either link to corporate data about employees, suppliers, locations and business units, customers, and users or hold copies of this information.

In Figure 24.3 you can see an example of the application of the architectural layers of the CMS. We shall look at this in more detail in Chapter 26, when we consider knowledge management. The CMS may include data from configuration records stored in several physical CMDBs, which come together at the information integration layer to form an integrated CMDB. The integrated CMDB may also incorporate information from external data sources such as an HR database or financial database. The presentation layer of the CMS will contain different views and dashboards to fit the requirements of different groups of people needing access to configuration information. In addition to a view suitable for staff responsible for SACM, views may be provided that are suitable for those involved in change management and release and deployment management or for staff in technical and application management functions or the service desk. The CMS will provide access to data in asset inventories wherever possible rather than duplicating data.

Configuration Baseline

A configuration baseline is a formally reviewed and agreed configuration of a service, product, or infrastructure. It captures the structure, contents, and details of a configuration and represents a set of configuration items that are related to each other. It is used to mark a milestone in the development of a service or to build a service component from a defined set of inputs. It can also be used to change or rebuild a specific version at a later date, to assemble all relevant components in readiness for a change or release, or to provide the basis for a configuration audit and back-out.

Snapshot

A snapshot is the current state of a CI, process, or other set of data recorded at a particular point in time. This is useful when problem management needs to analyze evidence about the time incidents actually occurred. It also facilitates system restores and supports security scanning software because any changes from the previous snapshot are obvious.

Asset Management

Organizations need to manage their fixed assets because they have a financial value. The process includes identifying and naming each asset and recording its owner. This information would be stored in an asset register, including details of the purchase cost, depreciation, and net book value of each asset. The process has to also safeguard the assets from interference and carry out audits to ensure their integrity. The major difference between asset management and configuration management is that asset management is concerned with the financial aspects of each individual asset, whereas configuration management is concerned with each item’s relationship with other items and in the provision of the service; an asset of very low financial value may play a key role in the provision of a service.

Outsourced service providers may manage some of the organization’s CI assets and carry out some or all of the same activities – tracking, naming, labeling, protecting, and auditing.

Software Asset Management

Additional risks are involved when managing software assets compared to other asset types. The risks include too few or too many licenses, loss of evidence of purchase, and inadvertent breaches of terms and conditions. Software asset management (SAM) manages the software, licenses, and activation codes.

Effective SAM is dependent on the use of appropriate tools, including a CMS and a definitive media library (DML). We look at the DML next.

Secure Libraries and Secure Stores

The DML is a secure library holding the definitive authorized versions of all media CIs. It consists of one or more software libraries or file-storage areas containing the master copies of all controlled software in the organization. This includes purchased software (with the license documents) and software developed on site and master copies of the relevant controlled documentation. The DML will also include a physical store (e.g., a fireproof safe) to hold master copies. Only authorized media should be accepted into the DML, and that is strictly controlled by SACM. The DML is a foundation for release and deployment management.

An area should also be set aside for the secure storage of definitive hardware spares. Details of these components, their locations, and their respective builds and contents should be comprehensively recorded in the CMS.

Electronic assets in the DML are held within the SKMS, and every item in the DML is a CI. Figure 24.4 shows the relationship between the DML and a CMDB in the CMS.

Decommissioning Assets

Assets are decommissioned for a number of reasons, including when a service is retired and the assets used for that service are no longer needed, when a technology refresh replaces old assets, when hardware failure results in components being replaced, and when reduced capacity requirements free up components.

The detailed steps to be taken when decommissioning assets should be documented in a service design package in the same way as for any other service transition. These steps should include redeploying, reusing, or selling the assets where appropriate to minimize waste and, where this is not possible, ensuring that the disposal meets the required environmental standards. The data stored on decommissioned assets must be removed and managed in accordance with the information security policy. If the equipment is leased, it should be returned, and maintenance contracts on decommissioned equipment should be canceled. Finally, the asset’s status in the CMS should be updated and the fixed asset management process informed so that the asset records can be updated.

Management and Planning

The level of service asset and configuration management required will vary between organizations, so there is no standard template. The management team should decide what level is required for the particular service or project and how this level will be achieved and document it in a SACM plan. There may be several SACM plans, one for each project, service, or group of services. These plans define the specific SACM activities within the context of the overarching SACM strategy.

Identification

The configuration identification process activities include defining and documenting the criteria for selecting CIs and their components and then selecting them according to the criteria. Each CI is then assigned a unique identifier. The relevant attributes of each CI are specified, including its relationship to other CIs, and the owner responsible for each CI is identified. The date from which each CI is placed under control of SACM is recorded.

Configuration Control

The configuration control activities ensure that no CI is added, modified, replaced, or removed without an appropriate procedure being followed. They ensure that before a release, a configuration baseline is taken that can be used for subsequent checking against actual deployment. They also ensure that the integrity of the DML is maintained.

Status Accounting and Reporting

This set of process activities tracks what happens to a CI by means of a number of statuses. Each CI will have one or more states through which it can progress, as in this simple example of a lifecycle:

• Development or draft: Denoting that the CI is under development and that no particular reliance should be placed on it
• Approved: Meaning that the CI may be used as a basis for further work
• Withdrawn: Meaning that the CI has been withdrawn from use, either because it is no longer fit for purpose or because there is no further use for it

The method by which CIs move from one state to another should be defined.

Audit and Review

The activities include a series of reviews or audits to ensure that the configuration records match the actual situation—that CIs and their documentation actually exist as stated in the CMS. The audits aim to verify the existence of CIs and their documentation and to confirm that they are configured correctly, especially when a release is planned. Any unregistered and unauthorized items that are discovered should be investigated and corrective action taken to address possible issues with circumventing of procedures by some staff. All exceptions should be logged and reported, and records of the audit should be created to support future compliance checking.

Triggers

Updates to asset and configuration information are triggered by updates from the change and release and deployment processes. Other triggers are purchase orders, acquisitions, and service requests.

Inputs

Inputs to service asset and configuration management include the designs, plans and configurations contained in service design packages, and the RFCs and work orders from change management. Other inputs are the configuration information collected by discovery tools and audits and the organization’s fixed asset register.

Outputs

Outputs include new and updated configuration records, snapshots and baselines, audit and status reports, and updated asset information for inclusion in the fixed asset register. The information output by the process regarding the attributes and relationships of configuration items is used by all the other service management processes.

Interfaces

SACM provides the single virtual repository of configuration data and information for IT service management, so it interfaces with every other process and activity to some extent. Perhaps the most important interface is that with change management, where it is used for impact assessment and also ensures that changes to CIs are captured, which is critical if SACM is to work effectively.

Other important interfaces include the interfaces with the following processes:

• Financial management, where it captures key financial information such as cost, depreciation methods, owner, maintenance and repair costs
• IT service continuity management, where it provides information regarding critical assets to be protected
• Incident and problem management, where it provides key diagnostic information and data to the service desk and helps identify problem causes
• Availability management, where it helps in the detection of points of failure by showing CI relationships

There is also a close relationship with the business process of asset management.