The ability to understand relationships and dependencies across IT components, applications and services has long been desirable for IT organizations and it is the promise of configuration management database (CMDB) projects. The accuracy of data that application dependency mapping tools provide, in combination with the need for higher quality configuration data to improve ITIL processes of incident, problem and change, are part of a collection of reasons why CMDBs grew so explosively over the last 12-18 months.

The catalyst for CMDB projects is simple and the benefits are a tangible reality. If IT understands infrastructure relationships and dependencies they are better able to control change and manage the impact of change when it does occur. Patch management is a good case in point. A recent Computerworld survey found that two-thirds of Oracle DBA’s don’t apply security patches, primarily because they can’t understand the impact installing a patch will have on the database service.

The model of information about IT infrastructure components that a CMDB provides enables IT to understand the interdependencies about components in the context of the service. The DBA in the paragraph above for example, can see a holistic service view of the database application prior to installing a patch. This enables the DBA to understand the business impact a patch may have on other IT components and by extension, the service and take measures to prevent any adverse effects prior to implementation.

While the improvement to IT service quality in this anecdote is highly desirable, it understates the magnitude of a CMDB’s value proposition: to provide a more flexible, agile and resilient IT infrastructure that is truly aligned with business objectives. The ability to control change and manage impact means IT can respond quickly and as a strategic partner to a number of business demands, including the following:

• Consolidate and integrate new IT infrastructure following a merger or acquisition.
• Quickly provision IT services to a new office in an emerging market.
• Rapidly implement a new web service in response to customer demand.

The business case for a CMDB project is compelling, however the implementation can be a bit more challenging. To that end, below are 10 tips for a successful CMDB:

1. The 4 “Ps”

A good chef knows that cooking up something appetizing is a combination of culinary skill, a time-tested recipe and fine ingredients. The best chef with the perfect recipe cannot even hope for a delicious outcome if the ingredients are lacking. Likewise a CMDB is about the ingredients or as ITIL says people, process, products and providers. A CMDB implementation requires organizational buy-in, a proven methodology for implementation and best-of-breed technology.

2. It’s what you do with the data
Don’t spend all your time defining the CMDB instead give it a purpose. It’s easy to fall into the habit of parsing words and arguing semantics. However, the point of a CMDB is to improve service quality. If IT folks can clearly describe what it intends to do with the data in the CMDB, then they have gone a long way to defining its purpose and understanding what is actionable information as opposed to merely data. This purpose will guide the thinking and logic throughout the projects, for example, what should, or should not be included in the CMDB.

3. Data quality over quantity

A successful CMDB is not contingent on data it’s contingent on the right data. Be sure to identify the relevant data and proper process for accessing it. A CMDB should tie together carefully selected silos of information that model a service in its entirety. This makes what was mere data more accessible and meaningful, and in turn, transforms data into the information required to control change and manage the impact of change.

4. Don’t get hung up on a database
That a CMDB is called a “database” is a bit of a misnomer and focuses staff into thinking about change or asset management since the term connotes the idea of a traditional relational database. This can set unrealistic expectations that derail a project before it even gets started. For example, what might begin as a broad-based project with lofty goals winds up as an asset management project.

A principle reason the CMDB disguises itself on the pages of an asset management RFP is because it’s a high-profile buzzword that’s easier to justify. However asset management is more akin to an inventory audit, while a CMDB is about relationships among physical or logical items that comprise the service IT delivers to the business. More importantly, it’s about the impact a break in those relationships has upon users. Asset management is just one of many important data sources in a federated and heterogeneous IT infrastructure.

The ability to understand relationships and dependencies across IT components, applications and services has long been desirable for IT organizations and it is the promise of configuration management database (CMDB) projects. The accuracy of data that application dependency mapping tools provide, in combination with the need for higher quality configuration data to improve ITIL processes of incident, problem and change, are part of a collection of reasons why CMDBs grew so explosively over the last 12-18 months.

The catalyst for CMDB projects is simple and the benefits are a tangible reality. If IT understands infrastructure relationships and dependencies they are better able to control change and manage the impact of change when it does occur. Patch management is a good case in point. A recent Computerworld survey found that two-thirds of Oracle DBA’s don’t apply security patches, primarily because they can’t understand the impact installing a patch will have on the database service.

The model of information about IT infrastructure components that a CMDB provides enables IT to understand the interdependencies about components in the context of the service. The DBA in the paragraph above for example, can see a holistic service view of the database application prior to installing a patch. This enables the DBA to understand the business impact a patch may have on other IT components and by extension, the service and take measures to prevent any adverse effects prior to implementation.

