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.
