Recently in CMDB 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

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.

Yesterday was a big day for the myCMDB team. We launched our initial code drop for the myCMDB Early Evaluation Program. The team is eager to get some feedback from our participants.

Overall the launch has gone very well. We had very few problems with user account setup, DNS problems, or any other technical issues. In fact, we have been surprised (and pleased) by the number of people that are already using the application.

We are eating our own dog food for this program so we can easily monitor statistics and auditing of the system: we can watch as people login, logout, and perform other activities. This was vital to our program so that we can monitor usage accordingly as part of our feedback.

We also setup myMO -- our  Web-based portal framework -- as the front end web site for all communication to the participants of the myCMDB EEP program. The site contains an overview of the program, instructional movies, beta documentation, a Blog site, calendar of events and other cool stuff to provide an easy means of communication between the participants and the myCMDB team. Personally, as the project manager, I am interested in hearing feedback on both the product as well as the Early Evaluation Program in general.

So far, my favorite thing about this program has been watching the community feeds as people register CI’s, update attributes, join communities, etc. In fact, it looks like a bit of competition may be brewing between the participants to see who can register CI’s the fastest. Interesting thought for those wanting to foster usage and coverage with a CMDB.

- Adam

We’re thrilled to see the buzz gathering around our newest announcement - analysts and media alike seem to agree that we’ve added something new and noteworthy to the market. We think this kind of innovation is especially welcome in a market that has little confidence in those larger competitors.

With myCMDB, we’ve really unleashed the power of the CMDB by adding the community features that should logically be part of any project that requires the input from so many different people within an organization. Heck, using email and voicemail for CMDB communication is like using a rotary dial for a smartphone.

Instead, we’ve brought CMDB communications and process into the 21st century, by adding a combination of Facebook interactivity, Wikipedia information quality management, and Google’s searching model. Basically, these features make it easier to get more users involved in its creation and maintenance, which means the CMDB quickly becomes a more accurate representation of the infrastructure, relationships, and services. This allows organizations to use the CMDB to better control the impact of change and move it into a decision support role.

Stay tuned as the buzz continues to build!

If I had a crystal ball, I’d look to see the IT of the future. The flow of data, streamlined communications and an accurate map of the relationships between applications, technology, and the business -- the IT future would be clear, in fact, so crystal clear even the line of business would enjoy the view into IT.

Current CMDB projects look more like information warehouses for IT – developed and maintained by small teams of IT technologists. Yet, the vision for the CMDB is much larger and broader than many current implementations would have us believe. In the coming months and years, the CMDB will evolve into the valuable corporate asset it was envisioned to be – providing critical decision support capabilities for both IT and business users alike.

Interestingly, realizing this vision for the CMDB is not beyond the realm of existing technology. In fact, it’s not a technology problem at all.

As I’ve stated in a previous post, 70% of the data needed for a CMDB already exists in the enterprise. What’s needed is the mechanism by which to tie this data together, and present it in a manner that can be easily updated by the enterprise and consumed by the business.

This mechanism is integration – and it exists today. The interface for consumption might be borrowed from social networking concepts, where the GUI reflects the community. Views would be based on organization role – for the business manager, the IT director and the service manager respectively – and derived from the same corporate asset: the CMDB.

-- Siki

The power and pitfalls of knowing every side of the story

As a manager, your company’s ability to execute effectively cannot and does not depend on your ability to scale your own execution across superhuman multiples.

Instead, it depends on two things – first, it requires a refined ability to assimilate data from a number of different sources to formulate an accurate and complete picture of the business as it stands today – and then, leveraging that picture to formulate a clear and concise blueprint and course of action for where the business needs to be in the future.

Secondly, it depends upon your ability to gain buy-in and participation across a number of different constituents – both within your team and across the company.

The challenge of building a blueprint, gaining buy-in, and then orchestrating work across a broad spectrum of resources, is what business management excellence is all about.

Interestingly, there are a number of similarities between effective business management and effective IT management – particularly, as it relates to the CMDB. From data assimilation, to blueprint, to plan of action – the CMDB provides a central focal point -- an accurate and complete view of the IT infrastructure.

And yet, CMDB data inaccuracy is the number one cause for CMDB project failures -- followed closely by a lack of broad adoption of the CMDB across a broad set of constituents within both IT and the business.

Going forward, the CMDB must be an absolutely accurate, trusted source of IT infrastructure information. In addition, the CMDB must be widely accepted and adopted across a broad set of IT and business users within the enterprise. IT organizations will each need to address both of these challenges for CMDB projects to be successful over the long-haul.

Don’t think Managed Objects hasn’t noticed.

-- Siki

Recently Edward Lorenz who popularized the concept of the "butterfly effect" passed away. The butterfly effect, according one article, is when "small differences in a dynamic system, like the weather, could trigger vast and often unsuspected results." In other words, Lorenz theorized a mere flap of a butterfly’s wings, while generally insignificant, could, given the right set of conditions, cause a subtle change that sets of a sequence of events that leads to a raging thunderstorm.

In the world of technology, those thunderstorms are often rendered in the form of an application slowdown, or worse, an IT outage. The butterfly that caused the outage can often be traced back to change, whether that change was planned (as in software upgrade) or unplanned (as in a fault failure). More often than not, someone pushed a button, turned a dial or pulled a lever that caused an IT outage. In fact, Gartner's research "consistently shows that 80% of mission-critical outages are caused by people and process issues, not by technology failures."

Yet process or best practices alone is not enough. Despite being an avid proponent of ITIL, one of our customers was challenged by the fact that 60% of incidents were caused by planned or approved changes. What’s the solution? Visually model the dependencies among dynamic IT infrastructure components to better understand the potential impact of planned change before they are made - even if that change seems insignificant, like the wing flap of a butterfly’s wing.

- Siki

Weeks after the announced acquisition much of the coverage and analysis surrounding the proposed HP and EDS deal still focuses almost exclusively on the effect this transaction will have on the respective companies. What missing is the impact this will have on their customers. As the Economist wrote, "Culture aside, EDS's big selling point is to be the largest services firm that is independent of any hardware or software vendor." That independence is about to be challenged.

Perhaps they are culturally dissimilar but the marriage between the two can be summed up like this: one has huge pockets and desires to be IBM, while the other empty pockets and desires to be ‘a somebody’ again. Fair or unfair, this assessment is precisely why the same Economist article also notes that while EDS "…will continue to advise clients to buy systems from all vendors…those clients are now likely to pay more attention when the boxes come from HP."

And customers ought to pay more attention to those boxes for a very simple reason: big vendors don’t have a track record of playing well with others. Now that HP has acquired all the software vendors it needed to build a BSM strategy, customers should be concerned that with the purchase of EDS, HP will outsource them too. The sales pitch will evolve almost nonchalantly, perhaps even unknowingly, from selling products -- to selling implementation services -- to outsourcing everything.

The promise to eliminate all IT headaches may sound alluring initially -- but the second and third order of effects can be severe: The client has absolutely no control of their IT destiny, and by extension -- given the reliance of business on IT -- no control of their business. Once again, having an independent, transparent, best-of-breed vendor, with a mastery over integration, will be essential for clients to retain an element of control over their businesses.

- Sean