Organizations frequently experience confusion regarding Configuration Management Databases (CMDB’s). This confusion arises because there is currently no single, universally followed standard. Various authorities, governance bodies, auditors, and technology vendors have each introduced overlapping frameworks. As a result, the definitions of key concepts—such as Configuration Items, CMDBs, and Assets—often differ depending on the source. Even within a single organization, multiple frameworks can coexist, some of which may be outdated or only partially adopted.

Inconsistent Approaches to “What” and “How”

Enterprises vary significantly in:

  • What info they choose to store in a CMDB and what they store elsewhere.
  • How they register and maintain the data in the CMDB.

In some cases, the CMDB follows a rigorous data model. In others, it is simply a broad collection of tables into which data is entered without consistent structure. One organization’s CMDB might record only core infrastructure, while another’s includes a wide array of software components.

A Subset of the Truth

Historically, the CMDB served as a single source of truth and was manually maintained. Modern practices, however, rely more heavily on automated discovery and federated data from multiple sources. Consequently, the CMDB often represents a subset of an overall configuration landscape. Many essential data elements exist outside the CMDB in other repositories, such as version-control systems, artifact repositories, asset-management tools, cloud managers, and network managers.


Definitions

To enhance clarity, the following definitions apply throughout this discussion:

  1. Digital Product
    A designed or defined baseline item that is owned, has a lifecycle state, and can be procured, delivered, or deployed. Digital Products may encompass applications, infrastructure, transactions, or data.
  2. (SDLC) Component
    A fine-grained portion or section of a Product (i.e., a baseline). It can be deployed or applied independently.
  3. Catalog Item
    A Digital Product listed in a catalog. It typically features a specification or brochure and may come in different variants or versions.
  4. Service (Offering)
    A capability provided by a Service Provider to a Consumer. It has clearly defined commitments and entitlements, and is supported. A Service may be offered in multiple variants or “offerings,” each with distinct service levels, availability, or support structures.
  5. Configuration Item (CI)
    A deployed instance of a Product, Service, or Component (for example, a virtual machine, a software certificate, or a microservice). Digital Products, Components, Services, and Catalog Items themselves represent baselines; they do not constitute Configuration Items by definition.
  6. Asset
    A record linked to a Configuration Item that captures monetary (OPEX/CAPEX) information. A software license is an Asset, whereas the instance of the software is a CI. Assets commonly specify the owner, user, status, and location.

Note: ISO 27000, ISO 19770, and ISO 55000 classify all items of potential corporate value as “assets.” However, many organizations choose not to track every item (e.g., email messages or contracts) at the level of detail implied by these standards.


Portfolios and Repositories

  1. Digital Product Portfolio
    A collection of Digital Products owned or provided by the enterprise. It may not include products owned or managed externally.
  2. Service Portfolio
    A collection of Services and Offerings overseen by a Service Portfolio Owner. It can include third-party services consumed by the organization.
  3. Configuration Management Database (CMDB)
    A database of deployed instances (CIs), which are Products, Services, or Components in actual operation.
  4. Version Control Repository
    A repository of versions or baselines of Components.
  5. Artifact Repository
    A store of compiled build artifacts, binaries, and packaged components.
  6. Asset Repository
    A record of financial assets with OPEX/CAPEX value, such as software licenses. It does not necessarily track each operational CI.
  7. General Ledger
    The repository for overall financial transactions, such as procurement value, depreciation, and book value.

Practices: Baseline Management

Enterprises employ various methods to manage their baselines (Products and Components), influenced by unique organizational factors:

  • Complexity of the digital portfolio: A global bank with thousands of applications may employ a more elaborate approach than a chain of restaurants using only a dozen applications.
  • Regulatory environment: Organizations operating in multiple countries may face more complex legislative frameworks than those operating in a single jurisdiction.
  • Documentation methods: Some companies rely on Excel spreadsheets, others use formal Product Portfolio Management platforms, and some store product baselines in the CMDB itself.

In many organizations, a Product Portfolio includes items that are not formally managed, leading to inaccurate or incomplete data. The more structured the approach (e.g., a dedicated portfolio management tool), the more consistent the results tend to be. Conversely, less governed methods (e.g., ad-hoc spreadsheets) often yield inconsistent practices.

Fine-Grained Components

Many modern enterprises decompose business applications into microservices, containers, and serverless functions. Infrastructure is increasingly defined through code (e.g., Infrastructure as Code), which introduces additional granularity in management. Ideally, these finer components reference the Digital Products they belong to, but practice varies widely.


Services: Managing Variants and Offerings

A Service is provided by a Service Provider to a Consumer and is often listed in a Service Portfolio:

  • Multiple Offerings: A single Service may be offered in various tiers or variations (e.g., premium, standard) to accommodate different user or business requirements.
  • Subscription vs. Catalog: While Services often involve subscriptions over time, a Catalog Item may be a one-time request or a pay-per-use item. In such cases, the corresponding Service might handle the lifecycle support of whatever was procured.

Organizations employing frameworks such as ITIL commonly maintain a Service Portfolio, sometimes following the Common Service Data Model in ServiceNow. However, the maturity of these models varies. In many cases, the scope of entitlements, commitments, and subscription details is not clearly documented.


Catalog Practices

A Catalog allows employees or teams to request and provision various items, including:

  • Hardware (e.g., laptops, phones, accessories)
  • Software (including applications and licenses)
  • Cloud infrastructure (e.g., virtual machines, storage, networking)

Some enterprises maintain a highly organized catalog that reflects a web-shop style (e.g., distinct items for each type of hardware). Others have more generic entries (e.g., “Hardware Request” forms), where users must manually specify requirements. In more advanced environments, cloud resources and software-defined infrastructures can be provisioned automatically via APIs, often integrated with DevOps pipelines.


Instances and Their Management

Whenever a baseline (Product or Component) is deployed, it becomes an instance in production, development, or test environments:

  • Configuration Items (CIs): These instances may be registered in a CMDB.
  • Assets: If there is a financial dimension, an Asset record is often created.
  • Transient Components: Some environments use microservices or containers that exist for short durations, rendering detailed registration impractical.

Discovery Tools and Updates

Traditional agentless discovery was effective when infrastructures were static and IP-based. Modern practices often involve:

  • Agent-based discovery for real-time or near-real-time updates.
  • Federation of data from specific source systems into the CMDB on a periodic basis.

In many cases, multiple approaches are combined to suit different environments. Some organizations limit discovery to broad, static elements, accepting that ephemeral resources cannot be tracked at the same level of detail.


Conclusion

A CMDB is no longer the all-encompassing repository it once was considered. Instead, it is one element of a broader configuration ecosystem comprising dedicated tools for product portfolios, asset management, version control, and other areas. This evolution reflects the shifting technology landscape, in which microservices and dynamic cloud resources present new challenges for configuration management.

By clearly defining concepts—distinguishing between Products, Components, Services, Catalog Items, and Configuration Items—organizations can tailor their repositories and processes to suit their specific needs. Although a universally adopted standard remains elusive, employing well-defined practices and governance can significantly improve consistency and reduce confusion in modern IT environments.