Nicola Askham Associates – Introduction of Rav Ubhi-Adams

Nicola Askham Associates – Introduction of Rav Ubhi-Adams

Introducing Rav Ubhi-Adams, one of my new associates who has almost 20 years’ experience in the curation and provision of data within both private and public sectors!

Read More
Comment

A Decade of Blogs

Ten whole years of The Data Governance Coach blogs

Yes, that’s not a mistake, you’ve read that right: I’ve been writing blogs as The Data Governance Coach for ten whole years!

I can’t quite believe it.

But when they say ‘time flies when you’re having fun’, that is precisely how I feel. Writing blogs on data governance for the last decade has been a complete joy.

Sometimes blogging can feel challenging. It’s either hard to get started or hard to keep up with - but the lovely feedback makes it all worth it!

I’ve absolutely loved being able to provide a free resource so everyone can take the next step (whatever that may be) with their data governance initiative. I never in a million years thought blogging from my little laptop would be so rewarding!

To celebrate hitting the BIG ten, I wanted to share my most popular blogs from over the last decade. Now, I won’t lie, this really was a lot of digging through the archives and some of these I completely forget even existed…

So, here goes.

1. Data Owners and Data Stewards - What is the difference?

A topic that has caused a lot of confusion over the years! In this blog, I addressed the difference between data owners and stewards and hopefully provided some much-needed clarification.

2. What’s the difference between Data Owners and Data Custodians?

This is a question that I frequently receive - and it’s an important one! Addressing roles and responsibilities is an essential part of implementing data governance. But how can we do that if we don’t know the difference between all the different roles needed?

3. What is the Difference Between Policies and Standards?

Over the 20+ years I’ve been working in data governance, this question always ends up in a (sometimes heated) debate! In this blog, I explored the difference between policies and standards and where on the earth the confusion comes from.

4. How To Identify The Right Data Owners

This one was inspired by my Free Data Governance Checklist where I talk all about how you need to define roles and assign responsibilities - and this blog covers where to begin.

5. Data Governance Interview - Jill Wanless

This was a very exciting interview that I did way back in 2013. What makes it even more exciting is that Jill is still a successful and senior Data Governance Practitioner!

6. Interview Questions For A Data Governance Manager Role

I enjoyed writing this blog so much as I got to collaborate with the data community to create this resource. Using LinkedIn we all came together and jotted down our best interview questions for a hypothetical Data Governance Manager role. I get so much feedback about what a useful resource this is, both for those hiring a Data Governance Manager and those preparing for interviews.

7. What do you include in Data Quality Issue Log?

Whenever I’m helping clients implement a Data Governance Framework, a Data Quality Issue Resolution process is at the top of my to-do list, so I thought I’d write a blog all about it and it has definitely proved a popular resource!

8. Make Sure you Follow These Practical Steps for Creating a Business Glossary

Way back in 2015, I teamed up with Collibra to teach a training course, and it seemed like the perfect opportunity to ask Carl White his thoughts on the best way for organisations to approach data governance.

9. Why are there so many different Data Governance definitions?

It’s a good question… I didn’t have a definite answer (and still don’t!) but I wrote down exactly why I thought that the data management community hadn’t pinned down any exact definitions.

10. When is a Data Quality issue not a Data Quality Issue? Part II

And last but not least, a collaborative blog on when is a data quality issue not a data quality issue, providing insights on the types of issues you will get thrown at you when you start doing Data Governance at your organisation.

When I first started blogging I wrote a list of topics for my blogs and was worried that I only had enough content for six months, I never dreamt that I would in the future be writing a post sharing my most popular blogs from the last ten years - make sure to leave a comment if you’ve had a favourite from the past decade that I haven’t mentioned above!

Thanks for reading, here’s to the next ten years!

Make sure you’re signed up to my newsletter, as you’ll be the first to hear about my latest blogs, videos, and podcast episodes, plus data governance tips, news, and events. 

By signing up, you will also receive my free report on the Top Data Governance Mistakes and How to Avoid Them.

2 Comments

