In one of our previous posts, we briefly described five steps for better data quality, and in this article, I'm going to delve into the second step, ' Secure ownership, ' in more detail.
The basic requirement for "Secure ownership" is to define how to find the responsible person or owner for the data within the selected data domain. The idea is to define the class that holds the owner data by walking through the data model, starting from the root record that is being modeled.
The term 'owner' may be a bit misleading here, as it depends on how data ownership is defined in general. The actual owner may be the person responsible for the entire domain, but on a day-to-day basis, it's usually a different person who should ensure that all details within the data are correct and up-to-date. Not to mention other types of owners that may be more related to financial and service responsibilities. Therefore, to be more accurate, we should examine the ownership from the Consumer-Owner-Provider model perspective.
The five-step model's first step (Select domain) describes how to define the owner of the entire domain from an information architecture perspective. This description aligns with the Data Owner role in the COP model above. The person who owns the model is responsible for ensuring that the model aligns with the requirements of consumers, the capabilities of providers, and agreed-upon policies.
The Data Owner in the Secure Ownership step refers to the Data Provider role in the COP model. This role is responsible for providing data according to the agreed-upon model and other requirements.
So, for step 1 (Select domain), the Owner is the same role as the Data Owner in the COP model. And the Owner for step 2 (Secure ownership) is more about the Data Provider role. In real life, data providers are often people or integrated systems that have responsibilities over, e.g., 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 most straightforward way to define a data provider as part of a data model/blueprint is a single attribute that refers to a record representing the owner.
For example, a Managed by reference field on an Application configuration item (CI) record.
This Blueprint includes the following details:
- The application is set as the root class, meaning that we are interested in Application CIs and how those should be modelled in the CMDB.
- The application class has a filter that excludes retired applications.
- The application class has a Reference field called Managed by to the User class: This reference defines who is responsible for the correctness of the application data.
- And the User class also has a filter defined so that the 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 lack a defined manager or where the manager is no longer active.
The results of this audit should be addressed to the domain owner, who should ensure that every record in this domain has valid owner/data provider information in place.
Now, with a similar use case, let's look at a couple of 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:
- The application doesn't have a direct reference to User, but has a Depends on type of CI relationship to a parent Business Service
- And the Business Service has a 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, ownership is defined by using a 'People relationship' record with a type of 'Service manager' connected to the application. This example uses a mandatory filter for the 'People relationship' record, which means that only records with the type 'Service manager' are accepted.
Note the red star next to filter icon indicating a mandatory filter.
This time, the blueprint defines the following requirements for application records:
- The application record must be referenced by a People Relationship record via a 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 a 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 crucial step in achieving a successful CMDB implementation. If you would like to learn more or discuss how DCM can help your organization improve data quality and fully implement ownership, please do not hesitate to contact us.
Additional CSDM Resources
We have written extensively on aligning with the Common Service Data Model and how Data Content Manager can help ease the process.
Here are some excellent places to start:
Please reach out to us if you have any questions!
