Recently in myCMDB Category

IT governance is a main motivator for corporate entities in their decisions to create compliant IT systems that include CMDBs. The CMDB is supposed to model (as closely as possible) a "vision of the truth" about those corporate entities’ IT systems. To that end I would like to discuss the governance of how a CMDB is constructed. By CMDB governance I mean: the performance, risk assessment and compliance of a CMDB to the actual true state of the IT system being modeled; I might also add to this the confidence in that CMDB as it relates to its accuracy in modeling the IT system.

How then are CMDBs constructed? The best way is to tie together existing data and complement that data with discovery tools and old fashioned data-entry. The latter may be done through the use of various scripts or the mining of databases that hold certain aspects of the system, but in large part these would be grouped under ‘formal methodologies.’

At this point the CMDB construction is already fraught with danger, for example holes in the data, or data that is inaccurate or stale. The confidence factor of such a CMDB may be quite low, which makes it rather useless. This problem is exacerbated by that fact that building it can be a very time-consuming and difficult procedure. There is a very well known decision matrix called the ‘Impact/Effort’ matrix. The idea is that if an activity has a high effort, but a low impact, then that activity is not worth doing.

This is a major problem in creating a useful CMBD. What to do?

Well, before I attempt to answer that question, let me introduce a different way that CMDB’s can be created: social networking tools.

The idea is that the IT systems knowledge (at least on a high level) is contained in the heads of many human beings. The raw data can be managed by the discovery tools and formal tools, but the structural knowledge and ability to correct or fill in knowledge requires constant, dynamic human intervention.

That’s why tools like Managed Objects myCMDB that allow ‘Wiki’ like intervention into the construction of a CMDB are so useful. This works by taking the view that the CMDB is a dynamic living entity that never really attains a static ‘state of truth,’ but instead has major portions that are basically static, and ‘outliers’ that are being dynamically changed as network needs change, as virtual machines are created and destroyed, and as complex applications go into and out of existence. The truth in a complex IT system is a living, breathing, and most importantly, changing beast. This is why the traditional methods of creating a CMDB always seem to end up with something that is out of date with the real thing.

To make sure that the data is maintained in the CMDB correctly, a ‘governance’ policy needs to be instituted between the ‘gathering’ of the data, and the ‘structuring’ of the data within the CMDB itself. Obviously there will be many things that can be instituted as boiler-plate within this policy, but there will be many aspects of this policy that will be unique to the corporate entity that is instituting them. The policy is itself stored within the CMDB which introduces an aspect of feed-back that will help to tailor this policy to better capture and structure the dynamically collected data that ultimately forms the CMDB model.

The feedback loop is essentially a human interaction activity and could be compared to idea of domain experts who edit an encyclopedia (or a Wiki).

These experts examine the current structures of the collected knowledge within the CMDB to the real world, and modify the policy so that the collection and structuring of data more closely fits with, and changes with, the real world. The ultimate hope is to get to a policy that produces the closest possible CMDB model to the real world.

As the policy improves within the enterprise, the confidence factor rises and, of course, the usefulness of the CMDB within the enterprise also rises.

- David

Daily updates keep rolling in and all indicate that our Early Evaluation Program (EEP) for myCMDB continues to progress nicely. We have been contacted numerous times by both customers and internal employees with feature suggestions, questions and bug reports. A handful of folks with whom we have never spoken with previously have even sent inbound requests to give the software a try.

In many ways, the EEP has also become an extension to our QA department. Many people find that it is fun to find a bug and to report these to us. While we don’t necessarily “like” having to fix these bugs since we would rather be working on features -- we know this is a vital part of the process and are very happy to find them early in the development process where the overall cost to fix is dramatically lower.

We have been following standard practice by categorizing the enhancement requests and bugs and placing them into our ticketing system so that they can be reviewed and addressed by the proper personnel during the proper time in the schedule. We are working to manage these fixes in between preparation for our next “formal” code drop for the EEP. We have been updating the code periodically during our maintenance periods for a few fixes we deem necessary, however, we are not delivering additional major features to the product until our next code drop in August.

Currently we are aggregating overall usage data and it will be interesting to see if there are significant trends: What type of user logs in most frequently? Who uses it less frequently? Who is leveraging the community aspects? Are the CIM standard for CI’s useful or have they constructed their own classes? Stay tuned. 

- Adam

For example, a recent poll at Gartner’s IOM conference found that 33% of respondents are currently implementing a CMDB -- another 19% plan to do so in the next six months -- while another 12 percent will do so within a year.

A separate study summarized in this article by EMA’s Dennis Drogseth found that "50% [of respondents] are in active [CMDB] planning and 50% are in deployment." Results may be dependent on a number of variables, but what’s remarkable is that both surveys show a marked contrast from another poll conducted a year ago by searchdatacenter.com which found that almost half of all of respondents had no plans for a CMDB.

While the numbers are interesting and certainly something to which we as a vendor pay close attention -- we find how this market is evolving most interesting of all. The nearby graphic indicates how we at Managed Objects have seen things shape up.