Expecting the Unexpected: Unexpected CIs in the CMDB

Overview – or, why do I care about unexpected CIs anyways?
 
Many CMDB administrators focus their time on ensuring that discovery is functioning as it should, looking for issues reported through the CMDB health dashboard and working to ensure processes are running smoothly to detect duplicates, stale CIs, etc.  However, one of the areas in the CMDB that gets very little attention is the concept of unexpected CIs.  While the existence of unexpected CIs isn’t reported on the CMDB health dashboard (today at least), it is also a very important indicator of CMDB health and can highlight areas where things may not be running smoothly.
 
What is an unexpected CI?  Before we go there, let’s do a quick review of how inheritance works in the CMDB.
 
CMDB Inheritance and the "container" classes
​ 
Remember that the CMDB classes work in an inheritance model, like a tree with cmdb_ci at the top.  As you start moving down the branches of the tree, the different classes in the middle (we will call these “container” classes) are useful as aggregation points for CI classes.  A good example of this is cmdb_ci_server, which is the branch point for cmdb_ci_linux_server, cmdb_ci_win_server, etc.  As a result, the inheritance structure (tree) looks something like this:

​Fig 1.  Sample inheritance tree for cmdb_ci_linux_server
 
 
In the CMDB inheritance model, attributes defined at one level are inherited by all classes below that definition point.  So for example, defining an attribute at cmdb_ci_computer makes it visible to cmdb_ci_server and cmdb_ci_linux_server.  Using the tree above as a guideline, the CMDB administrator can carefully plan out CI attributes so that they are inherited correctly by subclasses but do not appear in classes where they do not make sense (such as having “Service Pack” as an attribute for a network adapter).  The “container” classes such as cmdb_ci_server are very useful for providing aggregation points for defining attributes that apply to multiple child classes.
 
If we’re doing things correctly, we find that as we move down the tree and start getting more specific, classes start to have more attributes.  Those attributes are only visible at the definition point and below; so for example, kernel_release (defined in cmdb_ci_linux_server) is not visible at cmdb_ci_hardware.
 
Where we get into issues – Unexpected CIs
 
As we’ve seen above, the “container” classes are very useful in building the inheritance model, for defining parent-child relationships, and are key to instrumenting attribute inheritance.  However, while these are useful classes for CMDB schema definition, they generally are not a good place to store actual CIs, as they do not directly represent an object in the technology environment (you didn’t deploy a “hardware”, you deployed a “Linux server”).  Where we get into trouble is when we start finding CIs show up in the container classes like cmdb_ci_hardware.  So when we start seeing CIs showing up as being based in a “container” class, we call those unexpected CIs.
 
Why we care about unexpected CIs 

They may seem benign, but unexpected CIs can really mess up a lot of what should be working with the CMDB.  Some reasons why unexpected CIs are something to be concerned with include:

• We generally want CIs to appear in the most specific class that represents that CI.  This way we are sure that attributes created specific to that class are populated.  The data in the CMDB is all designed to inform processes and provide context.  These attributes are there for a reason, and not having this data harms the effectiveness of the platform overall.
  • For example, a Linux server stored in  would not have attributes for “Kernel Release” or “Operating System”, so how will you know what team to route an Incident to for this CI?  How would you even know it’s a Linux server? 
• Often times we use reference qualifiers to limit CI selection in process forms.  The reference qualifiers may unintentionally exclude CIs if they are contained in an unexpected “container” class that would not pass the qualifier.
  • For example, a Network Change ticket may only allow items that are children of , making CIs in  invisible.
• Unexpected CIs are an indicator of issues with CMDB data integrity.  Some method of populating or updating the CMDB has gone wrong, and CIs are being added or moved to the wrong class.  This could happen for any number of reasons, such as: 
  • Users are adding CIs in the wrong place manually 
  • Someone did a data import to the wrong table 
  • Discovery is not correctly performing classification of discovered CIs 
  • An integration has gone haywire 

 
Regardless of how they got there, unexpected CIs are an important indicator of CMDB health and should be on the CMDB administrator’s list of items to watch out for and remediate.
 
Commit to doing the work

Make sure you set aside the time and resources to stay on top of the unexpected, and that includes planning to catch and remediate unexpected CIs.  Unexpected CIs are not just one-off anomalies, but are an important indicator of CMDB process effectiveness and CMDB health. 
 
And remember that repatriating unexpected CIs to their rightful home isn’t necessarily as simple as just reclassifying the CI; you want to make sure that the resulting attributes for the CI are populated correctly and that you don’t create new problems due to missing attributes in the new class, etc.
 
Or even better, let us help you! 

But what if you don’t have the time or resources or expertise to dig into and manage your unexpected CIs?  And let’s face it, the CMDB is not fun and exciting, people would rather be rolling out Virtual Agent.
 
Speak to our experts at AJUVO about CI Watch, a comprehensive solution by AJUVO to get your CMDB back on track and help keep it there.  We use our own custom applications, dedicated CMDB experts, and consultative approach to help (re)design your CMDB to support your desired business outcomes, align your existing data to achieve that value, and then provide a managed service to keep your CMDB humming along smoothly at a fraction of your normal full-time resource costs.