What is a Data domain?

This is a very short and succinct question, and I thought the answer was likely to be the same. However, when I was sent this question, I was very surprised to see that it was a former colleague from my very first consultancy who submitted it!

I was taken aback at first because I thought to myself ‘surely, they would know the answer to this? on reflection I realised this is yet another example of how we data professionals are actually very bad at defining things and as data governance professionals,

that's even worse because we spend our time helping others and asking others to write definitions for their data and yet we so often don't define the terms we use well enough for others to understand. 

So, I decided that this was actually an excellent question and was definitely one that I should answer.

The first thing I did was look at one of my most commonly used reference books, the DAMA Dictionary of Data Management. This is an excellent reference book for anyone in data governance and as a DAMA member I would highly recommend it. However, on this occasion, it did take me aback.

I opened the page at Data Domain and was quite surprised at the definition it gave. It states that ‘a data domain is a set of allowable values for a data attribute’. However, that is not how I use the term and I think that is the perfect example of what happens as data professionals. We start using a term and people we work with start using it, it proliferates, but we're not necessarily using it for its original intention.

While a data domain is perhaps terminology more commonly used in data modelling and in databases, we use it a lot in the data governance world, but in my view, with a slightly different meaning. We clearly don't mean ‘a set of allowable values for a data attribute’ -that's very techy and data geeky and not at all the type of langue we would want to use when we're trying to talk to business users. So, what do we mean?

Well, when I use the term, I mean a logical grouping of data - something where we can tell where it starts, and it ends. From my point of view, I'm normally trying to find identify data domains so that I can identify data owners.

For example, you might call customer data a data domain. Or finance data, HR data, product data, supplier data. These are all ideas of logical groupings of data that all relate together.

It's then the work of data governance to work out the details of what is actually included in those domains… but that is what I, and many professionals that I work with, mean when we say, ‘data domain’.

Sometimes I don't use the word data domain. I talk in terms of ‘data set’, which is any logical grouping of data and I think you can use the words ‘data set’ and ‘data domain’ interchangeably. Just make sure that you actually understand what you mean when you use the term and explain to the business users that you're talking to what it means to avoid all confusion.

So, there you have it. That’s my definition of a data domain. I hope you find it useful. If you do, please help me on my mission to help as many people as possible be successful with data governance by sharing it on your choice of social media.

Do i really need data governence when i am doing data mangement?

This is a question that I have been asked many times over the years and my answer is always an unequivocal “yes”! Of course that is always followed up with the question “why”? And that one is a little harder to answer…

You can easily Google and find plenty of people that will tell you straight that you need Data Governance for Master Data Management but what they won’t tell you is why. I can understand why that might be the case and I struggled myself for many years trying to describe the relationship between the two until somebody challenged me to come up with an analogy. What I came up was a comparison to how we treat our own physical health.

Value your health = Value your data

If we are really healthy people, and we eat loads of fruit and vegetables and healthy whole foods, and everything we put in or consume is of really good quality and dense in nutrients, we are going to function really well, we are going to be at the top of our performance, we're going to be in a great shape.

However, if we start consuming only crisps and snacks, sweets, fizzy drinks and food with little to no nutritional value over time we are going to start getting sluggish and tired; we're going to start getting some aches and pains and perhaps some weird and wonderful symptoms that we've never experienced before, and that doctors can't quite put their finger on. The same is true if you do master data management without Data Governance.

Consider your Master Data Management repository is the human body… if you put good, clean, healthy data into it then it's going to work really well. You are going to have the right data in the right place, the right processes will work, you will make the right decisions on the data.

However, if you feed your system with rubbish, with poor quality data or missing data parts, or perhaps the wrong data in the field then you're going to start having things go wrong. Processes fall over and you are going to upset customers or suppliers. Production lines might have to stop because you don't have the right information or the right parts. Things will start to go wrong and unravel pretty quickly.

You may be thinking that seems a little dramatic but that is based on real life experience, and I have three scenarios that I have really genuinely seen happen as a result of people trying to Master Data Management without Data Governance in place.

Scenario One

