Data Governance Process

Micr
oso

ORIGINAL
 Microsoft 365

DATA GOVERNANCE PROCESS

Electronic Version is Current—Uncontrolled Hard Copy Valid Only at the Time of Printing

Document Number …..

Document Title
Version
Issuing Department
Legacy

Security Class
Retention
Next Review Date
Storage Type
OMF

Country Legal Discipline Document Type

ID GEN (General) Information
Technology (IT)

Automatic Electronic Approvals

Action Name Date
Created/Updated Hairistryan 16 February 2022
Approved
Published
Comment

Approved

Data Governance Process confidential

Page 2 of 23
 CHANGE SHEET

All major changes to the document at this current revision are recorded below.
(Does not include correction of typos or formatting changes)

Revision: Date: Originator: Description of Change:

0.1 Hari ini Infimedia 1.0

0.2

0.3

0.3

0.4

Data Governance Process confidential

Page 3 of 23
 TABLE OF CONTENTS

ESTABLISHING MULTI-DOMAIN DATA GOV- ERNANCE............................................................5

ENTERPRISE COMMUNICATION................................................................................................................................
ARCHITECTURE AND DESIGN...........................................................................................................6
APPROACH CONSIDERATIONS...................................................................................................................................
PROCESS OVERVIEW FOR DEPLOYING DATA GOVERNANCE.........................................................7
CONSIDERATIONS.................................................................................................................................................
FUNCTIONAL DESIGN........................................................................................................................8
TIPS FOR SUCCESS..................................................................................................................................................
DATA STEWARDSHIP..........................................................................................................................8
WHAT IS THE CURRENT STATE OF DATA GOVERNANCE?...............................................................................................
THE AGILE EDW SUBRELEASE CYCLE.............................................................................................11
DEEPENING THE SUPPORT FOR DATA GOVERNANCE..................................................................................................
MASTER DATA MANAGEMENT AND DATA QUALITY.................................................................13
MDM: A HIGH-LEVEL COMPONENT APPROACH.....................................................................................................
THE MASTER DATA REPOSITORY.............................................................................................................................
MASTER DATA SERVICES........................................................................................................................................
OPERATIONAL DATA GOVERNANCE.........................................................................................................................
DATA GOVERNANCE AS AN OPERATIONS PROCESS..................................................................17
DATA GOVERNANCE OPERATIONAL MODEL............................................................................................................
DATA GOVERNANCE FOR MASTER DATA MAN- AGEMENT.......................................................20
PUBLISHER SUMMARY..........................................................................................................................................
OVERVIEW OF DATA GOVERNANCE DEVELOP MENT AND DEPLOYMENT.............................21
CONSIDERATIONS...............................................................................................................................................

Data Governance Process confidential

Page 4 of 23
ESTABLISHING MULTI-DOMAIN DATA GOVERNANCE
Mark Allen, Dalton Cervo, in Multi-Domain Master Data Management, 2015

ENTERPRISE COMMUNICATION

A standard artifact of any data governance process should be a RACI chart to identify what roles are responsible or
accountable for, or consulted or informed about various decision events. A RACI chart can and often will be
customized to best suit the decision process and communication model dynamics, but however it takes shape, the
RACI concept is important to a high-functioning governance process. This RACI chart provides a vehicle where
master data decisions can be leveraged to ensure that there is clear engagement and communication for these
decisions. Figure 6.5 provides an example of a RACI chart.

Figure 6.5. Data governance RACI chart

Data Governance Process confidential

Page 5 of 23
 In general, the tracking and management of key communication items as they relate to master
data should be managed closely by the MDM PMO using the data governance RACI chart as
a communication tool. Although these audiences on the RACI chart will also be interested in
other data governance–related communications, they should always be kept informed about
any major policies, standards, rules, changes, events, and other important items involving
master data.

>Read full chapter

ARCHITECTURE AND DESIGN

John Ladley, in Data Governance (Second Edition), 2020

APPROACH CONSIDERATIONS

