Recently in Relationships Category

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

The consultants have been at it again. If you haven’t met them yet, strike up a conversation about a CMDB project and you’ll quickly find one interrupts. These consultants reinforce a conventional wisdom that says that building a CMDB is a linear process – with a beginning and an end – but as the saying goes, it’s the journey that’s most important. Those who endeavor on the CMDB journey should realized that the trip actually started long ago, perhaps before they even realized it and certainly before the advent of discovery tools.

Beginning a CMDB or even a BSM project with discovery is akin to drinking water from a fire hose: the data discovered is vast, often duplicative and difficult to filter, and moreover does not really identify meaningful relationships. A CMDB project is the base for creating and storing a “DNA map” of relationships between infrastructure, application and the business. To this end, the value of duplicative data for this type of project is questionable.

If not discovery, then where should the project start? My customers tell me that upwards of 70 percent of the data needed for a CMDB already exists in their enterprise. Where? It’s stored in existing IT management tools – in Service Management solutions like incident, problem and asset management. This makes existing tools a good place to start a CMDB. What’s needed isn’t more data, but rather a way to integrate existing data and rationalize relationships.

Discovery or application mapping tools are most valuable when they are used to complete the picture – to understand what has changed in the relationship structure, the configuration of each element, or if new elements have been introduced to the DNA service map. To put it another way, find out what you know about your infrastructure first by tapping data in tools like Tivoli, OpenView and BAC…later you can add discovery to find out what you don’t know.

Having just come back from the field where I spent considerable time with our customers – both in North America and in Europe – this is perhaps the single most important lesson I have learned. The most successful CMDB projects did not in fact start with discovery – they started by tapping existing data from tools they purchased and implemented years ago. Europe has discovered this important lesson and perhaps that’s a critical reason why IT management concepts seem to lead North America from across the Atlantic.

-- Siki