CMDB Governance: Who Decided This Was Supposed to Work This Way?

There's a moment in almost every CMDB implementation when somebody discovers something uncomfortable.

Nobody actually knows who owns the data.

Everyone uses the CMDB.

Everyone complains about the CMDB.

Everyone agrees that the CMDB should be better.

But when you ask:

"Who is responsible for making sure this information is correct?"

You get a lot of very interesting facial expressions.

That's where CMDB governance comes in.

Governance is the set of rules, responsibilities, standards, and processes used to make sure the CMDB is managed consistently.

It answers questions such as:

• Who decides what data should be stored?
• Who owns a particular type of data?
• What standards should the data follow?
• Who is allowed to change it?
• Where should the information come from?
• How often should it be reviewed?
• What happens when the data is wrong?

Without governance, a CMDB can become a very sophisticated place to store inconsistent opinions.

Governance Isn't the Same Thing as Administration

This distinction is worth understanding.

A ServiceNow administrator might configure tables, forms, integrations, roles, and workflows.

That's administration.

Governance is more about deciding how the organization intends the data and processes to work.

For example:

An administrator might configure a field requiring a support group.

Governance determines whether every server should actually have a support group, what that support group means, who is responsible for maintaining it, and what the organization's standard should be.

The administrator builds the mechanism.

Governance establishes the rules the mechanism is supposed to enforce.

The two work together, but they're not the same job.

Why Governance Matters So Much in a CMDB

A CMDB can collect information from many places.

Discovery might provide technical information.

An asset system might provide financial or ownership information.

An application portfolio might provide application information.

Manual users might enter information.

Integrations might bring in data from other platforms.

That's a lot of cooks in one kitchen.

Without rules, each source or team can start doing things its own way.

One team might call something:

• Production
• PROD
• Prod
• Live

All four might mean exactly the same thing.

That sounds harmless until someone tries to report on the data.

Now the CMDB has a consistency problem.

Governance helps prevent these sorts of disagreements from becoming permanent features of the database.

Start With Definitions

One of the simplest things governance can establish is a common definition.

• What exactly is a CI?
• What makes something an application?
• What does "production" mean?
• What does "owned by" mean?
• What qualifies as a business service?
• What information is required for a particular CI class?

These questions may sound obvious.

They aren't always.

Different teams frequently use the same word to mean different things.

And if two teams interpret the same field differently, the resulting data can be inconsistent even when everyone is doing what they think is correct.

Data Standards

Governance can establish standards for how data should be represented.

Suppose an organization decides that every production server CI must have:

• An owner
• A support group
• An environment
• A location
• A unique identifier
• Required technical attributes

Now there's an agreed standard.

That gives the organization something against which it can measure the data.

Without a standard, someone can look at a CI and say:

"Seems fine to me."

And someone else can look at the same CI and say:

"This is missing half the information we need."

Governance turns that argument into something more objective.

Who Owns the Data?

This is one of the biggest governance questions.

Consider a server CI.

Who is responsible for its information?

• The ServiceNow administrator?
• The CMDB team?
• The infrastructure team?
• The server owner?
• The person who discovered it?
• The person who originally created the record?

There isn't a universal answer.

The organization needs to establish responsibility.

And that responsibility may differ depending on the type of information.

The infrastructure team may be responsible for technical attributes.

A business owner may be responsible for business ownership information.

An application team may be responsible for application relationships.

The important thing is that responsibility is explicitly defined rather than assumed.

Data Ownership Doesn't Mean Someone Owns the Record

This can be confusing.

When we say someone "owns" data, we don't necessarily mean they are the person who physically enters every value.

An owner may be responsible for ensuring that information is accurate and maintained.

Another system may actually supply the information automatically.

For example, a server team might be accountable for the accuracy of server information even though Discovery is the mechanism that populates much of that information.

The person responsible for the quality of the data and the mechanism that updates the data don't have to be the same thing.

The Source of Truth Question

Here's a question that shows up everywhere in CMDB work:

Where should this information come from?

Suppose the CMDB says an application owner is:

John Reyes

But the organization's application portfolio system says:

Jonathan Reyes

Which one wins?

You can't solve that by simply shouting "CMDB!"

The organization needs a defined approach to authoritative sources.

For each type of information, governance can establish which system or process should be considered authoritative.

That helps prevent teams from fighting over which copy of the data is "correct."

Authoritative Doesn't Mean It Knows Everything

A source can be authoritative for one piece of information without being authoritative for everything.

For example:

• An asset system might be the authoritative source for purchase information.
• Discovery might be the authoritative source for technical configuration.
• An application management system might be authoritative for application ownership.

This is an important idea.

There doesn't have to be one magical system that knows everything.

Different systems can be authoritative for different attributes.

Governance and Reconciliation Work Together

This connects directly to something we covered earlier.

Remember reconciliation?

When multiple sources provide information about the same CI, ServiceNow needs rules governing which source is allowed to update particular attributes.

That's a technical mechanism.

But somebody had to decide what the rules should be.

That's where governance enters the picture.

For example:

• "The infrastructure discovery source is authoritative for operating system information."
• "The asset system is authoritative for purchase information."
• "The application portfolio is authoritative for application ownership."

Those are organizational decisions that can then be implemented through technical controls.

Governance defines the intended behavior.

Configuration helps enforce it.

What Happens When Nobody Makes These Decisions?

Chaos.

Imagine three teams maintaining the same application information.

Team A updates it manually.

Team B imports data every night.

Team C uses a spreadsheet.

All three believe they are helping.

Instead, the organization now has three competing versions of reality.

One says the application is active.

Another says it's retired.

The spreadsheet says it belongs to a different business unit.

Nobody knows which one should be trusted.

That's not primarily a technology problem.

It's a governance problem.

The technology is perfectly capable of storing the conflicting information.

It just needs someone to tell it which information should be authoritative.

Governance and Data Quality

Remember the previous breakdown?

We talked about CMDB Health and the importance of complete, correct, and compliant information.

Governance provides some of the rules that make those measurements meaningful.

Suppose CMDB Health tells you:

"Only 62 percent of application CIs have an owner."

That's useful.

But now what?

Governance should help answer:

• Is an owner actually required?
• Who is responsible for maintaining the owner?
• Where should ownership information come from?
• How often should it be reviewed?
• What should happen when an application has no owner?

Without those answers, the health score is just a number.

Governance turns the number into an actionable problem.

Governance Isn't About Controlling Everything

There's a temptation to interpret governance as:

"Create 900 rules and make everyone follow them."

That's not necessarily good governance.

The purpose is to establish enough structure to produce reliable, useful, consistent data.

Too little governance creates chaos.

Too much unnecessary governance creates bureaucracy.

Imagine requiring a five-person approval process every time a server's operating system is updated by an automated discovery process.

That would be ridiculous.

The organization needs controls appropriate to the risk and importance of the information.

Good governance is practical.

Data Stewardship

You may also encounter the idea of a data steward.

A data steward is generally responsible for helping maintain the quality, consistency, and appropriate management of a particular area of data.

The exact responsibilities can vary between organizations.

A data steward might help:

• Define data standards
• Monitor data quality
• Resolve data issues
• Coordinate with data owners
• Help establish processes
• Ensure policies are followed

Don't think of a data steward as simply "the person who enters data."

The role is much broader than data entry.

It's about helping the organization manage data properly.

Owner vs. Steward

These roles can overlap, but they're conceptually different.

A data owner is generally accountable for the data and the decisions surrounding it.

A data steward helps manage and maintain the quality and proper use of that data.

Think of the owner as having accountability.

Think of the steward as helping make the day-to-day data management actually work.

Organizations can structure these roles differently, so don't get trapped trying to memorize one universal organizational chart.

Focus on the responsibility being described in the scenario.

Governance and Access

Governance can also address who should be allowed to change or view particular information.

