In the April 2011 ITAK magazine, Dan Wilson of RightStar Systems published an article entitled “ITAM+CMDB= Success.” In that article, he mentions the single point of truth and how key it is to the success of an ITAM program. The configurations management database system (CMDB) has a place in almost every framework or methodology for IT service management. Sometimes it is part of a much larger data retention system such as the Knowledge Management System or simply part of the Service Management System. No matter the shape or form, it still must be the first and last point of truth for all items in your managed items. This paper is the result of many conversations at conferences about a CMDB or how they wished they could squeeze more productive information from the tool that they had. This is a summary of those conversations.
I’m going to build on the concepts of Dan Wilson 2011 paper and explore, in a little more detail and from a practitioner’s point of view, what you should be getting from your CMDB. When I say practitioner, I mean the person who does the work, writes reports, imports data and makes sure that the spider web of information is connected in such a way as to provide clarity and add value to the ITAM program. From a practitioners point of view the CMDB is never finished and there is always room for improvement. I’ll be looking into the information that should be coming in and also what should be going out. If your company still does not have a CMDB then this article should have some great bits of information to consider if you are buying or building a CMDB for your enterprise.
The Thread Connecting Everything
When building a strong asset management program, find the common thread that connects all of your asset items. In other words, where are you going to start? Does it start with the purchase request, the service desk ticket, purchase order or just the asset’s serial number? Having the ability to track an asset’s serial number based on inventory that is tied to a PO, scanned in via a barcode device and a linked to a warranty contract inside your CMDB gives considerable power to not only your asset manager but also the manager of any department that uses IT assets. However, you cannot connect these items if you don’t manage them in some way in your CMDB. Don’t be afraid to manage something that you didn’t manage before. Since we are talking about the practitioner’s point of view, let’s break down this process a little more.
As an example of a process, a service desk ticket for a new purchase generates a purchase request and / or a purchase order. After it’s ordered, it is received at the door with a barcode scanner. It is delivered to the requester and assigned to a location or automated location based on IP address. By simply importing that scanned barcode information into your CMDB, you can now make a connection to that PO, service desk ticket, user, cost, warranty and assigned location and we can continue this line of relational thinking even deeper if we want. Trying to budget for a hardware refresh? Yep, now you can have hard data to back up your historical use. Don’t stop there. There is a wealth of information that is gathered that can be useful to the IT Asset Manager. For instance, by connecting your service desk to the CMDB, you can find out whether a particular machine is having repeated problems.
There are other potential ITAM problems that can be solved with data from your CMDB. Let’s talk about moves, software installs and the change control process. Take as an example the possibility that some hardware may not be moved or relocated without affecting licensing or other warranty contractual items. Pulling data from your data center management software into your CMDB may help prevent costly errors caused by ill-planned moves or well-intentioned but undocumented software installs. If all of your hardware, software, licenses and contracts are connected (as they should be) in your CMDB, it is beneficial for your change management process in order to check for restrictions that may affect the request.
They Call our CMDB Sky-Net
A CMDB takes two basic forms; “federated,” or a single point of entry into many different data storage points, and “confederated,” or the single point where all the data is located, usually imported or fed into the database via some connection solution. When you add inventory data from an automated source the database can become very large quickly. Federating your data becomes necessary at some point and that point is usually defined by how long you are willing to wait for your database or the unacceptable size of the backups. Federating presents its own set of problems.
Federating the data of other departments often results in skepticism. I refer to this as the sky-net principle, giving homage to the Terminator movies where sky-net and the robots it controlled took over the world. Overcoming the fear that a single database is the first and last point of truth for a department that doesn’t control that system was challenging. As with implementing any change to any IT service, listening to the concerns and providing clear and concrete solutions helps to overcome the obstacle. Objections like over-exposed sensitive data can be overcome by clearly communicating what data is needed. A departmental manager responds differently to “I need to tie into your datacenter database” versus “Can I get location and serial number entries from your datacenter database?” Which one of these would you say yes to? Just because you are federating data doesn’t mean you need an entry point to see all of the data in a secondary database. Reassurance that you are only pulling data agreed upon data and not pushing will help to overcome these objections. Another way to overcome objections and bring value at the same time from your CMDB is to share the data. I’ve heard from other companies “our CMDB data just isn’t correct” or “we seem to be missing a lot of information.” How do you know what you don’t know? How do you overcome these errors and or objections? Simple: share the data.
Don’t hoard the info. Many tools exist that let others make use of CMDB data. Secondary report writing tools such as simple data query scripts or programs like Crystal reports or web interfaces scripting tools can give others access to information. When we share and then receive feedback, there is the potential to fix problems of missing or incorrect data. Take for example if your server teams tell you that you are missing some server names in your CMDB. But wait: you have an auto- deployed inventory agent. Sometimes with servers being duplicated from templates you won’t get the data from new server. Allowing them to see that data in their own environment allows you to get feedback on what might have gone wrong. Letting them see what you manage lets them see what they manage.
Use the CMDB to Solve Problems Not Create Them
What else should you doing with your CMDB to support your ITAM program? Automate and customize. Almost every tool on the market today comes with features that allow you to customize your CMDB as well as automate reports. Regularly scheduled reports such as license compliance or warranties set to expire are standard. But, think about contracts for services such as domains, certs as well as service contracts such as subscriptions like your IAITAM membership as part of your CMDB CIs to track. Automated reports that kick off at defined intervals are a great way to discover if all your hardware is allocated to a location or associated with a Purchase Order or if all software purchases are accounted for. By making all the connections, you have a great opportunity to find out information that would previously not have been considered like the saying “things we don’t know we don’t know.” Consider the wealth of financial information in your CMDB. An example may be to use past expenditures on warranty contracts to predict the percentage increase from year to year. What? You don’t know how to track that kind of information? The great thing about a customizable CMDB is that you can create and manipulate data classes. Just remember if it’s in there you can report on it.
What do I Need to Make this Happen?
In my opinion, practitioners need not fear stepping outside their comfort zones. Know your craft and I don’t mean just the technical aspects. Study the best practices and understand your company’s ITSM framework. Be a champion of change and learn to say “yes, that data is in the CMDB and I can get it out for you” or “we don’t currently track that, but we can.” If you are an IT Asset Manager, my suggestion is simple and somewhat self-serving. Get a Subject Matter Expert. What an “expert” is depends on your goals. Do you want an expert who knows SQL or maybe a coding expert? Maybe it’s someone who has certifications in ITAM or knows all the ins and outs of IT contracts or has ITSM certifications. Who is best suited to be your expert should simply not be who can do the work of today, but who can grow and expand their horizons for a few more years. If you have a strong, versatile expert in the field of ITAM you won’t be afraid to ask for the moon.
Good Info but I Don’t Yet Have a CMDB
Looking for a CMDB? What should you look for? Take the time to define your needs. Here are some criteria points discussed with other practitioner. Does it have easy to understand report writing? Can you write complex reports without being a programmer? Can you write reports from a third party package? Is the data proprietary? How customizable will you need it to be? What kind of community support and user forums are out there? Are there user-posted reports and tasks? Does it interface with any other third party products? When considering cost, consider if you need a separate license for the database. How many servers will you need? Can you get customer referrals? I’ve talked with many companies who bought a CMDB product and only use one quarter of what it can do. This happens when a tool is too complicated and a company doesn’t dedicate the human resources to run and maintain the system. There are fantastic CMDB tools out there but without expert training and experts to run them, most likely you won’t realize the full potential of your purchase.
How do you know you’ve got the right product? Define your success factors and key performance indicators. Is your successful CMDB defined only by your department or did you get input from other departments? What do you need from your CMDB three months, six months, one year and three years after you purchased it? Knowing what success should look like and how it’s measured will lead you to the best path for choosing the right CMDB product and bringing success to your ITAM program.