Twitter: @smtaylor12
I recently visited a customer whose environment includes Forescout CounterACT® as well as a leading IT Service Management (ITSM) solution that contains a Configuration Management Database, or CMDB. This isn’t unusual. What’s interesting, however, is that I’m finding a big lack of data in CMDBs.
While often thought of as a prerequisite to effective IT Operations and Service Management, CMDBs are typically not populated adequately, or not even used at all. To paraphrase the 18th century poet Robert Burns, “the best laid plans oft go awry.”
There are a variety of reasons why this is the case, but it likely boils down to this: CMDBs are difficult to use and require quite a bit of planning and research. Besides there isn’t much value in populating them today. The basic structure of a CMDB requires an organization to have a fundamental understanding of so many aspects of the IT organization—the services it provides, the components that comprise those services, the customers it serves, and more. The operational value of a functioning, populated CMDB is realized when an organization can use its data to evaluate change requests to ascertain which service, upstream or downstream configuration items will be affected by taking a particular device offline for maintenance. The value is seen when a service technician can rapidly identify where a broken device is connected and how best to implement a workaround to restore service as quickly as possible. Those different pieces of data should all be contained in a CMDB.
The task of populating a CMDB to make it work for you can seem overwhelming, but if you start small, you’ll obtain results quickly. According to the IT Infrastructure Library (ITIL), the de facto international standard framework for the implementation of IT Service Management processes, the CMDB should be the single source of truth for all data regarding the IT Services provided by an organization. It’s both a destination and a source for both data and IT processes. Data pertaining to service or network outages, also called incidents, are entered, stored and flow through a resolution process facilitated by data contained within the CMDB. Asset ownership data and software license entitlements, as leveraged by IT Asset Management or Financial Management processes, are stored within the CMDB as well.
If you could easily populate the CMDB with all the discovered assets you have in your network, why wouldn’t you do it? If you could accurately count the instances of software packages installed on your corporate-owned assets and use those in contractual negotiations, why wouldn’t you do it? If you could do both of those things as well as ensure that your service desk has details around the assets about which your end users are calling into the Help Desk, why wouldn’t you do it?
Now, imagine you can do all of that while having the peace of mind knowing that only authorized, compliant assets are on your network accessing the resources that you’re tracking in your CMDB.
Why wouldn’t you do it?
