THE FOLLOWING ITIL INTERMEDIATE EXAM OBJECTIVES ARE DISCUSSED IN THIS CHAPTER:
The syllabus covers the managerial and supervisory aspects of service transition processes. It excludes the day-to-day operation of each process and the details of the process activities, methods, and techniques as well as its information management. More detailed process operation guidance is covered in the intermediate service capability courses. More detail on the courses included in the ITIL exam framework can be found at www.axelos.com/qualifications/itil-qualifications. Each process is considered from the management perspective. Each process is considered from the management perspective. That means at the end of this section of the book, you should understand those aspects that would be required to understand the process and its interfaces, oversee its implementation, and judge its effectiveness and efficiency.
We spent some time in the previous chapter discussing change management. In many ways, service asset and configuration management (SACM) is the companion process to change management; each depends upon the other for success. Without configuration management, those involved in the change management process would struggle to understand the implications of any change because they would lack the information regarding the CIs and their interrelationships. Without the discipline of change management, those involved in the service asset and configuration management process would struggle to develop and maintain an accurate CMS because changes might happen without any notification or documentation.
The purpose of the SACM process is to ensure that the assets required to deliver services are properly controlled and that accurate and reliable information about those assets is available when and where it is needed. This information includes details of how the assets have been configured and the relationships between assets.
The objectives of service asset and configuration management are as follows:
Service assets that need to be managed in order to deliver services are known as configuration items (CIs).
The scope of SACM includes management of the complete lifecycle of every CI. It ensures that changes to all CIs are controlled and that releases are authorized. The relationship between items is recorded to build a model of each service. Included within the scope are the interfaces to internal and external service providers where shared assets and CIs need to be controlled.
Configuration management depends upon having a close interface with the organization’s asset management. Asset management covers the full lifecycle management of IT and service assets and the maintenance of an asset inventory. However, asset management is not about the relationships between CIs and how they work together to deliver a service.
Often the value to the business can be shown by the impact of poor configuration management, for example, service outages, fines, correct license fees, and failed audits. Accurate SACM enables better forecasting by the provision of information to the right people at the right time, which will assist with the management of change. It will also assist in the compliance to governance standards and the ability to assess the cost of services. The process provides visibility of accurate representations of a service, release, or environment that enables better forecasting and planning of changes, which in turn enables better assessment, planning, and delivery of changes and releases. Providing accurate CI information helps ensure that incidents and problems are resolved within the service level targets. By being able to track CIs and their status, the service provider will be able to ensure better adherence to standards or legal and regulatory obligations. Changes can be traced from requirements to implementation, and the costs of a service can be identified from the information showing all the CIs that make up that service. Finally, the business benefits from reduced cost and time to discover configuration information when it is needed and can be assured that the fixed assets that are under the control of the service provider are under proper stewardship too.
Modern businesses functions require complex configurations of items to support the business services. For example, a person in an office in the United Kingdom may use a PC attached to the company network but may be accessing a financial system running in a completely different part of the world, such as the United States. A change to the network or the financial system might have an impact on this person and the business process they support. Many services may run on different virtual servers hosted on the same physical computer; changes to the physical server could impact all of these services.
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.
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.
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.
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:
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.
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 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.
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.
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.
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.
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.
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.
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.
Before we start looking at the service asset and configuration management process activities, let’s see how these activities work together. In Figure 24.5, you can see the high-level activities for service asset and configuration management in this example of an activity model.
The service asset and configuration management activities include management and planning, configuration identification, configuration control, status accounting and reporting, and verification and audit. We shall look at each of them in turn.
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.
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.
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.
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:
The method by which CIs move from one state to another should be defined.
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.
Now let’s look at the triggers, inputs and outputs, and process interfaces for service asset and configuration management. Let’s look first at the triggers for this process.
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 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 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.
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:
There is also a close relationship with the business process of asset management.
As with all processes, the performance of SACM should be monitored and reported, and action should be taken to improve it. As you have seen, SACM plays an essential role in providing many other processes with the information they require, so success or failure in implementing this process will have an indirect impact on customers. As discussed previously, each CSF should have a small number of KPIs that will measure its success, and each organization may choose its own KPIs. The ITIL Service Transition core volume lists a number of CSFs and corresponding KPIs. We shall just look at a couple of these now.
Challenges to SACM include persuading technical support staff to adhere to the process when making changes to CIs. They often regard the process as a hindrance to a fast and responsive support service. Attracting and justifying funding for service asset and configuration management can be difficult because it is invisible to the customer. Another challenge is defining the optimal level of data to be gathered and managed—discovery tools may collect vast quantities of data that is not required but needs to be managed. Finally, due to its invisible nature, management may not appreciate the key support it provides to all other processes and therefore fail to provide the level of commitment and support required, especially when enforcing the process.
Risks to successful SACM include regarding it as technically focused and not appreciating what it delivers indirectly to the business. The accuracy of the information may degrade if the process and that of change management are not enforced. Errors found in audits must not only be corrected, but also investigated to identify poor adherence to the processes, which should then be addressed by management. An inaccurate CMS will lead to incorrect decisions based on faulty data. Too wide a scope will entail cost with little benefit; too narrow a scope will also fail to deliver any real benefit.
This chapter explored the service transition process of service asset and configuration management. We examined how this process is responsible for providing accurate information to many other processes. We looked at how the information about configuration items and their relationships with each other is gathered and maintained, and at the repository for this information, the CMS.
We also examined the importance of this process to the business and to the IT service provider.
Understand the purpose of service asset and configuration management. Be able to explain that the purpose of the service asset and configuration management process is to capture accurate and reliable information about the assets that make up our services.
Understand the objectives of service asset and configuration management. SACM objectives are about maintaining accurate information on configurations items and services. It is important to understand that this will enable informed decision-making across many processes.
Understand the scope of service asset and configuration management. SACM covers all service assets and configuration items that make up services and how the configuration items are identified and recorded as part of the configuration management system (CMS).
Know the different types of CIs. The different types of CIs are hardware CIs, internal and external CIs, service CIs, and service lifecycle CIs. Be able to give examples of each.
Understand the concept of attributes. Be able to suggest common attributes for different CI types.
Understand the use of configuration models. Configuration models show the dependencies and relationships between CIs to provide a model of the services, assets, and infrastructure.
Understand how the information held in the configuration management system (CMS) is used by other processes. Be able to provide examples.
Be able to explain the concept and use of a configuration baseline. A configuration baseline is used to capture the state of the infrastructure at a specific point to be reviewed and agreed on and used for trending, comparison, and planning.
Understand the difference between a baseline and a snapshot. A snapshot is a capture of the infrastructure at a point in time, but it may contain errors and inaccuracies because it is not reviewed and finalized.
Be able to explain the use and contents of the definitive media library (DML). The DML is a specific secure area set aside for the management of software media. It may consist of physical and electronic stores for master copies of licensed or authorized software in use in the live environment and the associated documentation.
Be able to list and explain the five main activities of SACM. The activities are planning, identification, control, status accounting, and verification and audit.
You can find the answers to the review questions in the appendix. Which of these statements is NOT part of the purpose of the SACM process? SACM is a process that supports which of the following stages of the service lifecycle? Which of these statements best describes a configuration record? The configuration management system (CMS) is composed of four separate layers. Which option includes the correct identification of those layers? Which of the following statements concerning the value of the CMS to the business is INCORRECT? Which of the following is NOT a potential danger when implementing SACM? Identify the correct word for the blanks in the following statements from the list provided. A ______________________ is any resource or capability that could contribute to the delivery of a service. A ______________________ is a service asset that needs to be managed in order to deliver an IT service. A ______________________ contains a set of ______________________ of a CI, including the relationships between it and other CIs. Configuration records are stored in a ______________________ and managed with a ______________________ . Which of the following are benefits of a configuration model? Which of the following is not a valid example of a service CI? Which of the following statements is TRUE?Review Questions