While the improvement to IT service quality in this anecdote is highly desirable, it understates the magnitude of a CMDB’s value proposition: to provide a more flexible, agile and resilient IT infrastructure that is truly aligned with business objectives. The ability to control change and manage impact means IT can respond quickly and as a strategic partner to a number of business demands, including the following:

• Consolidate and integrate new IT infrastructure following a merger or acquisition.
• Quickly provision IT services to a new office in an emerging market.
• Rapidly implement a new web service in response to customer demand.

The business case for a CMDB project is compelling, however the implementation can be a bit more challenging. To that end, below are 10 tips for a successful CMDB:

1. The 4 “Ps”

A good chef knows that cooking up something appetizing is a combination of culinary skill, a time-tested recipe and fine ingredients. The best chef with the perfect recipe cannot even hope for a delicious outcome if the ingredients are lacking. Likewise a CMDB is about the ingredients or as ITIL says people, process, products and providers. A CMDB implementation requires organizational buy-in, a proven methodology for implementation and best-of-breed technology.

2. It’s what you do with the data
Don’t spend all your time defining the CMDB instead give it a purpose. It’s easy to fall into the habit of parsing words and arguing semantics. However, the point of a CMDB is to improve service quality. If IT folks can clearly describe what it intends to do with the data in the CMDB, then they have gone a long way to defining its purpose and understanding what is actionable information as opposed to merely data. This purpose will guide the thinking and logic throughout the projects, for example, what should, or should not be included in the CMDB.

3. Data quality over quantity

A successful CMDB is not contingent on data it’s contingent on the right data. Be sure to identify the relevant data and proper process for accessing it. A CMDB should tie together carefully selected silos of information that model a service in its entirety. This makes what was mere data more accessible and meaningful, and in turn, transforms data into the information required to control change and manage the impact of change.

4. Don’t get hung up on a database
That a CMDB is called a “database” is a bit of a misnomer and focuses staff into thinking about change or asset management since the term connotes the idea of a traditional relational database. This can set unrealistic expectations that derail a project before it even gets started. For example, what might begin as a broad-based project with lofty goals winds up as an asset management project.

A principle reason the CMDB disguises itself on the pages of an asset management RFP is because it’s a high-profile buzzword that’s easier to justify. However asset management is more akin to an inventory audit, while a CMDB is about relationships among physical or logical items that comprise the service IT delivers to the business. More importantly, it’s about the impact a break in those relationships has upon users. Asset management is just one of many important data sources in a federated and heterogeneous IT infrastructure.

The ability to understand relationships and dependencies across IT components, applications and services has long been desirable for IT organizations and it is the promise of configuration management database (CMDB) projects. The accuracy of data that application dependency mapping tools provide, in combination with the need for higher quality configuration data to improve ITIL processes of incident, problem and change, are part of a collection of reasons why CMDBs grew so explosively over the last 12-18 months.

The catalyst for CMDB projects is simple and the benefits are a tangible reality. If IT understands infrastructure relationships and dependencies they are better able to control change and manage the impact of change when it does occur. Patch management is a good case in point. A recent Computerworld survey found that two-thirds of Oracle DBA’s don’t apply security patches, primarily because they can’t understand the impact installing a patch will have on the database service.

The model of information about IT infrastructure components that a CMDB provides enables IT to understand the interdependencies about components in the context of the service. The DBA in the paragraph above for example, can see a holistic service view of the database application prior to installing a patch. This enables the DBA to understand the business impact a patch may have on other IT components and by extension, the service and take measures to prevent any adverse effects prior to implementation.

While the improvement to IT service quality in this anecdote is highly desirable, it understates the magnitude of a CMDB’s value proposition: to provide a more flexible, agile and resilient IT infrastructure that is truly aligned with business objectives. The ability to control change and manage impact means IT can respond quickly and as a strategic partner to a number of business demands, including the following:

• Consolidate and integrate new IT infrastructure following a merger or acquisition.
• Quickly provision IT services to a new office in an emerging market.
• Rapidly implement a new web service in response to customer demand.

The business case for a CMDB project is compelling, however the implementation can be a bit more challenging. To that end, below are 10 tips for a successful CMDB:

1. The 4 “Ps”

A good chef knows that cooking up something appetizing is a combination of culinary skill, a time-tested recipe and fine ingredients. The best chef with the perfect recipe cannot even hope for a delicious outcome if the ingredients are lacking. Likewise a CMDB is about the ingredients or as ITIL says people, process, products and providers. A CMDB implementation requires organizational buy-in, a proven methodology for implementation and best-of-breed technology.

