Asset & Config Management
Table of Contents
  "Configuration management is really the IT organization's (ITO) version of the Hippocratic oath... To do no harm in the IT environment, the ITO needs to know about what it has and how it all fits together... to understand the capabilities and limitations of each item, and how that item will be impacted by changes in the environment. If an innocent-looking wire is pulled out over here, what will the result be over there?R"

Process Requires Re-writing for conformance with ITIL Version 3.

More...

Visit my web site

Introduction to Asset and Configuration Management

Asset and Configuration Management is a process within the Service Transition module of the ITIL Service Lifecycle.

Click to whole Service livecycle

  • Gone are the days when the resident shop “guru” is your single contact for information regarding your complete infrastructure architecture and all the associated components. The platforms that support service delivery are too complex and integrated for any one individual or group to identify.
  • How many times have your Service Desk staff wished for a quick reference of all customers and their services affected by a failing IT infrastructure component?
  • How often has your organization struggled with the identification of the technical components that enable the delivery of a service in order to set and measure meaningful service level objectives in support of Service Level Agreements?

It is the underlying process of Configuration Management that positions an organization to identify, track, record and report on IT infrastructure data as it relates to the management, costing and delivery of IT services."

Activating Configuration Management In an It Organization, Hewlett=Packard Whitepaper, 2001, p. 4

In many systems the technical staff operate on a knife-edge of nervous tension caused by a lack of confidence in whether changes will work or cause problems. Why ? - because of the complex inter-relationships which build up between components in a computer configuration. Errors in configurations can open the IT infrastructure up to security vulnerabilities and introduce conflicts that result in service outages. In addition, with the onslaught of regulatory compliance mandates demanding companies to institute stringent controls within IT, managing configurations has become one of the key areas where IT controls can be established. For example, employing best practices for security-related configurations or establishing patch management processes are areas where configuration management can help protect corporate data. A small change to one part of a configuration can have an unexpected interaction elsewhere for no obvious reason. Clearly, it would be useful if the support staff could have a snap shot of the individual components of the whole configuration so as to advise on:-

A Configuration Management Database (CMDB) should describe the "Known and trusted state" of the infrastructure. Only when this is highly defined, can faults and changes to that known state be properly identified and analyzed for potential impact. The impact analysis establishes the priority status of various components of the infrastructure for subsequent treatment in the event of failure or upgrade to maintain availability and overall performance commitments.

“When analyzing performance issues, most IT operations groups focus on their change, problem, release/software distribution and asset management processes. Yet, many of these problems are actually caused by inadequate configuration management, rather than the primary operations process in question. Configuration management provides essential information and auditing support for more than 50 percent of all critical IT operational processes.”

Aperture Systems - Technical Brief

Everything within the CMDB is a CI, which are hierarchically decomposable. The Configuration Management business processes are all based around the concept of CIs. CIs comprise the Configuration Management Database (CMDB). The CMDB may consist of a single or multiple distinct databases. In a large organization this repository might contain information on thousands of Configuration Items (CIs). Maintaining an accurate inventory complete with reliable inter-relationships amongst the components is a formidable undertaking. In short, while a goal to be striven for, 100% accuracy will be almost impossible to obtain at acceptable costs. There will be trade-offs required between the accuracy of the database and the costs required to maintain it.

Configuration Management (CM) and a Configuration Management Database (CMDB) are difficult processes to administer well. While it may be relatively easy to produce an inventory of IT hardware assets, it is far more difficult to assess and track the inter-relationships amongst hardware and between hardware and software products on a continuing basis. Even the initial exercise of database population may involve daunting complexities which are compounded by considerations of how to keep the data current. For this reason Configuration Management policies will stress the importance of Change Management as the primary vehicle for modifying the CMDB.

In later years Discovery Tools have been increasingly used to uncover computer assets throughout networks. As Asset Management tools, they are very effective in locating workstations, servers and the software resident on these machines. However, modifying the discovery tool to include rules by which one Configuration Item relates to others is problematic at best and may be totally impractical for some kinds of relationships. This means that Assets cannot be totally purged at regular intervals as the results of one scan replacing those of another. Instead, the results of scans must typically update certain fields in a CI record while retaining much of the relationship data intact. The addition of relationship fields in a CMDB is what renders its' maintenance far more difficult than an Asset database. These relationships, however, are what make the CMDB a far more useful tool for other ITIL processes such as the Incident, Problem, Change, Release and Service Level Management.

