OBLYTECH / SERVICENOW CAPABILITY
ServiceNow CMDB ownership model for accountable data decisions
Connect classes, sources, services and quality work to accountable operating responsibilities.
PARTNER DELIVERY — OBLYTECH is a ServiceNow Partner.
Discuss your ownership priorityA ServiceNow CMDB ownership model should make it clear who decides, who corrects,
who approves an exception and who reviews the result. OBLYTECH helps organisations
connect configuration classes, sources, services and quality work to accountable
operating responsibilities.
Ownership means a decision, not just a name
Putting a team name beside a class does not make the data owned. The owner must have
authority to define the information, resolve a conflict, approve an exception or
escalate a source problem. The model should also say what happens when the owner
cannot make the decision alone.
The responsibilities a CMDB model must separate
Data source and class ownership
Identify who owns each important class, source and field, and who can change its
definition. When two sources disagree, record the precedence and the person who
resolves the conflict.
Service and relationship ownership
Service owners need a way to confirm whether configuration relationships represent
the service they operate. Relationship ownership should support decisions such as
impact review, change assessment and incident routing.
Quality remediation and exceptions
A quality issue needs a queue, responsible team, escalation and closure condition.
The owner who accepts an exception should be different from an automated process
that merely reports it when the decision requires authority.
How OBLYTECH establishes CMDB ownership
- Identify the service, operational or audit decision the data supports.
- Map classes, sources, services, relationships and current responsibilities.
- Separate authority, stewardship, remediation and review duties.
- Define conflict, exception, escalation and closure paths.
- Test ordinary, stale, duplicate and conflicting records.
- Establish review evidence and change ownership.
For the wider route, see the ServiceNow services overview.
For the parent hub, see ServiceNow CMDB, CSDM and ITAM.
What the engagement can establish
- decision owners for classes, sources, services and relationships;
- stewardship and remediation responsibilities;
- conflict, exception and escalation routes;
- review evidence and cadence; and
- a controlled first ownership release.
Discuss your CMDB ownership priority
Bring the configuration area where nobody is sure who decides, who corrects or who
accepts an exception. OBLYTECH can help turn that ambiguity into an operating model.
Discuss your CMDB ownership priority
Bring the configuration area where nobody is sure who decides, who corrects or who accepts an exception.
Discuss your CMDB ownership priority with OBLYTECHWho is accountable when a configuration record is wrong
When a configuration record is wrong, many organizations discover it through a symptom. An incident is routed to a group that does not run the service. A change is approved on an impact list that leaves out a dependency. An auditor asks who approved a value and nobody can answer. Each symptom points back to the same gap: no one had the authority to decide what the record should say, and no one was obliged to act when the record failed. An ownership model closes that gap by separating the people who decide, the people who correct, the people who approve exceptions and the people who review the outcome.
The separation matters because these duties are often collapsed into one role. Naming each duty, even when one person holds several, makes the gaps visible before they cause a failed change.
The duties a CMDB ownership model has to separate
The table sets out four duties and the question each one answers. A single person can hold more than one, but the model should state which hat they are wearing when they make a decision.
| Duty | The question it answers | What it does not include |
|---|---|---|
| Decision authority | What must this class, source or relationship mean, and who may change that definition? | Routine data entry or the day-to-day correction of values |
| Stewardship | Is the data current, complete and consistent with its definition? | Approving exceptions to the definition |
| Exception approval | Should this record be allowed to stay outside the rule, and for how long? | Fixing the record itself |
| Review | Did the decision protect the operational use it was meant to support? | Changing the definition without the decision authority |
The review duty is often left out. Without it, the model defines who decides but never checks whether those decisions still serve the people who rely on the data.
Choosing the level at which ownership is assigned
Ownership can be assigned to a class, to a source, to a field, to a service or to a relationship type. Each level answers a different question, and assigning everything to the most convenient level creates ambiguity. A class owner decides what belongs in the class. A source owner decides which system is authoritative for a value. A service owner confirms that the configuration items linked to the service really support it. A relationship owner defines what a relationship type is allowed to mean.
Many teams begin with the service level because it matches how incidents and changes are approved. The risk is that a service owner is asked to confirm technical fields they cannot see. A workable compromise is to assign the service owner to confirm the service boundary and its supporting items, and to assign class and source owners to the technical attributes beneath it.
Handling disagreement between owners
Two owners will eventually disagree. A network team may say a device belongs to a service, while the service owner says it does not. A discovery feed may report a value that conflicts with a manually maintained field. The model needs a route for these conflicts before they happen, because a conflict resolved in a meeting can create a precedent nobody records.
- Record the conflict as a work item with both positions, the evidence each side relies on, and the decision it affects.
- Apply the precedence rule for that field or relationship type if one exists. If none exists, the decision authority for that class decides and records the reason.
- Where the conflict cannot be resolved within a set period, escalate it to the person who owns the service’s operating decisions, not to a general forum.
- Write down the outcome, including the precedence rule that now applies, so the next conflict of the same kind does not begin from zero.
The owner who accepts an exception should not be the same process that reports it. An automated check can detect a breach and open a task. Only a named person with authority over the decision should accept that the breach can stay.
Starting with a small ownership release
Ownership models tend to fail when they are designed for the whole estate at once. A practical first release covers the classes and services that feed one high-value decision, such as incident routing for a critical service family or impact review for changes to a shared platform. It names the decision authority, the stewards, the exception approver and the reviewer for that scope, and it tests the model against recent real cases before extending it.
The first release also reveals which owners do not yet exist. A class with no plausible owner is a finding, and it may mean the class should be retired or merged rather than governed. Recording that outcome is part of the work, not a failure of it.
Keeping ownership current as people and services change
Ownership goes stale when people move. A review that happens only at the time of a report will miss a transfer that happened three weeks earlier. Tie ownership changes to the events that cause them: a team reorganization, a service transfer, a supplier change or a retirement. Each event should trigger a check on the decision authority and stewardship for the affected classes and services. A transfer that is recorded in a service catalog but not in the configuration records is a common and avoidable gap.
Departing owners need a handover that covers their decisions, not only their tasks. The handover should list the exceptions they approved, the conflicts still open and the precedence rules they relied on. An exception approved by someone who has left is an exception nobody can defend.
Where the ownership model connects to the rest of the CMDB work
Ownership sets who decides. It does not produce the data, test the data or define what a class contains. Those topics are covered on the configuration item definitions page, the data quality and governance page, and the CSDM service modeling page. The parent CMDB, CSDM and ITAM page brings configuration data, service context and asset ownership together.
For organizations that run change and release through the platform, the ownership model also determines who can accept a risk on a change.
Questions organizations raise when assigning CMDB owners
Can a platform team own a class?
A platform team can be the stewarding party for a class, but the decision about what the class contains should sit with the business or service function that uses it. Platform teams often hold stewardship well and decision authority poorly, because they are closest to the technical data and furthest from the decisions it supports.
How many owners should one service have?
Fewer than people expect. One accountable service owner, one technical steward for the supporting items and one escalation point is often enough. Additional names belong in the relationship records, where their role in the service is stated.
What if no one wants to own a class?
Treat that as a decision. The class may be redundant, it may belong to an adjacent class, or it may need to be retired from the active model. Leaving a class without an owner and still populating it means its records will tend to degrade.
Should exception approval be delegated?
It can be delegated within limits. A steward may accept a short, defined exception that does not change a service decision. Any exception that affects incident routing, change impact or a reported availability figure should stay with the decision authority.
If nobody can say who decides what a configuration record means, the quickest way forward is to walk through one service and the classes that describe it with someone who can decide on both. Contact OBLYTECH about the service that has the least clear ownership, and bring the list of people who currently sign off on its configuration.
ServiceNow guides on this topic
Guides from the Oblytech ServiceNow library that explain the practice behind this page.