Configuration Mangement:

From HORSE - Holistic Operational Readiness Security Evaluation.
Revision as of 16:12, 23 March 2007 by Mdpeters (talk | contribs) (→‎See also)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Configuration Management

Configuration Management (CM) is an Information Technology Infrastructure Library ITIL IT Service Management ITSM process that tracks all of the individual Configuration Items (CI) in an information system which may be as simple as a single server, or as complex as the entire IT department. In large organizations a configuration manager may be appointed to oversee and manage the CM process.

Configuration item

A CI is an IT asset or a combination of IT assets that may depend and have relationships with other IT processes. A CI will have attributes which may be hierarchical and relationships that will be assigned by the configuration manager in the CM database.

CI attributes

  1. Technical - Data that describes the CI's capabilities which include software version and model numbers, hardware and manufacturer specifications and other technical details like networking speeds and data storage size. Keyboards, mice and cables are considered consumables.
  2. Ownership - Part of financial asset management, ownership attributes record purchase date, warranty, location and responsible person for the CI. Identification numbers like bar codes and type, like software, hardware and documentation are also ownership attributes.
  3. Relationship - The relationships between hardware items, e.g. a printer, software e.g. driver, and user, i.e. Alice.

Configuration Management Database

The fundamental component of CM is the CM database (CMDB) which contains the CI information and is used to understand the CI relationships and track their configuration.

Activities

The information in the CMDB is used for five basic activities:

  1. Planning: The CM plan covers the next three to six months in detail, and the following twelve months in outline. It is reviewed at least twice a year and will include a strategy, policy, scope, objectives, roles and responsibilities, the CM processes, activities and procedures, the CMDB, relationships with other processes and third parties, as well as tools and other resource requirements. The number of CI categories to track in the CMDB determines the scope. The detail of the CI information is the depth.
  2. Identification: The selection, identification and labeling of all CIs which creates a parts list of every CI in the system. This covers the recording of information about CI's, including hardware and software versions, documentation, ownership and other unique identifiers. CIs should be recorded at a level of detail justified by the business need, typically to the level of "independent change". This includes defining the relationships of the CIs in the system.
  3. Control: This gives the assurance that only authorized and identifiable CIs are accepted and recorded from receipt to disposal. It ensures that no CI is added, modified, replaced or removed without the appropriate controlling documentation e.g. approved Requests for Change of a CI, updated specification. All CIs will be under Change Management (ITSM) control.
  4. Monitoring: The status accounting and reporting of all current and historical data concerned with each CI throughout its life-cycle. It enables changes to CIs and tracking of their records through various statuses, e.g. ordered, received, under test, live, under repair, withdrawn or for disposal.
  5. Verification: The reviews and audits that verify the physical existence of CIs, and checks that they are correctly recorded in the CMDB and parts list. It includes the process of verifying Release Management (ITSM) and CM documentation before changes are made to the live environment.

See also