What is data governance and why does it matter?

Broadly speaking, data governance is a set of rules that an organization uses to dictate how information is collected, stored, and accessed.

These rules support many different goals, but most commonly they are put in place either to protect data or to make it more accessible. And yes, these two purposes often work against each other. Poorly designed rules may enable one goal at the cost of the other, and when that happens, the organization as a whole suffers as a result.

Let's take a closer look at these two kind of rules and what they do.

First off, the rules that are designed to protect data. These work to block unauthorized access (hacking), prevent data loss, and protect data from corruption. For example, an organization may require each employee to maintain a secure login to company accounts and not share their password, to prevent unauthorized use of company information. Cybersecurity, SSO, automated backups, access logs, and data sync that prevents manual entry are all initiatives designed to protect data.

Then, you have rules designed to ensure the accessibility of data across the organization. These work to make information discoverable by the right people. Accessibility protocols may, for example, require employees to save files in a shared location rather than on their local hard drive. Metadata, tagging, data aggregation and centralization, cloud solutions and digitization in general are often in service of data access.

What does data governance look like in practice? Imagine data governance as an employee handbook, but for information instead of people. And just like a handbook that requires staff to punch in at 9:00am, you need a clock-in system to support the handbook, or nothing happens. In the same way, data governance requires data architecture in the form of a database or platform. Software systems make it possible for people to follow the rules.

What can go wrong with data governance?

Data governance is full of tradeoffs. Is additional security more important than convenience in your organization? At what point is this no longer true? Is it more important for executives to be able to slice through data, or is it more important for field staff to collect it conveniently? As mentioned above, security and convenient access often work at cross-purpose with one another, in the same way the putting more locks on your door makes it less convenient to open. Bad tradeoffs are the Achilles' heel of data governance. Below I've given two examples of the kind of common failures.

First, let's look at what happens when organizations succeed on security but fail on convenience, and why. These failures happen because the field of cybersecurity is more advanced than the field of data access. Data security has clear best practices that apply across many different organizational structures. It's consistent and scalable. Data access on the other hand, depends heavily on the workflow of different user groups, and is highly variable. As a result, good data access practices are difficult to standardize. Unfortunately, this can lead to data governance practices that hinder or even block access to the resource they’re designed to protect!

For example, let's take a company that recently spent $2 million on a custom database system to store lab data. The database uses 2-factor authentication (2FA) via text message. However, poor cell service in the building has meant users find 2FA so inconvenient that they avoid using the database at all costs! Instead, most conduct their day-to-day activities in Excel, and ignore the database entirely.

Another way data governance can go wrong is when one user group is served at the expense of another. For example, an executive committee has decided they need to analyze the company's equipment rentals. To aid this goal, personnel are required to submit a rental request form and log their equipment usage daily. Field staff grumble a the extra work, and compliance with the program is poor. So to ensure compliance, the executives require an approval for rental requests before equipment will be delivered. Unfortunately, the delays caused by the new approval systems mean teams are waiting uselessly in the field. Productivity takes a massive hit and project costs skyrocket.

These simple examples might just sound like bad management, but getting data governance right takes a lot of work. You need to look at your whole organization holistically, and have a framework in place to make appropriate tradeoffs.

Choosing an appropriate interface is also extremely important, because a bad interface can undo all your hard work planning and prioritizing.

A bad data interface makes it hard to find what you need, or inconvenient to use the information. For example, without a good data access interface, you may not have good filters and search capabilities. So the information is there, but you can’t find it. Or maybe you’ve found a set of 100 images you need to give to users for a project, but they can only see them one at a time. As a result, very few members of your group make use of the whole set. There's a lot to consider. Fortunately, we've broken it down for you below.

Where can you get started with data governance?

‍

Ultimately, data governance is a strategic exercise designed to maximize the benefit you can gain from your data while minimizing exposure to risk. In order to put rules in place to govern your data, you can start with these four questions.
‍

1. What kind of data does your organization use?

2. Where is it stored?

3. Who needs to access it?

4. How should it be protected?

The first two questions tell you what you’re dealing with right now. The last two help you make strategic decisions about how data can benefit your organization and what kind of protection it needs. Using these questions, you can perform a data and workflow audit on our organization, and start to prioritize between different goals and user groups. Expect long lists and long discussions. This is going to be a long process. You'll need to interview stakeholders, root out siloes, make lists of apps, connections, and file trees, and put all this in a format that can be reviewed by different groups.

At Fieldshare, we use a modular data framework to stream and connect different groups and data, but you can go a long way on your own with the right questions and simple documentation. The examples below give you more insight into how these questions can be put into practice.

‍

‍

Data governance in practice: a simple example

Jean is hired to conduct a data audit of ABC Widgets. To start off, she creates a list of the different kinds of data ABC Widgets uses. This includes financial information, employee rosters, storage locations, contractor lists, engineering information, customer contact information and order details, environmental data from manufacturing sites, logistics routes and an extensive database of customer feedback in the form of verbal interviews. Then, Jean asks different departments what kind of information they use. It turns out that several types of data are only used by one department. For example, the customer feedback interviews are only used by the marketing and product design groups, and would only get in the way of the logistics people. Through these discussions, Jean maps out who needs to access which data.

Meanwhile, Jean has also created a list of potential risks, following security best practices. She’s learned that login information for the customer contact database is shared between ten different people, and hasn’t been changed in five years. Furthermore, proprietary engineering drawings are kept on personal laptops, which travel to unsecured locations. There are no rules in place for encrypting communication between offices, even when sensitive employee data is being transmitted. Jean notes the potential legal and business outcomes of these security holes.

Jean now has a thorough understanding of the organization’s data, user workflows, and security risks. She then shops around for a database that can support the data types she’s identified, that offers an interface that can be customized for each user group, that offers security features to mitigate these risks.

Lastly, Jean puts together a proposal to show her user groups. The proposal clearly highlights where tradeoffs are necessary so the business group can assess whether the solution will be in line with the organization's overall goals. From there, refinements are made and implementation can begin.

‍

‍

‍

‍

‍