Data Governance for Data Mesh

In order to set your data governance initiative up for data mesh, you first need to understand traditional data governance. What does it even mean? For me, functional data governance - at an organisation of scale - is not centralised in day-to-day decision-making. The central team just can't have the context or the knowledge across all the data to make good decisions quickly, if at all.

There absolutely needs to be a central team to provide support and knowledge and set federated teams up to succeed, they have a focus on friction-reduction and value-add work. To do that, you need to create standards and processes, but you need keep your frameworks, processes, and standards as simple as possible - no one single, all-encompassing standard please!

Data quality is key

As an example of functional governance, think about universal data quality standards. Every use case may require a different combination of data quality - why optimise for completeness if it's not needed?

Data Governance should be focused on helping business stakeholders define aspects of data quality and how to measure it - that way, data consumers can understand the quality of what they consume without learning different standards for each new data source, but we aren't setting data quality requirements that aren't helpful or useful.

Data mesh for the people

Data mesh is very much about the people side. That means the data governance team needs to collaborate with people outside the central team to iterate and improve upon your data governance approach. Feedback leading to improvements is necessary, the data governance team can't issue decrees from on high.

A part of data mesh that excites me is trying to solve for the age-old challenges of ensuring the data is the right data and that we get it in front of the right people to answer questions about the business - lowering friction to leveraging our data. What "right" means is always somewhat open to interpretation of course.

Whether you are doing data mesh or not, I believe data governance can't be about obstacles. That is how data governance got a bad reputation. The phrase should spark joy, not fear or revulsion.

Instead, it must be about making it easy for data consumers to find the right data and then being able to find the right people and documentation to help them understand that data. Governance is about providing low-friction ways to provide access and drive understanding of your data and how to properly use it.

Who does what?

One of the biggest lessons I have learned working on a data mesh implementation is that while in data mesh, there are a few new responsibilities that are called out explicitly, that might fall under different roles in different domains.

Some responsibilities may fall under a data owner in one domain and under a data steward or mesh data product owner in another. The differing role types are data owner, mesh data product owner, and data steward.

Find a standard setup for roles and responsibilities and then let the domains move responsibilities around as needed - don't make the domains come up with everything from scratch but don't hold on to your standard setup closely either. Everything in data mesh is about iteration and evolution!

When will I know my data governance is ‘good enough’?

No matter what, you won't get your data governance perfect when starting. Especially with something as immature as data mesh is right now. So have clear indications but nothing set in stone. Think about what capabilities are needed early to drive value: is that some complicated interoperability standards or some data quality definitions/measurement to enable people to understand and trust the data? Probably data quality definitions.

Every data governance approach should be tailored to the organisation, but it should start from a few building blocks:

  • Policy: as it mandates who will be required to do what and why? Domains just don't do data governance out of the goodness of their hearts.

  • Processes and standards: lay out what you are trying to achieve and why and then give people an easy way to achieve that. That drives consistency and reduces friction, a win-win.

  • Roles and responsibilities: it's very crucial to assign ownership and layout who exactly owns what; we've all been to meetings with no clear next steps, and they are almost always a waste of time. Who owns driving things forward? Be clear about it.

My top data mesh governance advice

  • Look for a relatively simple first use case. What has a high chance of success where you can also get some momentum and learnings?

  • Don't only look for the simple use cases early in your journey. That can lead to not being able to actually face the hard parts when they come. And with data, of course the hard parts will come.

  • Communicate early and often that you want to collaborate with people and that things will change. Solicit feedback and make constituents part of shaping your governance.

  • Make it clear the central team is there to help and not control - help around compliance, help with reducing friction, etc.

A general sentiment that has worked well for me in the past is telling people outside the data governance team: ‘if you don't get more value from data governance than you put into, we'll change our data governance frameworks’.

The data governance team may feel the pressure but if you aren't adding value with your governance, outside of regulatory compliance, why are you doing it? Teams will want to participate if you give them a reason to so find the value-add reasons to.

Final thoughts

