Data Management and Data Governance 104: The Yin Force of Data Governance. Part 2. Roles

Data governance creates a frame in which data management operates. Data governance roles are the second part of this frame.

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. The data management framework comprises two key parts: data governance rules (strategy, roadmap, 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.

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

The number of roles

Once, I 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, and I can share an Excel list.)

Roles are put in several contexts simultaneously.

To demonstrate my point, let’s consider the roles of stewards or similar ones listed in the DAMA-DMBOK first edition¹, second edition², and the DAMA Dictionary³:

“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 simultaneously in different contexts, which are then 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 isn’t easy to specify clear, unambiguous accountabilities, distinguish between the roles, implement them into practice, and create awareness among staff.

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,” and “data and information value chain.” I will use the term “data and information value chain” for this article.

Let’s return to the example of the “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 data governance roles.

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

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

A subject matter expert is “a person with significant experience and knowledge of a given topic of function” ⁴.

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

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

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

I have been a data management practitioner in the field for the past ten years. I communicate a lot with business people daily. 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 concerning the roles:

clarity: accountability of each part can be specified in several lines
unambiguity: each role needs 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 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.” ⁷ 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” ⁸. 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 as 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”⁹.

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

Such a model of a data management (sub)capability is an excellent tool for practically implementing a data management (sub)capability as it allows to specify different components of a capability along each dimension and links roles from other dimensions.

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

Specify roles along each dimension.

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

Let us look at each capability’s dimensions and corresponding roles.

Dimension “Process”
The role of business process owners perfectly matches this dimension. The core accountability of the role is the 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,” and “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.

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.

Using 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 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.” ¹¹ 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. Different operations, such as calculations, aggregations, re-formatting, and filtering, create new data and information. A few questions come to mind:

Who owns which data along this transformation path?
If data users use data for further calculation, do they become data owners?

And so on.

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

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

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

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

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, Level-1 and Level-2 Data Resources, and by Organizational Unit.¹⁴ Yet, neither of these options solves the puzzle.

Let us take two different examples of data entities: the country code and the revenue of a specific customer. Both data entities belong to the “customer” subject area. A country code entity would hardly change along the data transformation path. So, the account management function could be immediately assigned to the “data owner.” Revenue is more complicated. Revenue has been calculated based on the information from invoices. Later, accounting principles for revenue recognition and exchange rates were applied during data transformation. Who owns 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 a new data owner is assigned when new data is created. 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 consider the roles of data stewards. In practice, I try to avoid using the role of steward. In my opinion, SMEs, in combination with “data owner” and a “data user” roles and the roles from the organizational hierarchy, are enough to distribute accountabilities. For those still interested in implementing data steward roles, please be aware they have to appear on both sides: data owners and data users.

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

For those interested in getting the “ready-to-implement” set of roles for medium-sized companies, please consult my book, The Data Management Toolkit¹⁵.

This series’s fifth and final article will overview the step-by-step approach to implementing the harmonized data management/data governance system of capabilities.

For more insights, visit the Data Crossroads Academy site: //academy.datacrossroads.nl.

References

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.

DAMA International. DAMA-DMBOK: Data Management Body of Knowledge, Second Edition. Bradley Beach, N.J.: Technics Publications, 2017.

DAMA International. The DAMA Dictionary of Data Management, Second Edition: Technics Publications, 2011.

DAMA International. The DAMA Dictionary of Data Management, Second Edition: Technics Publications, 2011, p.230

DAMA International. The DAMA Dictionary of Data Management, Second Edition: Technics Publications, 2011, p.88

DAMA International. DAMA-DMBOK: Data Management Body of Knowledge, Second Edition. Bradley Beach, N.J.: Technics Publications, 2017, p.77

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.

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.

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.

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.

Steenbeek, Irina.The “Orange” Model of Data Management. Data Crossroads, 2019.
DAMA International. The DAMA Dictionary of Data Management, Second Edition: Technics Publications, 2011, p.83.