CMDB

The configuration management database (CMDB) template installs a database that catalogs your service landscape: the business applications and IT services people depend on, the infrastructure that runs them, and the relationships between them. CMDB relationships are built into the schema and queryable, so change management and impact analysis (e.g. “what’s downstream of this server?”) work out of the box. To set up a CMDB, either install it from the template library, or ask Catalyst to “set up a CMDB.” One team gets one CMDB database.

​

What it models

The schema is organized into three layers: business, service, and infrastructure.

​

Business layer

This layer maps the outcomes an application outage affects, so that business impacts are clear.

​

Service layer

The service layer describes what people name when they ask for help, and the applications behind it.

​

Infrastructure layer

The infrastructure layer maps the resources that deliver the services, typically ingested from cloud, MDM, and discovery sources.

​

The dependency map

In addition to the reference fields on each table, the CMDB template documents the following relationship types, which are useful for impact analysis:

• Delivered By: an IT Service to the Application Services that deliver it.
• Service Dependency: one Application Service to another it calls at runtime.
• Runs On / Hosted On: an Application Service to the Server or Cloud Resource it runs on.
• Uses Database: an Application Service to the Database Instances it reads and writes.
• Secures: a Certificate to the services it secures.
• Supports Capability: a Business Application to the Business Capabilities it supports.

Together, these relationships allow you to trace impact from a dead server, through the Application Service and its dependency chain, up to the IT Service an employee named in a ticket, and out to the Business Capability it affects. Open any record’s context graph to trace it, and the help desk agent traverses the same graph when it answers. The help desk agent can find Business Application and IT Service records by name without a requester link, because those are what people name in tickets (e.g. “Salesforce is down”). Infrastructure records stay scoped to the requester.

​

Use cases

• Impact analysis before a change. Before you take a server, database, or certificate down, trace what depends on it, so you know who’s affected and can plan.
• Faster incident triage. When someone reports a problem like “Salesforce is down,” the help desk agent resolves the named service to the applications and infrastructure behind it, and surfaces the likely culprit from the dependency chain.
• Service ownership. Understand which applications support each Business Capability and which infrastructure delivers each service.

​

Usage tips

• Populate it by connecting your cloud, MDM, and discovery sources with ingestion configs, or load records by CSV import. Key fields (e.g. FQDN, resource ID, instance ID) are the de-duplication keys that sync matches on.
• Extend it with your own fields, tables, and relationships, and add validation rules to keep records complete.
• Govern it with table, field, and record-level access, and mark sensitive fields so each reveal is logged in your organization’s audit logs (accessible by your admins).

​

How it fits with the other templates

CMDB, Hardware Assets, and Software & Licensing are separate databases by design, joined by shared values rather than hard links: a Server’s serial number matches its hardware-asset record, and Location means the same thing in each.