IT Service Management: Modernizing the CMDB for the Cloud Era

This is the first post in a Provance blog series exploring what effective CMDB practice looks like in the cloud era.

Throughout this series, we’ll examine how organizations can build and maintain trusted CMDBs by separating operational telemetry from operational context, modelling business intent more deliberately, and measuring service outcomes to drive continual improvement.

Why the Cloud Changes the CMDB Conversation

Traditional CMDB practices were designed for long‑lived servers, static networks, and manual change. Modern cloud and platform environments are different by design: resources are created, replaced, scaled, and destroyed continuously by automation.

Over years of working with customers modernizing ITSM and CMDB practices, one theme appears consistently: the cloud makes it easy to capture almost everything, but that does not mean everything should be captured.

When organizations attempt to track all discovered resources as Configuration Items (CIs), the result is predictable:

• CI sprawl and constant churn
• Reconciliation instability
• Stale or contradictory data
• Loss of trust in CMDB accuracy

The goal of a modern CMDB is no longer completeness. It is relevance.

Core Concepts: Ephemeral, Transient, and Intentional Resources

A cloud‑aligned CMDB starts with clear distinctions between different kinds of resources.

Ephemeral Resources

Ephemeral resources are short‑lived, system‑generated artifacts created to support execution:

• Pods and execution instances
• Auto‑scaled compute nodes
• Short‑lived containers or jobs

These artifacts are invaluable as operational telemetry, but they are not suitable as long‑lived configuration records.

Transient Resources

Transient resources are intentionally created to support a temporary phase or objective. They may exist for weeks or months but are not part of a steady‑state architecture.

Examples include:

• Migration or cutover infrastructure
• Staging or pre‑production environments
• Temporary parallel implementations
• Standby or fallback resources

Transient resources are not exhaust. They represent operational intent with a defined lifecycle.

Intentional (Steady‑State) Control Points

These are resources designed to:

• Support critical services
• Carry ownership and accountability
• Define boundaries or dependencies

These resources typically belong in the CMDB because they anchor operational context and service understanding.

Why Runtime Exhaust Does Not Belong in the CMDB

Operational telemetry—metrics, logs, events, and execution artifacts—changes constantly. Attempting to persist this telemetry as configuration creates churn and masks what actually matters.

Instead:

• Operational telemetry should be observed via monitoring and Event Management
• Operational context should be preserved in the CMDB

This separation allows each system to excel at its purpose.

Decision Framework: Track, Observe, or Ignore

Rather than asking “Can the CMDB track this?”, a better question is:

Does tracking this improve service understanding, incident response, or risk decisions?

We recommend evaluating resources using three intentional outcomes:

Track (Create or Maintain a CI)

Track an item when it:

• Represents stable operational intent
• Has ownership or lifecycle management
• Affects service impact or risk

Observe (Operational Telemetry Only)

Observe an item when it:

• Is highly dynamic or short‑lived
• Is system‑generated
• Provides execution‑time evidence

Ignore

Ignore an item when removing it does not reduce understanding, safety, or governance.

This framework protects CMDB trust while still preserving operational insight.

What a Modern CMDB Should Focus On

A modern CMDB should model:

• Service control points
• Ownership and accountability
• Designated use and criticality
• Dependencies and boundaries
• Meaningful structural change

This information forms operational context—the foundation for impact analysis, risk assessment, and improvement.

Tags as Intent Signals (A Preview)

One practical way to express intent early is through cloud tags. Tags allow teams to declare responsibility and intended use at creation time.

Tags are not the CMDB—but they are valuable signals that help bridge operational telemetry to persistent context. Later posts explore this pattern in detail.

Closing Thought

A disciplined CMDB does not try to mirror the cloud. It preserves what matters about the cloud.

Just because you can capture everything does not mean you should.

By prioritizing relevance, intent, and operational context, organizations can build CMDBs that remain trusted, usable, and valuable in the cloud era.