Standard CMDB
Standard CMDB
When a server fails at 2 AM, the questions are always the same: which services are affected, who owns them, and what else is about to break? A spreadsheet cannot answer those questions. The Standard CMDB can.
Version 3.0 of the schema gives you eight object types covering the infrastructure and service layers of IT: servers, databases, applications, network devices, cloud resources, software licences, business services, and documentation. The organisational layer (people, teams, vendors, locations) is no longer duplicated inside this schema. Standard CMDB now extends the Core schema and references those types where they already live.
What you get
| Object Type | Purpose | Key Attributes |
|---|---|---|
| Business Service | Business-facing services such as email, CRM, ERP | Service Name, Service ID, Description, Criticality, Service Owner, Support Team, SLA, Status |
| Server | Physical and virtual servers | Hostname, IP Address, FQDN, Server Type, Operating System, OS Version, CPU Cores, RAM (GB), Storage (GB), Environment, Location, Vendor, Status |
| Database | Database instances | Database Name, Database Type, Version, Port, Size (GB), Environment, Hosted On, Backup Schedule, Status |
| Application | Software applications and microservices | Application Name, Application ID, Description, Version, Application Type, Technology Stack, Repository URL, Environment, Hosted On, Uses Database, Part Of Service, Portfolio Entry, Status |
| Network Device | Routers, switches, firewalls, load balancers | Device Name, Device Type, IP Address, MAC Address, Manufacturer, Model, Firmware Version, Location, Status |
| Cloud Resource | Cloud infrastructure resources (AWS, Azure, GCP) | Resource Name, Resource ID, Cloud Provider, Resource Type, Region, Account/Subscription, Monthly Cost, Environment, Part Of Service, Status |
| Software License | Software licenses and entitlements | License Name, License Key, License Type, Seats, Seats Used, Start Date, Expiry Date, Annual Cost, Vendor, For Application, Status |
| Document | Technical documentation and runbooks | Document Title, Document Type, URL, Last Updated, Related Service |
8 object types · 10 reference types · extends Core
Every object type arrives pre-configured with attributes, relationships, and sensible defaults. Deploy it, populate it, and you have a CMDB that answers the questions your service desk asks every day: what runs on what, who owns it, and what breaks when something goes down.
Pro tip: You do not need to populate all eight object types on day one. Start with servers, applications, and business services. Add network devices, databases, and cloud resources as your team gets comfortable with the schema.
What comes from Core
Earlier versions of this schema (v2.x and before) carried their own Person, Team, Vendor, and Location types. Version 3.0 drops all four. Master data belongs in one place, and that place is the Core schema. Seven attributes in the Standard CMDB now point at Core types instead:
| Attribute | Core target | Reference type |
|---|---|---|
| Business Service → Service Owner | Person | Owned By |
| Business Service → Support Team | Team | Supported By |
| Server → Location | Location | Located At |
| Network Device → Location | Location | Located At |
| Server → Vendor | Vendor | Supplied By |
| Software License → Vendor | Vendor | Supplied By |
| Application → Portfolio Entry | Application | Instance Of |
A few details moved with the types rather than disappearing:
-
Member Of (the old Person to Team link) is now the Team attribute on Core's Person, so the Member Of reference type no longer exists in this schema.
-
Team Type lives on Core's Team.
-
Contract End Date on the old local Vendor was dropped entirely. Contract lifecycle is properly modelled by the Contract type in the Vendor Management schema, not by a single date on a vendor record.
-
Portfolio Entry is new in v3.0: an optional link from a deployed Application to the portfolio-level Application record in Core, using the Instance Of reference type. It connects what is running to what the business thinks it owns.
How references resolve at deploy time
You do not need Core installed to deploy the Standard CMDB. When you deploy, LaunchPad asks how each external reference should be resolved:
-
Link to Core: connect to the shared Core schema. Recommended whenever Core is installed; cross-schema sharing is enabled automatically and recorded in the audit log.
-
Create here: create the target type inside this schema from the bundled Core definition. The standalone fallback; you get a real object reference without installing Core.
-
Keep as text: keep the field as a free-text attribute. The minimal option for teams that are not ready to model the organisational layer at all.
For the reasoning behind this design, see Hub-and-spoke architecture.
When to use this schema
Deploy the Standard CMDB if:
-
Your organisation runs a mix of physical and cloud infrastructure.
-
Multiple teams manage different service areas and you need cross-team visibility.
-
You need proper asset relationships beyond the basics (dependencies, ownership, service mapping).
-
You are tracking more than 100 assets and the Basic CMDB no longer covers your needs.
If you have a small environment (fewer than 100 assets, one team), the Basic CMDB will get you started faster. If you need additional domains such as cybersecurity, vendor contracts, or workforce tracking, explore the Service model reference for specialist schemas that share the same Core foundation.
Not sure which schema fits? See Which Schema Should I Choose?
Schema at a glance
Within the Standard CMDB:
Database ──────────(Hosted On)──────▶ Server
Application ───────(Hosted On)──────▶ Server
Application ───────(Uses Database)──▶ Database
Application ───────(Part Of Service)▶ Business Service
Cloud Resource ────(Part Of Service)▶ Business Service
Software License ──(Licensed For)───▶ Application
Document ──────────(Documents)──────▶ Business Service
Out to the Core schema:
Business Service ──(Owned By)───────▶ Person (Core)
Business Service ──(Supported By)───▶ Team (Core)
Server ────────────(Located At)─────▶ Location (Core)
Network Device ────(Located At)─────▶ Location (Core)
Server ────────────(Supplied By)────▶ Vendor (Core)
Software License ──(Supplied By)────▶ Vendor (Core)
Application ───────(Instance Of)────▶ Application (Core)
Eight object types, richly connected, with the organisational layer shared rather than duplicated. The relationship model means you can trace a failing server all the way up to affected business services and the people responsible for them, even when those people live in a different schema.
Documentation
Quick Start Guide Step-by-step deployment and configuration. Walks you through deploying the schema, resolving the Core references, adding your first records, and verifying that relationships are working correctly.
Governance playbook and forms specification for this schema are part of the LaunchPad Playbooks offering (coming soon).