|
|
Many enterprises implement Asset Management before implementing Configuration Management. The processes in this section apply to both Asset Management and Configuration Management.
Controlling IT infrastructure and services across distributed systems across multiple locations and support groups requires careful planning. This planning should include the Change Management, Configuration Management and Release Management processes, as there are many interdependencies among them.The planning and implementation of a central function for Change Management, Configuration Management and Release Management should be considered, together with support from distributed specialist teams (see Annex 7A).
The initial project planning activities for Configuration Management include:
For all but the smallest systems, Change Management and Configuration Management support tools are essential, as paper-based systems are impractical. Computer hardware and storage resources are required to accommodate Configuration Management tools and, in particular, the CMDB. Support tools should, as a minimum, allow data to be transferred from separate 'project Configuration Management' systems without the need for rekeying. Ideally, the Configuration Management tools for a live system and for development projects should work together in an integrated way.
Once the high-level Configuration Management plan is agreed and signed off, implementation can be planned. A phased implementation is recommended, starting with a well-defined service and the corporate data. This enables the benefits to be demonstrated early and the implementation activities tuned for more effective implementation during subsequent stages.
The purpose, objectives, scope and priorities for Configuration Management should be agreed with the Services Manager and other managers and be aligned to the business requirements. There should be an agreement on whether it is to be incorporated into a central function that includes Change Management and Release Management.
The purpose and scope might be:
To implement consistent Configuration Management, Change Management and Release Management processes for operational environments, package applications and business systems.
The objective might be:
To bring all IT services and infrastructure components, with their associated documentation, under control, and to provide an information service to facilitate the effective and efficient planning, release and implementation of Changes to the IT services.
Detailed objectives for Configuration Management should include:
For many organisations, some form of phased implementation, including Change Management, is essential. The implementation approach may be on an organisational, geographical, Customer group, support group or other basis. Some organisations prioritise the CI types to be controlled.
The highest priorities might be:
Any such priorities have to be balanced with the change in procedures and practices within different groups. It is difficult for teams to implement a mix of processes for Change Management and Configuration Management other than for a short period of time.
The cost of support tools, together with any hardware requirements, needs to be planned. Although tools that integrate support for Incident Management, Change Management, Configuration Management, Release Management, Problem Management and Service Desks are likely to be more expensive than 'simple' Configuration Management tools, the additional cost will often be justified based on what the additional degree of integration makes possible. For larger organisations, these management processes are virtually impossible without adequate support tools.
A central function may be set up to be responsible for managing Changes to hardware, communications equipment and software, system software, live applications software, and all documentation and procedures that are relevant to the running, support and maintenance of live systems. Guidance on setting up a central function is described in Annex 7A.
Configuration Management requires staff who will adopt a painstaking approach and pay due attention to detail. Central support staff are required, other than in very small installations. The following factors should be considered when planning staff numbers for Configuration Management:
A role specification for the Configuration Management team needs to be developed. Examples of the responsibilities are shown in Annex 7B. Typical roles include the Configuration Manager and the Configuration Librarian. Assign the Configuration Manager and other key roles as early as possible, because assigned individuals can then be involved in the implementation as key business Users.
From organisations having no processes at all, some organisations now have many Configuration Management processes and procedures. These may be embedded in other procedures or be specific to one team. If one of the objectives is to introduce a common Configuration Management system with consistent processes, an important activity is to identify and analyse the following:
For some technologies and platforms, Configuration Management may be distributed across the organisation e.g. mainframe, physical networks and desktops. Some organisations devolve control to support groups that have expertise in a particular technology or platform, because it may not be cost-effective to train central staff in specialist areas. In these cases, the support group manager is responsible for the control of CIs owned and maintained by the group. The organisation's procedures for Change Management, Configuration Management, Release Management and a centralised CMDB should be adopted wherever possible. These may be defined in a Change and Configuration Management plan for the organisation (see Annex 7A) and be supported by functional and design documents for the Configuration Management system. The relationships between the plans should be documented to help staff see the context of Configuration Management within their group, with the manager of each group signing off its plan. An example relationship is shown in Figure 7.2.
Lower-level plans should align with, and refer up to, the higher-level plans so as to avoid duplication.
Although there will be situations where organisations' Configuration Management responsibilities will be devolved to individual areas with specific expertise, the ideal is to have a centralised function if resources permit; this ensures common processes and procedures. Devolution, on the other hand, needs careful management and regular auditing for compliance. It is always imperative that there is only one process owner - and this is even more important if there are a number of disparate groups performing Configuration Management.
Figure 7.2-Examples of Configuration Management Plans for an organisation
The Configuration Management plans define the scope of Configuration Management, which is valuable input into system design and the next planning stage.
Once the fundamental decisions on the scope of Configuration Management are made and the planning activities are completed, it is time to devise a plan for implementing Configuration Management. Unless the area is a greenfield site, procedures and records will probably already exist; clearly, there will be a need to plan the implementation with this in mind.
Key activities are as follows:
Extra staff may be required for implementing Configuration Management, auditing the current infrastructure and populating the CMDB. Sometimes managers will assign staff to assist if they see the benefits of Configuration Management and their staff resources are scheduled in advance.
Planning to implement Configuration Management in stages will help to deliver early benefits and establish the need to provide funding and resources for future stages. For each stage, the following activities should be planned:
If Configuration Management is used to underpin other processes, such as Incident Management, further planning is required to roll out the systems in parallel. Local Configuration Management plans may define the CI identification and control processes for specific technology groups. The group manager may assign a Configuration Manager to own the local Configuration Management plan, to liaise with the central Configuration Management staff, and to be a member of the main CAB(s).
Plan to populate the CMDB as the inventory is carried out for each stage of implementation. Time should be allowed to do this correctly. Consider using temporary, but skilled, data-entry staff for this task, although if time allows it may be an opportunity for Configuration Management staff to become familiar with the support tool. If any of the data is already electronically stored for other purposes, consider reformatting and transferring the data.
Ideally the state of CIs should be frozen or held in a low-volatility period during CMDB population, but this may not be practical. However, once Configuration Management data is captured for particular CIs, these CIs should be bought immediately under Configuration Management control. In that case, it may be possible to populate the CMDB in a phased way (e.g. start with the hardware and then gradually progress to software, networks) - see Paragraph 7.5.7.
It may not be possible to bring items under Configuration Management control as the inventory is taken. In this case, plans should be made for procedures to track and record any Changes that occur between the time the inventory is taken and the start of Configuration Management control (e.g. when CMDB population is complete).
When all of the preparation has been completed, the actual switchover will require people to start using the new procedures at the agreed date and time. Publish the implementation date and time for the new procedures to those who are affected - in particular all IT services staff, external suppliers and service providers. Staff should be reminded of their responsibility to adhere to the new procedures from the outset.
CIs should be brought under Configuration Management control as soon as the CI data has been collected. No new items that are in scope should be added to the IT infrastructure outside the control of Configuration Management.
An ideal option for CMDB population is to freeze Changes as the CMDB is being populated. Then every Change has to come under Configuration Management. This may not always be practicable but it is still worth consideration. Configuration Management and Change Management work very closely together - in fact, you cannot really have one without the other. As soon as the CMDB is populated, there has to be some level of Change Management in place to ensure that the configuration records and data are kept up to date.
If this approach is not possible, it is essential to record Changes that occur between collecting CI data, putting the data in the CMDB, and bringing the CIs under Configuration Management control. To do this, the time interval between these phases should be kept to a minimum for each CI. RFCs and Release records corresponding to Changes that are not yet implemented should be captured first. All RFCs from then on should be included in the CMDB. With this approach, the CMDB can be used to record all subsequent Change activity, including authorisation and implementation. The capture of any required historic records can be deferred until it is convenient.
Release Management should populate the Definitive Software Library in parallel with the implementation of the CMDB. Procedures are required to ensure that:
When the necessary staff, hardware and support tools are in place and all necessary training has been completed, the DSL and build environment(s) should be physically created. Security permissions should be established to limit access to authorised staff only. The DSL and build environments should be tested in accordance with criteria defined at the planning stage.
Project and applications staff should be told when to start delivering material and whom to send it to for inclusion in the DSL. Arrangements should be made for appropriate commercial off-the-shelf software to be housed in the CMDB and DSL with their associated documentation (e.g. licences).
Implementation of build management, distribution, and population occur sometime after creation of the DSL. These procedures should be tested before they are brought into use. If a gradual approach has been adopted, the first Release build will be when the deliverables from the selected project or supplier are to be subject to operational acceptance-testing. By the time Releases to the live environment are needed, the build and Release control procedures will have been used for putting software into the operational acceptance-testing environment, thereby providing another chance for many classes of potential problems with procedures and tools to be found and corrected.
Contingency plans should, however, be made in case the new procedures or tools fail. If software Releases are urgently required, it may be necessary to revert temporarily to previous procedures until the new procedures are corrected. Where possible, it is recommended that the procedures or tools for distributing software to sites are tested separately from those for installing and testing the software at the sites, thereby allowing problems with each of these phases to be isolated and corrected separately.
Although the procedures should be thoroughly tested before being brought into live use, time should be allowed to resolve any teething problems in the early stages of live use.
The cutover to the new processes can take place in parallel with CMDB and DSL population. CIs can be gradually brought under Configuration Management control as the CI data is gathered and the information is recorded on the CMDB. Any Changes to CIs that are not yet under Configuration Management control should be communicated to the central function. If possible, CIs affected by Change should immediately be brought under control. All CIs that are new after the Configuration Management system has been switched on should be immediately brought under control.
In many cases, procedural measures and the use of tools to automate some configuration control, Release, distribution and audit processes can prevent - or at least detect - reversion to any previous procedures or practices.
Once the new Configuration Management system is in operation, it is vital that no new items are added to the IT infrastructure without Configuration Management authority. Interfaces to development or procurement, and incoming-goods processes are required to make this happen. Existing items to which Configuration Management control applies (i.e. all CIs other than those temporarily excluded to accommodate a phased implementation) should not be changed without authorisation. All unauthorised CIs/CI versions should be either expunged or brought under Configuration Management control.
Configuration Management for infrastructure and services requires good planning and design to ensure that the objectives and expected benefits can be delivered.
The long-term commitment of management and staff is required for Configuration Management to work effectively. A successful implementation depends on having enough trained staff. If the Configuration Management function is understaffed or staffed by people who have not been adequately trained, it can become a bottleneck. Understaffing can also lead to critical errors, which can cost more to put right than the cost of adequate staffing in the first place. Additional staff may be required for a short period at implementation time (e.g. to assist with the CI inventory and/or populating the CMDB).
It is advisable to implement Configuration Management gradually, starting with those types of CI, or with those parts of the IT infrastructure, where control is perceived as most important or in the greatest need of improvement, and then expanding the system to encompass other areas.
With complex IT systems and services, it is essential to ensure that the Configuration Management system is maintained or the Configuration data will become out-of-date and fall into disrepute. Review and audit activities should be planned to ensure that:
An audit checklist is provided in Annex 7D.
The costs of implementing Configuration Management will be outweighed by the benefits. For example, many organisations cannot function satisfactorily unless they can handle a high volume of software and hardware Changes without sacrificing quality. Without adequate control, organisations are at risk from such things as computer fraud, inadvertent software corruption, software viruses and other malicious software. The damage caused by these can cost an enormous sum to rectify.
The costs associated with implementing a Configuration Management function include staff salaries and overheads, support tools, accommodation costs for the team and training costs. The initial operating costs may be slightly greater than normal, while the staff are learning the procedures.
The practical application of Change Management and Configuration Management will result in a better quality of service, which will more than repay any overhead costs. Overhead costs depend on many factors, including:
There may be an increase in staff costs during the initial data-capture exercise. However, do not make the mistake of categorising Change and Configuration staff as an overhead! If Configuration Management is not performed, there is likely to be a net increase in staffing requirements. Time will have to be spent in correcting things that would not have gone wrong if the disciplines had been in operation, and it will take more staff to handle Changes and Problems.
Other costs for implementation of Configuration Management will depend on:
|
|
