Management support is often mentioned as one of the key success factors when it comes to any CMDB project or initiative. True commitment from top management may increase the chance of success for in the project, but what happens when the project is complete and the CDMB is in use?
Once the day-to-day operations begin, top management or high-level steering groups are probably no longer involved, unless something goes wrong. Data quality becomes the responsibility of the team working with the CMDB. The team now needs to pay attention to data ownership and quality details on a continuous basis.
In this context, data quality is usually “good enough” if the data is
- regularly used by Data Consumers
- maintained by Data Providers according to agreed requirements.
Data quality, in practice, comes from BOTH the usage and the ability to provide. We often see CMDB’s which are automatically populated with everything that Discovery tools can find without much thought for who actually needs or uses the data. While there may be nothing wrong with this, we think that a “less is more” mentality probably leads to a more successful CMDB.
In this article I will discuss how to use the Consumer-Owner-Provider model to take control of your CMDB.
The Consumer – Owner – Provider Model
Understanding Roles and Responsibilities
Many organizations, especially larger ones, usually have people nominated for CMDB specific roles, 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 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 own the overall concepts, data models and processes to maintain the data. They work together with Consumers and Providers to define requirements, data models and processes, and provide instructions to Providers to fulfil the requirements.
Owners also have a quality assurance, auditing and monitoring role. They need to ensure that data is being provided and consumed as planned and agreed.
Data Providers are processes and actors that create and maintain data. Providers work together with Owners to meet Consumers’ requirements and often act as subject matter experts within their domain.
Let’s look at how we can apply this Consumer-Owner-Provider model to CDMB.
Begin with Consumers
Start by figuring out who uses the CMDB and what for? For example, is it:
- Service Desk agents trying to do initial root cause analysis and correct assignments to second level support?
- Change managers trying to understand the impact of planned changes?
- A Request fulfilment 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 the key users established, find out what are the most important and most used details. For example:
- If the majority of your incidents are related to Business Applications, then better start from there.
- If your business relies heavily on Hardware Asset Management data, then start by discussing with your Asset Managers.
There is absolutely no point in recording and maintaining data in the CMDB if no-one is using it.
There is absolutely no point in recording and maintaining data in the CMDB if no-one is using it. Identifying the different consumers and working together with them to define and prioritize the requirements for the CMDB is the key. You need to know this when trying to get resources and priority for the CMDB work at hand.
No CMDB Without Ownership
The number one point regarding owners is that Owner is not that same as Provider. 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 together with Consumers and Providers.
- However, Owners are not responsible for populating or updating the data within the CMDB, but they are responsible for making sure it happens.
This may include creating instructions, developing systems and processes to support the providers and consumers, but not actually “touching” the data.
The CMDB Owner
It is highly recommended that there is one owner for the whole CMDB. This should be a person who can (and should) make decisions when needed. While it is sometimes said that “co-ownership” is not ownership at all, it is still better than nothing.
Being a CMDB owner can be a lonely post, so it’s better to find some friends. Years of practical experience and multiple CMDB projects has shown that splitting the CMDB into different “domains” and assigning domain owners for each will help.
Domain owners are often experts in their own area and can help define the requirements for Providers based on the input from Consumers. Especially in larger organizations, Configuration Managers are good candidates as Domain owners. A group of domain owners is also a very good “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 less questions and confusion later on. If this group cannot reach conclusions, you need that single CMDB owner to make the final call.
Data Domain Examples
Some examples of Data domains can be taken from the Common Service Data Model published by ServiceNow. The CSDM splits CMDB data into four different domains:
- Foundation – Common data to all processes and workflows like users, organizational structures and locations
- Design – Business application portfolio and enterprise architecture
- 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 and therefore it is quite 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 define Data Providers for each domain or CI class/table.
Depending on the size of your organization and partner ecosystem, you should have:
- One owner for the CMDB as a whole
- One owner for each Data domain (the same person can be owner for multiple domains but one owner per domain is recommended)
- Possibly multiple Data Providers per Domain.
No Data Without Providers
From a single CMDB’s point-of-view, Providers can be other systems and integrations, discovery tools and processes. Regardless of the technology or a process, there are always people 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. It is crucial to work together with Providers, Consumers and Owners and 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 own 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 own 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 and integrations, and the data maintained within.)
- External systems, such as a service provider’s CMDB or some other 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 key 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.
If you have identified the three roles for at least one domain (or table), you are ready to get started. 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 would encourage you to tackle one use case at a time. 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 does it affect.
Saying “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.
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 and different stakeholders begin to assume things, the chance of things going wrong will increase.
Using simple models such as the Consumer – Owner – Provider 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 agreeing. There’s no rocket science involved, nor is there a need to recreate the wheel.
Tools such as Data Content Manager also help. Believing your CMDB contains the necessary information is not the same as knowing. With the proper tools you can know where you potentially have ownership issues and you will have the means to fix them.
Let us Show You How
Book a meeting with us and we will show you how Data Content Manager helps you get a grip on your CMDB, regardless of what you maturity level is at this time. DCM works on your CMDB no matter how you built it, and whatever customizations you have in place.