Almost every DG engagement could benefit from considering an interim, sustainable,

operating model. Leadership may challenge your program and say “minimal sustaining
operations will be fine forever.” That could be true but remember it will not deliver the full
value planned for DG. It needs to be made clear that this model serves only to prove value and
embed operational DG in the organization to some extent. If your first step is a noninvasive
approach, but oriented toward a POC, it MAY NOT BE MSOM. Your MSOM in a noninvasive
approach may FOLLOW the first iteration or two.

Data Governance Process confidential

Page 6 of 23
The MSOM should only have a few DG functions or processes. It can be based on one or two
principles and policies. The key input to this activity is your long-term operating model. The key
steps for defining the MSOM are:

1. Define the scope of MSOM if different from the long-term program scope.

2. Extract the necessary capabilities and processes that you want to make persis tent as part
of the MSOM. (This may require some facilitated meetings with stakeholders.) Identify
what functions need to be visible and can be persistent. Refer to Fig. 9.6 again - the
“bare minimum” column.
3. Verify and state slice of DG capability that can embed itself deep into opera- tions. Where
can the most value be added with minimal functionality?
4. Develop a roll-out plan (this can also go into your roadmap). But often the MSOM gets
implemented in parallel to the completion of the long-term roadmap.

>Read full chapter

PROCESS OVERVIEW FOR DEPLOYING DATA GOVERNANCE

John Ladley, in Data Governance, 2012

CONSIDERATIONS

You are building a program that requires a framework for operation. That means some basic
blocking and tackling in terms of Management 101. However, since many DG teams come from
technology areas, there is often a major slowdown in the DG effort as people who have never
done organization design start to do it. This is not an exercise in scraping together a few
organization charts.

Another common mistake is to fail to keep the design of information management processes
separate from data governance processes. This is usually because the initial staffing of DG is
drawn from information areas. Often the initial DG staff are told to “fit it in” to their current
roles and responsibilities.5 It is challenging for these individuals to maintain the separation of

Data Governance Process confidential

Page 7 of 23
duties mandated by the V while creating embedded organizational processes, new roles, and a
sustainable program.

>Read full chapter

FUNCTIONAL DESIGN
John Ladley, in Data Governance, 2012

TIPS FOR SUCCESS

If you receive feedback upon review of your functional design that it is “too much,” remind the
critics that business functional areas have similar sets of activity.

A common mistake is to fail to keep the design of information management process es separate
from data governance processes. The next activity gets specific about information management
processes. The lack of separation is usually because the initial staffing of DG is drawn from
information areas. Often, the initial DG staff a re told to “fit it in” to their current roles and
responsibilities.1 It is challenging to these individuals to maintain the separation of duties
mandated by the V, while also creating embedded organizational processes, new roles, and a
sustainable program. Remember, you must identify the IM functions as well as the DG
functions.

>Read full chapter

DATA STEWARDSHIP
Mark Allen, Dalton Cervo, in Multi-Domain Master Data Management, 2015

WHAT IS THE CURRENT STATE OF DATA GOVERNANCE?

For a multi-domain MDM program to succeed, data governance and data stewardship
practices need to be closely orchestrated. This effort needs to start with an effective data
governance process aligned with the MDM strategy and imple- mentation plan. Chapter 6

Data Governance Process confidential

Page 8 of 23
provided strategies and examples for how to establish a consistent, transparent governance
model across MDM domains and indicated that if a sufficient data governance process and
structure does not already
exist for the MDM program to use, the MDM program itself will need to become the driving
force behind the implementation of the necessary data governance processes. Similarly, if an
appropriate data steward model does not already exist, the MDM program and data
governance will need to become the driving forces behind the implementation of the data
steward model. Without well-aligned data governance and data steward models, the MDM
program cannot succeed.
Prior to a company having a multi-domain MDM strategy and plan, there are likely to be
existing instances of data governance and data steward practices that have resulted from locally
or functionally oriented data management initiatives. For example, in one functional area, a
data administrator or a support engineer may be acting in a data steward role to control a
specific set of master data, such as validating sources to target data loads according to certain
acceptance criteria and monitoring error log activity associated with any data mapping or
integration issues.