Lastly, the concepts of CMDB is converging with that of a metadata repository, but, have yet to assume the rigour attached to the use of metadata models. Some authors have commented that ITIL-inspired implementations pay "insufficient attention to the data structures required to meet CMDB requirements. These data structures– including the user-defined Configuration Item concept– are meta-models, and the data they contain is metadata (data about data and the systems that manage it).".Ref.

[To top of Page]

Asset and Configuration Management

Objectives Coverage Policies Scaling Concepts Roles Measuring Processes Appendix

Objectives

The objectives of configuration management are to:

Critical Success Factors

[To top of Page]

Process Coverage

Configuration Management (CM) covers the identification, recording, and reporting of IT components, including their versions, constituent components and relationships.

Scope

In Scope
Items under the control of Configuration Management include:

Usually Excluded

Discretionary

Process Inter-relationships

Relationship with Change and Configuration Management processes
Most commentaries, frameworks and models treat Configuration, Change and Release Management either together N or inextricably linkedN .

Area Emphasized

Change Management
Creating a CMDB is a whopping challenge," Casson said. "To do it correctly you have to use a change process to update every configuration item. We're not sure the market really understands that. For most IT shops, asset management is still done in the silos. It's not unusual to find a dozen different asset databases out there. To get to a federated configuration repository is a huge challenge, and you have to update it and create a systems awareness of it."

Managers Underutilize ITIL, Survey Says, By Paula Musich, August 17, 2005

"Before attempting to implement any of the Configuration management activities, the organization must ensure, that the Change Management process has been implemented and operated at a mature level. Without a well-established Change Management process, the integrity of the CMDB cannot be maintained."

Implementing Service and Support Management Processes: A Practical Guide, ISBN: 90-77212-43-4

Release Management
CM provides :

Build and Test

Incident Management
Incident Management provides a feedback to the Configuration Management process re CI accuracy.

Problem Management
Configuration Management provides the infrastructure data required to identify the root cause of incidents and to determine the course of action for problems.

Operations Management
CM Provides :

Service Planning

Security Management
The Configuration Management CMDB is used to store information about security specific CIs, such as firewalls.

Availability Management

Financial Management

Service Level Management

Capacity Management

IT Strategy Development

Customer Management
Configuration Management Is used to access current customer information and to update new customer information.

[To top of Page]

Policies & Guidelines

[To top of Page]

How the Process Scales

Small organization's may be able to maintain an inventory of their assets in a spreadsheet. However, this is a difficult vehicle to describe component dependencies and inter-relationships. Larger organizations will select an Asset database as a means to keep track of assets, particularly workstations and laptops which have a propensity to disappear. Often the savings due to the more effective control of licences is enough to pay for the Asset system.

The introduction of a viable Change Management system leads to the need for better identification of the impact of changes. Describing what applications and operating systems reside on a server and what servers are implicated in an application are examples. This information facilitates risk assessment and better decision-making about when and how to conduct changes. Because maintaining these relationships is a major administrative chore, the organization may populate a CMDB with only the CIs most often experiencing change or most important to the enterprise. This is usually servers and mission critical applications.

The inclusion of services and documents into a real or virtual CMDB reflects and organization's commitment to a highly organized approach to resource management. [To top of Page]

Concepts

Configuration Management Planning

Configuration Management planning consists of agreeing and defining:

CMDB Design

It is importamnt to decide the core information which needs to be stored in the CMDB and which information can be kept in other repositories that link to the CMDBN.

A configuration item (CI) contains three types of dataR:

"Using the federated CMDB approach, data that should be stored in the CMDB is sorted out from data that should not. By providing a simple means to access detailed and related CI data stored in other repositories, we can build a CMDB that will be much easier to manage, maintain, and scale while continuing to leverage existing investments in different IT management technologies. It is this core value proposition that makes the federated CMDB approach so important ."

Federation and a CMDB, BMC Whitepaper available at Bitepipe

