|
|
The planning of Configuration Management should reference existing procedures and plans wherever possible, in order to keep things simple and to avoid duplication. A Configuration Management plan should define:
Plan the first three to six months in significant detail and the following twelve months in outline. Performance relative to the plan should be reviewed regularly - at least every six months - and should include the Configuration Management workload for the period and the resources needed to service it. Checks should be made to ensure that the staff, IT resources, and support tools - including the size of the CMDB to be made available to Configuration Management - are likely to be adequate.
Where deficiencies are identified, steps should be taken to obtain further resources or procure enhanced support tools.
It is generally a fact that Configuration Management activity grows with the passage of time. The number of CIs under control and the frequency of Changes affecting them will vary. Information on growth should be available from the organisation's IT service, workload and capacity plans. IT Service Management may also decide to implement Changes in the light of management reports, efficiency/effectiveness reviews, and audits of the Configuration Management function.
At each review point, Configuration Management plans for the preceding period should be compared with actual events. Any deficiencies in the planning process should be rectified to improve future planning.
In considering the future work of the Configuration Management group, IT Service Management should ensure that only required Configuration Management data is handled; redundant data should be purged. The cost of keeping and capturing CI details should be compared with current and potential benefits; if the current level of detail is costing too much, do not store it!
The IT infrastructure configuration should be broken down and uniquely identified to enable effective control, recording and reporting of CIs to the level that the business requires. As a rough guide, this could be to the level of 'independent Change'. The scope should include the hardware, and software used to build, release, verify, install, distribute, maintain, recover and decommission CIs. This includes any environments and software tools used to build a CI. Examples of the components that should be identified are:
It is important to consider the degree of granularity that is required. Is it sufficient, for example, to merely register a PC at 'PC' level or to go deeper so as to consider the monitor, the base unit, the keyboard and the mouse - or even register the network card, the type of hard disk, and so forth. The same question can be applied to software (on module, submodule, or whatever level). Besides discussing the level of granularity required, a lot of discussion in practice is about scope: are telephones included, should SLAs, and so forth.
Consider the size of database to be created and the problems of maintenance and audit - is it really necessary to open up each PC and check each component at each audit? Before deciding on these issues, consider how to plan maintainance of the database and what to do with the information being maintained. How, for example, will one thousand PCs be updated to show that a new software Release has been installed on each one? Is the database to be used to estimate the financial value of the infrastructure for audit purposes? What is the value to the business of holding low level data?
Configuration structures should describe the relationship and position of CIs in each structure. In addition to the infrastructure configuration structure, there should be service configuration structures that identify all the components in a particular service (e.g. the retail service).
CIs should be selected by applying a decomposition process to the top-level item using guidance criteria for the selection of CIs. A CI can exist as part of any number of different CIs or CI sets at the same time. For instance, a database product may be used by many applications. Usage links to reusable and common components of the service should be defined - for instance, a configuration structure for a retail service will use infrastructure CIs such as servers, network and software CIs. The ability to have multiple views through different configuration structures improves impact analysis, service reporting, Change Management and Release Management.
The CI level chosen depends on the business and service requirements. Try to decide in advance the lowest CI level that will be required, even if you do not immediately populate the CMDB down to that level. It is worthwhile spending time on this activity and being as forward-looking as possible. It may save costly reorganisations of the CMDB in the future. However, deciding the right level of CIs in advance is not always easy. If possible, obtain a Configuration Management support tool that does not unduly constrain further breakdown of CIs to lower level ones. If this is not possible select a tool that allows the recording of properties of individual CIs, such as build level. Examples of an infrastructure and configuration breakdown are shown in Figures 7.3, 7.4 and 7.5.
Figure 7.3-Example configuration breakdown structure
Figure 7.4-Example infrastructure
Figure 7.5-Example configuration breakdown structure (for the infrastructure in Figure 7.4
Although a 'child' CI should be 'owned' by one 'parent' CI, it can be 'used by' any number of other CIs. If standard software configurations (sets) are used (e.g. all the terminals on a nationwide network have access to identical software sets), then these sets can be defined and 'access' relationships established to the sets. This can considerably reduce the number of relationships that are needed, compared with when individual software CIs relationships are used.
In some cases, a network service may be regarded as part of, or is used by, the IT infrastructure, but cannot be brought under Configuration Management control. For example, an external Wide Area Network (WAN) owned by another organisation can be represented as a single high-level CI with all connections to the network as 'used by' or 'connected to' relationships. Figure 7.6 shows how these relationships might be defined.
Choosing the right CI level is a matter of achieving a balance between information availability, the right level of control, and the resources and effort needed to support it. For example if a Change is to be made to module 1-2-2 in Figure 7.3, it is better to record the Change at module level rather than program level - but it will be more costly to populate and maintain the CMDB down to module level.
On the other hand, actual Changes should be made at the level recorded in the CMDB. Therefore, if it is decided that the CMDB will record software at program level, Changes should be made at this level. For example, if a single module is to be changed, it will be necessary to recompile the whole program to make the Change at program level.
If information at a low CI level would not be valuable - for example, if a keyboard is not usually exchanged independently, or the organisation sees it as a consumable - do not store it. CI information is valuable only if it facilitates the management of Change, the control of Incidents and Problems, or the control of assets that can be independently moved, copied or changed.
The organisation should plan to review the CI level on a regular basis - to confirm (or otherwise) that information down to a low level still valuable and useful, and that the handling of Changes and Problems and the management of assets are not deficient because the CMDB does not go to a sufficiently low level.
Figure 7.6-Example of an external network
Components should be classified into CI types because this helps to identify and document what is in use, the status of the items and where they are located. Typical CI types are: software products, business systems, system software, servers, mainframes, workstations, laptops, routers and hubs.
The life-cycle states for each CI type should also be defined; e.g. an application Release may be registered, accepted, installed, or withdrawn. An example of a life-cycle for a package application Release is shown in Figure 7.7. The role that can promote the CI should be defined, e.g. Configuration Management, Release Management.
Figure 7.7-Example of an application Release life-cycle on the IT infrastructure
Configuration Management should plan which attributes are to be recorded. As the required attributes may vary for different types of CI, consideration should be given to only current and forecast CI types. Note that some support tools may dictate the decision. Annex 7C gives a suggested list of attributes that should be recorded. It is useful to have an attribute to identify high-risk or critical CIs.
The relationships between CIs should be stored so as to provide dependency information. For example:
There may be many more types of relationships, but all of these relationships are held in the CMDB - this is one of the major differences between what is recorded in a CMDB and what is held in an asset register.
A mechanism is required for associating RFCs, Incident records (IRs), Problem records, Known Errors and Release records with the IT infrastructure CIs to which they refer. All these relationships should be included in the CMDB. RFC, and all Change and Release records should identify the CIs affected. These records should also identify the make-up of the Changes. See Chapter 9, Release Management, for further details.
Physical and electronic software libraries should be uniquely identified with the following information:
A configuration baseline may be created for any or all of the following reasons:
Configuration baselines should be unique to their purpose, and the CIs and information to be controlled in the baseline, including all commercial off-the-shelf products and proprietary items with their associated documentation. Configuration baselines should include the associated configuration documentation, including:
Configuration baselines should be established by formal agreement at specific points in time and used as departure points for the formal control of a configuration. Configuration baselines plus approved Changes to those baselines together constitute the currently approved configuration. Specific examples of baselines that may be identified are thus
Several baselines corresponding to different stages in the life of a 'baselined item', can exist at any given time - for example, the baseline for a software Release that is currently live, the one that was last live and has now been archived, the one that will next be installed (subject to Change under Configuration Management control), and one or more under test. Furthermore, if, for instance, new software is being introduced gradually on a regional basis, more than one version of a baseline could be 'live' at the same time. It is therefore best to refer to each by a unique version number, rather than 'live', 'next', 'old'.
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:
Configuration Management should arrange for a naming convention to be established for all CIs and control forms, e.g. RFCs. Individual instances of CIs should be uniquely identifiable by means of the CI's name, copy/serial number and version. (The details of copy/serial number and version need to be in the CMDB, but need not be part of the unique identifier.) The version identifies a changed version of what can be regarded as the same CI. More than one version of the same CI can coexist at the same time.
When the naming convention is being planned, it is very important that sufficient account is taken of possible future growth. Identifiers should be relatively short, but meaningful, and should re-use any existing conventions wherever possible. For hardware, if the CI naming conventions are not based on suppliers' device names and serial numbers, a mechanism should be set up to relate Configuration Management and suppliers' identifiers to each other - for example, for the convenience of hardware engineers.
Release records, Change records and other CIs that are 'associated with' the IT infrastructure all need CI identifiers. A simple naming scheme, such as R1, R2, R3, R4,... is recommended, with version numbers used to indicate Changes - for example to Release plans.
All CIs should be labelled with the configuration identifier so that they can be easily identified. Plans should be made to label CIs and to maintain the accuracy of their labels.
Physical non-removable labels should be attached to all hardware CIs. All cables/lines should be clearly labelled at each end and at any inspection points. It is advisable to use a standard format and colour for all such labels, because this makes it easier for Users to identify and quote from them, for instance when telephoning the Service Desk to report a fault. Barcode-readable labels improve the efficiency of physical audits.
Definitive copies of software in the DSL should have a software label containing the CI name and version number at the start of the file. All media containing software should be clearly labelled with the CI name, copy number and version number of each of the software items contained on the media (as well as the CI name and serial number of the medium itself).
Definitive copies of documentation should never be issued, but should be retained in a documentation library. If a document will change at some known future date, then a shelf-life date could also be included (e.g. 'the contents of this document are not valid after 30 September 2002').
The objective of configuration control is to ensure that only authorised and identifiable CIs are recorded in the CMDB upon receipt. The procedures should protect the integrity of the enterprise's data, systems and processes. When a Change is processed, the components being changed move through a number of planned/agreed states. Examples of states are: 'registered', 'fit for use', 'installed', 'in use', 'withdrawn', 'for disposal', 'disposed' and 'under Change'. Procedural and technical controls should be introduced to ensure that unauthorised Change is virtually impossible.
Licences should be managed and the total licence holding updated as CIs are added, updated, withdrawn or decommissioned. Procedures are required to ensure that relevant licence fees have been correctly paid and all irrelevant ones have been stopped, and that the organisation has complied with all legal restrictions relating to bought-in software.
The on-going configuration control processes are:
The process of registration begins with items being ordered or with development being commissioned. Some organisations use their procurement process to ensure that CIs are added when they are ordered. Suppliers may also participate by labelling CIs prior to dispatch. In this way the ordering and delivery of CIs is under Configuration Management control.
All deliveries should be recorded and their contents verified. See paragraph 7.6.4 (Configuration status accounting) for guidance on verification. If the software or hardware does not satisfy the check, rectification action is initiated. Licence holdings and attributes should be updated.
For software developed in house, the point of 'receipt' is normally the point at which software is ready for operational acceptance. The use of a DSL is recommended, where all software CIs and their documentation are held in their definitive, quality-controlled state. Registration procedures should ensure that details of all authorised software and supporting documentation CIs are entered in the CMDB before the CIs are transferred from the development library into the DSL. The status of the CIs should be altered when they enter the DSL (e.g. from 'planned' to 'present'). Ideally, the utility program or support tool that does the physical library transfer should carry out the CMDB update automatically. Unauthorised or corrupt items should not be allowed in the DSL.
For software CIs that have been configuration-managed during their development stages using the same CMDB, only a status Change, rather than a new entry, may need to be made initially. If a shared database is used for development and live CIs, access controls should be applied to limit access to only the appropriate staff - for example, development staff should only have access to development CIs. If a different tool or database has been used, the CI data should be transferred into the new CMDB. Ideally the CI data should not need rekeying.
Procedures should be planned for off-the-shelf CIs, including hardware, communications equipment, documentation, software packages, operating systems software and utilities. Change Management should ensure that all authorised new CIs are correctly registered in the CMDB before they are delivered and that the status of these CIs is changed as they are delivered, installed, tested and accepted. A check should be made that delivered CIs are authorised. Installation procedures should not commence until this check has been satisfactorily carried out.
Good build and Release controls ensure that updated versions of software and hardware are built correctly and distributed to target environments that are compatible with the Release. Configuration Management with Release Management should record and report the versions of software, hardware and documentation that were the result of the build and Release processes. This includes:
When software quality-control checks are successful, the software is authorised for acceptance and copied into the DSL. Care should be taken to ensure that software is not corrupted or changed during the copying or distribution processes.
The status of CIs changes as they progress from delivery to live use. Ideally, the CMDB should be updated automatically as the status of CIs and Releases changes. Associated documentation, such as test certificates and licences, should be placed in a controlled document library.
Changes to the attributes of CIs in the CMDB should be updated with a related RFC that authorises the Change to the attribute. If corrections need to made to the attributes - for example, after an audit - a Change record should be raised to track the attribute updates.
In many organisations it is difficult to keep up with Changes in ownership and roles, particularly where there is a high staff turnover or contract staff. Procedures to update the CMDB with Changes in ownership are essential in order to ensure that Requests for Change, Incidents and Problems related to CIs are notified to the right parties.
To ensure all IT infrastructure items are as authorised by Change Management, a record of all authorised Changes and enhancements is made on the CMDB. Once a Change is implemented, the CMDB should be amended to show the Change in status of CIs affected by the Change.
Configuration Management should verify that secure master copies of software, documentation, data, licences and agreements for supply, warranty and maintenance are lodged within the Configuration Management system or DSL.
The terms and conditions relating to the purchase of software may place legal restrictions on the organisation (e.g. no unauthorised copies to be made). It is particularly important, therefore, regardless of who carries out the implementation, that the CMDB is updated with details of who holds copies of software items. This assists the organisation in discharging its legal obligations, and it assists auditors and the Service Desk to check for the existence of unauthorised copies.
Scheduling and controlling the removal and disposal of CIs is often important for financial and security reasons. There should be procedures in place for decommissioning equipment or software so as to ensure correct disposal of the organisation's assets, and that the relevant records (e.g licence holding, number of desktops supported by a supplier) are updated. The CMDB should be updated and the status of the CIs promoted to the final state, e.g. 'withdrawn' or 'archived'.
To protect the integrity of the configuration and to provide the basis for the control of Change, it is essential that CIs, their constituent parts and their documentation be held in an environment that:
The processes for procurement, storage, dispatch, receipt and disposal of goods should ensure that equipment, software and documentation is delivered safely to its destination. Storage areas should be secure. Checks on delivery documentation against goods coming into the organisation should be completed and recorded. Installation, environmental and electrical checks should be planned and completed by the appropriate people (not Configuration Management) before connection to the network. Access controls should be defined and enforced so as to provide staff with the correct level of access to the Configuration Management database, physical hardware, software and documentation.
Configuration Management should ensure the integrity of the stored software CIs, irrespective of the medium or library, by:
Consistent replication of CIs is important in order to ensure that no extraneous items (such as software viruses or test data) are introduced. It is important to use a suitable medium to ensure the software and associated documentation arrives in the condition in which it was replicated. The medium should be selected to preserve the integrity of the contents over the expected life of service delivery.
Configuration Management should ensure that the delivered medium is prepared by approved procedures and should label the medium with the identification of the Release. Software distribution should be designed to ensure that the integrity of software is maintained whilst handling, packaging and delivering software. Automated software distribution to remote locations will save resources and reduce the distribution cycle time. After distributing software over a network it is essential to check that the Release is complete when it reaches its destination.
All IT staff should be asked to report any instances where they detect unauthorised CIs, or CIs that do not match the information on the CMDB. Depending upon their level of authority, IT staff should:
Configuration Management should trace the origin of each unregistered item and propose or initiate actions to register, correct, or delete the CIs. The deficiencies that allowed unregistered items to slip through should be corrected and reported to management. Sensitive handling may be required so as to avoid creating a 'black market' in unregistered CIs (e.g. unauthorised compact discs, software from the Internet).
Status reports should be produced on a regular basis, listing, for all CIs under control, their current version and Change history. Status accounting reports on the current, previous and planned states of the CIs should include:
Status accounting reports can be used to establish system baselines and enable Changes between baselines and Releases to be traceable. Status reports may include:
Before a major Release or Change, an audit of a specific configuration may be required to ensure that the Customer's environment matches the CMDB. Before acceptance into the live environment, new Releases, builds, equipment and standards should be verified against the contracted or specified requirements. There should be a test certificate that proves that the functional requirements of a new or updated CI have been verified, or some other relevant document (i.e. RFC).
Physical configuration audits should be carried out to verify that the 'as-built' configuration of a CI conforms to its 'as-planned' configuration and its associated documents. Interrogation facilities are required to check that the CMDB and the physical state of CIs are consistent.
Plans should be made for regular configuration audits to check that the CMDB is consistent with the physical state of all CIs, and vice versa. These audits should verify that correct and authorised versions of CIs exist, and that only such CIs exist, and are in use in the operational environment. From the outset, any ad-hoc tools, test equipment, personal computers and other 'non-registered' items should either be removed or registered through formal Configuration Management. Non-registered and unauthorised items that somehow make an appearance during configuration audits should be investigated, and corrective action should be taken to address possible issues with procedures and the behaviour of personnel. All exceptions should be logged and reported.
The configuration audits should check in addition that Change and Release records have been properly authorised by Change Management and that implemented Changes are as authorised. Configuration audits should be considered at the following times:
Automated audit tools enable regular checks to be made at regular intervals, e.g. weekly. For example, desktop audit tools compare the build of an individual's desktop to the master build that was installed. If exceptions are found, some organisations return the build to its original state. A rolling programme of configuration audits can help utilise resources more effectively. The Service Desk and support groups should be instructed to check that CIs brought to their attention, e.g the software that a caller is using, are as recorded in the CMDB. Any deviations should be reported to Configuration Management for investigation.
If there is a high incidence of unauthorised CIs detected, the frequency of configuration audits should be increased, certainly for those parts of the IT infrastructure affected by this problem. Note that unauthorised installations are discouraged when the Configuration Management team is seen to be in control and to carry out regular and frequent audits. If an epidemic of unauthorised CIs is detected, selective or general configuration audits should be initiated to determine the scale of the problem, to put matters right, and to discourage a proliferation of unauthorised CIs. Publicity will help to reduce further occurrences.
Back-up copies of the CMDB should be taken regularly and securely stored. It is advisable for one copy to be stored at a remote location for use in the event of a disaster. The frequency of copying and the retention policy will be dependent on the size and volatility of the IT infrastructure and the CMDB. Certain tools may allow selective copying of CI records that are new or have been changed.
The CMDB contains information on back-up copies of CIs. It will also contain historical records of CIs and CI versions that are archived, and possibly also of deleted CIs or CI versions. The amount of historical information to be retained depends on its usefulness to the organisation. The retention policy on historical CI records should be regularly reviewed, and changed if necessary. If the cost to the organisation of retaining CI information is greater than the current or potential value, do not retain it.
Typically, the CMDB should contain records only for items that are physically available or could be easily created using procedures known to, and under the control of Configuration Management. When Configuration Management has been operating for a period of time, regular housekeeping should be carried out to ensure that redundant CI records are systematically deleted.
Configuration Management should add value to the Service Management organisation. Recommended services of the function comprise:
|
|