Not everyone needs the ability to modify every CI.

Imagine allowing every employee to change:

• Business Owner
• Support Group
• Criticality
• Service Classification

on every CI.

That would make the CMDB very democratic.

It would also make it very unreliable.

Appropriate roles and permissions can help ensure that people have the access needed to perform their responsibilities without giving everyone unrestricted control over important information.

The Principle of Appropriate Access

The goal isn't simply:

"Lock everything down."

It's:

Give the right people the right access to perform their responsibilities.

A server administrator may need to update certain technical information.

A service owner may need to manage service-related information.

A CMDB administrator may need broader administrative privileges.

A normal user may only need to view information.

The exact role structure depends on the organization's implementation.

The important concept is that access should support governance rather than undermine it.

Governance and Change

CMDB data doesn't live in a frozen environment.

Organizations change constantly.

• Applications are replaced.
• Business units merge.
• Servers move.
• Cloud environments expand.
• Services are introduced.
• Ownership changes.

Governance needs to account for those changes.

For example, suppose an application is transferred from one business unit to another.

• Who updates the ownership information?
• What system should provide the new owner?
• Which relationships need to change?
• Who validates the change?
• What happens to the old owner's responsibilities?

These aren't merely technical questions.

They're governance questions.

Governance Can Prevent "Just Make a New CI"

Here's another situation that comes up often.

Someone says:

"This CI looks wrong. Just create a new one."

That sounds easy.

Until you have 15 versions of the same server.

Good governance can establish processes for when records should be created, updated, merged, retired, or deleted.

This is especially important because creating records is usually easy.

Cleaning up thousands of bad records later is considerably less fun.

Governance and Lifecycle Management

CIs have lifecycles.

Something can be:

• Planned.
• Ordered.
• Installed.
• Operational.
• Retired.
• Decommissioned.

The exact lifecycle states depend on the CI type and implementation.

Governance helps define what those states mean and how transitions should occur.

For example:

• Who can mark a CI as retired?
• What event triggers the change?
• Should an automated source update it?
• How long should retired records remain?
• Should relationships be removed?
• Should downstream processes be notified?

Again, the point isn't that one universal answer exists.

The organization needs a defined and consistent answer.

Why Governance Is Especially Important With Automation

Automation is fantastic.

Automation is also exceptionally good at doing the wrong thing thousands of times per hour.

If an automated process is poorly designed, governance doesn't disappear just because humans aren't typing the data.

In fact, automation makes good governance even more important.

Before automating a data process, the organization should understand:

• What information is being changed?
• Where does it come from?
• Who is responsible for it?
• What rules apply?
• What happens when the source is wrong?
• What happens when the source stops providing data?

Automation should enforce good processes.

It shouldn't replace the need for good processes.

A Governance Example

Let's say an infrastructure team is responsible for an organization's server CIs.

The organization establishes these rules:

• Discovery is the authoritative source for technical configuration.
• The infrastructure team is accountable for server information.
• Every production server must have an assigned support group.
• The support group is responsible for keeping ownership information current.
• Retired servers should transition through an established retirement process.
• Only authorized roles can manually override certain attributes.

Now everyone has something to work with.

The data source is defined.

Responsibility is defined.

Standards are defined.

Lifecycle expectations are defined.

Access is controlled.

That's governance.

What If the Data Is Wrong?

Governance should also establish what happens when bad data is discovered.

Imagine CMDB Health identifies 2,000 CIs with missing ownership.

A mature organization shouldn't simply say:

"Someone should fix those."

There should be a process.

Perhaps the records are assigned to the appropriate data steward.

The steward investigates the source.

The owner is identified.

The underlying process is corrected.

The data is updated.

The results are monitored.

If the problem keeps recurring, the organization investigates why.

That last part is important.

A governance process should help address recurring problems rather than endlessly repairing the same symptoms.

Governance Is What Keeps the Model Consistent

We've spent a lot of time talking about CSDM.

We've talked about CMDB health.

We've talked about data sources.