On the other hand, in another functional area, a data management team holds a broader and
more highly visible responsibility for overseeing various change control processes and data
quality management activities that include master data. Both are good examples of various
information technology (IT) or business functions taking the initiative to implement data
steward activity, but these cases are usually independently defined based on data management
requirements associated with a specific functional area; they lack a broader alignment with an
enterprisewide data governance strategy and plan.

As a company executes a multi-domain MDM strategy, these existing data steward functions
need to be identified and aligned with the enterprise strategy. This will pull together a more
cohesive network of data steward and quality controls that supports local and enterprisewide
requirements. For example, a local or regional order man- agement process requires the
customer’s name, address, and payment information to handle an order, but the customer’s
email address and telephone number is
not required, even though other functions in the company, such as marketing, finance, or
customer service, would benefit by having that additional information. In an enterprise MDM
and data governance model that has well-positioned data stewards, it will be much easier to

Data Governance Process confidential

Page 9 of 23
identify these data capture needs to satisfy the broader enterprise requirements and demands
for this data. A well-structured data governance process aligned with the MDM program
model and data architecture strategy will greatly aid in determining the master data priorities
and control points where data steward roles can be most effective.

>Read full chapter

Data Governance Process confidential

Page 10 of 23
THE AGILE EDW SUBRELEASE CYCLE
Ralph Hughes MA, PMP, CSM, in Agile Data Warehousing for the Enterprise, 2016

DEEPENING THE SUPPORT FOR DATA GOVERNANCE

Figure 19.4 enhances the previous value cycle diagram to address the needs of the company’s
EIM program by placing data governance at the center of the EDW subrelease development
process. By doing so, we will guide the EDW team in
focusing its contribution to the business-side of EIM, especially the data definition aspects of
data governance.

Figure 19.4. Agile EDW subrelease cycle showing support for data governance.

Data Governance Process confidential

Page 11 of 23
In Figure 19.4, the dotted arrows pointing toward the center represent contributions that EDW
team leaders can make during each step of the value cycle to a company’s data governance
process. Taken together, these flows will contribute a rich collection of target column definitions,
which will be extremely reliable given the multiple validations they will receive from both
business and the EDW developers during the many steps of the value cycle. The solid arrows
indicate areas where referencing the data governance information collected during early steps of
the subrelease assists either business or EDW team members in completing their work. These
flows consist of the following:

Step 1: Column and star schema object definitions vetted by the business while examining the
data governance prototype
Step 2: Further target column definitions and initial business rules stemming from the data
cowboy’s discovery work
Step 3: Detailed business rules and target column definitions gleaned from the system analyst’s
source-to-target mappings
Step 4: Additional details on the meaning, usefulness, and limitations of the proposed
analytical application’s components (e.g., a star schema’s metrics and dimensions) given the
stakeholder’s review of the live data prototype
Step 5: Further documentation regarding the basic set of metrics and dimen- sional attributes
the business considered while reviewing the backbone of the proposed data solution
Step 6: End-user refinements on the meaning and usefulness of the derived columns defined
during previous steps
Step 7, outflow from center: The data definitions for data warehouse elements to date, which will
guide the end users as they utilize the candidate version of the data warehouse to solve
business problems
Step 7, inflow to center: Refined definitions for both existing and newly requested features of
the analytic application, based on the innovations that end user created while using the
candidate version of the warehouse
Step 8, outflow: Data governance definitions that will guide the EDW devel- opers as they build
the remaining components requested by end users
Step 8, inflow: Definitions for the last set of derived columns just pro- grammed into the
subrelease candidate

Data Governance Process confidential

Page 12 of 23
 >Read full chapter

MASTER DATA MANAGEMENT AND DATA QUALITY

David Loshin, in The Practitioner's Guide to Data Quality Improvement, 2011

MDM: A HIGH-LEVEL COMPONENT APPROACH

