Data Governance series Pt.4 - You only need to change... everything

Governance is the overall complex system or framework of processes, functions, structures, rules, laws and norms born out of the relationships, interactions, power dynamics and communication within an organized group of individuals. (Wikipedia)
This quote comes from the source of universal knowledge (Wikipedia, not The Hitchhiker’s Guide To The Galaxy). Let it sink in for a moment.
Let’s take this seriously, then the introduction of Data Governance means providing three frameworks for processes, structures, and rules, laws and norms for working with data. And by “working with data” from this definition, we can derive that this means the relationships, interactions, and communication involving data.
So, we do not only need the structures to define relationships of data in itself but also of the people interacting with the data. And the structures, the definitions of these relationships and interactions, are not enough. We also need processes for these. So, we cannot merely define who can use what data. We also need a process to enforce that structure and relationship. And we need a process to monitor and improve the rules that apply to the data.
Last but not least, the definition of governance also mentions, rules, laws and norms. Laws are typically externally motivated: GDPR applies to your business and you will have to find a way to be compliant. But rules and norms can stem from external sources (HIPAA or BaFin) or from internal sources (a code of conduct, a codex of morality when dealing with certain types of data or simply the wish to protect one’s reputation).
Now, some processes, structures and rules are always inherent when storing and dealing with data. No organization just lets its data lie around totally unprotected. But as the organization grows, the structures and the processes need to adapt to newer needs. They will have to evolve which makes clear that a process for adapting the processes and structures also needs to be in place.
Taking responsibility
Implementing governance always implies defining responsibility. Having processes and structures to govern your data only helps if there is someone in your organization who takes over the task of defining these processes, adapting them to new constraints and making sure they are actually followed every day.
When talking about data - and referring to the building blocks we defined in part 3 of this series, you need people with responsibilities for the building blocks. And of course, in a bigger organization with a larger data estate, you will not find that one person who takes this responsibility for all the data in your organization. Rather, you will need to find people who are in charge of certain aspects of data governance for certain types of data. Take, for example, someone who is in charge of a product catalog. They will feel responsible for making sure that the product data is entered correctly and for fixing wrong product information as it arises. It is unlikely that they will also feel responsible for fixing the customer data at the same time. And if they are in charge of making sure the product data is correct and complete that does not mean that they feel eligible for ensuring security of that data or technical aspects like load speed. So you will need to partition your data estate horizontally as well as dividing your data estate vertically into different areas of responsibility. The vertical partitioning is typically given by different areas of responsibility for the processes. It is easiest for people to take responsibility for the data they work with on an day-to-day basis than for data you rarely interact with.
In terms of horizontal partitioning, when introducing data governance, responsibility is typically divided into functional responsibility and technical responsibility where the technical responsibility is again subdivided into two areas: ensuring functional aspects of the data technically and actual technical implementation of storing and accessing data.
This means that there are usually three roles:
- The data owner is the person who knows and understands the data. They can define quality measures, rules to apply and define how certain issues should be fixed. They usually are also the ones who can explain the business-side of the data. They have business responsibility for the data.
- The data steward is the person who takes care of the day-to-day aspects of working with the data. They are the ones who understand the business requirements and are able to translate them into tangible technical concepts. They fix the data according to the rules and guidelines set by the data owner and they can explain the data on a more technical level than the data owner. They are the “data expert” for certain data.
- The data custodian is the person who knows the technical details of how the data is stored. They can administer and maintain databases and are accountable for the security of the data. You can think of the data custodian as the database administrator for the server where the data is stored. Of course for each data object that you want to govern, these three roles have to work hand in hand. The steward has to understand the business implications and the rules set by the data owner and has to translate them into actionable tasks for working with data that the data custodian can implement on the database or server level.
REMARK: In many organizations the responsibilities of the data custodian and the data steward are fulfilled by one person, so it is not uncommon to see only the two roles data owner and data steward in organizations. For larger or more hierarchical organizations, however, it is not uncommon to divide the responsibility among two individuals.
Breaking the silos
Defining these roles and ensuring that the individuals understand the responsibilities attached to each role is a big step for an organization implementing data governance. However, as we explained, a vertical partitioning of the responsibilities also takes place to ensure that the roles can actually live up to their expectations. Now, having data owners defining rules and finding the applicable regulations individually, is not an efficient way to structure the data governance efforts of an organization. Sometimes, decisions will need to be taken on a higher level or certain aspects of data governance should be considered a joint effort to ensure that a common goal is reached. In this case, a higher instance is needed. This can be a member of the C-Level of the organization (typically the chief data officer, CDO, or the chief information officer, CIO), but in practice it is better to establish a layer between the data owners and the C-suite, especially in larger organizations. If such a layer is required, it is typically a data governance board that takes joint responsibility for implementing the guidelines a CIO or CDO formulates and translating them into joint efforts for the data domains that the data owners can then implement together with their data stewards and data custodians for the data they are responsible for.