CI relationships are described by: Association Inverse Association
Accessed ByAccesses
Connected ToConnected To
Documented ByDocuments
Impacted ByImpacts
Installed OnRunning
Interfaces WithInterfaces With
Member OfContains
Served byServes
Supported OnSupports
Used ByUses
Instance OfHosts Instance
Parent OfChild Of
Associated WithAssociated With

Hardware
Hardware specific policies and guidelines:

Software
Software specific policies and guidelines:

Documentation
The types of Documentation that will be put under change Management include:

Configuration Identification and CIs

"Critical configuration data includes both static asset inventory and licensing information, the mapping of assets to owners and users, and run-time information about device and software settings, parameters, patch levels, and so forth. Tools are needed to federate and correlate this information and identify dependencies and relationships across servers, storage, software, security and provisioning platforms. Making robust, accurate, configuration data management systems available is an imperative, as IT staff cannot be expected to make the right decisions if they don't have access to the right information

Getting Started with Change and Configuration Management Process Improvement, Mary Johnson Turner, BMC Whitepaper, July, 2005

Configuration Identification is the selection, identification and labeling of the configuration structures and CIs, including their respective 'owner' and the relationships between them. CIs may be hardware, software, documentation or key personnel. Examples include services, servers, environments, equipment, network components, desktops, mobile units, applications, licenses, telecommunication services, and facilities. Configuration identification includes allocating identifiers for CIs, including individual versions of the CI and their configuration documents. Other records and data associated with a CI include Incidents, Known Errors and Problems, and corporate data about employees, suppliers, locations, business units, and procedures.

Configuration Associations 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. This matter is covered in more depth later, but to provide an illustration, Figure "A" shows example System A - which is an assembly of components A1, A2, A3. Each of these components can be broken down into smaller components. Each of the components shown is a CI, including the total system.

In distributed environments, individual components occur 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. Correct configuration identification and documentation enables Change Management to be effective by knowing fully the potential impact of a particular change.

Data ReconciliationR
A CMDB must provide capabilities that help rationalize diverse IT infrastructure data - ie., coming from multiple discovery sources, to existing data repositories, to IT applications. A reconciliation process helps rationalize this data, bring it into a common format, and ultimately uses the data to help keep an accurate representation of the IT environment stored within a CMDB, which can then by leveraged by IT processes.

There are different approaches and capabilities for data reconciliation, but all revolve around three important activities. Working together to ensure consistency and accuracy across Cl data stored within a CMDB, these three activities comprise:

Configuration Control

Configuration Control is concerned with ensuring that only authorized and identifiable CIs are recorded from receipt to disposal. It ensures that no CI is added, modified, replaced or removed without appropriate controlling documentation e.g. an approved Change request.

Configuration Status Accounting

Configuration status accounting is the reporting of all current and historical data concerned with each CI throughout its life-cycle. It enables tracking of changes to CIs and their records, e.g. tracking the status as a CI changes from one state to another.

Configuration Verification and Audit

Configuration verification and audit comprises a series of reviews and audits that verify the physical existence of CIs and check that the CIs are correctly recorded in the CMDB and controlled libraries. It includes the verification of Release and configuration documentation before changing the live environment.

Configuration Baseline

A Configuration Baseline is the configuration of a product or system established at a specific point in time, which captures both the structure and details of a configuration. It serves as reference for further activities. An application or software baseline provides the ability to change or to rebuild a specific version at a later date. A configuration baseline is also a snapshot, or a position, that is recorded. Although the position may be updated later, the configuration baseline remains fixed as the original state and is thus available to be compared with the current position. A configuration baseline is used to assemble all relevant components in readiness for a Change or Release, and to provide the basis for a configuration audit and regression, e.g. after a Change. The Configuration Management system should be able to save, protect and report on a configuration baseline, its contents and documentation.

Configuration Management Database (CMDB)

Many organizations are already using some elements of Configuration Management, often using spreadsheets, local databases or paper-based systems. In today's large and complex IT infrastructures, Configuration Management requires the use of support tools, which includes a Configuration Management Database (CMDB). Physical and electronic libraries are needed along with the CMDB to hold definitive copies of software and documentation.

The CMDB is likely to be based upon database technology that provides flexible and powerful interrogation facilities. A few examples of its potential use are to list:

