Service Asset and Configuration Management

One of the key ways that an IT department can show its efficiency is by demonstrating that it has control over the assets it manages. Remember, the services that IT provides are crucial to the support of the business, and you must try to deliver these in the most efficient and effective manner possible.

In this process, you look at the ways you can establish a logical model of the infrastructure to assist service management. Capturing accurate information about your components and service assets will enable you to be more efficient in the delivery of services.

The elements we will be reviewing in this section are the purpose, objectives, and scope of the process; the concepts of the configuration management system, configuration management database, and configuration items; and the configuration model and the definitive media library.

The Purpose of the SACM Process

The purpose of the service asset and configuration management (SACM) process is to ensure that you are able to control the assets that make up your services. To achieve that control, it will be necessary to understand what each of those assets are and how they are connected to each other.

Managing the assets that make up your services can be a complicated task in distributed environments. Components of your services may be in diverse locations, managed by a wide variety of teams; and the more complex your technology architecture, the more involved the management becomes.

Identifying the assets is only part of the requirement; you also need to ensure you have accurate records about them. This is a challenging task for any department. The information captured should include the relationships between the assets, to maximize the use of the data. Understanding the relationships between the items will aid in the management of the infrastructure and the identification of the impact of changes, by showing the connections between the infrastructure items. Corporate asset management simply provides a list of the items; service asset and configuration management shows the relationships between items and allows for a greater understanding of how all the elements of the infrastructure depend on each other.

If appropriate, you should capture not only the relationships between items but also their configuration. It is important to capture appropriate information so that the full benefit of the information can be realized. It will be necessary to understand what the data will be used for within the organization so that the level of detail can be agreed upon as part of the process.

So, part of the purpose of SACM is to ensure you have accurate meaningful and relevant information about your assets.

The Objectives of the SACM Process

The objectives of the SACM process are to do the following:

• Ensure the assets that are under the control of the IT department are properly managed. This means the assets need to be identified and, once identified, controlled throughout their lifecycles. Managing the assets that make up your services is an important part of the governance and control you should have to support your organization.
• Capture information about the services you provide. This requires you to identify, control, and record the services and configuration items you use to support your businesses. Once this information is captured, you need to report on and audit the data, allowing you to verify the configuration of the services and how they support the business. This should include versions, baselines, and constituent components of the services, attributes, and relationships about the services.
• Manage the integrity of the configuration items (CIs) that make up the services. We expand on configuration items later in this chapter, but essentially it is an item of infrastructure that is managed to deliver a service. This should include accounting for and protecting the configuration items by using the change management process to ensure that only properly authorized items are in use in the infrastructure. Change management should be used to control the lifecycle of CIs so that only authorized changes can be carried out.
• Establish an accurate and maintained configuration management system, enabling the sustained control and integrity of the components and services. Creating a viable configuration management system is a very important aspect of the SACM process.
• Maintain historical, planned, and current information about the state of configuration items and services as part of the control and management of the infrastructure. By capturing historic and planned status, it will be possible to use the information for trending and modeling, so its accuracy will be important.
• Support efficient and effective service management processes, by providing information that allows accurate decision making by service providers in the delivery of services. This information is a crucial part of other service management processes, and it is sometimes said that SACM underpins and supports the entire lifecycle.

The Scope of the SACM Process

The process of SACM is there to identify the elements of the infrastructure that are to be managed as service assets and then to apply controls to that management. Service assets that are to be managed throughout their lifecycle, in order to deliver services, are known as configuration items (CI). Other assets that cannot be managed in this way, even though they are part of the overall service delivery, are not configuration items. All configuration items are service assets, but not all service assets will be classified and managed as configuration items. An example of this is a server; this would be classed as both an asset and a configuration item. But the knowledge used by the support technician to manage the server would not be classed as a configuration item, even though it is obviously an important service asset. To extend this example, the information stored on the server, although it is a valuable asset, is also not classified as a configuration item.

In the case of virtual infrastructure, a virtual server may still be classified as a configuration item and service asset, and even though it is as intangible as “knowledge” or “information,” it will still need the same management controls applied as its physical counterpart.

So, the scope of the process includes the management of all configuration items throughout their lifecycle.

Providing control over the entire lifecycle of a configuration item, and all configuration items that make up your services, requires a substantial amount of effort. The scope of this effort should be managed across the whole of the service lifecycle. It requires that all CIs be baselined (that is, identifying and agreeing upon the state of the infrastructure at a given point in time), maintained, and controlled through change management. Using the change management process will also help ensure that there is control over the management of releases into the production environment. No release should take place without the necessary authorization, which is part of the change process.

