CMDB

 

Have you ever been in a situation where leadership asks, "If this infrastructure component fails, what will be the impact on the business?"

If you've worked in IT Operations, Infrastructure, or Enterprise Architecture, you've probably encountered this question many times.

When we start on the journey of building a Configuration Management Database (CMDB), this is usually one of our primary objectives. Unfortunately, as the implementation progresses, we often lose sight of that goal. Let’s try to understand the reason.

One of the most common mistakes organizations make is focusing almost exclusively on populating the CMDB with Infrastructure Configuration Items (CIs) and establishing relationships between them. While this is important, we often overlook the non-infrastructure components—such as Business Capabilities, Business Applications, Business Services, and Applications—and, more importantly, their relationships with the underlying infrastructure.

The reality is that no single discovery or CMDB tool can automatically build end-to-end relationships between infrastructure CIs and business-facing CIs. While many tools can discover infrastructure and map technical dependencies, the business context often requires manual modeling, governance, or carefully designed automation.

As organizations continue to embrace a service-centric IT operating model, our focus should shift from simply discovering infrastructure to ensuring that every infrastructure CI supports a business outcome. In other words, we should avoid leaving our Service CIs orphaned.

A strong CMDB foundation starts with defining and relating to our Business Capabilities, Business Applications, Business Services, and Applications. Once this foundation is in place, infrastructure can be associated with the appropriate Application, enabling true end-to-end visibility from the business layer down to the underlying technology.

Before diving deeper, let's look at these concepts at a high level.

 

 

Different platforms offer different capabilities to automatically discover and establish relationships between Applications and the underlying Infrastructure. While these products can significantly accelerate CMDB implementation, they vary in their discovery capabilities, dependency mapping, and integration complexity. More importantly, no tool can fully understand your organization's business context without appropriate governance and modeling.

Coming back to the original discussion, the foundation of a successful CMDB should always begin with defining the Business Capabilities, Business Applications, Business Services, and Application, along with the relationships between them.

At a high level:

• A Business Capability is enabled by one or more Business Applications.
• A Business Service delivers one or more Business Capabilities to customers or internal users.
• A Business Service is supported by one or more Application.
• An Application depends on the underlying Infrastructure.

Once these relationships are established, every new infrastructure component should be associated with the Application it supports. Discovery and automation tools should enrich and update the corresponding Infrastructure CI rather than creating isolated or orphaned records.

Although this approach may require additional effort during the initial implementation, the long-term benefits are significant. Every infrastructure CI becomes traceable to a business outcome, making impact analysis, incident management, change management, and operational governance far more effective. Most importantly, no server or infrastructure component remains unaccounted for.