There is significant confusion in the ITIL community about the Configuration Management Database (CMDB) and Configuration Management. Some people believe that the CMDB includes every database and data-store used by IT to manage systems (I was formerly in this camp.) Others believe the CMDB is made up of only hardware and Software Configuration Items (CI). Many find themselves somewhere in the middle with fuzzy boundaries around what is and is not part of the CMDB.
In the past this has been something of a philosophical discussion. However, with the introduction of ISO/IEC 20000 (ISO 20K) in December of last year, this discussion becomes critical for any company pursuing ISO 20K certification.
ISO 20K contains a sub-section on Configuration Management (9.1) with no fewer than sixteen requirements for certification (Shall Statements) and thirty-one guidance statements (Should Statements). Three of the Shall Statements directly reference the CMDB. Now confusion about what is and is not contained in the CMDB can mean the difference between success and failure of an ISO 20K certification audit.
One of the classic discussions in the Foundations course is “can people be considered a Configuration Item (CI)?” If you answer yes then you open the door to including people’s HR information in the CMDB. If you answer no then you loose significant ability to relate CI and manage IT. When pursuing ISO 20000 certification the auditor’s opinion on this subject becomes critical?
A careful read of the Configuration Management chapter in the ITIL Service Support book leads me to define the CMDB very narrowly as containing only hardware, software, and those components directly related to providing a service. When CI are required that do not fit this description, I believe they should be included only as pointers to other data stores.
Most ITIL Foundations courses teach that people can be considered CI. In this scenario the CI for an individual should hold only one attribute, a record pointer to the HR database. This allows us to create relationships without creating a CMDB without boundaries. From a technical perspective, if we need additional information about this person we query other data-stores, i.e. the HR database, the roles database, etc.
Defining the CMDB in such a narrow fashion accomplishes some important things. It highlights a critical deficiency in ITIL guidance; the lack of a decision support/data integration process. It creates necessary conditions for successful CMDB implementation projects. And, if defined formally in the Configuration Management Plan, it sets the standard by which the ISO 20K auditor measures conformity to the Shall and Should Statements in section 9.1 of the ISO 20000 standard.
From a certification perspective, it is often not critical where you draw the line on a contentious issue. What is critical is that you formally draw a line and ensure that your processes are appropriate relative to the line drawn. In other words if you thoughtfully and appropriately define the CMDB in the Configuration Management Plan and you fulfill the Shall Statements relative to the definition in the plan you “Should” meet the auditing requirements. At the very least, if the auditor disagrees, he or she is placed in the position of defending his or her interpretation of ITIL.
Defining the CMDB is tantamount to defining success for your ISO 20000 audit.