For the purposes of data quality management, we can consider a component model view of a
master data environment, then consider the architectural implementation spectrum. Figure 19.1
provides an overview of the component model, which essen- tially composes a master data
repository, master data services, and the associated governance services necessary to support the
master environment.

Figure 19.1. The MDM component model.

Essentially, we can divide this component model into three pieces:

1. The master data repository,

2. The collection of master data services, and

3. The data governance processes and services.

Data Governance Process confidential

Page 13 of 23
THE MASTER DATA REPOSITORY

The master data repository is the framework in which master data objects and entities are
represented. Conceptually, this collection of components is used to manage multiple aspects of
what eventually is managed as master data:

• Reference data, consisting of the enumerated data domains and associated mappings
used by multiple business applications
• Metadata, including the data element definitions, semantics, and structure definitions,
for the shared data models for persistent storage and for data exchange
• Master data models, for the representation of the different data entities man- aged as
master data
• Business rules, which implement the business policies associated with the master data
• Hierarchies and relationships, used to establish connections between master data
entities (such as organizational chart, financial chart of accounts, or household
relationships)
• The entities themselves

All of these are accessed and managed via a set of services, subject to operational data governance processes. The
data is managed using one of a variety of MDM architectures, as discussed in section 19.7.

Data Governance Process confidential

Page 14 of 23
MASTER DATA SERVICES

Managing the master data environment depends on a collection of services that enable the
management of and access to the master data. For example, a master data environment could
be supported using these types of services:

• Integration and consolidation, including data intake process management, master

index/registry management, consolidation rules management, sur- vivorship rules
management, and source data and lineage management
• Data publication and data access, including publish, subscribe, data life-cycle services
(create, read, update, retire, archive); connectors to existing data as- sets; connectors to
existing applications; data transformations; and associated data access web services
• Data quality and cleansing, including parsing and standardization, data en- richment,
data correction, identity resolution and matching, and unmerging of incorrectly
consolidated records
• Access control, including management of a participant registry, participant life-cycle
management (create, read, update, retire), authentication, authoriza- tion, role
management, and role-based access control
• Metadata management, including master data model management, master data
exchange model management, master metadata management (data ele- ment definitions,
semantics, data types), reference data management, data quality rule management,
business rules management, hierarchy manage- ment, relationship management, and
aliasing and mapping rules manage- ment

Although this provides a high-level view of the types of services necessary for MDM, actual implementations may
describe provided services with a more precise level of granularity.

OPERATIONAL DATA GOVERNANCE

In support of the data governance techniques described in chapter 7 and the data inspection and
monitoring described in chapter 13, a master data management environment must also provide
services for operational data governance, including:
 Incident reporting and incident tracking, as discussed in chapters 13 and 17;

Data Governance Process confidential

Page 15 of 23
  Notification/alert management, so that when an issue is identified the right data steward is notified;

 Data browsing, which allows the data steward to scan through and review records as part of the issues
evaluation and remediation process;
 Data profiling and assessment, as described in chapter 11;
 History/log management, which allows the data stewards to review both the automatic and manual
modifications to master data;
 Privacy policy management, to review the privacy settings associated with accessing master data;
 Stewardship role management, for documenting which data stewards are responsible for which master
data sets; and
 Governance policy management, for overseeing the processes of documenting enterprise data governance
policies as they relate to master data, and their implementation.

>Read full chapter

Data Governance Process confidential

Page 16 of 23
DATA GOVERNANCE AS AN OPERATIONS PROCESS
Lowell Fryman, ... Dan Meers, in The Data and Analytics Playbook, 2017

DATA GOVERNANCE OPERATIONAL MODEL

To create an operations process you need to thoughtfully design three core areas: process, organization, and
technology. For data governance and the Playbook, these areas are:

• Process: The day-to-day approach to conducting the core data governance jobs listed in
Chapter 1. This includes the improvement process used to refine
the Playbook.•The Playbook provides a detailed description of the operations
processes.
• Organization: The types and locations of human resources that are part of executing the
data governance process. The organization also needs to include the oversight and
management elements. Most organizations have found that since the data governance
jobs and processes cut across functional groups, many data governance resources are
part-time.•The Playbook calls out the roles used in the process. Each role may be filled
by one or more human resources in the organization. Taken together, the Playbook
roles define the data governance organization.
• Technology: These are the applications and other tools the data governance organization
uses to run the processes efficiently and effectively.

• The Play book may describe specific technology actions to take, eg, send an email or post
a request to a specific portal folder. We refer to this level of detail as a “desk-level
procedure.” The Playbook is often one level higher. It is up to you to decide how much
detail to provide in the Playbook. The level of detail you provide is based on how
prescriptive you need to be for the specific resources that will be fulfilling the roles. In
some cases, this level of detail is absolutely essential to helping the organization execute.
For others, slightly less detail may be appropriate.

Data Governance Process confidential

Page 17 of 23
 Designing these areas for a data governance operations process can be as challenging as it is
to create processes spanning multiple profit and loss centers or manage- rial
boundaries. We use the term “operational model” to mean the specific choices you
make in these three areas when designing your data governance program. For example,
you may choose to minimize, at least initially, the amount of application support you
provide data governance human resources. This may be the “model” you use to launch
the data governance operations process. The model could later change as the process
matures. Once you cast data governance as an operations process, all operations
processes require a guide. The Playbook is the essential guide.
In addition to the core data governance process, organization, and technology areas, you
will also need to ensure that the operational process is improved and tracked over time.
Nearly all operational processes of significant scale are tracked through metrics. Some
operational processes have extensive measures that are identified and reported through
a scorecard. Many operational applications have built-in support to collect data for
calculating the measures.
Operational metrics will provide information to you on how well the process is
meeting its operational targets. Operational metrics may or may not include f-
inancial outcome metrics. The decision to use information-based approaches to
competing in the marketplace is a business strategy choice. Operations, such as data
governance, are the cost of doing business. While data governance may be a critical
dependency in growing topline revenue, data governance is often categorized like
infrastructure, computers, and people. They are necessary costs. Organizations engage
in data governance regardless of whether they have a formal program or manage
these costs explicitly.
Designing your operational model requires tradeoffs. We recommend that the
Playbook focus on the process and leave application-level details to other training
material.
For example, the Playbook describes steps to “obtain approval” for various artifacts such
as a business glossary entry or a critical data element (CDE). Depending on the artifact,
approval could be obtained in different ways each having different levels
of application support. Supporting data governance by implementing technology-
enabled “workflows” is a popular topic now in the data governance communi- ty.
Technology-supported workflows reduce the cost of running data governance

Data Governance Process confidential

Page 18 of 23
 processes, enforces accountability, and supports distributed consensus building.
Workflows can be implemented using technologies such as email and spreadsheets,
Microsoft Sharepoint workflow, and application tools such as Oracle’s DRM/DRG or
Collibra. In many cases, different workflow processes may be active for different data
governance artifacts at the same time. Describing all of the di fferent technology specific
workflows in the Playbook may make the Playbook hard to read and use.
Linking the Playbook to a description of a technology-specific approval approach is
useful. We encourage you to create an ecosystem of process notes and desk-level
procedures that are readily accessible. When designing your operating model, you
should realize that the way you communicate the process, the way you organize it, and
the way you employ technology may determine the success in deploying the Playbook.

>Read full chapter

Data Governance Process confidential

Page 19 of 23
DATA GOVERNANCE FOR MASTER DATA MAN- AGEMENT
David Loshin, in Master Data Management, 2009

PUBLISHER SUMMARY

