32,99 €
Discover what does--and doesn't--work when designing and building a data governance program In A Practitioner's Guide to Operationalizing Data Governance, veteran SAS and data management expert Mary Anne Hopper walks readers through the planning, design, operationalization, and maintenance of an effective data governance program. She explores the most common challenges organizations face during and after program development and offers sound, hands-on advice to meet tackle those problems head-on. Ideal for companies trying to resolve a wide variety of issues around data governance, this book: * Offers a straightforward starting point for companies just beginning to think about data governance * Provides solutions when company employees and leaders don't--for whatever reason--trust the data the company has * Suggests proven strategies for getting a data governance program that's gone off the rails back on track Complete with visual examples based in real-world case studies, A Practitioner's Guide to Operationalizing Data Governance will earn a place in the libraries of information technology executives and managers, data professionals, and project managers seeking a one-stop resource to help them deliver practical data governance solutions.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 276
Veröffentlichungsjahr: 2023
Cover
Wiley and SAS Business Series
Title Page
Copyright
Dedication
Acknowledgments
CHAPTER 1: Introduction
INTENDED AUDIENCE
EXPERIENCE
COMMON CHALLENGE THEMES
CHAPTER 2: Rethinking Data Governance
RESULTS YOU CAN EXPECT WITH COMMON APPROACHES TO DATA GOVERNANCE
WHAT DOES WORK
RETHINKING DATA GOVERNANCE SUMMARY
CHAPTER 3: Data Governance and Data Management
RESULTS YOU CAN EXPECT FOCUSING PURELY ON DATA GOVERNANCE OR DATA MANAGEMENT
SAS DATA MANAGEMENT FRAMEWORK
ALIGNING DATA GOVERNANCE AND DATA MANAGEMENT OUTCOMES
MISALIGNING DATA GOVERNANCE AND DATA MANAGEMENT
DATA GOVERNANCE AND DATA MANAGEMENT SUMMARY
CHAPTER 4: Priorities
RESULTS YOU CAN EXPECT USING THE MOST COMMON APPROACHES TO PRIORITIZATION
A DISCIPLINED APPROACH TO PRIORITIES
UTILIZING THE MODEL
PRIORITIES SUMMARY
CHAPTER 5: Common Starting Points
RESULTS YOU CAN EXPECT WITH TOO MANY ENTRY POINTS
BUILDING A DATA PORTFOLIO
METADATA
DATA QUALITY
DATA PROFILING
COMMON STARTING POINTS SUMMARY
CHAPTER 6: Data Governance Planning
RESULTS YOU CAN EXPECT WITHOUT PLANNING
DEFINING OBJECTIVES
DEFINING GUIDING PRINCIPLES
DATA GOVERNANCE PLANNING SUMMARY
CHAPTER 7: Organizational Framework
RESULTS YOU CAN EXPECT WHEN THERE IS NO DEFINED ORGANIZATIONAL STRUCTURE
ORGANIZATIONAL FRAMEWORK ROLES
DEFINING A FRAMEWORK
ALIGNING THE MODEL TO EXISTING STRUCTURES
ALIGNING THE FRAMEWORK TO THE CULTURE
SIMPLIFYING THE MODEL
DEFINING THE RIGHT DATA STEWARDSHIP MODEL
ORGANIZATIONAL FRAMEWORK SUMMARY
CHAPTER 8: Roles and Responsibilities
RESULTS YOU CAN EXPECT WHEN ROLES AND RESPONSIBILITIES ARE NOT CLEARLY DEFINED
ALIGNING ACTIONS AND DECISIONS TO PROGRAM OBJECTIVES
USING A RACI MODEL
DEFINING ROLES AND RESPONSIBILITIES
DATA GOVERNANCE STEERING COMMITTEE
PROGRAM MANAGEMENT
DATA GOVERNANCE COUNCIL
DATA OWNER TEAM
WORKING GROUP
DATA STEWARDSHIP
DATA MANAGEMENT
NAMING NAMES
ROLES AND RESPONSIBILITIES SUMMARY
CHAPTER 9: Operating Procedures
RESULTS YOU CAN EXPECT WITHOUT OPERATING PROCEDURES
OPERATING PROCEDURES
A SIMPLIFIED VIEW OF OPERATING PROCEDURES
WORKFLOWS
OPERATING PROCEDURES SUMMARY
CHAPTER 10: Communication
RESULTS YOU CAN EXPECT WITHOUT COMMUNICATION
COMMUNICATION PLAN COMPONENTS
SAMPLE COMMUNICATION PLAN
COMMUNICATION SUMMARY
CHAPTER 11: Measurement
RESULTS YOU CAN EXPECT WITHOUT MEASUREMENT
WHAT MEASUREMENTS TO DEFINE
PROGRAM SCORECARD – A STARTING POINT
PROGRAM SCORECARD SAMPLE
MEASUREMENT SUMMARY
CHAPTER 12: Roadmap
RESULTS YOU CAN EXPECT WITHOUT A ROADMAP
FIRST STEP IN DEFINING A ROADMAP: IMPLEMENTING YOUR FRAMEWORK
DEFINING A ROADMAP
FORMALITY FIRST OR SAVE IT FOR LATER?
CRITICAL SUCCESS FACTORS
ROADMAP SUMMARY
CHAPTER 13: Policies
RESULTS YOU CAN EXPECT WITHOUT POLICIES
BREAKING DOWN A POLICY
CONTENTS OF A POLICY
POLICY EXAMPLE – METADATA
POLICY EXAMPLE – DATA QUALITY
POLICY SUMMARY
CHAPTER 14: Data Governance Maturity
RESULTS YOU CAN EXPECT WITH MATURITY
DATA GOVERNANCE MATURITY CYCLE
MATURING YOUR PROGRAM
SUMMARY
About the Author
Glossary of Terms
Index
End User License Agreement
Chapter 3
Table 3.1 Data Management Capabilities.
Chapter 4
Table 4.1 Weight Factors.
Table 4.2 Assigned Weights.
Table 4.3 University Reporting and Analytic Capabilities.
Table 4.4 Detailed Yes/Sort Of/No Matrix.
Table 4.5 Prioritization Model Inputs.
Table 4.6 Prioritization Weighted Scores.
Table 4.7 Retailer Challenges.
Chapter 5
Table 5.1 Data Quality Dimensions.
Table 5.2 Record with No Context.
Table 5.3 Record with Better Context.
Table 5.4 Data Element Quality.
Table 5.5 Records for Data Element Quality.
Table 5.6 Data Element Quality Dataset Notes.
Table 5.7 Data Record Quality.
Table 5.8 Records for Data Record Quality.
Table 5.9 Data Record Quality Dataset Notes.
Table 5.10 Data Profiling Analysis Components.
Chapter 6
Table 6.1 “The List” and Potential Root Causes.
Table 6.2 Turning Root Causes into Objectives.
Table 6.3 Sample Objectives.
Table 6.4 Sample Guiding Principles.
Chapter 7
Table 7.1 Data Domain Model Pros and Cons.
Table 7.2 Business Function Model Pros and Cons.
Table 7.3 Application Model Pros and Cons.
Table 7.4 Project Model Pros and Cons.
Chapter 8
Table 8.1 Data Management Functions Aligned to Program Objectives.
Table 8.2 Strategy & Alignment Activities/Decisions.
Table 8.3 Establish Data Governance Program Activities/Decisions.
Table 8.4 Data Governance Operations Activities/Decisions.
Table 8.5 Data Architecture Activities/Decisions.
Table 8.6 Metadata Activities/Decisions.
Table 8.7 Data Quality Program Activities/Decisions.
Table 8.8 Reference & Master Data Activities/Decisions.
Table 8.9 Strategy & Alignment RACI.
Table 8.10 Establish Data Governance Program RACI.
Table 8.11 Data Governance Operations RACI.
Table 8.12 Data Architecture RACI.
Table 8.13 Metadata RACI.
Table 8.14 Data Quality RACI.
Table 8.15 Reference & Master Data RACI.
Table 8.16 Sample Data Governance Representation.
Chapter 9
Table 9.1 Policy Development RACI.
Table 9.2 Data Issue Intake RACI.
Table 9.3 Compliance Monitoring RACI.
Table 9.4 Prioritization RACI.
Chapter 10
Table 10.1 Prioritization RACI.
Table 10.2 Data Governance Communication Plan.
Chapter 11
Table 11.1 Sample Data Governance Program Measures.
Table 11.2 Data Governance Council Meeting Attendance.
Table 11.3 Data Governance Council Meeting Attendance.
Table 11.4 Data Governance Compliance Tracking.
Table 11.5 Data Governance Compliance Tracking by High‐Impact Elements.
Chapter 12
Table 12.1 Data Governance Critical Success Factors.
Chapter 13
Table 13.1 Metadata RACI Matrix.
Chapter 14
Table 14.1 Benefits Realization.
Chapter 3
Figure 3.1 SAS Data Management Framework.
Figure 3.2 Data Governance/Data Management and IT Alignment.
Figure 3.3 Data Governance/Data Management and IT Touchpoints.
Figure 3.4 Data Governance in Action.
Chapter 4
Figure 4.1 Business Value Definition.
Figure 4.2 Achievability Definition.
Figure 4.3 Sample Prioritization Model Output.
Figure 4.4 University Prioritization Output.
Figure 4.5 Retailer Priorities.
Chapter 5
Figure 5.1 Business Data Portfolio (Portfolio).
Chapter 7
Figure 7.1 The Data Governance Ecosystem.
Figure 7.2 Sample Data Governance Organizational Framework.
Figure 7.3 Sample Data Governance Organizational Framework.
Figure 7.4 Sample Data Governance Organizational Framework.
Figure 7.5 Sample Data Governance Organizational Framework.
Chapter 9
Figure 9.1 Data Governance Organizational Framework.
Figure 9.2 Data Governance Council Operating Procedures.
Figure 9.3 Policy Development Workflow.
Figure 9.4 Data Issue Intake Workflow.
Figure 9.5 Compliance Monitoring Workflow.
Figure 9.6 Prioritization Workflow.
Chapter 11
Figure 11.1 Data Governance Council Meeting Participation.
Figure 11.2 Data Governance Council Meeting Participation.
Figure 11.3 Data Governance Program Milestones.
Figure 11.4 Data Governance Policy Compliance.
Figure 11.5 Sample Data Governance Scorecard.
Chapter 12
Figure 12.1 Data Governance Organizational Structure.
Figure 12.2 Implementation Order for Data Governance Organizational Structur...
Figure 12.3 How to Read the Roadmap.
Figure 12.4 Overall Workstreams.
Figure 12.5 Launch Data Governance Workstream.
Figure 12.6 Data Warehouse Program Workstream.
Figure 12.7 Data Architecture Workstream.
Figure 12.8 Metadata Workstream.
Figure 12.9 Data Quality Policy.
Figure 12.10 Data Management Workstream.
Figure 12.11 Metadata Workstream.
Figure 12.12 Operationalizing Data Governance Workstream.
Chapter 13
Figure 13.1 Components of a Policy.
Chapter 14
Figure 14.1 Data Governance Maturity Cycle.
Cover Page
Wiley and SAS Business Series
Title Page
Copyright
Dedication
Acknowledgments
Table of Contents
Begin Reading
About the Author
Glossary of Terms
Index
Wiley End User License Agreement
ii
iii
v
vi
vii
xiii
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
207
208
209
210
211
212
213
214
215
216
217
219
220
221
222
223
224
225
226
227
The Wiley and SAS Business Series presents books that help senior level managers with their critical management decisions.
Titles in the Wiley and SAS Business Series include:
The Analytic Hospitality Executive: Implementing Data Analytics in Hotels and Casinos
by Kelly A. McGuire
Analytics: The Agile Way
by Phil Simon
The Analytics Lifecycle Toolkit: A Practical Guide for an Effective Analytics Capability
by Gregory S. Nelson
Anti‐Money Laundering Transaction Monitoring Systems Implementation: Finding Anomalies
by Derek Chau and Maarten van Dijck Nemcsik
Artificial Intelligence for Marketing: Practical Applications
by Jim Sterne
Business Analytics for Managers: Taking Business Intelligence Beyond Reporting (Second Edition)
by Gert H. N. Laursen and Jesper Thorlund
Business Forecasting: The Emerging Role of Artificial Intelligence and Machine Learning
by Michael Gilliland, Len Tashman, and Udo Sglavo
The Cloud‐Based Demand‐Driven Supply Chain
by Vinit Sharma
Consumption‐Based Forecasting and Planning: Predicting Changing Demand Patterns in the New Digital Economy
by Charles W. Chase
Credit Risk Analytics: Measurement Techniques, Applications, and Examples in SAS
by Bart Baesen, Daniel Roesch, and Harald Scheule
Demand‐Driven Inventory Optimization and Replenishment: Creating a More Efficient Supply Chain (Second Edition)
by Robert A. Davis
Economic Modeling in the Post Great Recession Era: Incomplete Data, Imperfect Markets
by John Silvia, Azhar Iqbal, and Sarah Watt House
Enhance Oil & Gas Exploration with Data‐Driven Geophysical and Petrophysical Models
by Keith Holdaway and Duncan Irving
Fraud Analytics Using Descriptive, Predictive, and Social Network Techniques: A Guide to Data Science for Fraud Detection
by Bart Baesens, Veronique Van Vlasselaer, and Wouter Verbeke
Intelligent Credit Scoring: Building and Implementing Better Credit Risk Scorecards (Second Edition)
by Naeem Siddiqi
JMP Connections: The Art of Utilizing Connections in Your Data
by John Wubbel
Leaders and Innovators: How Data‐Driven Organizations Are Winning with Analytics
by Tho H. Nguyen
On‐Camera Coach: Tools and Techniques for Business Professionals in a Video‐Driven World
by Karin Reed
Next Generation Demand Management: People, Process, Analytics, and Technology
by Charles W. Chase
A Practical Guide to Analytics for Governments: Using Big Data for Good
by Marie Lowman
Profit from Your Forecasting Software: A Best Practice Guide for Sales Forecasters
by Paul Goodwin
Project Finance for Business Development
by John E. Triantis
Smart Cities, Smart Future: Showcasing Tomorrow
by Mike Barlow and Cornelia Levy‐Bencheton
Statistical Thinking: Improving Business Performance (Third Edition)
by Roger W. Hoerl and Ronald D. Snee
Strategies in Biomedical Data Science: Driving Force for Innovation
by Jay Etchings
Style and Statistics: The Art of Retail Analytics
by Brittany Bullard
Text as Data: Computational Methods of Understanding Written Expression Using SAS
by Barry deVille and Gurpreet Singh Bawa
Transforming Healthcare Analytics: The Quest for Healthy Intelligence
by Michael N. Lewis and Tho H. Nguyen
Visual Six Sigma: Making Data Analysis Lean (Second Edition)
by Ian Cox, Marie A. Gaudard, and Mia L. Stephens
Warranty Fraud Management: Reducing Fraud and Other Excess Costs in Warranty and Service Operations
by Matti Kurvinen, Ilkka Töyrylä, and D. N. Prabhakar Murthy
For more information on any of the above titles, please visit www.wiley.com.
Mary Anne Hopper
Copyright © 2023 by SAS institute, Inc. All rights reserved.
Published by John Wiley & Sons, Inc., Hoboken, New Jersey.Published simultaneously in Canada.
No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning, or otherwise, except as permitted under Section 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per‐copy fee to the Copyright Clearance Center, Inc., 222 Rosewood Drive, Danvers, MA 01923, (978) 750‐8400, fax (978) 750‐4470, or on the web at www.copyright.com. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) 748‐6011, fax (201) 748‐6008, or online at http://www.wiley.com/go/permission.
Trademarks: Wiley and the Wiley logo are trademarks or registered trademarks of John Wiley & Sons, Inc. and/or its affiliates in the United States and other countries and may not be used without written permission. All other trademarks are the property of their respective owners. John Wiley & Sons, Inc. is not associated with any product or vendor mentioned in this book.
Limit of Liability/Disclaimer of Warranty: While the publisher and author have used their best efforts in preparing this book, they make no representations or warranties with respect to the accuracy or completeness of the contents of this book and specifically disclaim any implied warranties of merchantability or fitness for a particular purpose. No warranty may be created or extended by sales representatives or written sales materials. The advice and strategies contained herein may not be suitable for your situation. You should consult with a professional where appropriate. Further, readers should be aware that websites listed in this work may have changed or disappeared between when this work was written and when it is read. Neither the publisher nor author shall be liable for any loss of profit or any other commercial damages, including but not limited to special, incidental, consequential, or other damages.
For general information on our other products and services or for technical support, please contact our Customer Care Department within the United States at (800) 762‐2974, outside the United States at (317) 572‐3993 or fax (317) 572‐4002.
Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic formats. For more information about Wiley products, visit our web site at www.wiley.com.
Library of Congress Cataloging‐in‐Publication Data:
Names: Hopper, Mary Anne, author.
Title: Practitioner’s guide to operationalizing data governance / Mary Anne Hopper.
Description: Hoboken, New Jersey : Wiley, [2023] | Series: Wiley and SAS business series | Includes index.
Identifiers: LCCN 2023001522 (print) | LCCN 2023001523 (ebook) | ISBN 9781119851424 (cloth) | ISBN 9781119851455 (adobe pdf) | ISBN 9781119851431 (epub)
Subjects: LCSH: Database management. | Management information systems—Management. | Data integrity.
Classification: LCC QA76.9.D3 H6564 2023 (print) | LCC QA76.9.D3 (ebook) | DDC 005.75/65—dc23/eng/20230201
LC record available at https://lccn.loc.gov/2023001522
LC ebook record available at https://lccn.loc.gov/2023001523
Cover Design: WileyCover Image: © shulz/Getty Images
For the MAC team (Faramarz, Matthias, Matt, Katie, Noah, and Liz) for all your support
and
For Bill for never letting me throw the term “best practice” out there without explaining “the why”.
A methodology does not create itself overnight. It takes time, encouragement, and dedication from a lot of people. The methodology I have laid out for you is from the work and guidance of my colleagues at the SAS Institute: Faramarz Abedini, Matthias Gruber, Robert Stone, Matt Benson, Katie Lorenze, Noah Pearce, and Liz Baker. Some of you I have worked with for many years, some not quite as long. Either way, your fingerprints are embedded in the content of these pages. For that, I thank you!
As long as the practice of Data Governance has been around, the concept continues to lack sustainable adoption in many organizations. My main objective with this book is to share my experience and help you and your organization on your journey, no matter where in that journey you are.
My best guess is that you are looking at this book as a guide for one of the following reasons:
Your organization is thinking about Data Governance.
You have been tasked with Data Governance.
You need to get your Data Governance program back on track.
You have acquired a tool and want to get the most value from your investment.
You continue to have the same data quality issues over and over.
You attended a conference and learned about Data Governance and think it is something you need.
The content in this book is meant for a large audience because Data Governance impacts the entire organization. Whether a senior leader or an individual contributor, you may be asked to participate at some level in Data Governance, actively or passively.
This book guides you through practical steps in applying Data Governance concepts to solve business problems by adopting a disciplined approach to Data Management methods. The chapters cover prioritization, alignment of Data Governance and Data Management, organizational structures, defining roles and responsibilities, communications, measurements, operations, implementation, and policies. All of the examples presented are not conceptual; they are real‐world customer examples that can be applied to your specific organization.
You most likely have an interest in not just Data Governance, but in data itself. Do you remember your “Aha” moment that turned you into a data junkie? I remember mine clearly. In the early 1990s, I worked for a small naval architectural firm. The focus of the firm was primarily custom high‐end racing sailboat designs, including the America's Cup. One day my boss brought in a floppy disk and asked me to take a look at what was on it. Apparently, we had a client who thought his brand‐new boat was slow. The disk contained the data dump from the boat's instruments. There were fields like time of day, heading, wind velocity, and boat speed. I was able to parse the data and essentially recreate the races with the available data points. What I learned was that the boat tacked nine or ten times on the first leg of each race. I know not all of you are expert sailboat racers but take my word for it; tacking that many times on any leg of a race in a big boat is slow. What did that mean for my boss? He was able to have a different conversation with our client. We were no longer defending boat design or building materials but instead talking about racing tactics and offering suggestions for improvements there first.
That day changed my view of the power of data and from that point forward I chose classes and career roles that were focused on data. Initially, I focused on database development and support and then transitioned into data warehouse development. On the IT side, I managed the development of platforms to support finance and treasury processes as well as the re‐platforming of a home‐grown loan servicing system. That experience enlightened me to the need for data quality processes and the understanding of data lineage and documented business rules. There came a time when I transitioned into project management, product ownership, and finally consulting. The consulting role is what has helped me most in hearing customer challenges and helping them solve those problems by instilling discipline in Data Management processes.
Over the years, I have worked with hundreds of clients across all industry verticals to help them establish that discipline in Data Management practices. In other words, helping them to establish Data Governance programs that align with their individual organization's business objectives while also considering their maturity, culture, and appetite for Data Governance.
This book is not only a reflection of a tested and proven methodology but also my experiences in what works and what doesn't work, things to not get hung up on, and where best to focus efforts. Some of the chapters are shorter than others but I still believe the topics are important enough to cover. My hope is that this book helps you and your organization in your own Data Governance journey.
Most of what I've heard over the years can be broken down into a set of common themes. One of the best ways to talk about those themes is to share with you what I've heard my clients say. Every quote is directly from a customer. If any of these quotes resonate with you, then formalizing Data Governance can help. You will see these themes again in future chapters.
Metadata is the practice of gathering, storing, and provisioning information about data assets. As important as it is to collect and maintain, it is a practice that does not formally exist in most organizations. Most of my customers might not necessarily use the term metadata, but the concept is top of mind for them. There is a desire to have common terms defined and have a single repository to maintain information about those terms. Because there is no formal metadata process or repository, users spend a lot of their time trying to understand data on their own or relying on others to interpret meaning for them. Another byproduct from the lack of metadata process is that users complain of not knowing what data is available to them. Always keep in mind that metadata is a precursor to data quality; I will write more about that topic in later chapters.
Here is what clients have said:
“we need Rosetta Stone for our data”
“metadata is so important and it doesn't exist”
“the most time‐consuming part is to find what you're looking for”
“would be nice to follow the trail”
“can't get to confident decisions without common definitions”
“a little bit of detective work and a little bit of knowledge”
“this is what I mean when I say ‘this’”
“we haven't the foggiest idea of what the denominator is”
“you get the data and it's not what you meant”
“some people just want to call it something different”
Oftentimes, there are very few people with the “know‐how” and the tools to access data. Users who do have direct access feel they must navigate a labyrinth to get to the data they need. That labyrinth includes multiple reports, accessing tables, or calling people who have knowledge of data structures. Because of this, users find it easier to maintain their own datasets instead of accessing a common repository. In most organizations, users are anxious to have access to tools to make it easier to use data.
Here is what clients have said:
“we got to know what the hell we got”
“our issue isn't so much storage, it's access”
“quit parking data on some machine”
“a whole lot of horsepower to pull data out of that system”
“you have to have your DNA tested before you get access to it”
“not knowing something exists is a greater liability than not using what is available”
“a lot of what we're doing seems so hard”
“information does not seem readily available”
“manual data exercise to put it together”
“we have so much information out there in so many places”
“Excel becomes the big workhorse”
“we've created a process to deal with lack of access to information”
“want to hire an analyst, not a SQL person”
“high‐priced analyst just getting data for people”
Users want the ability to make solid decisions on trusted data that is deemed a definitive source of truth. However, users feel there is a lack of consistency across data sources. Some of the reasons for this could be related to data latency, poor data collection practices, a lack of data understanding (e.g., data acceptance, service level agreements, data remediation, and data profiling), or different groups creating and maintaining their own copies of data. This results in users feeling they spend a significant amount of time validating or defending the data they do use.
Here is what clients have said:
“depending on which query you run you get a different answer”
"can't create individual sources of truth”
“the place we pull the data from doesn't balance to itself”
“we don't know how reliable the data is”
“you trust the data until you know it's not right”
“if you can't fix the problem you work around it”
“how do we know what an error looks like?”
Data integration consists of processes for moving and combining data that reside in multiple locations and providing a unified view of the data. In many environments, users who need access to integrated data are essentially required to pull several reports or datasets and then integrate on their desktop using MS Access or Excel. There may also be a lack of formal processes or tool usage across divisions and even in IT. More often than not, this results in differing business rules that are applied to data, which turns into discrepancies in the data results.
Here is what clients have said:
“I'm living in spreadsheet hell”
“really no linking it all together”
“right now, it's fragmented”
“all our stuff doesn't talk to each other”
“being able to stitch data together is what we need”
“our systems have never been organized to allow us to answer questions”
“almost every prototype that we did last fiscal year had to do with the difficulty of pulling data from multiple datasets”
“we have a lot of questions, we have a lot of data, but we can't pull it out easily”
Users do not know who to contact when there are data questions. There is a desire to have a named data owner for the various domains who can answer questions, address issues, and help users understand data usage guidelines for given datasets.
Here is what clients have said:
“you're stepping on toes every time you go in there”
“everybody wants to control their own fate”
“that's our data so we should be able to keep up with it”
“lack of accountability for data responsibility”
“we don't really know who does that”
Users are becoming more data aware. Although some users only require operational reports, there is a growing curiosity and desire for more advanced analytic capabilities. This makes the reporting and analytic platform (e.g., data warehouse, data mart, date lake, etc.) being part of the overall strategic plan more important than ever. Most users feel it takes up a lot of their time to get reports and like the concept of a single point of entry for all of their reports as opposed to reports within the various applications that they are forced to self‐integrate.
Here is what clients have said:
“how much of that data is relevant to the next level of the department?”
“I don't think people realize what we could do [if our data were integrated]”
“very myopic view of the data”
“[we need to be able to provide] reliable, repeatable answers to questions”
”the most time‐consuming part is to find what you're looking for”
“would like to have a dashboard to share accurate information”
“it's more art than science”
“information is perceived as ad‐hoc”
“used to managing without information”
“too much reliance on old data to make current decisions”
While most organizations have an architecture practice in place, the teams often lack authority because they do not have a formally defined charter. There is no formal data strategy to help set the team's direction and enable it to define standards and guidelines for identifying, provisioning, storing, and integrating data. With newly formed teams especially, the focus is on new applications instead of the entire enterprise data landscape that has been growing for years with no formal practices in place.
Here is what clients have said:
“there have been so many architecture hands over the years”
“we are duplicating a lot of information”
“[there is] no logic in how we approach managing data”
“data should be accessible regardless of where its source is”
“it's extremely laborious”
“tendency to work like we're all artisans here”
“by the time you figure out what everyone else is doing it becomes faster to do it yourself”
“we're on the bleeding edge of end of life”
“[it takes] a whole lot of horsepower to pull data”
I cannot remember the last time I was with a customer who did not feel overly reliant on go‐to people to help them with understanding, getting at, or validating data or reports. Many of the things I talk about in this section are symptoms of an “I know a guy/gal” culture that becomes embedded in the organization because of a lack of a shared data dictionary, unknown data quality, difficulty in accessing data or reports, or an inconsistent data architecture.
Here is what clients have said:
“a little bit of detective work and a little bit of knowledge”
“if I need the data, so and so can whip me up a SQL query”
“it's a fishing expedition to find people who can get you information”
“not everybody knows everybody”
“need to unlock the creativity of the bright people in our organization”
“I should be able to run my reports”
Kicking off a Data Governance program or breathing new life into an existing program will more than likely require a culture shift. This can be one of the largest hurdles in overall sustainability of your program. This culture shift usually involves two things. The first is communicating across division or line of business silos. Communication involves everything from policies to policy compliance reporting to program performance. The second is in data sharing. I am often told that people want access to data not created in their focus area, but others just do not want to grant access because they are data hoarders. More often than not, I find that people are reluctant to share because they are afraid of how the data may possibly be misused or misinterpreted.
Here is what clients have said:
“[we are] great at planning but fall short on implementation”
“divisions operate within their own zones”
“we have a culture of independence and resistance”
“[there will] always be people out there doing crazy s**t”
“we're beyond ‘it would be nice to have’”
“lots of good people who do lots of good work”
“we have departments where all they do is protect themselves against bad data”
“we don't teach data awareness”
“focus a lot of our measures on things that are easy”
“what we do is reactive”
Let's think about the themes again, and I will provide some examples of how Data Governance can help. There is definitely cross‐over in some of these areas. For example, providing metadata to users will help with data access challenges in better understanding what data is available for use.
Data Governance provides the process for collecting, updating, storing, and provisioning. A metadata policy will contain not just the process but what attribution should be collected about what data in the environment. This helps users because they have access to common business terms (rationalized across different sources) and some sort of consolidated and updated data dictionary. I will explore metadata in more detail in Chapter 5, Common Starting Points, and Chapter 13, Policies.