Planet SCM

Configuration Management Databases or CMDBs are a hot topic of conversation in IT today. Whether you're looking to implement best practice standards like those found in ITIL, or need to find an enterprise solution for meeting compliance obligations, establishing a CMDB is becoming as much of a "must" for how data is managed as grabbing a PS3 is this holiday season for some families. And, just as disappointed as some kids will be to not see one December 25th, there's a similar expectation that a CMDB will magically appear under the corporate tree this year.

This past week, Dennis Drogseth, Vice President of Enterprise Management Associates, shared some timely reminders of what a CMDB is, not what we'd like it to be.

CMDB's are:

• Still in their infancy. Don't try to define them prematurely.
• A foundation and enabler that will continue to grow in importance
• A system that brings politics, culture, organization, technology and products together
• Not something you can buy, although you can purchase software that may be strategically useful in creating a CMDB system.
• Systems that demand a phased approach which requires executive buy-in.

If you are looking to successfully establish a CMDB system, it's important to reject the typical "microwave" solution we seem to favor - especially in America. By its nature, a successful CMDB will take cooperation among diverse groups within your organization. To successfully capture the appropriate information, you will need to plan carefully and involve multiple vendors. Make up your mind now that establishing a CMDB system is a process, not an one-time event.

So, where do you begin this CMDB journey? Drogseth spells it out clearly when he says, "I believe the single most defining thing in creating a CMDB system is identifying trusted sources of information, or sources of record...it's the one [step] aboe all that brings you immediate, intrinsic value."

Establish your objectives for the CMDB, then determine your trusted sources of the information that will meet your objectives. You can't pull up to a drive-thru and order a super-sized CMDB with a side order of compliance or expect to see a guy in a big red suit drop by with your gift-wrapped CMDB.While it's not glamorous or quick, a carefully followed plan will ultimately yield the benefits you're looking for when considering establishing a CMDB system.

I’ve been sitting back watching networking publications and industry analysts banter back and forth about the pros and cons of what vendors are touting as CMDBs. Most notable were a Network World article and a newsletter posting.

The article I’m referring to was written by Denise Dubie on September 20^th, entitled, Interop panel: Is network management irrelevant? In the article, Shmuel Klinger, vice president of architecture and applied research with EMC, states that, “…management vendors continue to collect more data and provide network managers with information on applications and systems performance, yet don’t provide enough intelligence or automation within their products for network managers to find the data useful for anything more than just an annoyance.

Contrasting Klinger’s “data annoyance” are Julie Craig’s comments in a recent Network World newsletter. Craig’s point is “The ITIL concept of a CMDB doesn't specify implementation details. And as time goes on and technology becomes increasingly complex, many vendors are finding that more and more information is needed to manage today's complex technology. The result is that, while ITIL focuses on CMDB Configuration Items (CI) as infrastructure elements and their relationships, today's CMDBs are also storing additional information that has become increasingly relevant over time.” So, which is it? Are we capturing too much or too little data?

I am strongly of the belief that the more information you capture, the more intelligent your decision-making will be. With initiatives like Business Intelligence (BI), Business Service Management (BSM), Enterprise Resource Planning (ERP) and Information Life-cycle Management (ILM) capturing headlines in IT trade publications on a weekly basis, it’s hard to believe IT executives would want to know less about their infrastructure.

What’s valuable about Klinger’s comments is not to focus on the volume of data we should or should not capture, but the point that capturing data without the tools to analyze it easily and accurately is, as he said, an annoyance.

The true value of a CMDB is to make use of the information gathered to offer true visibility into the operational integrity and delivery of business services — dashboards and reporting functions are critical to realizing this goal across the entire IT environment.

What are your thoughts on Klinger and Craig’s comments? Are we capturing too much or too little information, or do we just need to do a better job gaining intelligence from the data we have?