Master data management (MDM) is an enterprise initiative, and that means an enterprise data
governance program must be in place to oversee it. Governance is a critical issue for deploying
MDM. The objective of data governance is predicated on the desire to assess and manage many
kinds of risks that lurk within the enterprise information portfolio and to reduce the impacts
incurred by the absence of over- sight. Although many data governance activities might be
triggered by a concern about regulatory compliance, the controls introduced by data governance
processes and protocols provide a means for quantitative metrics for assessing risk reduction as
well as measuring business performance improvements. By introducing a program for defining
information policies that relate to the constraints of the business and adding in management
and technical oversight, the organization can realign itself around performance measures that
include adherence to business policies and the information policies that support the business.
This chapter discusses how business policies are composed of information directives and how
data rules contribute to conformance to those information directives. It examines what data
governance
is while introducing data stewardship roles and responsibilities and proposes a

Data Governance Process confidential

Page 20 of 23
collaborative enterprise data governance framework for data sharing. The three important aspects
of data governance for MDM are managing key data entities and critical data elements,
ensuring the observance of information policies, and documenting and ensuring accountability
for maintaining high-quality master data.

>Read full chapter

OVERVIEW OF DATA GOVERNANCE DEVELOPMENT AND

DEPLOYMENT
John Ladley, in Data Governance (Second Edition), 2020

CONSIDERATIONS

Why does every type of DG effort go through this activity area? Simply because this is where we
design the solution, regardless of how small or large, how invasive or not. Once we know what
DG needs to accomplish (alignment and requirements) then we need to identify WHAT and
HOW. Obviously, this is not a new means of arriving at a solution. For DG, however, many
program teams are in new territory, having worked with discrete programs or computer
systems.
Capabilities are used because they are the language of business and enterprise architects. Since
DG is usually a new business capability, it is important to keep these areas engaged. If these areas
do not exist, then the DG team needs to assume the temporary role of enterprise architect. Even
if a DG program is in place and you are reenergizing your program, shifting toward capability
thinking will strengthen your engagement with stakeholders.
You are building a program that requires a framework for operation. That means some basic
blocking and tackling in terms of Management 101. But this is not an exercise in scraping
together a few organization charts. The term “operating framework” is purposely used instead of
“organization chart.” Given that the goal
is to eventually blend in with ordinary day-to-day behavior, you will rarely develop a large
separate DG organization. There will always be a small virtual function of DG visible, but does
any organization need a stand-alone, permanently funded DG “department”?
There are detailed processes that are designed that make the WHAT of a capability become a
HOW. Also, this blends in workflow with how DG engages with its constituents. Obvious areas,
even for smaller efforts, are affected systems and data users. For more strategic DG programs,

Data Governance Process confidential

Page 21 of 23
engaging with strategic planning, budget planning, and compliance areas will require some
process definition. Avoid the

Data Governance Process confidential

Page 22 of 23
common mistake of blending DM processes with DG processes. This is usually because the initial staffing of DG is
drawn from information areas. Often the initial DG staff are told to “fit it in” to their current roles and
responsibilities.7 It is challenging for these individuals to maintain the separation of duties while creating
embedded organizational processes, new roles, and a sustainable program. Physical separate areas of DG and DM
are often not possible, but please maintain the spirit of separation of duties (the “V”). See Fig. 6.8.

Fig. 6.8. Separation of duties example

Lastly, pointing out new roles and who needs to do them is considered at this point. For the low-
profile approach, this may only be one or two individuals. A broad-scale, compliance-driven DG
program, or large MDM effort may require a larger e ffort to identify responsibility and
accountability. The same applies to high impact, but localized efforts like advanced analytics.
Whoever handles the data and verifies its readiness for analytical models is critical, and regardless
of how many data scientists are involved there will need to be some formal role and
responsibility definition.
This step also entails identifying the stewardship/ownership/custodian population. Please note the
mention of stewards and custodians and all similar roles has been delayed until the functional
design is completed. It is not effective to mention these roles earlier in the process. It places
people in a position of feeling they need to
do something, but that something is usually ill-defined until this point. It also avoids spewing
the whole stewardship vocabulary around before you have actually defined what that means for
your organization. Be patient, designate roles and responsibilities, and only then assign the
appropriate label to a specific catalog of duties.

>Read full chapter

Data Governance Process confidential

Page 23 of 23