ITIL Best Practice
As enterprises and their IT support organizations grow, their infrastructures become increasingly fragmented and spread across a variety of functions, technologies and organizations. As this IT infrastructure 'sprawl' continues, efficiency, optimization and overall control over IT resources suffers.
In large and busy enterprises (500 plus changes monthly), organizations often address the IT infrastructure 'sprawl' issue with automated or, in some cases manual, Change 'root cause' analysis tools. However, spreadsheets and manually maintained asset and specific purpose configuration repositories cannot sufficiently take into account the inter-relationships of CIs and fall far short of effective root cause analysis for complex IT infrastructures.
Root cause analysis, then, not supported by an accurate CMDB database and automated business rules that address complex inter-relationship of CIs can be labor-intensive, as well as ineffective.
However, justifying, developing and implementing a CMDB is not an isolated activity, a technology implementation or a database development effort. A CMDB is a means to an end, not an end in itself, and the end(s) are increased ITIL best practice Change Management and control and increased Configuration and Release Management control.
A strategy for CMDB deployment, then, must be developed, the goal of which is to identify and define Configuration Items (CIs) and their relationships; record and report the status of CIs and their related Incidents, Problems and Requests for Change (RFC); and verify the completeness and correctness of CIs. The ITIL best practice strategy should include:
- ITIL Best practice literature review
- Vendor literature review
- Functional attributes critical to the implementation of your CMDB
- An assessment of the current maturity of your organization in relation to
Configuration Management
- A 'model' reflecting the desired 'end state' of your organization in relation to
Configuration Management
CMDB processes must also be developed addressing planning, verification and audit, identification, control, status accounting and reporting on the Configuration Management process. These processes should take into account ITIL Change Management and ITIL Configuration Management best practices.
The business value of an improved Change and Configuration Management process and a CMDB must be developed and documented for use in a business case. Templates can be used to collect data that will assist in the quantification of:
- Business process re-engineering
- Change Management lifecycle improvements - Change Management approval board activities - Change and Configuration Management executions
- Metrics to support and make the case for improved Change and
Configuration Management and the CMDB
The business case should address:
- Change Management as a Basis for the CMDB - Today's Market Value of the CMDB - Business Drivers of the CMDB - Development of a Strategy for the CMDB - Development of the Business Value of the CMDB - Development of the Business Case for a CMDB
Ultimately the CMDB should be profiled as a crucial tool to the improvement of ITIL best practice Service Level Management and an important underpinning to an accurate and effective Asset Management system.
II. Change Management Control as a Basis for CMDB
IDC's January 2007 benchmarking study on CMDB and Change Management deployments claims that the CMDB is all about Change. States Stephen Eliot, research manager for Enterprise Systems' Management Software Service:
"8% of enterprise IT organizations have deployed a CMDB. However, over the next three years, 70% of enterprise IT organizations will consider deploying a CMDB. On average, these organizations make 528 configuration changes a month, which causes an increase in complexity and a high rate of IT service failures. CMDBs are helping and will help IT organizations get infrastructure change under control".
A. It's All About Change
So the business value of a CMDB is all about Change Control? True or False? The answer is "YES" and "YES".
As enterprises and their IT support organizations grow, their infrastructures become increasingly fragmented and spread across a variety of functions, technologies and organizations. It becomes more and more difficult for IT to gain and maintain control over every Configuration Item (CI) encompassed by the infrastructure. Even an asset management database only archives IT's assets and documents the CI locations, without exerting any control over them.
