How to Establish Ownership in Your CMDB

Management support is often mentioned as one of the critical success factors when it comes to any CMDB project or initiative. Genuine commitment from top management may increase the chance of success for the project, but what happens when the project is completed and the CDMB is in use?

Once day-to-day operations begin, top management or high-level steering groups are only involved if something goes wrong. Data quality becomes the responsibility of the team working with the CMDB. The team needs to pay attention to data ownership and quality details continuously.

In this context, data quality is usually “good enough” if the data is

• regularly used by Data Consumers
• and maintained by Data Providers according to agreed requirements.

Data quality, in practice, comes from BOTH the usage and the ability to provide. Unfortunately, we often see CMDBs automatically populated with everything Discovery tools can find, with little thought about who needs or uses the data. While nothing may be wrong with this, a “less is more” mentality probably leads to a more successful CMDB.

In this article, I will discuss using the Consumer-Owner-Provider model to take control of your CMDB. We originally published this in April 2021 and refreshed it with the latest ideas in February 2023.

The Consumer – Owner – Provider Model

Understanding Roles and Responsibilities

Many organizations, especially larger ones, have people assigned to CMDB-specific roles, with titles such as Configuration Management Process Owner, Configuration Manager, CMDB Owner, or CMDB Manager.

What does it mean to be a CMDB Owner or a Configuration Manager? One way to look at these roles and their responsibilities is using the Consumer – Owner – Provider model.

COP -model by Justin Group (C) 2018

Consumers

Consumers are processes or actors that use the data for a specific purpose. Consumers give feedback and requirements to Owners on what data is required and how it is intended to be used.

Owners

Owners own the overall concepts, data models, and processes to maintain the data. They work with Consumers and Providers to define requirements, data models, and processes and provide instructions for Providers to fulfill the requirements.

Owners also have a quality assurance, auditing, and monitoring role. They must ensure that data is provided and consumed as planned and agreed upon.

Providers

Data Providers are processes and actors that create and maintain data. Providers work with Owners to meet Consumers’ requirements and often act as subject matter experts within their domain.

Did you know that DCM provides personal data quality reporting for Data Providers?

Read more here

Let’s look at how we can apply this Consumer-Owner-Provider model to CMDB.

Begin with Consumers

Start by figuring out who uses the CMDB and what for. For example, is it:

• Service Desk agents trying to analyze the initial root cause and correct assignments to second-level support?
• Change managers trying to understand the impact of planned changes?
• A Request fulfillment process that uses CI data to automate workflow?
• Financial management trying to allocate infrastructure costs to correct Business Units or Cost Centers?

Once you have established the key users, find the most essential and used details. For example:

• If most of your incidents are related to Business Applications, you better start from there.
• If your business relies heavily on Hardware Asset Management data, begin by discussing with your Asset Managers.

There is no point in recording and maintaining data in the CMDB if no-one is using it.

There is no point in recording and maintaining data in the CMDB if no one uses it. Identifying the different consumers and working with them to define and prioritize the requirements for the CMDB is the key. You must know this when requesting resources and priority for the CMDB work.

There is No CMDB Without Ownership

The number one point regarding owners is that the Owner’s role differs from the Provider’s. CMDB is a wild animal, and you usually need a large group of people to tame it.

• Owners receive the requirements, handle the feedback, set the policies, and co-design the data models with Consumers and Providers.
• However, Owners are not responsible for populating or updating the data within the CMDB. However, they are responsible for making sure it happens.

This may include creating instructions and developing systems and processes to support the providers and consumers, but not actually “touching” the data. 

The CMDB Owner

We highly recommend that there is one owner for the whole CMDB. This should be someone who can (and should) make decisions when needed. While it is sometimes said that “co-ownership” is no ownership, it is still better than nothing.

Being a CMDB owner can be a lonely post, so finding some friends is better. Years of practical experience and multiple CMDB projects have shown that splitting the CMDB into different “domains” and assigning domain owners for each will help. 

Domain Owners

Domain owners are often experts in their area and can help define requirements for the Providers based on Consumer input. Especially in larger organizations, Configuration Managers are good candidates as Domain owners. A group of domain owners is also an excellent “board” for prioritization and roadmap work regarding the CMDB.

With limited resources, you often need to make compromises. When compromises are made together, there are fewer questions and confusion later. If this group cannot reach a conclusion, then you need that single CMDB owner to make the final call.

Did you know, that DCM also includes a dashboard tailored for Domain Owners? Book a demo to see how it works.

Data Domain Examples

Some examples of Data domains can be taken from ServiceNow’s Common Service Data Model. The CSDM splits CMDB data into five different domains:

• Foundation– Common data to all processes and workflows like users, organizational structures, and locations
• Design– Business application portfolio and enterprise architecture
• Build – Components of digital products
• Sell / Consume– Business service portfolio and request catalog
• Manage Technical Services– Technical service portfolio and all “technical” configuration items.

Candidates for domains and domain owners according to CSDM

Especially the Manage Technical Services domain is often too big for one person to handle. Therefore, it is common to split that even further based on technological service areas like Server capacity, Database management, or Networks and Data centers.

In addition to defining the requirements and owners per domain, the Domain owner should determine Data Providers for each domain or CI class/table. Depending on the size of your organization and partner ecosystem, you should have the following:

• One Owner for the CMDB as a whole
• One Owner for each Data domain (the same person can be the Owner for multiple domains, but we recommend one Owner per domain)
• Possibly multiple Data Providers per Domain.

No Data Without Providers

Providers can be other systems and integrations, discovery tools, and processes from a single CMDB point of view. However, regardless of the technology or process, people are always involved. The key here is to identify those people.

A single data domain can have multiple data providers, and a data provider can populate and maintain data for multiple data domains. Therefore, it is crucial to work with Providers, Consumers, and Owners to agree which records, attributes, and relationships should be maintained by whom and how the data is being used.

From an organizational point of view, data providers can be:

• Individuals like Service and Application Managers responsible for data regarding their applications and services.
• Operational groups like
  • Server Operations,
  • Database Management, or
  • Network Team, who usually maintain a large volume of similar CIs.
  • Application Development and Application Management groups that maintain records and relationships related to their applications.
• External personnel hired to perform on behalf of the above, often as part of an outsourced or otherwise purchased service.
• Internal systems via integrations. (Note that people or groups should be responsible for those systems, integrations, and the data maintained within.)

External systems, such as a service provider’s CMDB or another operational system. Again, some people or a group from the vendor side needs to be responsible for the data within the system.

Build a Strong Foundation in Small Steps

To sum up the COP model and some fundamental principles for a successful CMDB, you should:

• Only bring in data that someone uses
• Only bring in data that someone owns
• Only bring in data that someone is committed to maintain

I want to repeat the “only bring in data that someone” part to emphasize that it’s all about that “someone.” If you cannot identify the Providers, Owners, and Consumers for your CMDB data, then it’s probably better to get rid of it.

You are ready to start if you have identified the three roles for at least one domain (or table). But even then, start small.

Prove the Value of CMDB

One continuous challenge with CMDB is proving its value. What value does the data bring to its users? How are the Consumers impacted if the data is bad or missing?

To answer these questions, I encourage you to tackle them one use case at a time. First, narrow down the scope until you find the Consumers, Owners, and Providers. Then it will be easier to show that maintaining this data in CMDB brings more value than consumes resources.

For example, “doing business impact analysis for infrastructure changes” can be too vague without further defining what type of infrastructure, what kind of changes, and which part of the business it affects.

“Doing impact analysis for virtual Windows servers related to our critical business applications in the Logistics business unit” is much more concrete. Being specific, any goals are likely to seem more realistic, and you will be better equipped to talk to the right people about meeting the goals.

See some examples of how DCM can be used to ensure your data support impact and root cause analysis:

• How to ensure Server CI Relationships exist
• How to Ensure You Can Do Root Cause Analysis

In Summary

Ownership is sometimes a difficult thing to understand. It is also sometimes difficult to establish, and its importance is easily overlooked. If ownership is not clearly agreed upon and different stakeholders begin to assume things, the chance of something going wrong will increase.

Simple models, such as the Consumer – Owner – Provider model described here, make the necessary relationships easier to understand and define. We highly recommend using them since, at the end of the day, this is a matter of communication and agreement. There’s no rocket science involved, nor is there a need to recreate the wheel.

However, believing your CMDB contains the necessary information is not the same as knowing. Tools such as Data Content Manager also help. With the proper tools, you can see where you have ownership issues and will have the means to fix them.

Get Started Now

We believe establishing ownership within your CMDB is key; we see organizations constantly struggle with this. The Consumer – Owner – Provider model is an excellent tool for alleviating pain. When you combine it with our 5 Steps. When you combine it with our 5 Steps Model for Improving Data Quality, you have a set of tools that will take you a long way.

Of course, for the best outcomes, you will need appropriate tools. Our product Data Content Manager supports the COP model as well as the 5 Steps model. It can help you get a grip on your CMDB regardless of your maturity level. DCM works on your CMDB no matter how you built it and whatever customizations you have.

Book some time with us and we will show you how.