Business requires quality IT services provided economically. To be efficient and effective, all organisations need to control their IT infrastructure and services. Configuration Management provided a logical model of the infrastructure or a service by identifying, controlling, maintaining and verifying the versions of Configuration Items (CIs) in existence.
The goals of Configuration Management
The scope of Configuration Management
Configuration Managment covers the identification, recording, and reporting of IT components including their visions, constituent components, including their versions, constituent components, and relationships. Items that should be under the control of Configuration Management include hardware, software, and associated documentation. Given the definition above, it should be clear that Configuration Management is not synonymous with Asset Managment, although the two disciplines are related. Asset Management is a recognized accountancy process that includes depreciation accounting. Asset Management systems maintain details on assets above a certain value, their business unit, and their location. Configuration Management also maintains relationships between assets, which Asset Managment usually does not. Some organisations start with Asset Management and then move on to Configuration Management.
Configuration Management covers the identification, recording, and reporting of IT components, including their versions, constituent components, and relationships. The item that should be under the control of Configuration Management includes hardware, software, and associated documentation. Given the definition above, it should be clear that Configuration Management is not synonymous with Asset Management, although the two disciplines are related. Asset Management is a recognized accountancy process that includes depreciation accounting. Asset Management systems maintain details on assets above a certain value, their business unit, and their location. Configuration Management also maintains relationships between assets, which Asset Management usually does not. Some organisations start with Asset Management and then move on to Configuration Management.
The basic activities of Configuration Management are:
Planning. Planning and defining the purpose, scope, objectives, policies, and procedures, and the organizational and technical context, for Configuration Management.
Identification. Selecting and identifying the configuration structures for all the infrastructure’s CIs, including their ‘owner’ their interrelationships and configuration documentation. It includes allocating identifiers and version numbers for Cis, labeling each item, and entering it on the Configuration Management Database (CMDB).
Control. Ensuring 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 appropriate controlling documentation, e.g. an approved Change request, and an updated specification.
Status accounting. The reporting of all current and historical data concerned with each CI throughout its life cycle. This enables Changes to CIs and their records to be traceable, e.g. tracking the status of a CI as it changes from one state to another for instance ‘under development’, being tested’, or ‘withdrawn’.
Verification and audit. A series of reviews and audits that verify the physical existence of CIs and check that they are correctly recorded in the Configuration Management system.
Configuration Management interfaces directly with systems development, testing, Change Management and Release Management to incorporate new and updated product deliverables. Control should be passed from the projector supplier to the service provider at the scheduled time with accurate configuration records.
Basic Concepts
configuration planning consists of agreeing and defining:
The configuration policy/strategy sets the objectives and key success factors (KSFs) of what should be achieved by configuration Managment. The detailed activities and resources required to achieve the objectives and KSFs in the Strategy may be documented in a project plan. The milestones are often summarised in the Configuration Management Plan.
Configuration identification and CIs
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 or documentation. 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. 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.
Figure 7.1 Configuration Breakdown
Figure 7.1 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 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.
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, replace or removed without appropriate controlling documentation e.g. an approved Change request.
Configuration status accounting with each CI
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, e.g. ‘development’, ’test’, ‘live’ or ‘withdrawn’.
Configuration verification and audit
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, e.g ‘development’, ’test’,; live, or ‘withdrawn’.
Configuration baseline
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 a 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
Many organizations are already using some elements of Configuration Managment, 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. 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 databases 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 systems 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 cost. 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 personal information, 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. 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 filestores. The libraries should be separate from development, test or live filestore 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.
License Mangement
Company director, senior managers, and others are liable to face imprisonment and fines if the illegal software is found to be in use within their enterprise. Configuration Mangement 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.
"*" geeft vereiste velden aan