If you are looking at data mesh as only making data more accessible and usable to existing data consumers… that's a big, missed opportunity. Data mesh can make data more accessible to more employees, driving better decisions. We need data literacy to get to that target outcome but implementing data mesh will lead to a lot of wasted potential if we don't expand the data consumer pool.

And don’t forget - you can actually drive buy-in for data governance. Whilst trying to sell everyone on upping your data governance game with the same message is not likely to succeed, data governance really does have value for all participants!

If it doesn't, you need to change your governance approach. So drive that home; tailor the message and speak to your organisations pain points and how you can help them address the pain.

Don't forget if you have any questions, you’d like covered in future videos or blogs please email me - questions@nicolaaskham.com.

Or you’d like to know more about how I can help you and your organisation then please book a call using the button below.

Comment

Five signs your Data Governance initiative is failing

One: There are different understandings of the terminology within the same organisation

Most organisations are full of lots of jargon and terminology which can mean different things to different people. It’s all very subjective and this is usually because of the culture within a particular organisation. The way the various terms are applied within organisations can vary their meaning. And that’s ok - but you should also be wary of it.

Data Governance takes a long time, and particularly in the early phases, it takes quite a lot of effort. Therefore, it is understandable that people look for ways to quicken this process up. One of the ways I am often asked if this can be done is by fast-tracking the creation of items like a data glossary by using standard definitions.

However, it’s not a part of the process that can be skipped or glossed over, so to speak. Part of the reason for this that organisations, even those within the same industry, very rarely use the same terminologies in exactly the same way. This means there is no bank of standard definitions to pick and choose from; what works for one client, will very rarely work for the next. Only by creating your own data glossary can you be sure that everyone fully understands the definitions within it.

Two: Disengaged stakeholders and a lack of budget

Another reason many data governance initiatives fail is a lack of support at a management level. If senior management does not buy into the benefits of data governance and only sees the associated costs, an initiative will almost never succeed.

First, there is a danger that the required processes won’t be executed correctly. Additionally, because of costs, critical improvements may not be implemented, or the initiative may need to end prematurely.

Sourcing the budget needed for an initial data governance initiative is easier today than ever before because there are regulations that justify it, for example the GDPR. However, it is crucial that management also makes sufficient long-term resources available to finance all roles and functions required for robust data governance on an ongoing basis.

If your stakeholders aren’t prepared to put their money where their mouths are, this would indicate that the initiative is not being taken seriously enough and its value is not understood.

Three: Only implementing Data Governance because of regulations

If the pressure to implement data governance comes from a regulator, then it is very tempting for organisations to look at satisfying the absolute minimum required to keep the regulator happy. This is a big mistake, as in the long run, these organisations end up doing more work than if they properly implemented data governance in the first place. They also miss out on all the business benefits that come from improving their data management practices.

The tick-box approach to data governance is normally task-focused and completely ignores the people involved. They issue a checklist of things that need to be accomplished and issue threats if the tasks are not completed. As a result, people go through the motions because they must, and they see no real benefit to their day-to-day job.

As a consequence, it’s going to be hard to embed your data governance framework within your organisation and you will always be chasing people to make sure that they have complied with the regulations.

Regulators are notorious for moving the goal posts, so if you have not embedded data governance into your organisation, every time they change the regulations and update the checklist you will probably move back to square one, which means implementing the new checklist.

Four: No data quality issues being reported

If data users aren’t reporting data quality issues, this indicates that either people don’t know about your process to investigate and fix issues, they don’t think you will be able to make a difference (maybe based on years of no-one being interested in making data better) or perhaps they don’t understand that the manual workarounds they have to do every day/week/month are the result of poor data quality and everything could be improved and streamlined if the underlying issues were addressed.

Whatever reason, it all boils down to communication. And if you’re failing to communicate with your data users your data governance initiative is sure to fail.

Five: It’s not being talked about outside of IT

The key to data governance success is getting stakeholders to take ownership of their data and take the lead in data governance initiatives. When I perform a data governance health check for companies that are running into trouble, it is fairly common for IT to be leading the data governance initiative.

