|
|
Configuration Management 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 Management. 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 is the selection, identification and labelling 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, licences, 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. This matter is covered in more depth in Paragraph 7.6.2, but to provide an illustration, 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 shown is a CI, including the total system.
Figure 7.1 - Configuration breakdown
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 is concerned with ensuring that only authorised 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 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 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.
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.
Many organisations 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 licence. An additional bonus is the use of the CMDB to cover the legal aspects associated with the maintenance of licences and contracts.
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 authorised 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 authorised 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. For details see Chapter 9 - Release 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 licences, from purchase to disposal. Software licence 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 licences 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 organisation's Security Policy (see the ITIL book on Security Management-ISBN 0-11-330014-x).
|
|
