The Fundamentals of Data Governance – Part 1
Among Talend’s blog posts are many outstanding ones on data governance, such as David Talaga’s “Life Might Be Like a Box of Chocolates, But Your Data Strategy Shouldn’t Be” which encourages us to know our data, and his two-part post on “6 Dos and Don’ts of Data Governance,” in which David offers steps to take and pitfalls to avoid when starting out on data governance. In “5 Key Considerations for Building a Data Governance Strategy,” my colleague Nitin Kudikala describes five data governance best practices and success factors.
I plan to add a few more posts to the category, focusing on specific Talend products that contribute to operationalizing data governance. Before I talk in detail about these tools and how they add value I feel it necessary to say something about data governance first, as a way of establishing a foundation on which to build.
In the preface to the children's tale "How the Elephant Got His Trunk" is this short poem:
I keep six honest serving-men
(They taught me all I knew);
Their names are What and Why and When
And How and Where and Who.
These questions, “What? Why? When? How? Where? and Who?” are fundamental to solution-seeking and information gathering. I’m going to use them to frame this introduction to data governance fundamentals. Part 1 covers the What, Why and Who. Part 2 will cover the When, Where, and most importantly, How. Keep in mind as you read that the "5 Ws and 1 H" are neither mutually exclusive nor as separate as their presentation suggests. They pop up together and continually throughout whatever journey to data governance you may take. Ready? Let’s get started!
The "What" of Data Governance
When talking with someone about a topic, it’s always worthwhile to confirm that all parties are aligned on what exactly they’re talking about, so let’s begin by establishing what data governance is. In a tie-in to the earlier poem, recall the parable of the blind men and the elephant, which originated in India (fig. 1).
There are many interpretations of this story, but the one that applies here is that context matters, and that the truth of what something is often a blend of several observations and impressions.
What Data Governance is vs. What it is Not
To that end, I offer these definitions from noted luminaries within data governance, including our own product team. These four sources are the wellspring from which I drew most of my content:
- DAMA’s DMBoK, via John Ladley: The exercise of authority and control (planning, monitoring, enforcement) over the management of data assets.
- Steve Sarsfield: The means by which business users and technologists form a cross-functional team that collaborates on data management.
- Bob Seiner: Formalizing and guiding existing behavior over the definition, production, and use of information assets.
- Talend: A collection of processes, roles, policies, standards, and metrics that ensure the effective and efficient use of information in enabling an organization to achieve its goals.
Within the definitions, I’ve bolded important recurring themes:
- Data governance is not an IT-only function—it’s a partnership between the business and technologists. Indeed, John Ladley, a noted data governance consultant, advises against the CIO “owning” data governance.
- Data governance is a bit of a misnomer, as what’s really governed is the management of data. More on this momentarily.
- Data governance is cross-functional—it’s not done in isolation but rather pervades the entire organization. Once it’s live, no single group owns it.
- Data governance views data as assets—not in some nebulous figurative sense, but as real, tangible assets--that must be formally managed.
- At its core, data governance is not about technology but rather about guiding behavior around how data is created, managed, and used. Its focus is on improving the processes that underlie those three events.
- Data governance is intended to be an enabling function, not exclusively a command-and-control one. Its purpose is to align data management practices with organizational goals, not be the data police.
Having established what data governance is, I’d like to say a few words about what it is not:
- It is not simply a project—it’s a program. What’s the difference you may ask? According to the Project Management Institute, "A project has a finite duration and is focused on a deliverable, while a program is ongoing and is focused on delivering beneficial outcomes." Projects have ROIs; programs are enablers—they’re required for other organizational initiatives to succeed. Let me hasten to add that the establishment, i.e., the “standing up,” of, data governance is indeed a project, but its business-as-usual state is as a program.
- It is not achieved through technology alone. It’s achieved through changes in organizational behavior. Technology plays a big part in getting there, but to succeed at data governance you need to establish and institutionalize the activities and behaviors the tool is supporting. It may seem strange that a person who works for a technology company is downplaying technology, but keep in mind my role as a customer success architect is to help ensure just that, and critical to the successful leveraging of any tool is the success of the program it supports.
- It is not a stand-alone department. As a program, it may have a Center of Excellence, but it’s not a distinct functional area. Instead, you’re putting functionality in place throughout the organization.
- It is not the same as data management. Management is concerned with execution, while governance is oversight—an audit and small-”c” control function. Data governance ensures the management is done right by establishing, maintaining, and enforcing standards of data management. Recall I mentioned earlier that data governance is a bit of a misnomer—that it’s really data management Data governance is to data management what accounting is to finance. There’s the governed and the governor.
The "Why" of Data Governance
The benefits of governing data are many, but quite simply, those organizations that govern their data get more value from it.
Here are a few macro-level benefits of DG:
- Data governance leads to trusted data. As Supreme Court Justice Louis Brandeis said, “sunlight is said to be the best of disinfectants.” By putting eyeballs on data, data governance enables better-quality data. When data quality goes up, trust in the data does too.
- Data governance enables benefits at every management level by enabling and improving the processes around the creation, management, and use of data. Strategic benefits include aligning business needs with technology and data, better customer outcomes, and a better understanding of the organization’s competitive ecosystem. Tactical benefits include data silo-busting, i.e., greater data sharing and re-use, and timely access to critical data. Operational benefits include increased efficiencies and better coordination, cooperation, and communications among data stakeholders.
- When deciding whether to do something, organizations commonly decide the value of that “something” by the extent to which it impacts the “Big-3”: revenue, costs, and risks. Governing data increases revenue, reduces costs and mitigates risk in manifold ways, but how it does so is highly specific to an organization. These particulars are identified when the business case for DG is developed, which I cover later.
The "Who" of Data Governance
There’s an old joke that asks “How many psychiatrists does it take to change a lightbulb? “Only one,” goes the answer, “but the lightbulb has to want to change.” Change—especially organizational change—is, of course, difficult, but with data governance, the juice is worth the squeeze.
I mentioned above that those organizations that govern their data get more out of it, so the glib answer to the “who?” question is “everyone.” Bob Seiner argues that “you only need data governance if there’s significant room for improvement in your data and the decisions it drives.” As you can imagine, he believes that description applies to most organizations.
Organizations recognizing data as a strategic enabler govern their data to ensure that data management responsibilities are aligned with business drivers. It’s also the case that heavily regulated organizations such as banking and financial services are driven to implement data governance to ensure they’re doing the right things the right way. If you’re data-driven, you should govern that data.
In this post, the first of two on data governance fundamentals, I’ve discussed the what, why, and who of a governance program. What data governance is (and isn’t), why it’s worth doing, and who should govern their data. In part 2, I’ll conclude with the when, where, and how of data governance. Thanks for reading!