Is there a prevalent confusion between CI and CI record? (for the benefit of new people, between Configuration Items and Configuration Item records)
(Sorry –  I am going into some thing fundamental. But can’t help it when have to keep answering those queries many a time…)

I want to use the following examples for the related confusions that I come across –

  • ‘CMDB contains CIs!’ –A fundamental misinterpretation, when you are talking about ITSM’s CMDB (or CMS) as per ITIL. I will get back to this in a moment.
  • ‘Is a document a CI? so that need to be stored in CMDB?’
  • ‘Are incident and change records CIs? so do we need store them in CMDB?’
  • and so on…

I mentioned above the notion ‘CMDB contains CIs’ is a fundamental misinterpretation. Before some of you barge on this (or me! :-)) let me explain:

ITSM CMDB (as represented in ITIL) contains ‘information about’ CIsnot the CIs themselves. It will contain the information about a Server (assuming the Server is identified as a CI) – attributes, status and relationships. So it might be a better way to say CMDB contains CI records.

So how do we differentiate CIs from CI records? (must be obvious by now):

  • CI is an designated element in your service management scope (any significant element in your service management canbe a CI – irrespective of it is physicl, logical, hard or soft etc etc – Any designated Service Asset , if you are conversant with V3).
  • A CI record is an ‘information record’ which contains the information about the designated CI. Each identifed CI should have a corresponding CI record in the CMDB (or CMS). These information about the CI is generally as attributes, status and relationships.

Coming to the question quoted above regarding documents, Documents can be CIs – most definitely. But the corresponding CI record will be stored in the CMDB – not the document itself.

What would the CI record contain for a document CI?

As in most  ITIL answers, it depends! 🙂

Here are some indicative examples:

  • Attributes like – name, author, owner, version number etc
  • Status  – draft, under review, live, archived,
  • Relationship with other CIs – ‘used to manage’ Service A (CI # xyz123),  ‘is a sub-process of’ Process X (CI# abc567)

Coming to the question about Incident records, Change records etc, here is my take on that:

We need to be clear here on one thing: Are we considering  A change as CI or an RFC (Request for Change) or the change record as a CI?

Most often than not,  we want considering a change as the CI, then the RFC can be treated as the CI record for the same (similar explanation can be used for incidents).

Now, if so, do we need to store all RFCs in the CMDB?

I would rather treat the RFC repository as a part of my larger CMS – and create relationships to other CIs in that. Attributes and status are anyway a part of the RFC.

Can you consider each RFC as CI – yes you can. But am not sure about the value you might get from treating each RFC as a separate CI and then maintaining an information record for that. If there is a value, that also can be done…

I would like to hear the thoughts and inputs from others on this…

Advertisements