Trying to sell Data Governance to corporate leadership is a rite of passage for data professionals…like the Kobayashi Maru test from Star Trek. You’re invited to pitch your proposal. You show slides with councils and processes and RACI charts. In the center sits a metadata repository and business glossary. Partway through you notice your executive’s hand surreptitiously wrap around the edge of the table. Was that a button click? A minute later the admin bursts into the conference room with an urgent matter that requires immediate attention. The end. Or perhaps worse, nods and handshakes all around at the end of the presentation, followed by months of nothing.
Stop trying to convince leadership to pursue Data Governance programs.
It’s not working.
You’ve probably noticed. And it’s been not working nonstop for decades. The headwinds seem to be even greater today, with the term “Data Governance” now encumbered with a perception problem. It’s like brussels sprouts. At least for me. I am convinced that I don’t like brussels sprouts. Repeated experience supports that conviction. Not only are many companies not doing Data Governance, repeated experience has led to a reluctance to even have conversations about it.
We’ve tried shrinking it, making it painless (that makes it sound like … discretion prevents me from saying what that makes it sound like), effortless, and minimally viable. Maybe we get some traction in a few areas, but enterprise-wide adoption, particularly among legacy companies, is small. We see it in surveys every year. Pursuing Data Governance initiatives is always a priority. For next year. AI has driven an uptick in adoption, but for the most part it’s a priority to be a priority, but not a priority to actually do.
In an earlier article, I talked about the need to stop putting Data Governance in a separate box in our analytical ecosystem architecture diagrams. Next, we need to stop talking about Data Governance as a discipline entirely. We don’t have boxes on our diagrams labeled Source Code Management, or Project Management, or Testing. No, these are simply components of our standard operating procedure. Data Governance needs to be treated the same way.
Incorporate the capabilities that comprise Data Governance into existing processes.
For many years I have advocated for a minimum set of data requirements: definition, expected content, security, and authoritative sourcing. A friend calls this “Minimum Viable Governance,” but this isn’t really a governance program. It’s a list of deliverables that should be produced as part of the development process. What’s the point? It’s the same as the point of the capabilities associated with source code delivery: correctness, security, deployment controls, traceability, etc.
Definition and expected content (i.e. Data Profiling) are required by testing. How can you evaluate the correctness of a data element if you don’t know what it’s supposed to contain semantically and syntactically? You can’t. Or at least you can’t do it properly. Like looking at the data coming in, comparing it to the data going out, and if it’s the same then declaring success. Too often that’s what happens. Security, including access restrictions, encryption requirements, and the like are mandated by the Chief Information Security Officer. Finally, it should matter to the data consumers that they receive data only from Authoritative Sources to improve reliability and avoid conflicts. If it doesn’t matter to your users where they get their data from, ask them if it matters to them where their drinking water comes from. Same thing.
From there, ongoing data quality analysis can be incorporated into runtime monitoring. Moving an application into production, regardless of deployment methodology, requires a standard set of activities, reviews, and certifications. Data must simply be added as another one of these requirements before application deployment can be considered finished.
But don’t talk with leadership about Data Governance as a discipline or its dimensions. Leadership doesn’t care about any of that stuff. They don’t care about data domains or encryption schemes or source data debates or data models or architectures or data type consistency. And for goodness’ sake, leave the DMBOK wheel in your cubicle or office or home or in the parking lot or in a field far away.
Focus conversations with leadership on outcomes and risks, and articulate the connections between cause and effect.
That’s what they’re concerned with. That’s why they’re on board with security. They recognize that the risk to the company and even to themselves personally can be considerable. The consequences of failure or negligence can be considerable. They understand the connection between cause and effect in that case. It’s like the idiot light metaphor I introduced a few weeks ago.
Be prepared to tell stories of what happens in your organization when data is incorrect or misunderstood.
You probably already have several.
Photo by Keenan_Loo from Freerange Stock.
0 Comments