We have argued for many years that the surest way to kill off your well-intentioned data governance and data intelligence initiative is to make it part of your bureaucracy. Set up a formal hierarchy, replete with large committees whose members might change frequently? Check. Make sure that individual users have to pass all their ideas to a committee, which will then in all likelihood escalate them to a higher-ranking committee? Check. We're already on our way to killing this corporate initiative. This blog post will discuss the importance of taking a just-in-time, customer service, and help desk approach to data governance.
How can we make sure there's no buy-in? What if we talk about data governance as a way of protecting data from users, rather than as a way of empowering users? Sounds great. Finally, let's make sure that data governance personnel have no real authority over data at the organizational level, and, what's more, let's not come up with any consequences for units or individuals that don't follow the restrictive data security protocols we're trying to pass off as governance.
Could we do more, if we needed to, to bury this program? Well, as with any initiative that involves or touches on technology, we could make sure everyone recognizes they're being asked to do more work for the same salary, and we could also skimp on the training or ongoing support our people need in order to do whatever it is we want them to do.
Yes, I think we've nailed it.
Look, we see the charm and the potential of making a big deal about data governance, securing executive sponsorship, naming data guardians and data stewards, at least paying lip service to the idea that data is an organizational asset and thus worthy of regulation. But anyone who has worked for any length of time in an organization of any size knows that most edicts from management don't affect daily work or operations much, if at all, and that it is possible as an organization to both care deeply about some issue and also to do nothing, or next to nothing, about it.
The good news is, even if data governance initiatives have failed in your organization, they probably haven't failed spectacularly. More likely, they've fizzled out as key champions have left, or as key pockets of quiet resistance have further entrenched themselves, or maybe simply as other initiatives have come along and pulled attention away.
Chances are good, then, that even if formal data governance was tried at your organization but didn't take off, people still generally favor it. Everyone wants to make better use of data. No one wants confidential data leaked or exposed. Even those rogue corner-cutters you work with aren't necessarily opposed to regulations or policies, they just don't want to be bound by the ones that prevent them from getting their work done.
We seem to be seeing this more and more with clients. Some have been with us a long time, but now they are experiencing renewed interest in better governing data. Others are returning to us, saying they weren't really ready the first time around, but now they're better situated to take this work seriously. Potential clients that meet with us for data governance consults, or who want to kick the tires on the Data Cookbook, have a much better sense of where their data is problematic, and how inadequate their data governance has been up to this point.
Note that we said inadequate rather than nonexistent. Our observation, and we're not the only ones to make it, is that most organizations have been governing data to some extent all along. Someone makes decisions about what data to capture and where to store it, and most of the time there are policies regarding granting access to or otherwise sharing data. Many of our clients have staff who have gone above and beyond in terms of understanding their organization's data, and they can often explain not only which data exists where, but also what the business terminology around that data is, and how to reconcile discrepancies and inconsistencies.
If you have one person like that in your organization, you're lucky. (Maybe do something to hang on to them!) If you have more than one, you've hit the jackpot in our opinion. But relying on hitting the jackpot seems a little like saying you're saving for retirement by buying lottery tickets every week.
When we introduced the Data Cookbook, it was primarily designed as a tool to help business users and their technical teammates understand each other better, in large part by using the same terminology, and to support easier, more transparent documentation around requesting and providing data. Over the years, we have added more features, but it continues to be a tool where organizations catalog not only their data assets and products, but also their knowledge and usage surrounding those assets and products.
We have generally recommended something we call just-in-time data governance, by which we mean performing the specific data governance task when it's needed. What do those tasks look like? Sometimes in a meeting or conversation it becomes clear that two business units are using the same word or phrase to refer to different things! Well, let's see about coming up with two different terms and documenting what distinguishes them. A business glossary doesn't have to go live with every piece of data terminology already included. It can be built over time as people have conversations about data. Maybe someone is interested in looking at data they don't currently have access to or knowledge about, so someone needs to review and respond to that request or question.
Sometimes there is greater urgency around data governance tasks. For example, we need to provide a new dashboard or data summary to management, and thus we need to figure out exactly what management wants to know, and what the best way to provide that information to them is. As part of that work we could discover that we need new glossary entries, and/or that we might also need to annotate our dashboard (or whatever our product is). Maybe we'll see that data lineage needs to be reviewed. Perhaps during testing someone realizes the results are funky, and we need to open a data quality investigation.
All of those actions help data users and practitioners in the moment, or near the moment, when they need help. In a just-in-time model, people across multiple job functions collaborate on one thing, and they focus on aspects of data that matter to the business right now, and then they get back to doing what they were doing. We don't need all of their expertise and knowledge all at once. And the work of governing data is just one more aspect of the work everyone does every day.
We suppose it could be argued that many organizations have historically (and largely unintentionally!) practiced last-minute data governance, with predictably dismal results.
- Some users have access to huge swaths of data they have no business or, often, interest in using, while others with considerably more legitimate demands are denied access.
- Some data requests go through exhaustive requirements-gathering sessions to ensure everyone understands what's being requested and why, while other request are taken at what someone thinks is face value and too quickly turned into data products that don't answer questions or meet needs.
- Data elements are flagged as confidential or sensitive in a transactional system, but when they flow into a lakehouse that classification is shed along the way, and perhaps data circulates more widely than it should.
Focusing on just-in-time governance doesn't mean you can't still hold data governance committee meetings, or that people can't work on developing or revising policies, or improving process flows.
Policies and procedures and people with formal data responsibilities are necessary, and if your organization doesn't have those in place, it should put them in place, and pronto. But documents and diagrams and committees and working groups are not enough, especially if there's no way for that effort to be made quickly and easily available to users and consumers. The output of data governance work needs to be visible and accessible, which is where a tool like the Data Cookbook would be useful.
Whatever your tools are, however, the work of data governance is not complete until you have something like a data help desk. Ideally, your help desk has articles or training documents or policy summaries available all the time. And it has people (data stewards) --and AI bots, sure, why not--in place to produce and update these assets, and to answer questions from other people. And--and this is where most help desks in real life come up short--there is a path for users to ask and answer questions without having to know the ins and outs of the org chart or the names of the individuals on the BI team. Thank about your points of engagement with data governance.
- You develop and publish dashboards. You know people will have questions about them. Do your dashboards have an explainer? Is there a link I can click that enables me to send a question to the appropriate data team or business unit?
- Maybe you have a business glossary (you definitely should!). If I hear someone use some data-related terminology and I can't find that term in the glossary, how do I suggest a new term or an expansion of an existing one?
- And the help desk analogy goes even deeper. As a user, I know that data exists that would really enrich my understanding of our operations. How do I find out if that data exists at my organization? If I find out that it does, how do I figure out where it lives, and what's involved in sharing it with me? If we don't have it and I want to get it, what does that process look like?
Now, anyone who's encountered the help desk knows that answers aren't always immediately forthcoming, and sometimes they're not happy with the answers they do get. But without a help desk, routine activities can become complicated and time-consuming, and users experience significant losses in productivity and satisfaction. For too many organizations, even the most basic use of data has been unsatisfying and unproductive, and for a lot of users the "death by committee" approach to data governance and management has only made things worse. We think you should have a help desk for your data. And we'd be happy to work with you to set one up.
We hope you found this blog post useful. Also check our our data governance spotlight resources located at https://www.datacookbook.com/spotlights. IData has a solution, the Data Cookbook, that can aid the employees and the organization in its data governance, data intelligence, data stewardship and data quality initiatives. IData also has experts that can assist with data governance, reporting, integration and other technology services on an as needed basis. Feel free to contact us and let us know how we can assist.
Photo Credit: StockSnap_GEKK2UOHCY_WomenShaking_HelpDeskData_BP #1301