The CMDB should hold the relationships between all system components, including Incidents, Problems, Known Errors, Changes and Releases. The CMDB also contains information about Incidents, Known Errors and Problems, and corporate data about employees, suppliers, locations and business units.

Automated processes to load and update the Configuration Management database should be developed where possible so as to reduce errors and reduce costs. Discovery tools, inventory and audit tools, enterprise systems and network management tools can be interfaced to the CMDB. These tools can be used initially to populate the CMDB, and subsequently to compare the actual 'live' configuration with the records stored in the CMDB.

The CMDB may also be used to store and control details of IT Users, IT staff and business units, although the legal implications of holding information about people in the CMDB should be considered. Storing such information in the CMDB would allow personnel Changes to be related to Changes in CI ownership.

In addition to storing personnel information, the CMDB is often used for Service Level Management to hold details of services and to relate them to the underlying IT components. The CMDB is also used to store inventory details of CIs, such as supplier, cost, purchase date and renewal date for a license. An additional bonus is the use of the CMDB to cover the legal aspects associated with the maintenance of licenses and contracts.

Software and Document Libraries

A controlled library is a collection of software or document CIs of known type and status. Access to items in a controlled library should be restricted. Software libraries are used for controlling and releasing software throughout the systems development life-cycle, e.g. in development, building, testing and operations.

Definitive Software Library (DSL)

The Definitive Software Library (DSL) is the term used for the library in which the definitive authorized versions of all software CIs are stored and protected. It is a physical library or storage repository where master copies of software versions are placed. This one logical storage area may in reality consist of one or more physical software libraries or file stores. The libraries should be separate from development, test or live file store areas. The DSL may also include a physical store to hold master copies of bought-in software, e.g. a fireproof safe. Only authorized software should be accepted into the DSL, strictly controlled by Change and Release Management.

The DSL is a common foundation for the Release Management and Configuration Management processes.

License Management

Company directors, senior managers, and others, are liable to face imprisonment and fines if illegal software is found to be in use within their enterprise. Configuration Management enables an enterprise to monitor and control software licenses, from purchase to disposal. Software license structures, and corporate and multi-licensing schemes, need to be understood and communicated to service-provider staff and Customers. Responsibility for controlling and auditing software licenses should be unambiguous and should involve purchasing and Asset or Configuration Management. This may be difficult when Users find it so easy to purchase and download software from the Internet, but this can be resolved by links to disciplinary procedures detailed within the organization's Security Policy.

Roles and Responsibilities

Configuration Management Process Owner

Owns the Configuration Management Process at all levels.

Configuration Manager

The Configuration Manager is responsible for managing the operational activities. The Manager is involved in ensuring integration with other Service Management processes. The Manager is also involved in developing the configuration management database (CMDB) data model, core policies, maintenance processes and procedures, key performance indicators and ongoing management reports. Responsibilities include:

Configuration Coordinator

Technical domains often maintain records of the assets under their management and control, often using data repositories in spreadsheets and databases. This data needs to be consolidated and transferred to a central CMDB. It stands to reason that due to the complexity of the infrastructure and the sheer number of CIs to be managed, these technical domains could maintain the data within the physical layer of the CMDB data model under their control. Each technical domain should establish and formalize a role responsible for ensuring active and consistent updating of the configuration management database.

Responsibilities are as follows:

CI Owner

The CI Owners function involves planning, design, development and implementation activities and they are responsible for:

Operations

Operations is responsible for supporting the CI infrastructure, including:

[To top of Page]

Performance Measurement

Configuration Management should continually assess the efficiency and effectiveness of the Configuration Management system using regular management reports. A review of the expected growth of demand of Configuration Management activities should be scheduled on a regular basis, for example, every six months, although in more volatile situations more frequent reviews may be appropriate.

Management Reporting

Management reports for Configuration Management should cover the following:

Management reports should be designed to support Service Management activities such as progress monitoring, Problem Management, Change Management, Release Management, Configuration audits and service planning. The reports should be made available for interrogation and trend analysis by IT Service Management and other groups within the IT services structure.

In general, IT Service Management should set the future direction for Configuration Management in the light of these management reports, taking account of the planned Configuration Management workload and growth.

Key Performance Indicators