2. It’s what you do with the data
Don’t spend all your time defining the CMDB instead give it a purpose. It’s easy to fall into the habit of parsing words and arguing semantics. However, the point of a CMDB is to improve service quality. If IT folks can clearly describe what it intends to do with the data in the CMDB, then they have gone a long way to defining its purpose and understanding what is actionable information as opposed to merely data. This purpose will guide the thinking and logic throughout the projects, for example, what should, or should not be included in the CMDB.

3. Data quality over quantity

A successful CMDB is not contingent on data it’s contingent on the right data. Be sure to identify the relevant data and proper process for accessing it. A CMDB should tie together carefully selected silos of information that model a service in its entirety. This makes what was mere data more accessible and meaningful, and in turn, transforms data into the information required to control change and manage the impact of change.

4. Don’t get hung up on a database
That a CMDB is called a “database” is a bit of a misnomer and focuses staff into thinking about change or asset management since the term connotes the idea of a traditional relational database. This can set unrealistic expectations that derail a project before it even gets started. For example, what might begin as a broad-based project with lofty goals winds up as an asset management project.

A principle reason the CMDB disguises itself on the pages of an asset management RFP is because it’s a high-profile buzzword that’s easier to justify. However asset management is more akin to an inventory audit, while a CMDB is about relationships among physical or logical items that comprise the service IT delivers to the business. More importantly, it’s about the impact a break in those relationships has upon users. Asset management is just one of many important data sources in a federated and heterogeneous IT infrastructure.

5. Clearly define an end-state

Just like a purpose is required to set the vision for the project, a CMDB also needs to have a clearly defined end-state. An end-state can serve as a trigger point to move a project into the next phase of implementation, for example once you’ve successfully modeled your SAP application in the CMDB, you move on to other critical applications such as CRM or order processing. Both the CMDB designer and user need to be included in building consensus around this point and it boils down to answering one simple question: how will you measure success?

6. Allocate enough resources
It’s an understatement to say that projects need executive sponsorship and successful CMDBs need a CIO-level sponsor. A committed executive level sponsor can ensure the project is properly staffed with the right resources. This does not mean you need your CMDB vendor to bus in an army of consultants, but on the other hand, the chances of success diminish if the project is assigned to an IT operations staff that also has a day-job, like keeping the lights on.

7. Just enough CMDB

Forrester Research advocates a methodology called “just enough CMDB.” This can be accomplished by focusing on a critical service, a given domain or even a line of business. Take a top down approach and avoid trying to model every service or application in your enterprise. Choose carefully because early success will help garner the support and acceptance required to roll the CMDB project to other areas.

8. Build in flexibility and modularity
The modularity of service orientated architecture (SOA) provides a degree of flexibility previously impossible. This is one of the reasons the concept is so popular. A CMDB should also build in flexibility and allow you to integrate multi-vendor sources of federated data. For example, agnostic technology enables IT to integrate performance data with asset management in the first phase, and then later tie in discovery information. A modular approach through integration allows IT to leverage existing IT management tools and deliver a faster return on the CMDB investment.

9. Don’t let “perfect” get in the way of “good”
ITIL tells us that change management process is important for continuous improvement. For example, if you find a process is producing suspect data, identify that area as problem and come up with a plan for correcting it. However, keep an eye on the big picture: a service approach to IT management that delivers higher quality to the business. Don’t spend 80%of your time fixing 20% of the problems.

10. Don’t wait to get started
That technology will continue to change and evolve is a maxim, but not a good reason to delay a CMDB project. Most large organizations have enough raw materials—some combination of a service desk, enterprise monitoring, asset management, or discovery—to begin building a CMDB today. With these tools installed, there are enough data elements to begin relating the data into the constructs of service. By virtue of having these tools in place, IT also has some degree of process. Through the course of integrating these pieces, IT organizations will continue to enhance the discipline and rigor to their change and configuration process.

Conclusion
Interest in CMDB projects grew substantially in 2007 and it is likely such project implementations will continue to accelerate over the course of 2008 and beyond. The ability to understand interdependencies among IT components and relate those components in the context of business impact will enable IT to be the strategic business partner it strives to be.

While the urgency to start a CMDB projects is understandable IT should be on alert for lessons learned from other concurrent or previous CMDB implementations. The CMDB could conceivably prove to be the most important acquisition of the IT enterprise for the foreseeable future.

Michele Hudnall is a former-META Group analyst and is currently the director of service management for BSM vendor Managed Objects, which is one of five vendors in the industry that meet Gartner’s functional requirements to be classified as a CMDB. She also sits on the board for the US-chapter of the IT Service Management Forum – itSMF.