CHECK OUT THE PREVIOUS ARTICLES OF THIS SERIES:

 

In the previous article, we started talking about the role of data governance in setting up a data management framework. Data management framework consists of two key parts: rules (strategy, road-map, policy, etc.) and roles. In the first part of the article, we looked at the rules on different business levels. In this second part, we will discuss the development of a feasible and easy-to-implement set of data management/governance roles.

Each time I read something about data management/governance roles and bodies I experience a mix of emotions: confusion, wonder, curiosity… I have discerned three key reasons for these feelings:

  1. The number of roles

Once, I have counted data management functions, roles, and bodies mentioned in DAMA-DMBOK editions. Can you guess how many there are? 120!!!!
(If you are interested, let me know, I can share an Excel list with you.)

  1. Roles are put in several contexts simultaneously

To demonstrate my point, let’s consider roles of stewards or similar ones listed in the DAMA-DMBOK first edition1, second edition2, and the DAMA Dictionary3:

  • “data steward”
  • “data custodian” (the same as “data steward”)
  • “chief data steward”
  • “business data steward”
  • “coordinating data steward”
  • “executive data steward”
  • “data stewardship facilitator”
  • “technical data steward”
  • “subject matter expert”.

As you can see, the role of a “steward” is presented in different contexts simultaneously, which are then being mixed up. These contexts are:

  • different levels of the organizational hierarchy
  • area of expertise
  • tasks to perform.

Such a complicated approach creates roles that are difficult to perceive. Furthermore, it is difficult to specify clear unambiguous accountabilities, make a distinction between the roles, implement them into practice, and create awareness among staff.

  1. Omittance of the dynamic character of the data and information value chain

Data flows from its origin to its destination. Several similar concepts describe this movement: “data lifecycle”, “data lineage”, “data flow”, “data and information value chain”.  For this article, I will use the term of “data and information value chain”.

Let’s come back to the example with the role of “data steward” role. Data stewards will have different tasks depending on their place in this chain. But it is something you would hardly see in the list of roles.

DAMA-DMBOK has invented a solution to this issue by creating additional roles: “data creator”, “data producer”, “data owner”, “data consumer”, “data user”.

I will demonstrate the DAMA-DMBOK solution by quoting the chain of definitions:

Subject matter expert is “a person with significant experience and knowledge of a given topic of function”4.

Data steward is “a business leader and / or subject matter expert accountable for [tasks related to data management]”5. The list of the tasks is too long to quote it in full. Unfortunately, the new second edition of DAMA-DMBOK does not even have a clear definition of a “data steward”, only “stewardship”.

Data owner is “a business Data Steward, who has approval authority for decisions about data within their domain”.6

So, a data owner is a data steward, who is, at the same time, a subject matter expert. All these roles are considered by DAMA-DMBOK as independent ones. It means that these three roles could be simultaneously assigned to one employee.

I am a data management practitioner working in the field for the past 10 years. I communicate with a lot with business people on a daily basis.  Assume, tomorrow, I will approach one of my colleagues and say: “Hi John, congratulations!  In our new data governance structure, you will get several roles. You are a subject matter expert, business executive data steward, data owner in one data chain and data user in another data chain. You have now plenty of additional accountabilities and tasks. Please, read several policies in which these roles are described.” Shall I continue or can you guess John’s reaction yourself?

For me, there are two simple requirements with respect to the roles:

  • clarity: accountability of each role can be clearly specified in several lines
  • unambiguity: each role need to have a unique list of accountabilities.

So how can this be achieved?

Decision 1.  Roles correspond to the dimensions of a business capability

Let us get back to the concept of a business capability. “A business capability is a particular ability or capacity that a business may possess or exchange to achieve a specific purpose or outcome.”7  A business capability is comprised of several dimensions. The Open Group defines these dimensions as the following: “A combination of roles, processes, information and tools enable a business capability”8. In Figure 1, you can see the graphical representation of business capability dimensions.

Figure 1. The data management (sub)capability structure.

Roles describe the participation of people in business operations. Roles are described in the form of business units, functional jobs, etc.

Process means  business process on different levels of abstraction.

Data “represents the business information and knowledge required or consumed by the business capability” 9.

Tools “include information technology systems and applications; physical, tangible assets […]; intangible assets” 10.

Such a model of a data management (sub)capability is a great tool for practical implementation of a data management (sub)capability. As it allows to specify different components of a capability along each dimension and link roles from different dimensions.

Let us apply the model to management/governance roles in two steps.

  1. Specify roles along each dimension.

Figure 2. The data management capability model with corresponding roles.

Let us have a look at the dimensions and corresponding roles of each capability.

Dimension “Process”
The role of business process owners matches perfectly to this dimension. The core accountability of the role is management of the process performance.

Dimension “System”
The role of a system or application owner immediately comes to mind. The key accountability focuses on the maintenance and management of the lifecycle of any information system.

Dimension “Roles”
The organizational structure in this dimension is the best example. Then labels like “chief”, “executive”, “coordinating” could be placed.

Dimension “Data”
This dimension can include two groups of roles. The first group is defined by the type of task: “Subject matter experts (SME) vs Data management professionals”. Subject matter experts are professionals that are experts in their fields and perform data management tasks together with their core professional tasks. For example, a financial controller is an expert in financial data definitions. They will participate in data management activities sharing their expert knowledge with a data modeler, who is a data management professional. The second group “Data owner vs Data user” demonstrates the influence of the data and information value chain on the structure of the roles.

Before diving into the complicated subject of data and information value chain, let us link roles that belong to different dimensions.

  1. Link roles from different dimensions

For demonstration, once again, I will use the example with the list of different roles of stewards. The results you can see in Figure 3.

Once specifying the role of a data steward, you can link them to different roles in the organizational hierarchy.