In these instances, the data migration onto your new Master Data Management solution has gone well. You've had a team of analysts on their project who have worked hard to map the data, to migrate it, to make sure it was good enough quality to go into your new system. All goes well; you have a successful go live, everything is looking really good. But what I can tell you in these circumstances, if you haven't put in place data governance to protect and proactively manage that data, over time it starts going wrong.

People will start using fields for slightly different things, or people want to change things but there's no process for agreeing to do that, and so perhaps things can't get changed and users get frustrated. Or perhaps things do get changed, because you just ask the friendly person in IT and they agree with you and change it, but you cause problems for other people because neither of you understood the downstream impact of making that change. And slowly but surely, over time, without Data Governance in place your MDM solution becomes poor quality, and I can promise you, your users will start complaining about it.

Scenario Two

The second scenario I have seen is where the data migration to begin with never even happens. It fails and you fall at that first hurdle. In this scenario, there usually hasn’t been enough engagement with business users and the business hasn’t done enough analysis, or any data quality assessment.

That means we don’t even get to your successful go live that I was describing in the first scenario. In this situation, you can't even get your data to go successfully into the Master Data Management solution.

Now, in one real life instance where I came across this, it actually was the weekend before the ‘go live’ when they had a dress rehearsal for the data migration and they found so many issues with the data either not being mapped correctly, or it was too poor quality to actually go into the target system, that they actually abandoned it and the whole programme was put on hold with only one week to ‘go live’.

If you're in the middle of a Master Data Management Programme at the moment, you know as well as I do these are not cheap programmes, and this whole programme was put on hold for 18 months before they managed to get the business case approved to restart it. They had invested a lot of time and effort and significant amounts of money, and it nearly all got wasted! And of course they had all the additional costs of the rework needed to fix the data.

Scenario Three

In this scenario, the data is not quite as bad as in the second scenario so we can actually get it into the Master Data Management solution. It has some niggles and some problems, but surely it will alright?! I like to describe this as shoehorning the data into your new MDM system. We just keep pushing and pushing the data until it will eventually load into our new Master Data Management system. The attitude is that once it's in there, the business can fix it and it doesn’t need to be done as part of the project.

Well, the business won't fix it because they'll be too busy telling you how rubbish your new system is, because not only have you got the poor-quality data from the old systems in it, but you've probably made it worse by shoving it into a system that's set up and structured differently.

I even came across one instance where I was told that they had to turn off the relational integrity of the database of the new MDM solution, because the data was so poor that it would break the system and it wouldn't run if they didn't!

These scenarios are the realities of the type of scenarios that you are likely to face if you try and do a Master Data Management Programme without Data Governance. The first one is your best-case scenario; that you do a good job to begin with, and then it's a few years down the line before you start having major problems, but you start having niggly problems quite soon on. Scenarios two and three are quite catastrophic, and you really don't want to face them.

The Business Case

So why doesn't everybody just implement Data Governance at the same time as Master Data Management? Well, it usually comes done to issues making the business case for it and often a desire within the business for things to go quicker, or just a poor understanding within the business about the importance of Data Governance.

But the answer to that is simple: if you do Master Data Management with Data Governance, what you're going to actually have is the right people from the business involved in agreeing which data is going to go into your Master Data Management solution, what the fields really mean, and by agreeing which fields are the right ones to match and merge and you're going to have data quality rules agreed.

Therefore, you can actually measure the data and improve it both before the migration into the system, and afterwards. And you'll be laying the framework, the foundations for a successful data migration, and therefore a successful starting place for your master data management solution. I really, really believe that master data management and data governance are better together.

That’s great, but where do I start?

Start with identifying the data domains which are in scope of your MDM solution. It could be customer data, product data orsupplier data, but identify those domains.

Agree who's going to support Data Governance and MDM, because you want to agree who is going to support the master data system once it's gone live and you also need to agree who is going to support data governance - it will possibly be the same team.

Go back to your data domains where you have worked out of what is in scope of your Master Data Management solution and agree data owners. And then work with those data owners to create some definitions for the data and some data quality rules, and you'll be giving yourself a really good start for your MDM initiative.

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

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.