Service Matters

To Be a CI or Not, That is the Question!

To Be a CI or Not, That is the Question!

By Chris Pope - 2014-06-27


This is the second installment of my Seven Steps to Change the Way Your Work Gets Done series. My role at ServiceNow allows me to travel (almost continuously) around the world, meeting with users and discussing and sharing experiences that are changing how we look at service management.


If you haven’t already done so, please check out my initial blog on this subject here


A common mistake I see from users when implementing a CMDB is defining a scope that is too large, and not understanding the effort required for maintenance. The gorilla in the room is actually who is going to maintain your shiny new toy! People play as much an important role as the data itself. (I am an advocate for creating a configuration item (CI) class called ‘Person’ – but that’s for a later discussion!)


Scope, generally, is misunderstood or confused with levels of detail. Opinions vary per class as to what is or isn’t needed, who gets to decide, what is the frequency that the data is updated, and so on. There is no silver bullet to getting it correct. Previous attempts at establishing a common data model have really gone nowhere or haven’t been adopted due to complexity. It’s not understanding what problem is being solved. 


Many large technology companies have tried to document the model, but I have yet to come across one that has an actual live production deployed implementation! (If and when you come across me on my travels, be sure to ask.) Levels of detail on a CI, whether attributes or relationships, vary immensely depending on the user, but what cannot be forgotten and is a core principle at the outset is to establish: a Data Provider, a Data Consumer and a Data Owner.


Qualifying a CI:



If the value of adding a CI is comparatively less than the overhead to manage it, don’t add it!


Asking the right questions and understanding the need for any given class of CI is crucial to ensuring the anticipated benefit can be achieved, as well as the effort required to maintain and govern the data. Too often, we scope the effort in terms of the initial data entry or load, and move onto the next thing without planning for the on-going investment to ensure continued success.


Criteria – Asking the Right Questions

Establishing a survey or set of assessment questions is a good way to objectively qualify data that is intended to be used in the CMDB. This can almost seem like a small child continually asking, “Why?” but it will force the requestor to really think about the reasoning and need for bringing the data into the CMDB.


Several categories of questions I have used previously are listed below:  

  • Cost or value
  • Change considerations
  • Traceability
  • Governance and compliance requirements
  • Management of service commitments
  • Maintainability
  • Delivery cost and quality
  • Interrogation capability

Attributes vs. Relationships

Understanding the make up of CIs and their relevance to other things is really where the value of a CMDB can be found. What is an attribute, versus a relationship, is a common question, but can be understood fairly easily by determining the intended use or outcome. The complexity of maintaining the data may drive the design left or right, and automation could be a key enabler as well.


For example: Is the Operating System (OS) of a server an attribute or a relationship to another CI?


If we go back to the four questions towards the beginning of this post, we should be easily be able to determine the most appropriate action based on those answers. Add to this the assessment categories, and we will have our solution.


In reality, I have seen this information captured both ways, as each customer has different needs and level of maturity. The first customer had a pressing requirement around Software Asset Management (SAM). So understanding where the software was deployed, being able to reconcile the counts back to purchases, and contractual licensed counts were important drivers for them to create a CI and use relationships. It reduced the overhead of the technical implementation, and automation was a huge benefit to them in maintenance. The users in the SAM group had specific compliance reporting requirements that were best served using a relationship to another class, rather than an attribute based approach. That wasn’t to say that the server CI did not have an attribute of O/S!


Confused yet? The graphic below shows several examples of attributes compared to relationships:



Challenge, Challenge, Challenge

As we draw to the end of the second step in this series of seven, we are yet to come across a technical challenge or limitation – have we even referenced one? Its mostly been related to the most unpredictable asset we have in any company - People


Do you have an assessment framework for determining what is or isn’t a CI? Take 10-15 minutes with your service owners and ask the challenging questions. Use the answers to step back and look at your approach – you may be surprised at what you find! Whose purpose are you really serving, yours or theirs?


Next up in my series: Step 3, Resources for the CMDB...

Buy Apps on the ServiceNow Store