01 / OWNERSHIP
Classes, sources and services
Name accountable owners for configuration classes, authoritative sources and remediation.
CMDB problems rarely present themselves as a data quality project. They surface as an incident routed to the wrong group, a change that disrupts a service nobody expected, a vulnerability report that cannot be matched to an accountable owner, or an audit that cannot reconcile licensed assets with what is installed. Reading each symptom back to the record that should have prevented it is the quickest way to decide what to fix first.
| Symptom | Record question behind it | Typical first check |
|---|---|---|
| Incident routed to the wrong team | Is the affected configuration item linked to the right service and support group? | A sample of recent incidents, compared with the item and service they reference |
| Change impact underestimated | Are service relationships present, current and correctly directed? | Dependency view for a small set of critical services |
| Vulnerability with no owner | Does the item or service carry an accountable owner? | Count of active records without an owner, grouped by class |
| Licensing position disputed | Do asset records and discovered items describe the same installation? | Reconciliation of one software product across both sources |
| Duplicate items | Do two sources create the same thing under different identities? | Comparison of identity rules for one class |
Each symptom in the table is usually a different defect, so the first diagnostic question should be which symptom is costing the business most. Treating all five at once tends to produce a broad program that cannot show progress on any of them.
The configuration management database, the Common Service Data Model and IT asset management are related but not interchangeable. The database stores configuration items and their relationships. The data model is a shared vocabulary describing what those items are and how they relate to services, so that a class means the same thing to every team that reads it. Asset management concerns the financial and contractual life of an asset: acquisition, assignment, retirement and licensing. Teams that blur these disciplines often add classes to answer a licensing question, or add licensing fields to answer a service question. Naming the discipline that the first release belongs to prevents most of that drift.
| Discipline | Question it answers | Typical owner |
|---|---|---|
| Configuration management | What is installed, and how does it connect to other things? | Platform or operations team |
| Common Service Data Model | What kind of thing is this, and which service does it support? | Architecture or service owner |
| IT asset management | Who holds the asset, what does the contract say, and when does it end? | Asset or procurement function |
A completeness percentage says how many records have values in their fields. It does not say whether the records support a decision. A useful diagnosis picks two or three decisions the business makes often, traces the records behind each one and grades those records on whether a person could act on them. The sequence is short: choose the decision, list the classes and relationships it reads, sample the records, mark each sample as actionable, ambiguous or unusable, and write down the reason for each mark.
Ambiguous records are often the most useful finding. They usually mean that two sources disagree, or that a rule is missing. The fix then belongs upstream, in the identity rule or the source precedence, rather than in the individual record.
Ownership fails when it is assigned to a function rather than to a person or a queue. Each configuration class needs an accountable owner, each authoritative source needs a named steward, and each business service needs an owner who can say what the service includes and which support group receives its incidents.
| Element | Owner | Decision the owner makes |
|---|---|---|
| Configuration class | Platform team, with architecture input | Required attributes and allowed values |
| Authoritative source | Steward of the discovery or import route | Which source wins when two disagree |
| Business service | Service owner | Which components belong to the service, and which group takes its incidents |
| Remediation queue | Operations lead | Who corrects a flagged record, and the time allowed for doing so |
The owner of a record should be able to say no to a change request that does not fit the rule, and the process should record that refusal. Without that authority, ownership becomes a label on a spreadsheet.
A sensible remediation sequence starts with the records that feed the next decision and works outward from them. Stopping new duplicates comes before cleaning old ones. If an import that creates duplicates keeps running, a clean-up is undone by the next scheduled run.
The sequence deliberately avoids correcting every record at once. A bulk correction without a stable identity rule tends to create a second round of problems, usually in the records that were correct before the clean-up began.
Two kinds of artifact make a CMDB improvement reviewable: a rule register and a remediation log. The formats below describe their structure. A buyer can check, before any work begins, whether a proposed route would produce artifacts like these.
| Artifact | Key fields | Purpose |
|---|---|---|
| Data quality rule register | Rule reference, class, condition, owner, queue, review cadence, exception route | Turns a quality check into an action that someone can take |
| Source precedence table | Attribute, ranked sources, conflict handling, reviewer | Settles which value wins when records disagree |
| Identity rule record | Class, identity attributes, matching logic, known exceptions | Controls the creation of duplicate items |
| Remediation log | Record reference, condition found, action taken, owner, verification date, outcome | Shows what changed and whether the change held |
| Service relationship extract | Service, component, relationship type, evidence source | Supports change impact analysis and incident routing |
Automated features that draft, route or summarize operational work depend on the records they read. If the configuration data is ambiguous, an assistant produces confident answers from weak evidence, and the errors look plausible enough to pass review. A practical test is to ask whether a person could make the decision from the records as they stand today. If not, an automated assistant will not make it reliably either.
Clean-up should come first when the AI use case depends on service ownership, impact analysis or asset status, when the same item is duplicated across tools, or when nobody can say which source is authoritative. Work can go ahead sooner when the use case reads only the text of a single item, such as summarizing one request. Governance controls for AI use are described on the AI governance and risk controls page.
| Use case | Dependence on configuration data | Sensible sequence |
|---|---|---|
| Routing incidents to support groups | High, because it needs service and group relationships | Confirm service ownership first |
| Summarizing a single request | Low, because it reads the request text itself | Can proceed with defined controls |
| Change risk suggestions | High, because it needs dependency data | Model critical service relationships first |
| Asset lifecycle reporting | High, because it needs reconciled asset and item records | Reconcile the sources first |
Configuration data is only as current as the process that maintains it. Discovery helps where the estate changes often, but a discovery route without an identity rule and named owners creates more records, faster, and none of them easier to act on. The question that usually decides the outcome is who keeps the data current once the project has finished. ServiceNow upkeep is described on the support and maintenance page, and the wider managed service area is described on the managed IT services page.
Use it as a trend, not a target. A high completeness figure can hide records that nobody can act on, because the fields are filled with placeholder values that pass a presence check. Pair the figure with the share of flagged records that reach an owner and close within an agreed time.
No fixed duration is offered here. Timing depends on the number of sources, the condition of the data, the number of classes in scope and how quickly owners respond to review requests. Those factors need to be established before a plan is agreed.
Not always. Discovery is most useful where the estate changes often and manual records fall behind. Where the estate is stable, a reviewed import and a clear identity rule may be enough to start.
Often yes. An assessment can help fix the scope and identify which decision the CMDB work must support. The ServiceNow assessments and readiness page covers a starting boundary for platform work before a commitment is made.
A useful starting point is one decision the business makes repeatedly, such as which group takes an incident or which owner approves a change, together with the records that decision reads. The contact page is where that decision and the places where the records disagree can be described.
ServiceNow TBM, which stands for Technology Business Management, allocates the cost of technology to the business services it supports, so a finance or product owner can see what a service costs rather than what a department spends. It gives a credible answer only when two data sets agree: cost records from finance and procurement, and a service model in the CMDB that says which components support which business service.
In practice the sequence runs in four steps. First, agree the cost pools, which group spend into areas such as hosting, network, licences and support labour. Second, map each pool to the configuration items or services that consume it, using the relationships already held in the CMDB. Third, allocate shared costs with a driver the business accepts, such as user count, transaction volume or share of compute. Fourth, put the allocated figures in front of the service owners who can challenge them. A figure a service owner has never seen is rarely corrected.
The common failure is starting with the cost data and building the service model afterwards. The cost totals still balance, which makes the gap hard to see, but the allocation is only as good as the relationships underneath it. Typically, a component attached to no service lands in an overhead pool, and the overhead figure grows each time someone adds an unmapped item. Check the unmapped share first, because it shows how much of the spend is still guesswork.
| TBM question | Data it depends on | Typical first check |
|---|---|---|
| What does this service cost? | Service relationships and allocated pools | Share of spend with no service mapped |
| Why did the cost move? | Cost history by pool and driver | Whether the driver changed rather than the spend |
| Which cost is shared? | Pool definitions and driver rules | Shared pools with no agreed driver |
TBM does not replace the configuration data work. The CSDM describes what a business service is and how it is structured, and the CMDB holds the items and relationships beneath it. Without those, a TBM report reproduces the spreadsheet it was meant to replace. The CSDM service modelling work is usually the prerequisite, and the ServiceNow CMDB guides cover the configuration side in more depth. Duplicate items inflate both the cost and the mapping errors, so reconciliation and duplicate control should come before the first allocation run.
Guides from the Oblytech ServiceNow library that explain the practice behind this page.