This is always for the best of intentions. Even though IT does not own the data, they understand the implications of not managing data properly, and therefore they are often the first people in any organisation to realise that proper data governance is needed.

Businesses often leave IT to deal with data governance because they confuse the infrastructure with the data. If you work for an organisation that still believes that IT owns the data, then assigning IT to run the data governance initiative may seem logical.

However, an IT-led data governance initiative can be fraught with problems. True data governance will only really happen once the business has taken ownership of their data, and an IT-led data governance initiative makes that more difficult.

In my experience, IT-led initiatives are too focused on tools that do things like cleansing data. This is understandable, as companies tend to get their advice from IT vendors who are in the business of selling tools. The problem is that unless a business changes the way that data is captured at the point of entry, the quality of the data will never improve.

Don't forget if you have any questions, you’d like covered in future videos or blogs please email me - questions@nicolaaskham.com.

Or you’d like to know more about how I can help you and your organisation then please book a call using the button below.

3 Comments

Guest blog - Data science and data governance: collaboration for trustworthy data insights

Data scientists are storytellers. They gather data from a variety of sources, clean and combine that data, and use their programming, math, statistical and analytical skills to interpret that data. Data scientists can help businesses understand customers and market trends, forecast sales, improve processes, and help to make better, smarter, faster decisions. But the data driven results depend on good and reliable data. Advanced data models and algorithms are only as good as the data they are applied on. Without good quality data, even the best models and algorithms fail.

Strong Data Governance policies and practices ensure valid, quality data and thus ensure that data analytics and data science methods can arrive at meaningful and trustworthy conclusions. Collaboration is key for the best results.

As a data scientist, you can expect to spend up to 80% of your time cleaning, transforming, and checking your data. A discovery and understanding stage is important, but it should not be so prolonged. If the data scientist is confident that the data has been verified by the business, it is consistent and compliant with regulations, then they can focus on bringing out the stories within the data rather than double checking its content. Data governance plays the key role of validity checking to prevent confusion over the data or misunderstanding and thus meaningless data science results.

What can a data scientist do for your business? Visualisations can be produced to understand and extract insights from data about the business and its customers. Machine learning (ML) models can be developed to continuously capture insights to help make more informed business decisions. Past performance can be studied and predictions made.

One example of the use of ML is the work I carried out for a research hospital in Rome to understand public opinion. Vaccine hesitancy was identified as one of the top threats to global health by the World Health Organization (WHO) in 2019, with the growth of online communications and misinformation about vaccines an increasing area of disquiet. The hospital wanted to understand people’s stance on the subject of vaccination. Concerns had been raised about the low maternal vaccine uptake in Italy. Social media is increasingly being used to express opinions and attitudes, so we decided to use Twitter as our source of data. I trained and fine-tuned a natural language processing machine learning model to classify the vaccine stance (promotional, neutral, or discouraging towards vaccines) of Italian tweets. This is now used on a web platform for medical professionals and policy makers to monitor vaccine stance in almost real-time.

Another example of applying data science to a business is the work I have done for a local gin distillery, analysing sales data to predict future sales and profits. Data visualisations and predictions were an important part of the business plan for explaining the business and its potential to investors.

Data governance can deliver high-quality, trusted, and compliant data. Data science can deliver insights into that data. Collaboration between data governance and data science professionals increases the level of certainty in the results, models and predictions so you can make the data-driven decisions for your business with confidence.


The author: Susan Cheatham is an independent consultant in data science and data mentoring. She gained her technical data skills and physics PhD from the European Centre of Physics Research (CERN). She enjoys communicating and sharing knowledge.

2 Comments

What is Data Wrangling?

If you are a regular follower of my videos and blogs, you will know that one of my key aims is to help explain the vast - and sometimes confusing – amount of terminology that is found within Data Governance.

Often things have different meanings depending on the organisation you work within or can even vary from person-to-person, which is why I want to say first and foremost: there is no such thing as a stupid question! The person who sent me today's question actually apologised for asking it but I'm a great believer that there should be no such thing as a stupid question when it comes to Data Governance.

