Finding ROI in a Configuration Management Database (Part 5)

Posted by Mark Hillyard on Apr 30, 2013 3:57:00 PM

In ITIL, Process Improvement, Configuration Management, CMDB, CMS, ITSM Tools

This is our final chapter. Here, we're covering some of the challenges we'll face as we implement a CMDB, how tools can help, and some final thoughts.

Common CMDB Challenges

This segues quite nicely into the challenges you face as you begin your journey toward good configuration management. As I mentioned before, immature Change Management is a sure-fire path to mediocre configuration management. The two are inextricably linked. To finish my analogy…Change Management is the horse.

The second big obstacle you will face, once you make the decision to dive into building a quality CMDB is the dreaded rogue database. Gee, what’s a rogue database, you ask? Well, if you have ever worked in a small IT shop, especially one in a rapid-growth organization, chances are you had a spreadsheet of all of the systems you were responsible for. You probably didn’t share it with anyone, just updated it when things changed, so you could quickly reference it when something went wrong, or someone needed some data. You basically ran your own CMS in Excel. And, that was probably sufficient to avoid the pitfalls of no configuration management. But then the company grew. Assets increased five, 10, maybe 100-fold. And there were a lot of other people keeping similar spreadsheets to themselves regarding their systems. When you start, at an organizational level to begin true configuration management, you have to snuff out these one-off solutions. Not in a bad way. They can go a long way to federating your data, to be perfectly honest. And, if you approach the task in a positive way, “Hey, I really like what you have there; that data is going to be really useful to us as we build our central configuration management database,” it will help with buy-in from those admins and engineers who will complain about updating two systems. HINT: They only need to update yours, once the data is gathered.

It can be a tough road getting everyone to jump on the CMDB bandwagon, and as with many initiatives, inclusion of the stakeholders, especially those that will be responsible for maintaining the CMDB, is key to winning them over. Give them that one feature that they just cannot live without. Turn your biggest critics into your biggest allies. As with so many things, converts are the best evangelists.

Automation Tools for CMDB

There is a—truism—in ITIL. Something our trainers stress in every Foundations class. While ITIL, itself, is not prescriptive when it comes to technology and tools, it does tell us something very useful, and we spell it out as explicitly as possible. Tools help with everything. Tools are useless without process, to be sure. If you just go out and install the first slick-looking ITSM tool you find on the market, but you have no processes in place to support it, you will be much poorer, with the exact same problems that led you to buy the tool in the first place. And everyone will hate the tool. So, process 1st, tool 12th. (The intervening 10 steps are also process, just to be clear).

But, now you have some great processes in place. They are working well, but boy is it tedious. It takes too many people too much time to do what should be very little work. Effort levels through the roof, productivity seemingly at a standstill.  Now you have the perfect opportunity to look at automating some stuff. And that is where…Tools help with everything.

Something a lot of you are probably familiar with on at least some level is the idea of automated discovery. Altiris, LANDesk, and myriad other tools on the market all claim to find everything on the wire, and store, classify, and polish it all to a high gloss sheen in a super-easy-to-use database that will integrate with everything including the toaster in your break room (which was probably manufactured in 1964, and still had bread crumbs from that year stuck in the bottom). A lot of these tools are insanely cool. I’ve worked with several of them, and it is kind of astonishing how effective they have become at gathering unsettlingly accurate and thorough information regarding every system you have attached to your network. Which tool should you use for automated discovery? That is a question for you and your organization to answer. Most have great strengths. They all have some weaknesses. It all depends on your budget and threshold for implementation effort.

So, how does an automated discovery tool really work? Well, mostly SNMP, to be honest. Some require a special agent be installed on the target systems, and that can be a bit clunky.  But most work within a pretty standard set of parameters and give you a really good peek inside your infrastructure. And, once you have a real baseline of your environment, you can use that as a touch point down the road. You can see baseline changes to existing components, and, perhaps more importantly, you can audit your environment with a high degree of accuracy. This helps weed out changes that maybe didn’t quite follow the processes you painstakingly built to help you maintain your pristine CMDB.

The next step is finding an ITSM tool that can help you with a lot of linking of components within the CMS. A good tool will be able to show you that when you are going to change that print server and add a high traffic database, what services are going to be affected. It can also help with maintaining license information. And, if you have ever been the target of a software license audit, you are keenly aware of just how unpleasant vendors can be when they find you’ve over-allocated your seat licenses by 28%.

Additionally, a good ITSM tool can help you to visually understand the interactions between components. I touched briefly on this while discussing  Problem Management, but it is a key feature that a quality ITSM tool will provide.

It can be as simple or as complex as you require for your environment. And there are hierarchical ways to establish these links. Each CI can be linked further up or down the chain until you have a complete picture of how your environment interacts with itself. So, when you are about to run Change 10181, you know that it could impact CI ATX9023, even though that is not the component that is being acted upon in the change. This can go a long way toward planning, justification, timing, and budgeting for your environment. And, since the majority of us are, in fact, visual learners, pretty pictures can be worth even more when you head to your daily CAB meeting.

Final Thoughts

So, there is a lot of value that you can glean from a quality, well-maintained CMDB. It is by no means the fix-all for what might ail you, but if you are heading down the path of best practice, a good configuration management system, anchored by a great CMDB, will really make all of your process improvement efforts more effective.