By ITIL® from Experience ©
The responsibility for the relationships between Configuration Items (CI) is relatively simple when the CIs are owned and maintained by the same group of specialists. For example, with the appropriate process it is relatively easy for the Networking Group to maintain the relationships between network components. The challenge happens when CIs depend on CIs that are managed by a different organizational units or technical specialists teams.
Asking CI owners to maintain an inventory of what is on their items and how they are being used is difficult. Questions quickly arise like:
- Should the Application group maintain the relationship that their application "runs on" a particular server?
- Is it the responsibility of the server group to know what is installed on their servers?
- Who is responsible to identify the switch a server is connected to? The Server Group or the Networking Group?
For applications, it is very difficult for the Server Group to identify the relationship between their CI and the application hosted on it without an in-depth knowledge of the various application components. Of course, discovery tools can help. However, the result is often overwhelming and it is difficult to distinguish between what is installed automatically by the application, what is installed manually and configured to make it functional, let alone determine the type of dependencies.
A similar challenge happens when I.T. map dependencies between the business and applications. For example, it is straight forward to assume that the billing system is used to produce invoices. But, it is difficult for I.T. to know that the Finance Department also depends on the billing system to prepare the cash-flow management forecasts. Thus, the business is best suited to identify the dependencies it has to applications (i.e. relationships). This explains why effective Business Impact Analysis must include the Business. Moreover, it is the equivalent of asking the car mechanic to identify how the car owner uses the car and how dependent he/she is on the vehicle for their day to day business.
As a result, relationships are best established and managed from the top down or in other words, whoever installed or connected to it (e.g. who uses the service/device instead of to whom is supplying it).
This approach also makes sense from a Change Management and Release Management perspective. It is easy for the individual who last changed the CI to ensure that the relationship(s) are updated in the CMDB. Therefore, the individual completing the Request For Change (RFC) is responsible for the relationship between the application and the server as being “runs on” or “dependent on”, etc. As a result, each layer is responsible to determine how it relates to the layer below.
Even though sophisticated auto discovery tools can automatically maintain these relationships as soon as a discrepancy arises, knowing who is responsible for the relationship makes it straightforward for the right people to resolved it (see Why is the CMDB inaccurate).
Last updated on: 2016-12-15
"A configuration item is an asset in its context.
- How many Configuration Librarian(s) do we need
- Which CIs to load first in the CMDB
- We need a strategy and roadmap to implement a CMDB
- Is there a standard we can use for the CMDB structure.
- Should we automatically import auto-discovered CIs in the CMDB
- Should everyone be allowed to create CIs
Copyright 2013-2016 - ITIL® from Experience - D.Matte<HR>