These roles in the hierarchy can also be linked to other dimensions. For example, to the role of “system owner”, you can add labels, such as “chief”, “executive”, etc..

The usage of such a method will simplify attempts to create a clear unambiguous set of roles.

Figure 3. An example of linking roles from different dimensions.

Now let us have a look at the influence of a data and information value chain on the design of roles.

Decision 2. Roles follow the design of a data and information value chain.

“The data and information value chain is the set of actions supported by the collection of data management capabilities that enable the transformation of raw data into meaningful information to deliver the corresponding value propositions to the stakeholder groups.”11 The roles of “data owner” and “data user” indicate different concerns and actions of stakeholders (SMEs) regarding data along this path of data transformation. There is one big challenge with the definition of these roles. Let’s take a look at Figure 4. Data flows through the set of applications and is being changed on its way. Different operations, such as calculations, aggregations, re-formatting, filtering create new data and information. A few questions come to mind:

  • Who owns which data along this transformation path?
  • If a data user uses data for some further calculation, do they become data owners?

And so on.

Figure 4. Roles of data owner and data user along the data transformation path.

Answers are not very straightforward. And definitions of “data owner” do not provide an answer.

In the DAMA Data Dictionary, data owner is defined as “an individual responsible for definition, policy, and practice decisions about data within their area of responsibility”.12

In the second edition of the DAMA-DMBOK, data owner is “a business Data Steward, who has approval authority for decisions about data within their domain”.13

Unfortunately, nobody explains what “area of responsibility” or “domain” means in this context. I have seen some explanations about domains provided by Robert Seiner in one of his articles. According to him, three options exist to define domain: by Subject Area, by Level-1 and Level-2 Data Resources, and by Organizational Unit.14 Yet, neither of these options solves the puzzle.

Let us take two different examples of data entities: country code and revenue of a specific customer. Both data entities belong to the “customer” subject area. A country code entity would be hardly changing along the path of data transformation. So, the account management function could be immediately assigned to be the “data owner”. Revenue is more complicated. Revenue has been calculated based on the information from invoices. Later on, accounting principles for revenue recognition and exchange rates have been applied during data transformation. Who is the owner of this newly created data: still account management or did the data get a new owner – finance?

In practice, I have seen two different solutions.

Solution 1
This solution is based on data modeling practices. In our example with revenue, revenue is a data entity that belongs to the “customer” subject domain.   It means that the account management is assigned to be the data owner of customer revenue figures. Then, of course, the question about the role of finance as the “owner” of transformation rules comes to the scene.

This solution is more applicable for large organizations where the number of applications or points of data transformation counts to dozens and hundreds.

Solution 2
The second solution is based on new data creation principles. It means that when new data is created, a new data owner is assigned. In our case, finance will become the new data owner. This solution is more feasible for small- and medium-sized companies.  There are only a few data transformation points along the data and information value chain.

You might have noticed that in this discussion, I did not take the roles of data stewards into account. In practices, I try to avoid using a role of stewards. On my opinion, SMEs, in combination with a “data owner” and a “data user” roles and the roles from the organizational hierarchy are enough to distribute accountabilities. For those who are still interested in implementing data steward roles, please, be aware they have to appear on both sides: data owners, as well as data users.

The best job you can do when it comes to designing a set of roles is to make it as simple as possible to ensure its clarity and feasibility in implementation.

For those who are interested to get the ‘ready-to-implement’ set of roles for medium-sized companies, please consult my book The Data Management Toolkit15.

In the fifth and final article of this series we will overview the step-by-step approach to implement the harmonized data management/data governance system of capabilities.

 

 

References

  1. Mosley, Mark., and Michael Brackett. The DAMA Guide to the Data Management Body of Knowledge (DAMA-DMBOK Guide), First Edition. Bradley Beach, N.J.: Technics Publications, 2010.
  1. DAMA International. DAMA-DMBOK: Data Management Body of Knowledge, Second Edition. Bradley Beach, N.J.: Technics Publications, 2017.
  1. DAMA International. The DAMA Dictionary of Data Management, Second Edition: Technics Publications, 2011.
  1. DAMA International. The DAMA Dictionary of Data Management, Second Edition: Technics Publications, 2011, p.230
  1. DAMA International. The DAMA Dictionary of Data Management, Second Edition: Technics Publications, 2011, p.88
  1. DAMA International. DAMA-DMBOK: Data Management Body of Knowledge, Second Edition. Bradley Beach, N.J.: Technics Publications, 2017, p.77
  1. The Open Group. Open Group Guide. Business Capabilities. Prepared by the Open Group Architecture Forum Business Architecture Work Stream. The Open Group, March 2016, p.2.
  1. The Open Group. Open Group Guide. Business Capabilities. Prepared by the Open Group Architecture Forum Business Architecture Work Stream. The Open Group, March 2016, pp.2,3.
  1. The Open Group. Open Group Guide. Business Capabilities. Prepared by the Open Group Architecture Forum Business Architecture Work Stream. The Open Group, March 2016, p.4.
  1. The Open Group. Open Group Guide. Business Capabilities. Prepared by the Open Group Architecture Forum Business Architecture Work Stream. The Open Group, March 2016, p.4.
  1. Steenbeek, Irina.The “Orange” Model of Data Management. Data Crossroads, 2019.
  2. DAMA International. The DAMA Dictionary of Data Management, Second Edition: Technics Publications, 2011, p.83.
  1. DAMA International. DAMA-DMBOK: Data Management Body of Knowledge, Second Edition. Bradley Beach, N.J.: Technics Publications, 2017, p.77
  1. http://tdan.com/the-data-stewardship-approach-to-data-governance-chapter-7/6173
  2. Steenbeek, Irina. The Data Management Toolkit. Data Crossroads, 2018.