If you feel that you need to ask the question, then that means that somebody hasn't explained it well enough to you. So, the question we’re dealing with in this blog is not a stupid one.

What is Data Wrangling?

Now, the person who sent me this e-mail felt stupid because they felt that perhaps it was something they should be doing, but they didn't understand what it was, and they didn't want to look stupid by asking.

The short answer is this: yes, the chances are you probably do have to do Data Wrangling in your job, whatever your job is, but whether you should be doing it is a different matter entirely.

I've actually heard the term Data Wrangling quite a lot over the past year or so, and I think people are using it to describe the situation where data isn't perhaps where you would like it to be, or it isn't good enough quality for you.

So, what they tend to use the term to mean, is the getting together of data from various sources and doing something to it so that you can use it.

What could that be? Well, it might be amalgamating it into a spreadsheet; it could be cleansing and fixing the data; it could even be running around various people asking them to fill in the gaps that you've got on your spreadsheet.

That all means that unfortunately, Data Wrangling is unfortunately a necessary thing if you have poor quality or missing data, and is very common in organisations that perhaps haven't yet got a proper Data Governance initiative in place or are very early on in their journey.

It’s part of the problem – not the solution

Data Wrangling also tends to be used to describe the frustration that you have of doing these activities, of bringing together data from disparate systems or spreadsheets, or fixing data before you can do what you should do with it.

Therefore, I don't think Data Wrangling is necessarily a good thing. It’s definitely not a skill you should perhaps aspire to have – what you should be aspiring to have is complete and accurate business data with a proper Data Governance initiative in place. Data Wrangling is not the solution – it’s a temporary fix for a much wider problem within your organisation. Especially if you find yourself having to do this regularly. At that point you should really stop and ask yourself ‘why am I having to do this so often – what data quality issues is my organisation facing and how can we find long-term solutions to address them’?

Data Wrangling is just something that unfortunately we have to do a lot of in our jobs at the moment, but it should be one of the things we should be looking to eradicate by having Data Governance in place.

Get in touch

Don't forget if you have any questions you’d like covered in future videos or blogs please email me - questions@nicolaaskham.com.

Or you’d like to know more about how I can help you and your organisation then please book a call using the button below.

2 Comments

Who Owns the Data that Appears in Your Reports or Dashboards?

If you’ve ever read any of my previous blogs on data ownership, you’ll probably know that I feel quite categorically, from my many years of experience, that you really cannot have more than one Data Owner per data set. It really doesn't work, and I don’t recommend you try it.

There’s no exception to this rule - believe me, I've been there, done it, still have the scars... What I believe you need to do is find one senior person within your organisation who is going to take overall accountability for that data, wherever it is within your organisation.

So hopefully, from that you're getting an inkling of the answer to today’s question… ‘Who Owns the Data that Appears in Your Reports or Dashboards?’

Well, I believe quite strongly that if the data that is showing in that report, is the same data as it has always been - it has not changed and is therefore still the original data, then it is owned by the same data owner who has always owned it!

For example, if you have a data owner that owns customer data, and you have a report, or more likely a whole suite of reports that contain customer data, then the owner of that data is still the customer data owner.

Now of course when you have reports, there are going to be multiple different data sources in them. And you might have many different data owners per report. This is why quite often when I'm rolling out a data governance framework, I don't make it an official Data Governance role, but I work with the BI or MI analytics team - whatever you call yours - to determine a role called Report Owner.

So, whoever first asked for that report, whoever gave you the requirements and then signed off on them. They are the report owner, and they are the people who know why that set of data was brought together in that report or dashboard and why it is useful – but, crucially, they don't own the data in it.

If there is a problem with the quality of any of the data in that report, then you would follow the normal data quality issue resolution process and you would go back to the original data owner or owners to get it fixed.

Now, there is sometimes a slightly different alternative and that is in a case where the data has been changed. I see that a lot where organisations are creating models or the report in some way aggregates data or transforms it performs a calculation.

