The DCM Blog

Defining Data Ownership

By Mikko Juola

December 5, 2018

In one of the previous posts we briefly described “5 steps for better data quality” and in this article I’m going to dig in to the second step “Secure ownership” in more detail.

The basic requirement for the “Secure ownership” step is to define how to find responsible person or owner for the data (within the selected data domain). The idea is to define the class holding the owner data by walking through the data model, starting from the root record that is being modelled.

The term “owner” may be a bit misleading here, since it depends on how data ownership is defined in general. Actual “owner” may be the person responsible for the whole domain, but on a day to day basis it’s usually a different person who should make sure that all details within the data are correct and up-to-date.

There may also be other types of “owners” that may be more related to financial and service responsibilities. So, to be more accurate, we should take look at the ownership from the Provider-Owner-Consumer? (POC) -model point of view.

POC Model

The Five-step model’s first step (Select domain) describes that one should define who is the owner for the whole domain (from an information architecture point of view).

This description matches with the “Data owner” role in the POC model above. The person who owns the model is responsible for making sure that the model is in line with the requirements of the consumers, capabilities of the providers and in line with agreed policies.

The Data Owner in the “Secure ownership” step is more referring to the Data Provider role in the POC model. That role is responsible for providing the data according to the agreed model and other requirements.

So, for step 1 (Select domain), the Owner is the same role as the Data Owner in the POC model. And the Owner for step 2 (Secure ownership) is more about the Data Provider role. In real life the Data Providers are often people or integrated systems that have responsibilities over CI, user, company, agreement etc. data records.

Next, let’s look at some examples: how to define ownership (or data providers) as part of data models.

Data Model Examples

Example 1: Simple Reference

Probably the simplest and most straight forward way to define a data provider as part of a data model / blueprint is a single attribute that is referring to a record representing the owner.

For example, a Managed by reference field on an Application configuration item (CI) record.

 

Ownership Model 1

 

This Blueprint includes following details:

  • Application is set as root class, meaning that we are interested in Application CIs and how those should be modelled in the CMDB.
  • Application class has filter where Retired applications are left out.
  • Application class has Reference field called Managed by to User class: This reference defines who is responsible for the correctness of the application data.
  • And the User class also has filter defined so that user record has to be Active: With this filter we can get more detailed audit results also for applications that have manager defined, but the manager record is no longer active.

When auditing existing application records against this blueprint, we can easily identify all application records that do not have a manager defined or where the manager is no longer active.

Results of this audit should be addressed to the domain owner who should make sure that every record in this domain has valid owner / data provider information in place.

Now, with a similar use case, let’s look at some more complicated models for defining a Data Provider.

Example 2: Ownership via Another Record

In this example, we are saying that ownership for the application data is defined via the related business service.

 

Ownership Model - 2

 

This blueprint is different from the first example since:

  • Application doesn’t have direct reference to User, but has a Depends on type of CI relationship to a parent Business Service
  • And the Business Service has mandatory reference to User called Owned by
    • This reference now defines the Data Provider role for both the Business Service and the Application

Example 3: Ownership Defined by a People Relationship

This time, the ownership is defined by using a People relationship record with a type Service Manager connected to the application. This example is using a mandatory filter for the People relationship record which means that only records with type Service Manager are accepted.

 

Ownership Model - 3

 

Note the red star next to filter icon indicating a mandatory filter.

This time, the blueprint defines following requirements for application records:

  • Application record must be referred by a People Relationship record via CI reference field.
  • The People Relationship record has mandatory filter where type has to be Service Manager
  • And the People Relationship record is also referring to User which still has an optional filter defining that User has to be active

With this blueprint we can identify Applications that are missing a particular type of People Relationship.

With these examples I’ve shown three different ways to define Data Provider for a selected root class, the Application CI in this case.

The next step in the five-step model is to define a minimum viable data model for the applications. Meaning the minimum required information after ownership has been secured. And that step will be covered in another blog.

Have you defined Data Owners and Data Providers related to your CMDB or other service data? This is probably the most important step when it comes to successful CMDB implementation.

If you want to know more or discuss how DCM could help your organization to improve data quality and fully implement ownership into your organization, do not hesitate to contact us.

Additional CSDM Resources

We have written a lot on aligning with the Common Service Data Model and how Data Content Manager can help ease the journey.

Here are some excellent places to start:

Please reach out to us if you have any questions!

Mikko Juola

Mikko Juola

Chief Product Officer at Qualdatrix

LinkedIn

Built on now

Featured Posts

5 Challenges to Address for Better CMDB Data Quality

5 Challenges to Address for Better CMDB Data Quality

Comprehending the impact of CMDB Data Quality, especially its absence, can be difficult. It is a big problem since poor data quality is often the main reason ITSM systems, like ServiceNow, don’t meet expectations. We are deeply involved with data quality daily. Our...

How LapIT Improves CMDB Data Quality with DCM

How LapIT Improves CMDB Data Quality with DCM

LapIT designs and implements solutions for information and communication technology environment services in Northern Finland. Their customers are mainly municipal, public administration, and healthcare organizations. We interviewed Leena Broas, Development Manager at...

Video: How to Improve Foundation Data in ServiceNow and CSDM

Video: How to Improve Foundation Data in ServiceNow and CSDM

In this video, Pekka Korpi, CEO of Qualdatrix, and Mikko Juola, Product Owner of Data Content Manager, discuss the importance of Foundation data in ServiceNow and how it can be improved using Data Content Manager. Foundation Data in ServiceNow refers to the critical...

Build a Business Case for Data Quality Improvement

Build a Business Case for Data Quality Improvement

Accurate and reliable data is the backbone of any successful organization. Countless data quality improvement projects are started across organizations since poor data quality can lead to misinformed decisions, wasted resources, and lost opportunities. On the other...

How Metsä Group Improves Data Quality with DCM

How Metsä Group Improves Data Quality with DCM

Metsä Group uses Data Content Manager to improve data quality in their CMDB. We had a chance to interview Mika Lindström, the ICT Configuration Development Manager at Metsä Group. Thanks, Mika, for joining us. Metsä Group are an internationally operating frontrunner...

How to use CSDM to Improve Incident Management

How to use CSDM to Improve Incident Management

It’s been a while since this article was originally published, so I thought it would be time to update it to reflect changes to the CSDM model and our latest thinking. We published this article first in 2020 when ServiceNow’s Knowledge event included the first...

How CMDB Supports Regulatory Compliance at Danske Bank

How CMDB Supports Regulatory Compliance at Danske Bank

Data Content Manager improves data quality within an organization’s CMDB, reducing manual and disparate work for data quality maintenance. This increase in data transparency and ease of data management helps companies to achieve and maintain regulatory compliance,...

Get Started

Book a Call with us Now.

 

Explore how Data Content can enhance the quality of your data in ServiceNow. See how you can accelerate your CSDM journey and improve your CMDB or any data in your platform. All without the need for scripting, additional reports, or customizations.

 

Related Content You Might Like:

CSDM

The Recipe For Success eBook

Contents:
  • Establish Ownership & Roles
  • Manage Your Scope
  • Choose the Right Tools

We talk to people about CSDM alignment every day and constantly see organizations struggle with the same things over and over again. We wrote CSDM - The Recipe for Success to share our experiences.

It gives you hands-on guidance on some of the most important things you must address on your CSDM Journey, regardless of your maturity level.

CSDM The Recipe for Success eBook

Get Your Free eBook