Implementation of a CMDB
A successful CMDB can be vital for an organisation, or rather it should be!
The implementation of a CMDB, should herald the dawn of a new era: The transformation of an organisation from being a reactive and Technology/System managed based Service Provider, to being a truly proactive Service based Service Provider
A CMDB enables the visibility of accurate representations of a service, release or environment that enable multiple benefits including:
- Better forecasting and planning of changes
- For changes and releases to be assessed, planned and delivered successfully
- For incidents and problems to be delivered successfully
- For service levels and warranties to be delivered
- Improved adherence to standards, legal and regulatory obligations
- The ability to identify the costs for a service
However, in practice, very few CMDBs are successful! Industry analysts disagree on the precise number, although there is consensus that fewer than ten percent of Service Providers effectively utilise their CMDB to support their IT service management initiatives. Indeed, this depressing statistic has led to the creation of the “Five Percent Club”, i.e. that elite 5% of organisations who actually succeed in justifying and implementing a CMDB.
This begs the question, “Why!?”
Our own experience can shed some light on this.
Often too little thought is given to and organisation’s CMDB design which in the absence of an underpinning vision and enabling strategy, is often conducted in an ad hoc manner. A vision and enabling strategy is essential to meet stakeholders needs, which raises the next question, “who are the CMDB’s stakeholders and what are their needs?”. A CMDB offers potential benefits to stakeholders across the organisation. However therein lies a danger. CMDB projects often seek to be “all things to all men” and are insufficiently focused to realise real value to anyone.
The absence of a vision and supporting strategy commonly typically mean that:
- Contain superfluous, and Configuration Item (Ci) Types and Attributes
- Are missing key Ci Types and Attributes
- Ci Types are not structured to form a coherent hierarchy, i.e. Tiers that discern Business Service, IT Service, Logical and Physical CI Types from one another
- CMDB’s predominantly contain Physical and Logical CI Types with an absence of Business Service and IT Service CI Types
- CMDB’s re not supported by controls and process to ensure their completeness and integrity
- Contain a multitude of potential relationship types that do not follow a logical model, are undefined, open to interpretation and applied inconsistently
These factors severely impede the organisation’s CMDB from being able to provide the core capability of a good practice CMDB, i.e. the capability to be able to define the relationships necessary to enable business service to be modelled and the associated impact analysis to be conducted.
By Eddie Potts
Webinar on CMDB Implementation by Peter Hubbard