Friday, March 29, 2024

Plugging into the Nerve Center of ITSM

Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

The Configuration Management Database (CMDB) concept of ITIL seems to

generate the most questions from readers and may stem from the relatively

small amount of information on the Web regarding it. So let’s take a few

moments to look at the seemingly arcane CMDB, and remove the needless

cloak of mysticism around it.

The CMDB is a relational database that serves as the nerve center of IT

service management. While the word ‘configuration’ makes people think it

is tracking build information, it is far greater than that. The CMDB

represents a logical model of IT. As such, it is tasked with tracking

configuration items (CI), attributes (metadata) about each and, very

importantly, their relationships to one another.

The CMDB can be all in one database or interfaced together (federated) to

preserve normalization of data, ease of collection, etc.

First off, everything is a configuration item. Hardware, software,

people, accommodations (ITIL’s term for facilities), data files,

documentation (including data records), and services are all top-level

CIs. What an organization uses, and how they use it, are based on their

needs.

For example, under hardware, maybe they need tables for each CI type to

track network devices, servers, storage devices, etc. Records, such as

those for changes, problems and incidents, also are CIs and need to be

defined based on business need. In general, you want to use a CI when

one-to-many and many-to-many relationships exist. However, risk or other

needs also may prompt you to define a class of CIs vs. simply using

attributes.

A good way to think of attributes is that they are the data fields that

make up the CI tables. As an example of CI vs. attribute, would you want

to have a field in the server CI record called ‘Operating System’ or

would you want a CI called ‘Operating System’ that then had attributes

defining each type of operating system in use? The correct answer depends

on your needs.

At the heart, we know we need to understand some basic elemental

attributes regardless of CI type such as:

  • CI ID — a unique identifier for the CI that is then referenced in

    documentation, etc.;

  • Status — Has the CI been purchased, in testing, in production, or

    has it been retired? You want enough meaningful status values to

    represent the lifecycle of the CI;

  • Supplier — Who did you buy it from? This could be the external

    vendor ID or the internal department;

  • Purchase Date — When was it purchased? You may need to know this

    for calculating the book value;

  • Purchase Cost — You need the total purchase cost information

    associated with the CI. In other words, work with accounting to make sure

    that the correct total purchase cost is entered. This may include

    purchase price, shipping, professional services, etc.

  • Security Information — What security information is needed about

    this CI? ITIL is big on confidentiality, integrity and availability

    (CIA), but you should use what makes the most sense;

  • IT Owner — In IT, who is responsible for this CI?
  • Physical Location — Where is it located? Depending on the CI, some

    groups may need to know the physical location as well as logical

    locations;

  • Production Date — When did this CI enter production?
  • Comments — Miscellaneous comments (Be careful. Don’t let this

    attribute evolve into something unmanageable.)

    For each CI type, you may add, change or delete attributes as needed, but

    you want to keep the CI structure both meaningful and manageable. If the

    CMDB becomes too complex to maintain, then its value plummets and people

    will stop using the system out of frustration.

    Database table relationships could be as follows:

  • Parent Relationships — What assembled/compound CIs uses this CI as

    a component?

  • Child Relationships — If this is an assembled/compound CI, what

    component CIs make it up?

  • RFC Records — Need to relate this CI to all request for change made

    against it. This may be the same as the change record IDs but it’s listed

    separately here. The reason is to show all RFCs — accepted and rejected;

  • Change Records — Relate this CI to all changes made to it. This

    allows for the Change Manager and other stakeholders to gauge historical

    activity;

  • Problem Records — What problems has this CI been associated with?
  • Incident Records — What incidents have this CI been associated

    with?

    Moving along, assembled or compound CIs are made up of n-levels of

    hierarchically grouped components. A SQL Server is made up of hardware,

    software and documentation. A service is made up of hardware, software,

    documentation, and people. The idea is to understand how CIs are

    assembled for cost, impact analysis, overall planning and so on. For

    those people with a manufacturing systems background, think of an

    assembled CI as being analogous to a bill of material (BOM).

    One of the most important outputs of Configuration Management is the

    documentation of relationship. It is critical that the CMDB be able to

    relate all of the various CI types together. These relationships allow

    for Change Management to do impact analysis.

    If I allow this change to happen, what are the risks? Who and what are

    involved? By having the relationships in the CMDB, the Change Manager can

    begin to answer those questions.

    The bottom line is that the CMDB is the hub system of all activity in the

    world of IT Service Management. The exact tables and composition should

    be driven by the needs of the business, then the services that support

    those needs and finally the resources that comprise each service that IT

    delivers. When people ask what a CMDB should look like, they must realize

    that there is no one-size-fits-all answer. They must work to understand

    what the business needs, what IT needs and then design a data model that

    meets those requirements.

    Note: For further reference, the ITIL Service Support volume lists

    potential CI attributes in Annex 7C of Configuration Management.

  • Subscribe to Data Insider

    Learn the latest news and best practices about data science, big data analytics, artificial intelligence, data security, and more.

    Similar articles

    Get the Free Newsletter!

    Subscribe to Data Insider for top news, trends & analysis

    Latest Articles