SEARCH 

About this Entry

This page contains a single entry by Siki Giunta published on March 17, 2008 9:15 AM.

The intelligent energy system... was the previous entry in this blog.

Be a BSM Superhero, step 3.5 is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.

Syndicate




 

Who says discovery before CMDB?

| Comments (1)
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

1 TrackBacks

Listed below are links to blogs that reference this entry: Who says discovery before CMDB?.

TrackBack URL for this entry: http://www.wearebsm.com/mt-tb.cgi/16

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... Read More

Visitor Comments

I agree that doing more discovery when so much information exists seems less than efficient. However, as Configuration Management is all about one's services, and relationships tie the configuration items together into views of the services, would you allow that adding a relationship discovery tool into one's early efforts makes sense?

Leave a comment