Recently in Discovery Category

Doug McClure’s at it again. The former Muse-man turned Tivoli guru has posted a thoughtful seven-step program to becoming a BSM Superhero on his blog. Doug’s blog is an excellent resource on the topic of BSM – be that ITIL, CMDB, or Discovery. Though he’s a true IBM-er, his vendor-neutral approach and efforts to stimulate public discourse is commendable.

It is in that spirit of dialogue that we offer an alterative 7 step program – the “just enough” approach - just-enough being a concept popularized by Forrester Research:

1) Identify the purpose of the project

2) Choose a one or two critical applications or services

3) Model the service or services

4) Integrate federated data from asset management, service desk and other tools

5) Define rules and analyses

6) Create analytics and reporting, and

7) Define role-based views.

When a BSM is carried out in a top-down manner with a just-enough orientation in mind, design and implementation can be easier – especially when approached with a service-oriented perspective. Need 10 Tips of a Successful CMDB? Click here.

-- Greg

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