3 Tips To Improve Your CMDB For IT Asset Management
As an ITAM consultant and coach, I’m brought into organizations to figure out why they cannot obtain the accurate and trustworthy data they need to avoid downtime, security breaches, and devastating software asset audit penalties. If you’re an IT director or ITAM lead and you’re struggling in this area, the first thing you should do is work to improve your CMDB.
Despite the promise of CMDB automation, the unfortunate truth is this: in most large companies and institutions, much of the data collection process is still being done manually. Here’s a typical scenario: a new employee has been hired, and you need to request hardware and software for that person. Instead of being able to run a report that tells you if you need to buy more software licenses to cover the new employee, you – or someone on your team – must get a human being involved.
How can you stop having to swivel between various systems and people to get an answer to the most simple question about your computing environment? You start by making a concerted effort to improve your CMDB.
The Promise Of The CMDB
CMDBs were initially proposed in the early 2000s and promised to enable IT service managers to anticipate problems and create solutions by creating a single source of truth. But to this day, most CMDB installations require a lot of manual data entry and spit out inaccurate and/or incomplete information. They rarely deliver the insights they promise to.
Not long ago, I was in a strategy meeting with a potential client – a Fortune 500 clothing retailer. They were shopping for a brand new CMDB and were prepared to spend a lot of money re-platforming their entire service management tool, including asset management. At the time, they were still using spreadsheets and a ticketing tool they’d created in-house. They had invested in a CMDB already, but it was only partially implemented.
I told them not to invest in a new CMDB. They looked at me like I was crazy! They couldn’t fathom that a consultant was advising them not to spend money. I said, just improve your CMDB…the one you already have. But they were bound and determined to buy a new CMDB, so I didn’t get that job.
As I understand it, that company never bought a new CMDB but kept doing things the old-fashioned way, and it wasn’t too long before they experienced a credit card breach. (Oops.)
Improve Your CMDB With The Digital Twin Concept
A digital twin is a virtual representation that serves as the real-time digital counterpart of a product or process that’s fed by real-time data provided by the computerized components of the product or process itself. The Digital Twin concept is integral in Internet of Things (IoT) technology and represents product design and engineering evolution. And the same concepts can be used with current computers, users, and services.
A good illustration of the digital twin concept is the modern race car. During a race, engineers in the pit can see telemetry through GPS and view essential data critical to a vehicle’s performance on the track, such as tire pressure, g-force meters, oil temperature, fuel consumption, etc. They can view the data and tweak settings on the fly to improve their vehicle’s chances for a win.
If you already have a decent CMDB, it probably contains the essentials of the Digital Twin Model, which are:
- Connectivity: Information must pass between the physical item and its virtual representation, so a change in one is instantly applied to the other. Consider how an agent can report back to a command & control tool (MEM, JAMF, etc.) about its make/model/serial number, the user logging into it, the GPS coordinates, etc.
- Homogenization: No disconnects or knowledge gaps should exist between the information presented on the virtual record and the physical device. If a human has to input any data or make any updates, there is no chance for the Digital Twin to react fast enough to be of any use.
- Digital Traces: As both items pass through their operational lifecycle, complete logs and receipts must be generated. The information in those logs – especially timestamps – contains a great deal of information that will drive Digital Twin automation.
- Re-Programmable: While still in the production environment, it must be possible to make adjustments to the physical item to extend its useful life. It can’t be just a “dumb device”; it has to have some sort of operating system and software that can be manipulated by the Digital Twin.
- Modular: One individual item must be able to be replaced by another item (of the same type) without any impact on the overall process or service it’s supporting. To put it another way, physical devices need to be swappable without reconfiguring or altering the entire system. Unplug the old computer; plug in the new one.
Most organizations could and should be using Digital Twin technology for hardware and software asset management, but the way they recognize, gather, and organize their data frequently prevents it.
3 Tips To Improve Your CMDB
If you’re ready to improve your CMDB using Digital Twin concepts, here are 3 tips:
- Do not depend on only one source of information about your computing environment.
Digital Twins take information from sensors sprinkled throughout the physical device and merge them together. Our aforementioned race car would use GPS telemetry, accelerometers in the chassis, and transmission gear turns to calculate speed. And it would display an error message to the pit crew should one, two, or all three begin returning conflicting information.
What would that look like in a CMDB? Modern corporate computing environments have many different scanners, agents, and command & control tools that touch all the laptops, desktops, servers, switches, etc., and do so multiple times per day. If all of these tools are working in the same environment, they should be in agreement. Where these tools agree (and disagree) will help you improve your CMDB by identifying knowledge gaps and keeping it as informed as possible.
- Include data maps when modeling service management processes.
You can flow-chart and RACI process designs with the best of them, but how often do you model the data points each step of your service support process produces? And if a particular data point doesn’t populate the expected Configuration Item attribute, do you know how to troubleshoot what went wrong? And when it went wrong?
Digital Twin models track both the item and what the item is doing in the supporting process at any particular point in time. An oxygen sensor at the intake manifold is different from the oxygen sensor in the exhaust manifold – the Digital Twin of our race car example knows which is which and when to expect the sensor’s information.
Your CMDB should also know that an asset reporting back an IP address and an end-user login is no longer sitting in inventory. If an approved change request is also associated with that record, program the CMDB to change the asset’s lifecycle flag accordingly.
Going another step further, your CMDB could be programmed to anticipate the deployed asset’s needs. For example, the end-user logging in should have a job code associated with them in Human Resources. What software do other individuals with that same job code use? Why not automatically deploy the needed software (and purchase new licenses, obviously) based on what other users with the same job codes use?
- Automate record updates when appropriate.
In the race car example, if a pit crew chief observes worrisome pressure and temperature information on a tire, orders a pit stop, and the crew replaces the entire wheel. The driver doesn’t have to pull over and troubleshoot on the track. Nor does the pit crew need to stand there and troubleshoot the old wheel while it’s still mounted on the race car. The pit crew chief trusts the Digital Twin to detect the new wheel assembly and baseline the telemetry from the new sensors, all while the driver gets back to the race.
The same should be expected of your CMDB. Few, if any, modern corporate IT service departments troubleshoot and repair in the field. Nowadays, the solution to an end user’s complaint is “swap with like replacement.” So why require your Tier 1 and Tier 2 technicians to type out all of their troubleshooting steps before closing the trouble ticket? Improve your CMDB and automate the process – the record updates, the system notifications, etc. – so your end-user can get back to productive work.
If you still can’t get reliable data without needing someone to upload a report manually or reach out to another department, maybe it’s time to improve your CMDB. There’s an excellent chance your current system could be doing much more for you – and making your life so much easier.