So according to the data ownership principles I have already laid out, this means the data has changed. It's no longer the data that it was originally. It is new data. If you have performed any calculation or transformations to the data and created something else as part of producing that report or dashboard, then this is now new data, and the resulting data should have a new data owner.

If it was closely related to the original data, it may be the same data owner, but it may be somebody else. In those instances, it's often the consumer of that data - the person who has given you the requirements for what that calculation or aggregation is – they would be the data owner of the new data.

Now, if you have maybe two or more interested stakeholders interested in the same data set, what you must do is get them together and draw a conclusion as to who is the most appropriate person to own it and the other to be key stakeholders.

Another even better option is to consider splitting that data set into subsets until you find a way of splitting it so that everybody's happy that they are owning and responsible for the data that they really should be. Doing it any other way, I can guarantee you, is not going to work.

It's going to cause you loads of pain and is going to result in people telling you that this Data Governance doesn't work or doesn't help them. So, I really, cannot stress this enough - you should only have one data owner per data set – and that includes any data that you may use and/or change to form part of a report or dashboard!

Don't forget if you have any questions you’d like covered in future videos or blogs please email me - questions@nicolaaskham.com

Or you’d like to know more about how I can help you and your organisation then please book a call using the button below.


Comment

How to get your business stakeholders to want and use a Data Glossary

Getting a data glossary in place can take a lot of hard work and effort, so it can be particularly frustrating if/when your business users don’t truly appreciate the value it brings and either don’t want to help you build it or don’t use it when it has been built.

Why are you creating a Data Glossary?

A big reason why such a scenario happens is because we often ignore why we are creating a Data Glossary in the first place.  By this, I don’t mean you should have one because you are implementing Data Governance. I mean answering the question why your business users should want and use one?

This doesn’t mean rattling off a predefined list of benefits, but rather taking that deep breath, stepping back (figuratively speaking) and working out why exactly you’re building a data glossary in the first place and for who.

Why does your organisation need a Data Glossary?

I’m often asked how to engage business stakeholders (which you should be doing right from the start of your Data Governance initiative) with your data glossary. To do this you need to understand the value a data glossary would bring to them.

And this message needs to be tailored to each group of individuals you’re speaking to, as one reason why won’t work universally across different stakeholders. These messages need to be specific for your each of your groups of stakeholders, however, here’s a couple of benefits to give you some examples when seeking to communicate the value of your data glossary.

For instance, the faster development of reports is a common theme as a lot of time and effort often can be wasted creating reports without agreed definitions. This can result in ongoing disputes, wasteful meetings and, ultimately, poor decision-making with damaging consequences for an organisation.

Another potential benefit of a data glossary can be identified in the quicker implementation and deployment of new systems. Whether building a system from scratch or implementing a bought package, decisions need to be made as to the data which will reside in the system and this will result in lengthy debates on the exact definitions of certain terms like ‘customer’. Wouldn’t it be nice (and much quicker) if those debates happened just once and the agreed definitions logged in the data glossary to be referred to in the future instead of repeating this for each new system?  And of course this approach inevitably results with different systems having slightly different definitions of the same thing! That is not going to help data integration and analysis...

A data glossary is invaluable for streamlining definitions across an organisation and ensuring a common understanding over data and how it can or should be utilised.

A data glossaries can act as a cornerstone of proper, consistent communication – the value of this speaks for itself.

Ah, you say, but we already have a business glossary but our business users are not engaged with it. How are we supposed to communicate value?

Simply put, don't let the fact that you already have a data glossary stop you from taking the approach detailed above. You simply have to work out what value it will bring and communicate it. This would mean identifying what data challenges your business users are facing and to use these examples to demonstrate how a data glossary can solve those challenges.

When having conversations with your business stakeholders, it is common for them to get confused between a data glossary and a data dictionary. If that is a challenge you are facing this blog will help you explain with confidence. Read it here.

And you may want to share this video with the people you want to write definitions for your data glossary to make sure you get good quality useful definitions to put in your data glossary. Click here.

If you are struggling with engaging your business users, please book a call using the button below to find out how I can help you:




Comment