Fabian Kunzke
Mega Sage

Hello everyone,

 

Now this is a blog all about how my best practice ideas got flipped-turned upside down and I'd like to take a minute, just sit right there, I'll tell you how i got inspired by this unrelated song about the prince of Bel'Air.

 

I always found it most easy to remember things when they were bound to a melody. So today I'd like to share my "Melodies of a CMDB" and how they help me to design a clean CMDB structure. (This is not an ordered list)

 

1) Queen - Bohemian Rapsody

 

Is this real life? Is this just fantasy?

The main goal of a CMDB is to visualize reality. However, a lot of fancy schmancy stuff often leads to rules and restrictions which no longer allow for a picture of reality. Relationships need to follow a naming convention, the first level support has no idea what "D02381 - Win 7 TCP UDP CDA GN" is and why "it needs some new backup from LKJF", the windows maintenance team cannot find their servers, as they are named differently than they are used to because of some weird naming convention. This goes on and on (or around and around). But there is one easy way to validate this: Smalltalk.

Sit down with one of the windows maintenance guys over a cup of coffee and ask them: What are you current rollouts (-> Add this as a certification)? What applications are you running (-> compare this to the "Runs on:: Runs" data in your CMDB")? What are you naming your Clusters as?

You want to visualize reality? Get the people around you talking about their reality, their wording, their expectations, their understanding of reality. Because only then can the CMDB visualize THEIR reality.

 

2) Alex Claire - Hummingbird (Unplugged Version) (because i like that one more)

 

Take what you need and leave the rest, no I don't mind, I'll get this off my chest [...]

When done with step one, go one step further: What do you actually need? Do you really care about monitors? About that keyboard your coworker is using? Do you really need warranty data or does the external partner store that information? Do you really need to know all of your load balanced Unix VMs or is it fine knowing that there is a service which provides some load balancing? Do you really need to know all software that is installed or do you just care about some office installation you are paying for? What do you really need? And with you: Remember "you" isn't you. It's the people that are supposed to work with the CMDB. And: Smalltalk is king.

 

3) Spice Girls - Wannabe

 

If you wanna be my lover, you gotta get with my friends.

A CMDB is only worth anything, if it is getting used. Problems, Incidents and Changes? Reference them to the CI and/or to a service. No service/CI present? No problem, create it, use it (boop it, twist it). Examples? I lost count of the provisioning request fulfillment workflows that create a CI and don't add the reference to the request item. That small extra step allows you to immediately know why some weird device popped into your network and where it came from. Use the CMDB - or every investment into the CMDB is a waste of time and money.

 

4) Plain White T's - 1,2,3,4

 

There's only one thing, to say, three word, for youhuuuuuuu...

Identification, Reconciliation and Remediation.

ServiceNow has provided us with an amazing tool to keep data within the CMDB clean, organized an managed. Imports should not be done with mappings (if they are related to the CMDB). Use the goddamn IRE from ServiceNow. It takes some getting used to, but if you want to maintain Identifiers and multiple other forms of assisted data maintenance - use it; use it everywhere. No matter if it is a provisioning request, an asset import, the SCCM interface (which already uses this btw) - just use it. It takes some effort, but it is more than just worth it. Now all the time and work spend within the CMDB Health module finally is put to some use.

 

And that's it (for now). These 4 melodies of a CMDB help me to see what is going "wrong" and how to improve on the current state. Feel free to add and share melodies of your own, who knows, this could be a great playlist for all those CMDB workshop-preparation-sessions.

Regards
Fabian