We've talked about identification and reconciliation.

All of those things depend on consistency.

If every team interprets the model differently, the benefits of having a common data model begin to disappear.

Governance helps keep everyone aligned.

It provides the organizational rules behind the technical implementation.

A Realistic Governance Problem

An architect notices something strange.

The CMDB contains 30,000 application CIs.

The application team says there are only 22,000 applications.

The architecture team says there are 25,000.

The asset team has another number.

Nobody can explain the difference.

The architect could spend six months deleting records.

But before doing that, they should ask:

• What qualifies as an application?
• Who is allowed to create one?
• What system is authoritative?
• What is the lifecycle?
• When should an application be retired?
• Can duplicates be created manually?
• What information is required?
• Who owns the data?

If nobody has answers, deleting records is treating the symptom.

The organization has a governance problem.

Governance and the CMDB Team

The CMDB team can be extremely important, but they shouldn't automatically become the owners of every piece of information in the CMDB.

That's a common trap.

The CMDB team may manage the platform and processes.

But the people closest to the underlying data may be better positioned to own it.

For example:

• The network team may be responsible for network information.
• The server team may be responsible for server information.
• Application teams may be responsible for application information.
• Business stakeholders may own business-related information.

The CMDB team can coordinate the overall framework without personally becoming responsible for every attribute.

What the CIS-DF Exam Wants You to Notice

When a question describes an organization trying to establish:

• Data ownership
• Data standards
• Responsibilities
• Policies
• Roles
• Authoritative sources
• Processes for maintaining data
• Consistent definitions
• Quality expectations

you should start thinking about governance.

Don't get distracted by the fact that the scenario happens to involve a server, application, service, or CI.

The important part may be the organizational process surrounding the data.

Governance vs. Data Quality

These two concepts can also be confused.

Data quality asks:

"How good is the data?"

Governance asks:

"How are we going to make sure the data is managed properly?"

If a report says:

"40 percent of our CIs are missing owners."

That's a data quality finding.

If the organization decides:

"Every CI must have an owner, the application owner is responsible for maintaining it, and ownership comes from the application portfolio system."

That's governance.

Governance creates the structure that helps improve and maintain data quality.

Governance vs. Data Integration

Another easy trap.

An organization may have a fantastic integration that brings data into ServiceNow.

That doesn't automatically mean the data is governed.

Integration answers:

How does information move?

Governance answers:

What information should move, where should it come from, who is responsible for it, and what rules should apply?

You need both.

An automated pipeline can move bad information into the CMDB extremely efficiently.

That isn't success.

That's just faster bad data.

Governance vs. CMDB Health

And one last comparison.

CMDB Health tells you:

"Here's where your data has problems."

Governance helps establish:

"Here's what good data should look like and who's responsible for making it that way."

They complement each other.

Health identifies problems.

Governance establishes the framework for preventing and resolving them.

The Governance Test

When you see a CIS-DF scenario, ask yourself:

• Is this primarily about how the data gets into ServiceNow? Think data ingestion or integration.
• Is it about which CI an incoming record belongs to? Think identification.
• Is it about which source is allowed to update information? Think reconciliation and authoritative sources.
• Is it about whether the data is complete, correct, or otherwise healthy? Think CMDB Health and data quality.
• Is it about who defines the rules, owns the information, establishes standards, or is responsible for maintaining it? Now you're in governance territory.

That's the distinction you want to be able to make.

The Big Takeaway

A CMDB doesn't become trustworthy just because someone installed ServiceNow.

It becomes trustworthy when an organization decides what its data means, establishes standards for that data, assigns responsibility, identifies authoritative sources, controls appropriate access, and creates processes for maintaining the information over time.

That's governance.

And governance is one of those subjects that can sound incredibly boring until you encounter a CMDB where nobody established it.

Then suddenly someone is standing in front of 300,000 CIs asking the most terrifying question imaginable:

"Who was supposed to take care of all this?"

If nobody knows the answer, the CMDB has a much bigger problem than a missing field.