Defining success for ISO 20000, Section 9.1

Submitted by RonBPalmer on Sun, 01/07/2007 - 5:24pm.

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.

More articles from Ron B Palmer 

More about Ron B Palmer


Score: 10.0, Votes: 3

I find this to be very important to define the CMDB and CIs in this context.  If we were to include people and other DBs in the CMDB with other than a pointer I beleive the CMDB would quickly become unmangeable for an organization of even relatively modest size.

 

In studying recently for the ITIL Foundations exam it is much easier to grasp the concept of the CMDB and Configuration Management if the definition is narrowed.

Submitted by awalk5 on Mon, 01/08/2007 - 9:53pm.

Thank you for a thought-provoking article. You have given us all something to think about. There is indeed a danger in putting everything into a CMDB. Managers have to use their judgement and talk to their peers about a given context.

Submitted by majidiqbal on Fri, 01/26/2007 - 1:45pm.

Thank you very much for the great article. I think there is no need for HR data to be in CMDB, because CMDB is federated database where the data called through server request only when needed. But, the data itself doesn't have to reside in CMDB. IT staff data could be part of this deal. But, even though people profiles can be called, this should be restricted to only relevant personnel. For instance, people records are considered CIs in CMDB, only if they are related to the management and the change of the CIs i.e. H/W, S/W and documentation. More specifically a person profile is a CI when the change in the status of that person affect the status any of the CIs.

 

Submitted by mirghani on Sat, 01/27/2007 - 10:02pm.