Capturing all this information is done by creating the configuration management system (CMS). This system allows you to develop a logical model of the infrastructure, which provides details of the relationships among all of the CIs. Known as a configuration model, this is an important tool for service management processes.

Other items that make up the services, perhaps not traditionally captured as assets by the other parts of the organization such as work products (for example, organization models, process documentation, roles, and responsibilities in a RACI matrix), may be classified as CIs in the CMS.

The scope will also include any interfaces that may exist with internal and external configuration items, such as any shared assets that are part of the service provision.

In most organizations, there will be an existing business process for managing fixed assets. Some of these assets will be under the management of IT and will need to be included in the CMS as CIs. It will be important to ensure that there is cooperation between the two areas so that the management of these assets is maintained appropriately.

Configuration item information may be stored in smaller databases, known as configuration management databases (CMDBs). The configuration management system can be made up of a number of CMDBs, because the management and accuracy of a local database may be more effectively achieved. The CMS takes a federated approach to managing the data.

The Description and Definition of Configuration Items

We have spoken a lot about configuration items throughout the purpose, objectives, and scope of SACM, so it is important that we provide some full definitions according the process framework:

These definitions are important both for taking the exam and as part of the process of SACM.

The concept of the configuration item is particularly important. As stated earlier, a configuration item is a service asset that needs to be managed in order to deliver an IT service. The type, size, and complexity of configuration items may vary widely, from a single module of software to a complete system or service, including all hardware, software, and documentation. Configuration items may be managed by grouping individual items together, as in a release.

One of the most crucial factors is to define the level of detail required to manage configuration items successfully. If there is too much detail, it will be difficult to accurately maintain and keep up-to-date the information about them; if there is too little information, then the CMS will not be useful enough. Configuration items should be identified, grouped together, and classified in a way that makes it possible to manage and trace them throughout the service lifecycle.

ITIL suggests a number of different categories for classifying CIs. These are only suggestions; each organization will have to agree on their own categories and the level of detail for each CI, whether an item is a CI in its own right or simply an attribute of another CI. For example, is a desktop PC a CI on its own, with attributes listed as memory, hard drive capacity, monitor, and so on, or are each of these elements identified as CIs that will be under management control?

The categories suggested by ITIL are as follows:

The Description of the Configuration Model

Service asset and configuration management provides a model of the services, assets, and infrastructure by capturing the details of each configuration item and their relationships to each other. You can see an example of this in Figure 9.1.

FIGURE 9.1 Diagram of a configuration model

© Based on Cabinet Office ITIL material. Reproduced under license from the Cabinet Office.

Integrated into a service management system, the configuration model can provide important detail for the support of many service management processes. Imagine the benefits of having this level of connectivity of information about your infrastructure for use by the service desk. A user calls the service desk, and once the analyst has identified them in the system, information about the services, the infrastructure, and the service level agreements they use can be immediately accessible. The same detail can also be used for assessing changes, allowing complete understanding of the interdependencies when proposing to alter a CI. Information relating to cost will be available in the system, for use in financial management. Design for new or changed services will also make use of the configuration management system, enabling future enhancements to the infrastructure to be planned effectively and efficiently.

One of the key benefits of the system is that it is a consolidation of all the information sources into a single repository. That repository can consist of a number of smaller databases, linked so that the information can be connected to maximize the benefits of gathering the data.

The level of detail captured will depend on the value of information to the organization, the ability to manage the data, and whether it is feasible to maintain the level of change control required to ensure accuracy. This has to be an organizational choice, and it is part of the process to ensure that this is planned and executed in a controlled manner.

Using the Configuration Management System

The configuration management system is the system you use to manage the configuration model and deliver the information to those who need it. It is therefore extremely important to ensure that the tool is both fit for purpose and fit for use, just as you would with a system or service being provided directly to your customers and users.

The CMS holds all the information about the CIs that have been identified as part of the process of SACM. Figure 9.2 shows the relationship between the configuration records, actual CIs, and the larger, more complex service knowledge management system (SKMS), of which the CMS is a part.

FIGURE 9.2 Relationship between CMS and SKMS

Based on Cabinet Office ITIL material. Reproduced under license from the Cabinet Office.

