|
|
There are three aspects of Configuration Management where special guidance can perhaps be given.
Many organisations start by defining very high-level CIs. Identifying critical services and their components is, however, a useful place to start with Configuration Management. Some items may be more critical at particular times of the day or year. Examples of critical or high-risk CIs are:
Some organisations drown in too much detail. They assume that, just because they have low-level details in one part of the structure, this is required throughout all the other configurations. Although this may help consistency and understanding, it will result in poor control data because there could well be insufficient resources to maintain all the data. A replanning exercise may be required to return to an appropriate level of control, using input from the CMDB. Another idea is to have a configuration clean-up or decommissioning activity to remove old kit or redundant items - it also removes the need to maintain the control details.
So the target is maximum control with minimum records.
Although the same CI cannot be used in more than one location on an IT infrastructure, it is quite possible to use a slightly different version of what could otherwise be regarded as the same CI. This slightly different version would have a different version number, and such CIs are called 'variants'.
To appreciate how variants can be useful, consider a computer with two disc drives labelled A and B, both initially using version 1.1. If B is modified to increase the capacity and data-transfer rate, it becomes version 1.1.1. Drive A could be left unmodified to retain backwards compatibility. If a design fault is subsequently found in A and is corrected (taking A to version 1.2), this Change should be propagated to B (taking it to version 1.2.1). A and B could be regarded as different, unrelated CIs; however, it can be advantageous, because they share a large number of common components, to regard one as a variant of the other. Another and very common example of the use of variants is where a 'standard' system is 'customised' for particular applications.
There is normally a trade-off involved. The use of variants can result in fewer CIs to manage and may make it easier to identify items for commonality of treatment, be this in error handling or for the implementation of Changes. The use of variants will, however, introduce extra complexity to the Configuration Management system, and/or other systems such as Problem Management that rely on it.
General guidance is thus: if a CI can be regarded as slightly different from another related CI, and Problems affecting one are likely to affect the other, or Changes made to the one will probably have to be made to the other, then use of a variant should be considered; otherwise, a different CI should be used.
Many software suppliers include some Asset Management or Configuration Management functions in their product offerings. It is important to understand the functionality in the existing and proposed service and system management tools to avoid any overlap or gaps. For example, some tools support only two levels of CI and this can be very restrictive.
As organisations depend increasingly on software, the ability to manage and control all types of software is becoming more important. Care should be taken when selecting software Configuration Management tools to make sure that a range of the organisation's platforms can be supported or your organisation may end up with a tool for every platform. The ability to control software files automatically can save time and reduce errors. The length of the identifier is crucial with software, because there are often duplicate filenames in different parts of a structure.
|
|
