Basic requirement for “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. Not to mention 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.
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 has 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 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 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:
- 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 Application 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.