The SKMS (which we will cover in more detail in the “Knowledge Management” section) is an overarching system of tools and databases, used for managing all information relating to service management knowledge throughout the service lifecycle. Many CIs are available in the form of knowledge or information (for example, a service level agreement or a report template), and these items will be stored as part of the SKMS. SACM is not responsible for the management of the SKMS.

The CMS may include information from a number of configuration management databases, which allows for the localized management of the data source. Capturing information for a specific site, location, or section of the infrastructure may be easier to manage in smaller segments. However, each CMDB must be constructed with the intention of integration into the CMS, so the naming conventions, structure, and definitions of the data captured must support overall management through the CMS.

Populating the CMS can be achieved by integrating existing information sources and using discovery tools to automatically update or capture information about the infrastructure. These tools can be used to populate CMDBs and then used to verify the accuracy of the information as ongoing maintenance. Although some information may already be in existence in organizations in spreadsheets or databases, wherever possible this should be an automated activity.

All changes to CIs should be managed under the change management process, and any related records and information held in the CMS should be updated as part of this activity. As the CMS maintains the relationships between records such as incidents, problems, known errors, changes, and releases, it is important to ensure that all records are maintained accurately and link to the specific CIs affected in each case.

One of the many benefits of the CMS is the ability to capture and agree on baselines, identifying and agreeing on the state of the infrastructure at a given point in time. Baselines are reviewed and agreed for accuracy and used as a reference point for future activities. Baselines can provide support for the design and planning activities in the service lifecycle, providing historical information or a rollback point for major changes to the live environment. It is also possible to capture a snapshot of the infrastructure, which although unverified and not reviewed (meaning it may contain errors and inaccuracies) is a valuable tool for problem management or the initial assessment of success after a release.

Using a CMS means the data is captured by a multilayer mechanism, as defined by the structure of the SKMS. In this way, you have the ability to capture a variety of information sources, which are then integrated by the information integration layer. Ensuring these are manageable and provide a useful resource, you have a knowledge processing layer and a presentation layer providing access to the information in a usable state.

The integration of various information sources to support the delivery of services is a vital part of service management effectiveness and efficiency, including business information sources, such as HR information.

In Figure 9.3 you can see the different layers of the CMS, their relationship to the SKMS, and additional information sources.

FIGURE 9.3 Architecture of the CMS

© Based on Cabinet Office ITIL material. Reproduced under license from the Cabinet Office.

Using the Definitive Media Library

As we have discussed, some information sources may exist outside of the SKMS or CMS, but there are also aspects of your services that are captured as records in the CMS or SKMS but are in fact physical libraries or stores.

Secure stores or libraries allow you to manage those elements of your infrastructure or CIs that you need to ensure retain their integrity, outside of their operational use. Consider the use of authorized software, purchased under license from a third party. You should ensure you keep a master copy of the software and its associated license documentation in a secure store for use in service continuity situations or to maintain a “clean” version for reinstallation should there be any issues of data integrity in the live environment. This will also apply to unlicensed software developed in-house by your organization.

Records of these CIs should be captured and managed in your CMS (perhaps as a specific CMDB), and in this way you can validate and control the use of the software versions in the live environment. SACM has a large part to play in license management and will be supported by release and deployment management to ensure that only authorized versions are used in the live environment.

Management of the secure library or store should be achieved by SACM controls through change management. The physical store may be actual disks or documents, but there may also be electronic stores if much of your software and its associated documentation is managed electronically. However the media is captured, the definitive media library (DML) is managed to ensure the integrity and security of the authorized versions of software in use in the live environment.

In reality, the DML may consist of a number of software libraries or file storage areas, which are managed and kept separate from the live, test, or development storage areas.

Hardware spares may also need to be controlled, but although this will also be managed by a secure physical store, this is not managed through the DML but as part of the overall management of the infrastructure through the CMS.

It will be important, as part of the planning for SACM, to define the structure, scope, and content of the DML. Consideration will need to be given to the security arrangements for the physical store but also for the security of any electronic media. Basic procedures for backing up electronic media and procedures for ensuring physical data storage is still viable will need to be created. There is no point in having physical data storage if you find that the master copy has lost integrity when you need to restore it. Archiving and changes to technology also need to be considered when managing the DML. What will be the retention policy; how frequently will versions be archived, and which versions of the software will be managed? Will only the latest version be archived, or should the previous versions of software be included?

Information about all CIs held in the secure libraries or physical stores will be held as records in the CMS, and the policies that control the management of the DML will form part of the SKMS.