Measurable targets for objective metrics will be set for the effectiveness of the Configuration Management process. The following metrics will have set targets designed to improve them over a realistic timeframe:

Other indicators and targets that will be looked at include:

[To top of Page]

Processes

Configuration Management Summary

Controls
  • Policies and Guidelines
  • CI naming conventions
  • relationship definitions
  • Configuration Verification procedures
Inputs
  • Configuration baselines
  • Software and document libraries
  • Approved RfCs
  • CI Ownership
  • Service Request updates
  • Incident Management updates
  • Change Management updates
Activities
Outputs
  • Management Reports
  • CI Status accounting
  • Configuration audits
Mechanisms
  • CMDB population
  • CMDB updating
  • Discovery tools

[To top of Page]

Activities

CfM1 - CMDB/ CI Planning
Staged Implementation
Configuration Management and CMDB implementation is an important IT asset and pivotal to an organization's ability to centrally manage IT resources and improve its' ITIL-managed processes. While ITIL Configuration Management best practices can provide guidance in devising and implementing a CMDB its' ultimate form will be conditional on a number of organizational factors which will either be difficult to articulate at the outset or will be constantly evolving as the technology tools and internal infrastructure characteristics adapt and change. A staged implementation which allows the organization to adopt a 'pivot position' (ie., a position from which it can take a number of courses of action - that is, achieve flexibility) is desirable.

Single or Multiple CMDBs
If multiple, logical CMDBs are designed, single primary keys will need to be defined to link to the Local level CMDBs, such as CI # or CI (logical) name. Access to the Local level CMDBs must be provided to the people requiring more information than is contained in the Enterprise level CMDB in order to manage service delivery. This is stated as a concern for the purpose of recording this as an option to consider upon implementation of Phases II and III. Remedy Service Desk - "out of the box" is a single data base containing generalized attributes, some of which may not be relevant for particular kinds of CIs.

Granularity
When planning to activate a Configuration Management process, the organization will need to determine the breadth, depth and scope of the CMDB and the associated costs linked to these decisions. As detailed in figure "B", the CMDB breadth includes the definition of CI attributes, the CMDB depth or level includes the number and degree of CI relationships that are maintained and the CMDB scope involves identifying which CIs will be stored. The deeper and broader the scope and level of the CMDB design exponentially increases the cost of initial population and ongoing maintenance of the infrastructure data.

CMDB Granularity

Secure Discovery Tool

In order to populate and maintain the accuracy of asset records it is necessary to secure a discovery tool. Possible alternatives include:

Initial Implementation
As depicted in Figure 1, Once the CMDB is defined and all data sources and migration strategies have been identified, it is critical to ensure that as soon as the CMDB is populated it is under change control, otherwise the CMDB will soon be out of date. Once an initial load of the CMDB is completed a physical audit should be performed against that information. This information will then validated and updated online. Once the audit is complete and the information updated the CMDB is submitted to Change control to be placed into production. From this point all changes to the CMDB should go through the change management process.

Cfm2 - CMDB Maintenance

Identification
Configuration Identification is the function of identifying the CIs (building-blocks) of a system for the purpose of systematically controlling changes to this configuration and maintaining the integrity and traceability of this configuration throughout the system lifecycle.

CI Selection
The selection of CIs should be determined by the organization's need to control specific components of its infrastructure. It should be optimized to allow proper control both in the acquisition and in-service stages.

It must be emphasized that whenever items are not selected as CIs, it does not necessarily mean that the configuration of those items is not controlled. Their configuration could be controlled through the documentation of a higher level item that has been selected as a CI (e.g., a PC disk drive is controlled by the standard desktop model in production).

If any asset falls under the CI Category Tree Structure then it will need to be brought under CFM.

CI Labeling
Naming conventions should be established and applied to the identification of CIs, configuration documents and Changes, as well as to baselines, Releases and assemblies. 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 permit the management of:

CI Control
Once Configuration Items have been identified and documented, they themselves are placed under Configuration Management. Service Providers are responsible for ensuring that changes to the infrastructure are implemented as approved in RfCs and that all changes to Configuration Items, resulting from approved changes, are reflected back into the CMDB. To be useful, the list of Configuration Items must be easily accessible and readily amendable. Appropriate tools/mechanisms will be put in place to provide for ease of update while ensuring the integrity of this departmental resource.

