Statistics indicate that only 25% of organizations are actually receiving meaningful value from their CMDB investments. The CMDB Data Model is often implemented in a technology-focused way, making its content difficult for business stakeholders to understand, especially as technology becomes increasingly complex. Adopting a Common Service Data Model helps restore focus and align the company’s silos. However, the purpose of CSDM5 is often overlooked, and people frequently go overboard in modelling its artefacts. The subtle differences between the CSDM versions are usually not incorporated. As a result, outdated practices persist, emerging capabilities/practices are not adopted, data quality deteriorates, costs skyrocket, and the expected benefits fail to materialize. Even if you manage to implement a perfect CMDB, this means nothing if the CMDB data is not used for its intended purpose. 75% of all CMDB investments fail to deliver meaningful value.

Having worked with/on CMDBs since 2008, with CSDM since 2017, and with TBM since 2020 (both on successful and unsuccessful CMDB projects), I concluded that success was achieved only when keeping it simple, whilst populating the CSDM model with clean data that is fit for purpose and for the audience, and not going overboard. Automating the maintenance of CMDB content through discovery and/or federation, and ensuring people can’t manipulate data anywhere other than in its source, also proves to be a critical success factor.

In the Common Service Data Model (CSDM5), the following types of objects are differentiated:

  • A Business Application: a logical business-facing product that provides Business Capabilities.
  • A Technology Application: a logical technology-facing product that provides Technology Capabilities.
  • A SDLC Component: a deployable (or deployed ) component that is an integral part of a Business/Technology Application (or an instance thereof).
  • A Business Service; a business-facing service that may consist of offerings (each with different commitments and subscriptions):
  • A Technology Mngt Service; a technology-facing service that consists of offerings that each contain (or rather: manage) one or more Service Instances.
  • A Service Instance: a representation of a logical stack of deployed items, typically enabling a DTAP instance of a Business Application (or logical group thereof)
  • A Service Delivery System: a collection of technical products facilitating (components/instances of) Business Applications and/or Technology Mngt Applications.
  • A Product Model: a model of a discovered/federated product instance. E.g., a model/version of a Hardware- or Software Product.

A Service Instance connects Applications to Business Service Offerings, Technology Management Services, and Service Delivery Systems. For most companies, it is recommended to create one Service Instance per deployed instance of a Business/Technical Application. The remaining artefacts then automatically fall into their logical place in the CSDM. E.g., when modelling the Service Instances as recommended, the following is possible:

  • Relate any Service Instance to any other Service Instance, enabling modeling of horizontal dependencies that facilitate impact analysis and automated workflows.
  • Relate each Service Instance to a single Business Application, so that the Instance can inherit from the Application it is an instance of.
  • Relate each Service Instance to the one Technical Mngt Service Offering that defines its commitments, owner, and operations teams.
  • Relate a production Service Instance to subscribed Business Service Offerings that depend on that production Service Instance.
  • Map relevant instances of technical products (e.g., servers, databases, components, cloud service accounts) to the Service Instance that consumes them.

Customer Cases and Employee Interactions (aka Universal Requests) refer to:

  • The subscribed Employee or Customer for which the Case/Interaction was logged
  • Business Service Offering (incl. its related Service Desk Team, Commitments, Business Service and Taxonomy Node)
  • The Agent (who is a member of the Service Desk), who is assigned to the Case/Request/Issue
  • (Optionally) One of the Service Instances that the Business Service Offerings depends on.
  • (Optionally) The Internal Task record that is created to address the Case/Request/Issue

Requests, Incidents, Problems, and Changes (aka ITSM Tasks) refer to:

  • The subscribed Employee who raised the incident, Problem, or Change (not the external customer)
  • The Technology Management Service Offering (incl. its related DevOps Team, Commitments, Technology Mngt Service and Taxonomy Node)
  • The Fulfiller (who is a member of the DevOps team) who is assigned to the Task
  • (Optionally) One of the Service Instances that the Technology Management Service Offering contains
  • (Optionally) One of the Dynamic CI Groups that the Technology Management Service Offering contains
  • (Optionally) One of the Configuration Items that the Selected Service Instance depends on

  • (Optionally) All of the Configuration Items that the Selected Dynamic CI Group contains at the time of registration.

Notes

  • Coarse-grained logical Business/Technical Applications are recorded to enable Architects to manage the Application lifecycle and dependencies. Employees and Customers may use Business Applications. Members of DevOps teams may also use Technical Applications. Architects manage the lifecycle of these applications via Application Portfolio Management. The Applications are supported by (internal or external) Teams and/or by the (SAAS) Vendor. The Application is usually provided (to its subscribers by the Provider/Owner) as a Business/Technical Service offering that meets documented commitments. The licenses/authorisations for the Applications are periodically reviewed and harvested by the team that maintains the Application/Offering and its subscriptions on behalf of the Application’s Owner.
  • The Business Services and their Offerings are documented in Service Catalogs. Internal Business Services are defined by the Corporate Function (or Technology Tower) that provides or sells them (e.g., IT Workplace, HR, IAM, Finance, Facilities, etc). The company’s Marketing organisation defines the External Business Services, incl. its commitments and subscriptions. The Services and their offerings, including their owners, groups, commitments, subscriptions, etc, are reviewed/updated periodically.
  • The Technology Management Services and their Offerings are documented in the Catalogs of the Technology Towers that provide those Management Services. The Offerings are subscribed to by the parties that depend on them (being representatives/teams of the Business and/or Technology). The Services and their offerings, including their owners, groups, commitments, subscriptions, etc, are reviewed/updated periodically.
  • By adopting the Technical Business Management (TBM) content for commodity solutions, the Technical Management Services and Business Services can be imported/used out of the box, including their Solution Types and Solution Categories (which can be used as taxonomy nodes). For company-specific Business Services that differentiate your company from your competition, you have to reinvent the wheel yourself, and probably you have already done so. By adopting TBM Solutions, you only need to fill in its product- or module-specific offerings, including commitments and subscriptions. This will save you 3-4 months of implementation effort, a lot of reiterations, and circumvent conversations with people who like to reinvent the wheel without proper justification. Why should the delivery and maintenance of Windows Laptops be fundamentally different for your company than a similar-sized enterprise? The hidden benefit of reusing market-standard content is that your vendors and outsourcing partners can work with you more effectively, improving data quality, reducing your risk profile, and reducing the total cost of ownership.
  • The (lifecycle of) the Technologies that underpin the Service Instances (e.g., AWS/Azure Public Cloud, SQL Server 2026, Apache Tomcat, Windows Server 2022, Wildfly, HP Elitebook 840 G8, Active Directory, DNS, Kafka, Mulesoft, etc) are managed in tools such as XL Deploy. Once deployed (often as part of a template), the technologies (including their versioned Product Model) are discovered and federated into the CMDB.
  • The (lifecycle of) Packages and Software Images that may be deployed on PC’s, tablets, or Mobile Phones are managed in end-user computing tools such as Entra, Intune, and Corp. Portal. Once deployed, the packages (including their versioned Product Model) and the versioned OS are discovered and federated into the CMDB.
  • Fine-grained, elastic, and/or transient Cloud Resources, Pods, Containers, and Microservices are dynamic and managed/orchestrated at runtime directly via CDAAS tools. These items are observed/monitored (e.g., by Zabbix, Dynatrace, DataDog, etc.), but are not federated to the CMDB. The changes to the configurations/flows are registered (as standard changes) at the time of deployment, including their impact on the affected offerings.