IT’S YOUR DATA, AND THIS IS YOUR BLOG

Welcome to the Collibra Blog, where CDOs, data stewards, and data citizens go to learn about true data governance.

subscribe

How Not To Do Data Governance

Share: Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInEmail this to someone

How Not to do Data Governance

Here at Collibra, we work with hundreds of organizations around the world on their data governance initiatives.  And it is often the case that our work with them is not the first time they have attempted a data governance initiative. After all, finding, understanding, and trusting data is not a new challenge.  But why did earlier efforts fail? And what was it about those efforts that contributed to that failure?

A number of common themes stand out. While many of these issues seem obvious when brought to light, it is often the case that they are not something that happened with intent. Rather, an approach was developed by trial, error, and expediency over time.  As your organization works toward improving access, understanding, and use of data, it is important to be on the lookout for these dysfunctional approaches.

The Police Attitude

In some cases, especially in regulated industries, the approach to governing data is driven by what you are NOT supposed to do with the data. Recently, regulations like GDPR have made this type of thinking more commonplace across a broad set of companies. While regulatory compliance and the associated governance activities that go along with that are crucial for your business, they should not drive the approach to overall governance.  This type of approach is visible when the requirements discussions revolve around “what we need to do to prevent…..”.  This statement assumes that the core deliverable from governance is some sort of restriction.

A simple shift from restriction to driving “what we need to do to enable within the guardrails” will make a huge difference. If the focus is on enabling users and helping business outcomes, then the project will have a much greater chance of success. In practical terms, this is the difference between the system “preventing users from emailing our data around” to “enabling users to share data safely”.

Assuming Data Governance is a Data Problem

Governance is not about data. Well, of course it is about data, but it is usually not about the data itself. The data is what it is. What is in question is its meaning, its validity, its quality, its trustworthiness, its appropriate uses – and the list goes on. In other words, data governance is about decisions about data. And the focus needs to be on creating actionable decisions. Obviously there may be data that is incorrect, incomplete, or otherwise flawed, and remediating those flaws may be part of the project. But first there needs to be a series of decisions about how those flaws impact the overall organization, and whether the priority of those issues makes it worth pursuing the solution right away. The governance program should be first and foremost about making decisions. And those decisions should be clear and documented. Also, any work that is done as a result of those decisions needs to be clearly linked with that decision and tracked as part of the overall progress and deliverables.

What often happens in these situations is that either the organization assumes that all data problems must be fixed (which is an impossible task), or that just because someone has the ability to resolve a problem also means that he or she is motivated to do so. Implementation is always the biggest challenge.  Automating the governance effort, and making it an easy part of people’s day to day activities, is crucial for driving broad participation.

Making Things Too Rigid

Your governance initiative has to be flexible at both the large and small scale. At the larger scale, different groups, teams, departments, and lines of business will have different approaches and different objectives for governance. Adopting a program requires that the program satisfy their needs, as well as overall organizational ones. Any approach, and any automation that supports it, must be able to encompass different and sometimes conflicting approaches simultaneously. This is a tremendous challenge to the people managing the governance program, but it makes governance easier (or even possible) to implement in the field.

The second piece of flexibility needs to be at the small scale level, around what data is governed. Everyone looks at the large transactional systems; clearly there is work to be done there. However, it is often the case that small, departmental systems that use desktop technology may be the drivers for a lot of organizational behavior. The governance approach needs to encompass these types of systems and their data, as well as the data from major ERP, CRM, and other enterprise sources.

Staying away from the police mentality, avoiding the assumption that this is all about data, and steering clear of creating rigid approaches will go a long way toward making your data governance program a success.

Dan is an experienced software industry expert, with broad and deep experience in the data and software markets. Dan began his career as a developer and product manager for BI and reporting software, moved into integration and middleware. He spent several years at Gartner as an industry analyst in the software space, covering data management, middleware, application architecture, and SAP. He has spent time at various software companies, and is currently Product Evangelist and Influencer Relations at Collibra.