An important aspect of CM is the concept of baseline management. A baseline is a reference point in the development or lifecycle; at the end of each stage of system lifecycle a formal baseline should be defined. In-service lifecycle management on operational baseline is maintained through Configuration Management.

CI Status Accounting
Configuration status accounting is the reporting of all current and historical data concerned with each CI throughout its life cycle. It involves recording and reporting the status of a CI throughout its' lifecycle. This process is tightly linked to the Change Management process, which instigates changes to the status of a CI.

A CI exists in the production environment in a number of different states. Possible states include:

[To top of Page]

CfM3 - CMDB Verification

Configuration Verification can be defined as the processes or procedures used to ensure Configuration Control is executed consistently and effectively. Configuration Audit can be defined as the process of verifying that the identified infrastructure, systems and software configurations are what they are declared to be. Under the ITIL methodology, this process is described as comparing data within the CM Repository to the actual physical infrastructure.

[To top of Page]

Appendix

Terminology Best Practices in Establishing CMDB Pinkscan Criteria

Terms
TermDefinition
Asset ManagementThe business process that manages an asset throughout its financial lifecycle. Asset Management includes activities such as contract management, cost depreciation, total cost of ownership, total value of ownership and obsolescence for each asset.
Asset Management DatabaseMaintain details on assets above a certain value, their business unit and location. Relationships to other assets are not usually recorded.
Change CalendarA documented record of the sequence of steps involved in building a release (implementing a change).
Change ManagementProcess of controlling Changes to the infrastructure or any aspect of services, in a controlled manner, enabling approved Changes with minimum disruption.
Configuration BaselineA frozen "picture" of the IT environment at a set point in time that identifies the structure of the IT environment and the underlying dependencies of the components of that environment.
Configuration Item (CI)Component of an infrastructure - or an item, such as a Request for Change, associated with an infrastructure - that is (or is to be) under the control of Configuration Management.CIs may vary widely in complexity, size and type, from an entire system (including all hardware, software and documentation) to a single module or a minor hardware component.
Configuration Management Database (CMDB)A database that contains all relevant details of each CI and details of the important relationships between CIs.
Definitive Software Library (DSL)Term used to describe a secure compound in which the definitive authorized versions of all software CIs are stored and protected. This one Storage area may in reality consist of one or more software libraries or file-storage areas. It contains the master copy of all controlled software in the organization. The DSL should include definitive copies of purchased software (along with license documents or information), as well as software developed on site. Master copies of controlled documentation for a system will also be stored in the DSL form.
EnvironmentA collection of hardware, software, network and procedures that work together to provide a discrete type of computer service. There may be one or more environments on a physical platform e.g. test, production. An environment has unique features and characteristics that dictate how they are administered in similar, yet diverse, manners.
Forward Schedule of Changesee Change Calendar
IncidentAny event that is not part of the standard operation of a service and that causes, or may cause, an interruption to, or a reduction in, the quality of that service.
ProcessA connected series of actions, activities, Changes etc. performed by agents with the intent of satisfying a purpose or achieving a goal.
Process ControlThe process of planning and regulating, with the objective of performing a process in an effective and efficient way.
ReleaseA collection of new and/or changed CIs which are tested and introduced into the live environment together.
Release ManagementThe process of coordinating and managing releases to a live environment to ensure that releases are implemented in a controlled and systematic way that limits negative impacts to the IT environment.
Request for Change (RFC)Form, or screen, used to record details of a request for a Change to any CI within an infrastructure or to procedures and items associated with the infrastructure.
Service Level AgreementA written agreement between a service provider and Customer(s) that documents agreed services and the levels at which they are provided at various costs.
SystemAn integrated composite that consists of one or more of the processes, hardware, software, facilities and people, that provides a capability to satisfy a stated need or objective.

[To top of Page]

Best practices for developing a CMDB

The following provides some best practices for developing a CMDB:

[To top of Page]

PinkScan Configuration Criteria

A "Pinkscan" is a set of criteria used by Pink Elephant to assess the capabilities of a Configuration Management or Asset tool to be ITIL compliant. PinkScan Criteria:

[To top of Page]


Visit my web site