Defining Data Ownership

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.

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.

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.

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.

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.