A typical constellation would be for the CxO to formulate a strategic goal like “we want to make sure that data problems do not affect our delivery processes”. Then the data governance board can look at data quality reports for the different data domains to find out where data problems occur. In the next step, they can formulate goals for the different data owners. This means the data owner of the customer data needs to ensure that the quality of the address data is improved, the data owner for the warehouse data needs to ensure that stock levels are always correct and the data owner for the product data needs to ensure that product dimensions are correct so that there are no problems in shipping the products. Each data owner can then look into the data quality for their data object and find out why the data quality is low and discuss with the data custodians and data stewards how to fix it. This can be as simple as asking team members to verify the correctness of the data and as complicated as improving the form where customers enter their addresses in the order process.
When these steps are taken, their success is measured by monitoring the data quality reports (sometimes even by defining new data quality reports) and in the end of course, also by measuring the desired business outcome, in our example the number of delivery issues.
It is, of course, important to notice that this is not a one-time-effort. As enterprises evolve, new business models replace old ones, new interfaces, products and customers appear, new errors can be introduced into the data pipeline and new efforts to reduce these errors need to be undertaken. And to notice, when a new effort is due, it is also important to introduce a practice of reviewing and monitoring the reports.
The things that (you) will change
By introducing these responsibilities and also introducing a chain of responsibility from the highest level in the organization down to the person maintaining the database server, you have introduced a shared accountability.
Every person working with or on the data will feel responsible for the data they work with. Furthermore, clear accountabilities will help these people to know when they can or cannot act. This means that the whole way of handling data throughout the organization will change.
You want to use data for a fancy new AI project? You know who to ask, you have a direct path to find out what the data can and cannot do and you can find out if the data is good enough for what you have planned.
You find a problem in the data when using it? You know who to contact to get it fixed.
In the end, returning to the imagery used in the first part of this series, introducing data governance in your organization will help you avoid spillage and dilution of your 21st century oil. And if spillage should happen, you will know who to inform rather than waiting for the problem to solve itself. Your whole approach to working with data will change and improve for the good.
And also for the individuals working with the data, taking responsibility in the new roles, life will be better. It is highly likely that they already had the responsibility and accountability of the data owner, data steward or data custodian, however without the authority to take decisions or change anything. Data governance clearly defines the boundaries in which they are free to act and gives them a liberty to do so and the peers with whom to discuss topics and take joint decisions. So also for these individuals, life will be better when introducing data governance.
For them, what feels like a big change in the first step will in the end be an improvement and only a small change in their daily work. From their perspective, the introduction of data governance can be summed up by a quote from Douglas Adams:
Mostly harmless (The Hitchhiker’s Guide To The Galaxy)
Read the whole series!
Photos:
- Green Field: Photo by Kai Pilger
- Silo: Photo by Muharrem Alper
A german version of this post can be found on the virtual7 Blog



