How Does Software Development Fit in with ITIL's Configuration Management Database?

Many organisations or groups who develop software consider themselves outside the scope of ITIL – considering it something that is only relevant to IT Operations and Support groups. This was perhaps understandable with ITIL V2, and yet we believe it is no longer the case with ITIL V3. We shall address this in more detail below.  This article focuses on a subset of ITIL processes and in particular the CMDB/CMS.

Misunderstandings and Evolution of the term CMDB
In ITIL V2, the term CMDB was often misunderstood – its definition: “A database that contains all relevant details of each CI and details of the important relationships between CIs”. This lead many people to think of it as a single database in which everything should be stored that related to Configuration Items.

It was never the intention of the ITIL authors that the CMDB should be defined as a single physical thing – it is a logical concept that is implemented via a number of physical systems (that in many cases already existed) that could be termed “CMDBs”.

Many vendors should share in the blame, in that they saw a tremendous market opportunity, and rather over hyped the particular capabilities of their CMDB solution(s).

One of the key problems with defining a usable CMDB is being very clear as to what results you want to get out of it. What information do you actually need to be able to better plan and manage the services your organisation provides?

Network discovery tools can discover reams of information about objects on your network, including PCs, laptops, routers, servers etc. For each item discovered, you can also get details down to which versions or patch level of operating systems and applications are installed.

The problem is, most of that information is not relevant to managing a service where you may need the answer to the question “the power to rack X in the data centre has gone down – which services are affected?”. If you put all that unnecessary information into a CMDB (which some organisations did) you make it more complicated and larger than it needs to be, more difficult to navigate etc.

There also needs to confidence in the data within the repository – confidence that it reflects the real world.

This resulted in some rather large and expensive projects to define, collect and feed data into their CMDBs – rather brings to mind Audrey II in Little Shop of Horrors – “Feed me, Seymour, feed me!”. The problem with the resulting CMDB projects, was that at least Audrey II provided success and romance to Seymour! The monster CMDBs consumed vast amounts of data and gave back out-dated, inconsistent and partial results back (if they gave any at all) – and thus quickly fell into disuse.

What Changed with ITIL V3?
Quite a lot! ITIL V3 focuses a lot on delivering value and business outcomes. It focuses on ensuring that all service assets (including applications) optimise the value of a service and its service performance. This clarifies and strengthens the link between best practice and the business benefits.

As David Norfolk writes in The Register  in [an article on Service Design]: http://www.theregister.co.uk/2007/10/10/itil_service_design/ Sharon  Taylor , ITIL's chief architect, summarises the aims of Service Design  rather well in the foreword to this volume: "In the past, the IT world  has been viewed in two parts - the development world and the