Data Governance is a loaded topic. Most people want to stay away from it. Junior data management consultants aren’t excited when they hear that they’ve been staffed on a data governance project. To the point that they really try to avoid them all together. This doesn’t just apply to junior consultants, it is a market wide trend that reaches all the way up to executives. Many articles have been written about how DataOps is the new data governance and that a data governance 2.0 is needed. I don’t think there’s anything wrong with data governance, but that the implementation should be more practical. In this blog, I give three practical tips to approach data governance.
In their book Extreme Ownership, Leif Babin and Jocko Willink discuss the difference between ‘blue work’ and ‘red work’. They explain that blue work is about thinking and planning, while red work is the doing and executing. They go on to explain how the two shouldn’t be mixed, because when you are in a red work mode, you don’t really have the mental space to do blue work. This is why it is unfair to expect red work people to do blue work at the same time.
Data governance versus Data Management are the same: data management is red work and data governance is blue work. Data management is about the doing and executing and data governance is about the thinking and planning. That is the reason why junior data management consultants don’t like data governance: they want to be doing and executing. Data governance projects are generally very high level and contain lots of policy documents without truly getting anything done (except for lots of lonely writing).
I was an odd duck: I’ve greatly enjoyed data governance projects from the start. But that is because I really enjoy blue work. I like to think about the relations between concepts. I am a bit idealistic in that sense. However, I am also result-driving. Thinking and planning is good – but only to a certain extent. To be practical, I keep the blue work side of data governance as short and interactive as possible. Then it’s action time. 3 very practical steps I’ve applied in previous projects are outlined below:
1. Enrich your job descriptions with data responsibilities
This may seem trivial, but it is a fantastic quick win. Data governance is about establishing roles and responsibilities. Traditionally, this is done by establishing a data governance framework which is full of different roles, levels and meeting structures. Before getting all of that approved by stakeholders, months have passed… And truth is, we really don’t need more meeting structures. Don’t we have enough of those as it is already? The practical way is to start small. Integrate data into existing roles and meeting structures. What does that mean? In your job description, your responsibility for data should be formalised. So this is literally adding one or two responsibilities to a list. A sales person is responsible for correctly entering a relations’ name and contact information into the CRM system. The sales manager is responsible for periodically checking the accuracy and completeness of this information and asking employees who have not done this correctly to fix it. This is part of their job. It is formalised. If employees don’t live up to it, then this is a negative point in their performance review.
2. Don’t get lost in a meta-exercise
Beware of getting lost in the meta side of things. If you’re documenting information about information without access to that information… What are you doing? Check yourself for a second. I am all for structure and quality documentation, but make sure that it truly adds value. Only spend time on defining attributes that are used often. I once tried filling out a data catalog demo environment to illustrate how it works… I gave up after a few hours. It was way too much work, and no fun at all to do by yourself. Create a definition for something people actually use, and you’ll receive plenty of feedback. There is no point in documenting things that no one uses. It doesn’t motivate anyone and will definitely scare people off. If your data catalog is just a meta-reflection of your data landscape, reconsider whether it adds value. There are solutions that also index the actual content of your data. They add way more value than a metadata catalog because they show what’s inside your data. And that is what matters at the end of the day: the content!
3. Democratise data modelling
A big element in a common language and data definitions are your data models. This is a concept that also tends to scare people off, yet pretty much every business person makes drawings to explain what they’re talking about. Drawing out how different concepts relate to each other does way more than a definition in a business glossary no one uses. As for your physical data models, have a look at which data attributes appear in multiple tables and/or systems. If they do – do they have the same name? This is such an easy thing to implement and when doing so it helps avoid so many miscommunications. Work with sketches too. When development has to create something quickly and there is no formal data model yet, allow them to create a temporary sketch. This way, you don’t slow down the process and do have documentation of existing solutions. The sketches can be used to integrate temporary solutions into your permanent solutions. Plus, it really helps break down business requirements.
Data governance doesn’t have to be a loaded concept if you approach it from a practical point of view. Make sure you aren’t asking people who are busy with red work to do blue work at the same time. I hope these three tips help you out!
