Recently in CIO Category

For example, in one session on CMDBs, in excess of 50% of the audience (by show of hands) said they were currently implementing a CMDB. Two-percent admitted they were on their second try having failed the first time around. No surprise integration was routinely cited as the main culprit and that’s an area Managed Objects has certainly mastered.

StackSafe has posted some notes from the show here – and we’d like to offer some bits and bytes – mostly paraphrases – as well:

>> Congratulations to Cindy from Hallmark (photo nearby) who won our Wii raffle.

>> IT is good at measuring performance, but poor at measuring quality.  A help desk that aims to solve 60% of incidents on the first call is really just encouraging staff to close a ticket with a poor answer and reopen a new one with another call. – Malcolm Fry, “CIO and the 366 Degree Circle”

>> Roughly 10% of the audience raised their hand when asked “do you know what BSM is?” – Lisa Erickson Harris, “BSM and Best Practices, Elevating the Role of the Service Desk”

>> IT investments will continue to grow, but they must either produce cost savings in the supply chain or improve the customer experience – Charlie Feld “Enabling 21st Century Business Model with IT”

>> A well run IT department is like air – it’s taken for granted. – Dennis Ravenelle, IT Service Continuity Management, Where do I start?

>> “An inaccurate CMDB is worse than no CMDB.” – Richard Peasley, Building Decision Support Systems that Work

- Abbas

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

Sometimes people learn to live with pain. The pain may be real, enduring and chronic but people choose to ignore the pain -- which isn't the same thing as making it go away.

I was speaking with a prospect recently about our BSM solution, and though after listening carefully to our presentation this person’s first reaction was "we just don’t have the pain" to drive this sort of initiative. However, as conversation evolved, we began to uncover that not only was this organization living with pain -- the pain was in fact excruciating and had a direct impact on the highest levels of IT leadership. They had in effect, chosen to ignore the pain. Here’s the story as conveyed:

We have a heterogeneous IT management environment. Our tools report silos of information that must be manually correlated to understand the overall health of the IT infrastructure. As such our users usually provide IT with the first indication that there is a slowdown or outage. For example, a user in California will call the helpdesk in New York to report that an application is running slow.

Upon receiving the call, IT looks at their tools, but the screens are all reflecting green: IT can’t see the problem. Frustrated their issue isn’t being resolved, the users begin to assume IT isn’t worth their salt, and consequently stop calling to report incidents or problems.

Later our CIO goes on a company-wide townhall tour, to visit users and better understand how IT can support the business. He’s taken aback when he gets blasted by users during a meeting (ambush?) at the California office because the PeopleSoft application has been running slow for weeks.

Determined to get to the bottom of this issue the CIO returns to the office with this anecdote and thoroughly questions his staff. "Why wasn’t this problem addressed?" he demands, noting how critical the application is to the business. "No one reported the incident," is the response.

This is a quintessential business case for BSM if I’ve ever heard one. By integrating those existing IT management tools, BSM can consolidate those silos of information and link the underlying infrastructure components to the service being provided (in this case a PeopleSoft application). The benefit of doing this has been proven time and time again: IT will be able to rapidly determine root cause of incidents and problems, often before their customers are even aware, and dramatically reduce the mean-time-to-repair (MTTR). This supports the overall organization’s maturity to move from a reactive to a proactive IT organization. Why not eliminate chronic pain instead of learning to live with it?

As for my prospect, well, we have a second meeting soon and the CIO will be involved.

- Randy

In many ways technologists are fighting for the same ideals – just on different levels. The single source of truth is one of those ideals and I find it fascinating to know that other members of the IT community are tacking a similar problem in parallel. Consider the following:

ERP: CEOs look to enterprise resource planning software to provide a single version of the truth with regard to a company’s finances. According to CIO.com, “Finance has its own set of revenue numbers, sales has another version, and the different business units may each have their own version of how much they contributed to revenues. ERP creates a single version of the truth that cannot be questioned because everyone is using the same system.”

MDM: A March 2008 report from Gartner describes how master data management “can help enterprises achieve a single view of the product.” For example, a consumer goods manufacturer that produces wigits in different countries tends to maintain different versions of the same product specification data for governmental or regulatory reporting requirements. Over time the quality of these different versions changes or erodes leaving the business with multiple versions of the truth.

CMDB: Many IT departments have embarked on configuration management system (CMS) projects to synchronize and reconcile multiple federated data sources from performance, asset and system management tools. To provide a single source of truth about the health, availability and quality of the service provided to the business.

As a BSM vendor, my experience with CMDB customers tells me that the most suitable approach for this type of project it to leverage data directly from the trusted sources through integration, rather than attempting to copy, duplicate or otherwise centralize the data with methods such as ETL. In other words, build a centralized view, not a centralize repository, which of course is a key reason why calling it a configuration management system is more appropriate than calling it a configuration management database.

Still the fact that other areas of IT are seeking to find solutions to the similar challenges is interesting – and we’ll be on the look out for best practices. It’s also reminiscent of the idea that those who don’t read history are bound to repeat it.

- Jim