 Hello and welcome, my name is Shannon Kemp and I'm the Chief Digital Manager for Data Diversity. Thank you for joining the latest in the Monthly Webinar Series, Data Architecture – I can speak today – Data Architecture Strategies with Donna Purbank. Today, Donna will discuss master data management, practical strategies for integrating into your data architecture. Just a couple of points to get us started. Due to the large number of people that attend these sessions, you will be muted during the webinar. And we very much encourage you to chat with us and with each other throughout the webinar. To do so, just click the chat icon in the bottom middle of the screen to activate that feature. For questions, we will be collecting them via the Q&A in the bottom right hand corner of your screen. Or if you like to tweet, we encourage you to share highlights or questions via Twitter using hashtag DA Strategies. As always, we will send a follow-up email within two business days containing links to the recording of the session and additional information requested throughout the webinar. Now, let me introduce to you the series speaker, Donna Purbank. She is a recognized industry expert in information management with over 20 years of experience helping organizations enrich their business opportunities through data and information. She is currently the managing director of Global Data Strategy Limited, where she assists organizations around the globe in driving value from their data. She has worked with dozens of Fortune 500 companies worldwide in the Americas, Europe, Asia and Africa, and speaks regularly at industry conferences. And with that, let me get the floor to Donna to get today's webinar started. Hello and welcome. Hello. Thanks, Shannon. Always a pleasure to do these. So yeah, I see a lot of familiar faces on the attendee list, and I appreciate those who join fairly regularly because as you may know, this is a series. So we have started in January with a good wide range of lineup, and they are all on demand. I know that's always a question from folks. So any of the past that may be of interest to you are on demand. In this webinar, when we are finished, we'll be on demand not only with the slides but with the recording, and Shannon and her team send that out after the event. So today's topic is on master data management. And more importantly around master data is practical strategies for integrating master data management into your wider data architecture. And without further ado, we'll get started. So you may have seen this from the abstract, but really what is master data? So it has to do with getting that view of that critical data around customers and products. And a lot of people want to do that, but they may think that's overly complex, right? Doesn't that seem too hard? And I've heard a lot of my customers this year say that it seems like something I want to do, but isn't that just too hard? Well, it is. Again, it can be hard, but if any of you do it right and you pick the right approach, the right architecture, and importantly, the right governance, you can really see some success, and we'll show some success stories around that. And so, again, you may have seen this. This is a framework we use in my practice, and it's got some good feedback. One of the reasons I use it is that, you know, before you do anything, you look at the business strategy. And we'll talk about that specifically with MDM, and you'll see that MDM is listed there as a box, but it's part of a wider strategy. So if you don't know why you're doing master data and it's not aligned with your business, it may have issues. If you're not using governance as part of your master data strategy and you don't have the right stewardship around that, that's going to have issues. If you don't understand your existing data assets and the integration and the metadata around that, those can also be a challenge. And then, you know, what data, what information are you mastering, right? Is it in data sources, in CRM systems, is it in PIM systems, et cetera, et cetera, et cetera? So you really need to look holistically at MDM as part of a wider strategy and go from there. So just to start, basic fundamentals. I'm an architect, so I always like to kind of see core fundamental principles. You know, when we think of master data, that's the core entities of the enterprise. So your customers, your prospects, if you're a, you know, a government, it could be your citizens, right? If you're a manufacturer, it could be your suppliers, your sites. Also the hierarchies around that. And I took these definitions from Gartner off there, sort of technical data dictionary, but I think I like them, they're a nice simple way to understand what we're talking about when we're talking about master data. And then master data management, it could be just sort of obvious it's the management of master data, but it is a bit more than that. It's not only getting the uniformity and accuracy around that information, but it's things like the stewardship. Who's the one that's going to check this golden record? Make sure it's right. What business processes around that? What's the accountability around these shared assets? Because they really are the assets of your organization. So if you're thinking of something like customer and you're a retailer, not much more is important than that, right? But there is other things that are important, your suppliers, right? Your products. So it really is getting a center core around these core information assets. So many of you may be aware we did a survey last year on trends in data architecture and master data management, of course, was one of the trends we took a look at, right? So a lot of talk about master data management, it is a hot topic in the industry, which is one of the reasons we chose this. Who's actually doing it? And we noticed from the results that over 65% were actually actively pursuing an MDM strategy at various stages of maturity. And we'll talk about that. But I think that's a fair percentage. And the more interesting thing is that it is on the rise. And I find it interesting because almost all of the topics that we pick in this series, whether it's master data, whether it's data modeling, whether it's metadata, we're seeing an increase in those, even though you may say those are sort of foundational and they've been around for a long time, isn't that the old stuff? Well, what's old is new again. So I'm actually seeing a massive resurgence in my practice with MDM and people being interested in it. So when we ask a little deeper in the survey about, okay, you're interested in MDM, but where are you on your MDM journey? Because it is a journey. MDM is not a project where you start and then you're done in a few weeks or a few months and then it's done. It should become embedded in your business processes and your way of working and into your architecture. So we ask the further question of where are you? Are you actively using it? But in the initial stages, which is sort of that lower level of maturity, are you at a high level of maturity, or are you just beginning? And you'll see that the largest percentage there is really just beginning. Very small percentage was not considering, and then kind of a few, I'm not really sure. But so I think that again is showing that trend of people just beginning this journey and wanting to know more. So we're going to open it up to you in the panel. I'd be curious where you are in your MDM journey. Are you in your early stages? Are you doing it for a while? Are you in the process of beginning, but have not really implemented, or are you not considering it at all? So I'm going to press it to Shannon to kind of open up the survey and see where you stand. The poll is open. All right. I do need some jeopardy music for this. I would sing, but yeah, you won't want me singing. And we've got a few people responding, but... Is it slow? I think people need to click, or it should be obvious. I hate to find it on my interface, but... Yeah, they've changed things around a little bit, but looks like we've got some good. Looks like it's going to be a tie between the first and third ball as A and C. Oh, and the poll is closing. It is calculating. Drum roll, please. Excitement down. I wish it calculated much faster, but it doesn't. I know Shannon tries to convince me not to do these polls, but I'm a stubborn old lady, and I keep doing it, but I'm curious. I like to make the interaction as you can see. All right, here are the pollers. All right. You are right that sort of a lot of people are in the process of beginning or in the early stages, which may be self-defining, and it may be why you are joining a webinar to learn more about it. But that also helps me in the context as we go through this webinar to kind of see where you are in your stages. So thank you for looking at it. Looks like a couple people are in the high stages. So I know there's always an active chat during these, so anyone who is actually in the high stages of doing this and wants to share their experiences, people ask questions, please do that as well. That is one of the benefits of dataversity. There's always great feedback between people in nice Q and A. So without further ado, moving along, I can't seem to be able to move my own slide. So one of the main reasons of what is MDM, one of the classic ones is that single view of customer and kind of getting that single view. And I like to kind of tell that through a story. So do we even understand our customers? So one of it is just, can we get a single record of Stefan Kraus and what age he is? But you can also sort of start to link that with other things. What is his address? This gentleman lives in Pontresina, Switzerland. He's a ski instructor. So maybe some more interesting things. This is a skiger company. He's been in our loyalty program for a certain amount of years. He has purchased a certain amount of gear. He buys all online on his cell phone and he prefers text messages rather than figure a physical snail mail. And he skiers in the call. He finishes the Angadine ski marathon in 2015. So we kind of know some things about his purchasing patterns as well. So you can get a lot of very interesting information about your customer as well as some sort of the basics. But really where that comes in, and I've had several customers in the recent years that I've been working, that have had this very similar scenario. So when we talk about customer, there's so much we could do to get that full view. We could do social media analysis and we can get credit history and all of these things. But if you can't get that core golden record of who is Stefan Kraus, none of that else matters. So in this example, is it Stefan Kraus who's a ski instructor in 31? Or is it Stefan Kraus who's a banker in 62, right? The same name, but one maybe is a father, one is a son. Maybe there's no correlation at all. So just getting that match is key. So why is that important? Well, Stefan Kraus, he's a banker. He lives in Zurich. He actually doesn't ski or do anything at all, but he makes a lot of money. So he actually has purchased more gear than the ski instructor, right? Because he has a lot of money and when he spends, he does it on holiday. He likes to buy it in a store and he wants a piece of mail. And he doesn't really use the equipment other than staying warm because he watches football. But he's been a member of your loyalty program but not very active, right? So they're all very interesting insights but it all comes back to, do I even know who my customer is? Which Stefan Kraus is it? And we probably all have those stories of getting that wrong or getting that right, but that is core. So you can't add the nice flash of Stefan Kraus unless you actually know some of the core of how do I match? How do I merge? How do I get the survivorship around? Who is Donna Burbank? Who's Stefan Kraus? Who's Shannon Kemp, right? We need to get that information. So another sort of question that comes up or misunderstanding as people talk about master data is what it is. And that may be obvious to some of us on the call, but it may not be. So I thought it might be worth kind of talking that through. So if this is a typical, kind of to keep that ski analogy through, if this is your transaction data, you kind of have a customer, Stefan Kraus, he bought a telemarked ski boot with a certain code. He bought that in Europe. So it was Europe and St. Merit, Switzerland. Those are your transactions. And the way of thinking about that is that's a verb. That kind of describes the action. How many products did he buy? When did he buy it? When did a patient come in for an appointment? All of these sort of transactional information. But from that, you can really start to build out the nouns, which are more of the who. So let's go back to the previous slide. Sorry, who is the customer? Who's the product? What location are those around? And then build out the attributes around that. So in my example, you know, Donna Burbank lives in Boulder, Colorado, and Stefan Kraus lives in St. Merit, Switzerland. Well, there's some information around there and there all are different types, either master data or transaction data or reference data. So I thought it might be helpful to kind of walk through that. So again, the transaction data, those are the verbs, those transactions with the date on them. You'll see that the master data would be the customer, the fact that I have a Wendy Who and a John Smith and a Stefan Kraus and a Donna Burbank. And then you also product master data. What are the core product codes? Are your product codes different in Europe than in the U.S.? They have different prices. Are there hierarchies between those codes? Is there sort of a telemark ski hierarchy or a clothing hierarchy or a yoga pant? Is that even the same category as ski wear? Right, all of your retail understand all that hierarchy and complexity around just product data. But then there's also around your location. Is this the location where the customer lives? Is that where they bought? More likely this is probably the store. And do you have a master record of all your stores or retailers or suppliers? Is this a supplier or is it our own retail store? And all of the questions around that, those can be your master data. There's also a category, and one could argue when we do in data management a lot, is this master data or is it reference data? So under the reference data, I would say that might be things like your codes, like is CO Colorado and therefore a state code and CH is a country code. There's still a two letter code and there's some commonality there, but they're very different things and you want to have that valid list. With the last thing you want is when you're building a warehouse, you're trying to find Donna Burbank and in one system it has CO and the next one has Colorado and the next one it has Massachusetts because that's where I used to live when I was a kid, right? You want not only a consistent terms, but also a consistent global record, right? So I thought it was worth kind of those core based principles just before we get started into the rest. So another kind of system view of master data and there's different ways of doing this. You can have a centralized approach. I'm actually sort of a fan of the centralized approach for many reasons, but there's different ways you can do that. You can do it more distributed. But if we take the classic sort of golden record at the center and I'm putting MDM, that's your master data that may be customer or supplier in this case and I have the reference data as kind of a little cousin to it over to the left, but in this case where this big customer as an example that may live in many source systems and they all have their own unique identity reason for being in their own definition. So I often get the question, why do we have MDM when we have a CRM system? Isn't that our customer master? Well, sort of. Or the same thing will come up with why do we have MDM for product when we have a PIM or product information system and the list goes on. They really have a different functionality and purpose. So yes, you may only have one system that has customer information, but a CRM as you know, it's really understanding the customer and their transactions and their history and whether they're a prospect or there's a lot of functionality just built for purpose for that, which is different from matching is this the right customer data with this Don Burbank that lives in a certain address. The other piece is if you think of MDM is less of and it can be both. So I'm not gonna belittle the fact that it is a single store of information or a single logical view of information. It doesn't all physically have to be stored in one place, but say it were in this case. It can push it back out to the system. So I have identified that Don Burbank has a name and an address, but maybe on the online sales store, we also have her credit card information if you can store that or her gender, right? So maybe name and age comes from the CRM and gender comes from the online sales store. You may create that golden record for different systems. So we kind of walk through that MDM data model can either be, and one can argue which is the best approach, either subset from all those source systems. Maybe each subset has, you know, if one of the entities of the seven entities you want to store, right? So we get the name from one system and the address from the other and the age from another and the gender from another. We create this perfect golden record from that. Or in some cases it's more of a superset that each one of these only has one and there's no one place that has all that together. And you can argue the semantics or whatever. The idea is that all of the information that we want about a customer in this example, we want the correct value, we want the values that we care about, we want to be able to both take it from the source system, model it correctly and push it back out. Some of the other pieces that you want to know, this isn't a passive system, it isn't just this record that sits there. It can also feed things like your data warehouse. So if you think of your conformed dimensions maybe and you have a dimension for customer, the MDM can feed that. So it's a nice way to get that single source and use it in things like your BI and your reporting. You can also use it as a active record in the systems, especially as you're at a higher level of maturity. So I'm in my sales system and someone calls in and I say I'm Donna Burbank and they can look up at the MDM and say, are you the Donna Burbank that lives at 123 Main Street? Well, yes I am. Or maybe there's another. So you can actually, that helps with things like data quality as well. Where you can actually take that clean record and use it in your patient systems or your customer systems, et cetera, et cetera. Because there is a component of data quality you'll see in those matching rules where we need a cleanse or augment. A lot of companies use sort of third party data to kind of augment their MDM party of record as well. So that's another feature of these MDM systems. Key to the architecture though is really understanding the governance and business process around. And so what we just showed is difficult. Getting that architecture together is a challenge but it's not rocket science. If we have the right rules in place and we have the right architecture together, we can create some good matching rules and population rules to get that work. But this is something else I took from Gartner that some of the reasons that MDM systems may fail. One of them is failure to align with business process and really start to understand the business value. So where is customer data used? We may have thought it was seven systems. We never asked the business users and mapped out the process. We realized that most of it comes through a form on the website that we hadn't seen. So really aligning it to the process and how it's used. And the other part is governance. So who is the one that decides the golden record? Who is the one who can actually look at the record and see if that's the same John Smith or they might just know, oh, no, that's John Smith's son, not the father. I know because I just spoke to them yesterday. So how do they actually have that right level of human governance either on stewardship to do the checks on those valid values or and or all of the above? Who creates the rules? Who decides how you match customer? Who decides where some of the records are and what the source is and all of that really needs strong governance. So this alignment of process and governance is critical to really making this a success. So what leads to this slide, that real successful governance is that sweet spot sort of between data architecture, process alignment and architecture and data governance and stewardship. So the data architecture side, that's going to be your system architecture and your data flow and just the simplest step of what systems are we taking information from? How is data flowing today? And then how do we want to get that into the MDM system? What data models do we use? What are the fields for customer if we continue with that example? What are the valid values for those fields? What is the data type for those fields? Is there a hierarchy? Say if we're looking at sales rep, is there sort of a reporting hierarchy or a geographic hierarchy or a product hierarchy is another common one. And then how do we do those match and merge and survivorship rules? How do I know it's the same John Smith? And if there's two choices, how do I pick the right one? And then how do I integrate that back into my system design? That's the good piece of work. But if we look down to the lower left, I always integrate that with a process model. Where is this data used? How is data mapped to this process? Some of you may have heard me talk before and you'll hear me again here about CRUD matrices are create, read, update, delete. Who right now is creating that information? Because you may find that seven systems are using customer name. But where's the one where maybe, I was just working with a healthcare company, on intake of that customer, of that patient, that is where they got the name address and the birth and those forms you fill out when you go to the doctor. But then the other systems have that information in them but they're just reading it. They really should not be updating somebody's age when they come in to get their blood pressure checked in this particular clinic, right? So you wanna make sure that's enforced and that helps with your master data. Who should be controlling it or updating it and who should just be reading it? And when can this be deleted? And then often you find as you go through those business processes, you can optimize the business process itself. What you don't wanna do is take a paper process and put that same process into your MDM system. You can probably optimize that. And then on the right, there's the accountability and stewardship. Who makes the rules? Who validates the rules? When there's a conflict of a code or a product or a customer, who makes that decision? And how do you prioritize some of these values and the implementation of it? Especially I'm working with a large international company and we're doing an MDM right now. One of the bigger questions, they're doing all of these, all of these stages. But even just, do we do it by region? Do we do it by department? When you're thinking of, I don't know, 20 countries and 65 departments and different business units, it's hard to get that right accountability. And I'm a fan of kind of starting in pieces and moving out. So how you prioritize not only from data domain, but in terms of ownership and stewardship and groups within the company, those are all important. So this is just sort of a visual of what I mentioned too in terms of business process. And I often get kind of the feedback of all this architecture stuff, doesn't this take a long time? We don't have time to do all of the full enterprise architecture. Maybe you don't, but do it in pieces. So I worked with a customer last month and there was a big problem. We literally just whiteboarded this where we had the swim lanes and we said, okay, what happens when the patient comes in? What do you do next? We got so much valuable information. We took a picture of it and put it in the PowerPoint. This was a fancy BPM tool, but it made so much difference if we had some aha moments, if I didn't realize that someone touches that data and someone else chimed in of, well, this is where the data is touched. And you'll see the swim lanes in terms of which pieces of the department is it claims, is it underwriting, if we're an insurance? So which different pieces of the puzzle are people touching? What happens in this person's daily job and then what data is touched? And that can help sort of understand redundancy, conflicts. What you can also see here, and I'm a big fan of pictures, if you've seen my webinars before, you'll see the pictures. I will put in where there's a manual process with a piece of paper or in this example, you'll see that an email is sent. Is that the ideal way? Maybe we could put this in a system and have a lot of MDM tools have great workflow capabilities. Could we make this a workflow in the MDM tool that can kind of automate some of these manual processes? So not only is process helpful and understanding data usage, it can also be helpful in designing your MDM system because workflow is such a key part of MDM. You wanna make sure it's almost an as is to be. This is how data is entered today. With this new MDM infrastructure, how do we want workflow to work and where do people fit in this process? It isn't just this automated, we point the system to it and it magically works, right? I think you understand that, but it's worth calling that out. So this other piece I mentioned, which is a horribly named but very helpful tool called the CRUD matrix. So it stands for create, read, update, and delete. And there's different ways you can do this. You can do it by system, you can do it by attribute, you can do it by entity, or do it by department. For example, we're just talking about the product price. Who enters the price? Is it accounting that puts it in? But maybe marketing can update that and finance reads it. But maybe you might come into those situations where two people think they're creating it. Well, then who's master? Who's the main owner of that? Maybe it's a case by case scenario depending on whose quality is better, which is mastered. But you better at least talk about that before you implement the system. Because that's often where things start to go wrong, is who owns it and who updates it. You don't want to override a system that someone didn't realize this was being overwritten. Here's an example of this, actually in a real world example that we did implement that worked out very well. So it was a restaurant company that I worked with and their product was actually their menus, which to me was sort of a menu. It wasn't a shirt or a car, it was actually their product was their menu and they were very innovative in their menu. And they realized as they were kind of going through their digital strategy, they were trying to do a lot of more things with their data. They really did not have a central source of their menu data. I think one of the comments from marketing was that I think our printer has a better master data than us because they printed the menus, right? So they knew. So we did sort of all of the above that we mentioned. We did interviews with everyone from the chef that you see he didn't quite wear that hat but he sort of had his kitchen and he created the menu and his pieces of that, just like any product, it has components. So his components in that case were nutritional pieces of food, right? So is it the right slice of cheese? What are the menu instructions for this cheese? What's the nutritional value? Are there any allergens associated with breed cheese versus American cheese? Any customer going to my maze, how much detail is important and little pieces of data when you order your hamburger at the other end at the point of sale that that becomes important and in this company it actually did come important. So we actually went to the restaurants and kind of tested their point of sale system but what had happened is they had sort of a new, in this case I think it was a sandwich and you could on the point of sale just switch out the ingredients. So they said instead of American cheese I want blue cheese, right? That's something I can do. But in this case blue cheese cost a dollar more. So they actually had a major because of cost override because the person who was configuring the point of sale system was not aligned with the chef that said this sandwich can only have American cheese because we've worked with supply chain, we've worked with accounting and it has a price for a certain reason. So anything with so many pieces of the puzzle that come into play with just clicking on a button and ordering your sandwich online. So with this company they started with process and they went through the business process and they mapped it out and they ran it through everyone through the chef's kitchen, through marketing, through supply chain, to point of sale, through kitchen design, through everybody and really created that single view and created the governance around that. Well then who's gonna own which piece of data and built the data model? So they did all of that before they even started with an MDM. They did use an MDM tool because I think a tool is important but the tool is not the answer. They had to do all of this together and at the end there was a lot of happiness. The marketing was able to finally see all of the menu items and the correct source to do their marketing campaigns. The chef was able to, instead of having to type in or write a piece of paper, the ingredients he hadn't actually automated list because who knew this whole food databases out there that you can check that gets you all of the ingredients and nutritional information and price and all of that price but the rest of that and then it could integrate that with supply chain because as you may know the complexity is that ingredient available in Canada in the summer? Maybe not or maybe it is in the summer but not the winter. So all of that was integrated in one central business process, data modeling, workflow and master data and governance as well. So that was kind of a great success that we came in thinking we thought we were going to do master data. The more we looked at it we realized it was a process and governance problem. So here's a kind of a very meaty slide I apologize but I think it sums up kind of that intersection of some of the architecture where master data management fits and where some of the governance roles come in. So at that top level we think of kind of the enterprise-wide prioritization. A big fan of just starting with a conceptual data model. Something with when we're mastering customer what do we mean by customer? Is it individual? Is it a company we're working with? Is it the holding company of the parent company or the individual stores? So many questions just about at a very conceptual level what are the main entities? We're talking about also health prioritize. We've got a hundred main master data entities we could use in our company. What do we start with? Supplier, customer, patient, employee, student, all of these. And then I'm a big fan of mapping that to in this example I say customer journey or logistics journey or student journey or patient journey or process model, whatever you wanna call it. I think the hip way is kind of design thinking a lot of I've worked with several companies that have something like a customer journey which I did one recently with a student journey which was kind of fun. But that kind of puts the why and how into it so you could do a lot of things but how does this actually matter to a customer in their journey or a patient? And then help prioritize some of those subject areas and domains. And then especially if you're an international company how do you do that roll out? Do we do it all at once in a big bang? I may not recommend that. Do we start with one of our smaller company countries because it's easier and we'll have less risk or do we start with one of our larger countries because there's more value? None of, I can't answer any of those for you right now. That's where you're starting. Those are all valid concerns and your steering committee or your governance and MDM team need to get together themselves and prioritize that. And that's a combination of business which is kind of the blue with your business data owners and your technical. So data architect, I think they're a unique role that they can kind of talk technical and understand how you might structure some of this but also talk business and understand hierarchies and business roles and things like that. So I would highly recommend starting there. You don't wanna start with the wrong domain or the wrong, you can go into a lot of it comes down to prioritization and the right use case. And then on this business and technical alignment I kind of broke those into kind of more the business side and the technical side. So on the business side just starting with that logical model what even attributes do we start with? If we're talking about customers at name, address, date of birth, social security number, can we track that, all of those basic rule? And then what are the rules around that? How do we identify with match merge criteria, survivorship, harmonization? And again, that's sort of what we talked about before with linking that with process and stewardship. So here you're going through one level lower where maybe there's a data domain steward or someone who understands that process or might understand that that works differently in Europe than it does in the US, which is different than Latin America and based on your company, maybe it's a lot smaller than this or maybe it's even broader than this but getting the right people in the room to ask those questions that you're not going to implement MDM and someone will say, oh, but we don't do it this way in Region X or the system you forgot or looking holistically at it. And again, from the technical side there in the green, you may have an enterprise data architect, you might have business analyst, you may have an MDM architect who's a little different than a data architect, enterprise data architect, whereas maybe the enterprise data architect might look holistically across all of the data and all of the priorities. An MDM architect gets a little bit nittier, grittier at the word. Hey, how are we going to build the match merge criteria? How are the survivorship rules working? Are we going to do fuzzy matching, et cetera, et cetera, et cetera? There's a lot of very specific technical skills around that. And again, if you have a much smaller company, some of these people might be the same person in one body, different roles. But larger companies that often is important to even just break these out. And then at the technical level, there's a sort of physical data model and data quality steps that help actually implement the hub itself. So I'm a big fan of doing your data profiling. So we have a cut, we're picking these seven fields for customer and we're going to match on, I can uniquely identify my customers if we go by name and date of birth and address. And we can do some profiling we say, but date of birth is only filled in in 50% of the cases. It's empty half the time. Well, we may want to change the rule. Either that's not the right rule or we need to change the business process that people actually enter date of birth and they understand why, et cetera, et cetera. Do we want to start augmenting address? We don't know the address but we can purchase that through a third party or we can validate that through a third party. Can we create dashboards? One thing I often implement in the data governance committee is having a regular KPI dashboard. If we are matching on name, address and date of birth, do we have a dashboard to know how good the quality of that data is? I'm making a business decision on these just like I want a KPI of my sales data. I want a KPI of my data, right? I want to understand the quality of the data that I'm using to make decisions on. And then as we integrate data, you'll see there's integration rules, publish and subscribe rules. I'm a big fan of that, Prud Matrix. And then the platform itself and there's a lot of good tools in the market. Please don't ask me which one. You know, I hate to answer that. But in terms of pick the tool that is the right fit for your team, a lot of, I've seen, you can go look at the Gartner Magic Quadrant or the Forrester Wave and get some good but is that the right fit for your tool? So what systems, oh, your environment, what systems are you integrating in? Do you need to integrate with a CRM or a PIM or an e-commerce system? What's the level of maturity of your organization? What skills are needed? Some of the MDM tools can be very wizard-based. You don't need a lot of coding. Some need a lot of expertise. So you need to do that evaluation to make sure the tool matches for you. I have one customer that isn't using a tool at all and they're actually doing their own match merge rules. I personally would prefer to use a tool. I think they have done this before. A lot of these rules, the logic behind this can be kind of automated and you can help yourself with there. But, you know, it's a functionality. You could build anything yourself. So there's a range, but do that wisely because it has to match your environment. The tool that might be the highest in the Magic Quadrant might not fit your use case. And I know that's obvious, but I think there's a temptation, especially as you're selling up to management or if it's a joke you can't get fired for buying IBM or whatever, there's an aspect of that. Because this is so popular, there are some new vendors coming up that have some good functionality they may not have as big of a user base. So that's something else to consider as well. I am a big fan of stories and this is when there's success stories. So this one I've talked about I think in the past in perhaps a different context, but I have been a fan of promoting this idea of mapping to the customer journey in the lifecycle and also doing a full enterprise architecture but in a small-phased approach. So this was a retailer we worked with in the US and they were doing a lot of exciting things. It was an internet of things enabled product. So they were building the data lake and they could actually get real-time data usage from how the customer used the product. They were trying to do a lot more with understanding the customer and loyalty programs and things like this and they actually had an MDM system. But it wasn't working very well. So we took a step back and we said, well, why is it not that working? They had one of the leading MDM tool vendors, nothing wrong with the tool and what was implemented in the tool was fine. But they had not necessarily stepped back and took a holistic, when we mapped the customer journey and we started from the beginning, what did they do when they're just in the discovery phase? Do we know anything about, they may have visited the website, they may have visited a store and given information at the store. And this actually was an actual use case. What would happen is they would go to the store, the high-end product, they would actually talk with a salesperson and the first phase in the sales journey was the salesperson to get their name and email. Well, if any customers like me, you probably gave, yeah, I'm stupid at stupid.com because I don't want the salesperson to follow up with me, no offense to anyone who's in sales. But I'm not ready then, I want to just look at your product, leave me alone. The problem was how the system was built and probably rightly so, that email address cascade of the cross so that later when the person did buy the product, they put in the correct email, but the system, they kept the original. That was a classic crud. It was created and it was never updated. So when they called customer support, when their product didn't work or they couldn't get their product delivered, they weren't getting the email because they put in stupid at stupid.com. Which could have been validated. I mean, there was a lot of different, maybe it was a valid email, but just they weren't looking at it, right? And then they also had things, the loyalty program, when the person really liked the program product and they signed up for the loyalty program and weren't getting the emails because it was never updated. I mean, literally this was a classic map out the process, see where the data is used. We picked that very small sub case just saying where is email address used. We looked across the system, we had a small governance committee on this one particular work problem. And I consider this one of the sale successes in my career. And again, no disparagement to sales because we all have to sell at some point in our lives. But we had the head of sales after we discussed this problem and saw how the data flowed through the system. And a lot of it came from the initial email. He said, well, I need to, and set my, train my people and govern my people, they can even use the word govern to get that correct email from the beginning. And there are other ways we can force the right email, et cetera, et cetera. He never would have said that because he didn't, until he understood the downstream impact of putting in the wrong email. So that was a case that nobody was doing anything out of malice everyone was busy with specific tasks. No one had sort of stepped back and looked holistically at the business process, the governance around the data and the architecture around the data to really see that holistic view. Once they did, it was an easy fix. The technical fix was not so that difficult. The hard part was seeing holistically and getting the right people in the right room would make the decision. So I know that was sort of a long winded example, but I think it shows a good example of how they could get all of those pieces together by just picking a small use case and getting all of those pieces of an enterprise architecture together. The other piece that we didn't have in the stories, they were using IoT data and they really wanted to get that information, but they weren't able to easily link that back to a customer, partly because of security issues, but also they didn't have that customer record. So once they were able to do that, they were able to kind of do that new next generation sexy stuff, because they were able to kind of do the core MDM style stuff. I know stuff is a very technical word, but. So in summary, I will say that master data is on the rise. More and more people are looking to get that common consistent source of information, whether it's customer products, supplier, employee, patient, et cetera, et cetera student, but really to be successful, you need to start integrating that into your wider data architecture with process and governance around it because it really can't have a good positive impact on the business. If this was of interest to you, you may be interested in next month in October, which is on data modeling, business-centric data modeling, which I know is always a hot topic. We always have a good turnout there. And the web white paper that I mentioned is available on our website where it does talks not only about MDM, but a lot of the other trends in the market about master data and metadata and architecture. If you may, it's free, so you may be interested in downloading that as well. So without further ado, Shannon, we can just do a little bit about us. We do this for a living, but we can open it up for questions if people had any comments or questions about MDM. Everyone's really quiet today, Donna. I wonder if everyone's distracted by television. News events. This is a rare, I think this is the first that we've never seen. I know, I know, it is rare. But most commonly people ask about slides and recording and just a reminder that I will send a follow-up by End of Day Monday for this presentation with links to slides, the recording and anything else requested. But yeah, everyone's just super quiet. Any questions out there? Great, not a problem. So I will put, I notice often we find a lot of people, maybe it is because of news cycles, people do catch us after the fact and get their recording, which I think is a great feature of data diversity. I've gone back myself. I never have time during the day, so I have watched a lot of my colleagues' webinars at night and that sort of thing. If you do have any questions or concerns, don't hesitate to take my emails on this slide. Maybe that was risky. But I do have people who said, yeah, I caught it a few weeks later and I have a question. And if I don't ask you, I apologize because I'm busy, but I do generally have a pretty good tech record if it's a little bit late if you do have something that kind of caught your interest. Well, we do have a couple of questions coming in now. And of course, I will send out your contact info in the follow-up email as well. So where would you start if you were coming into a new business engagement? I would start basically where with some of those core practices I mentioned with starting with the wall, actually I'll go back to my favorite slide. You just wanted me to put up the slide. Thank you for that. No, really looking holistically at the big picture architecture. Sorry, gosh. But basically starting with the business question of the why. Why are we doing this? What are the business goals? Because sometimes one of the hardest questions is even what to master. I'm sorry, I can use my own slide. Looking at that general business strategy, where are we trying to head what's the most important data to govern? And then we would start out with kind of a system. What systems does that data come through? So maybe we decide it's patient data. We don't have a good set. What systems does that come from? What business processes are touching that data? And then do a very high level data model of that. So high data model of the source systems, data model of the target systems, and really try to get some of those rules around what are the fields we want to master? I would not boil the ocean. Maybe start with something small. And then how do I do the matching rules and do some data quality checks on that? So these are the fields I want to master is my, because it may be the right answer to wait a little bit. I want to do this matching. Our data quality isn't good enough yet. Maybe I need to go back and get the quality right, or maybe MDM can help with that quality. And I would definitely have a government, if you don't have a governance organization in place, this may be a great time to start it, because it's not gonna succeed if you don't have the governance to get the right people looking at the data to make those matching rules, or to actually look at the data coming in to say, is this the right match? So the rules are very important, so you don't want this to be an IT-led initiative. Definitely having the business involved is key. Could you address the difference between reference data and MDM once more? Yes, and I'm not gonna try to move my slide, because for those of you who might think I'm an idiot, I'm on somebody else's laptop with this really tiny screen, and I can't hit the button on the slide. But I did have one, so in a bit it's an academic, but sometimes it's not. I would say reference data in the sense that it's smaller. That might be your country codes, your state codes, your procedure codes. And in some cases, you may say that product codes, that's a core aspect of the business. There's often transactional data around that, so a customer product, your big buckets, where there's a lot of different systems, tends to be changing more, those would be your master data. I would say reference data are generally smaller, more slowly changing data sets, whereas I may change my address more often than I may change a state code in the US, if that makes sense. And often you, sometimes in another rule, you may get those from a third party, some of your references. It's more of a reference, almost by the name of it, that you reference certain data. Your master data is the ones that are actually running your business, your customers, your products, your suppliers, things like that. Have you seen any implementations in big data or in data lakes? Yes, I don't think they're mutually exclusive, so don't get me started, I'm old enough to start my rant. Of data, if it's not replaced master data, it is augmented by it. So just today I'm actually on a client site and that's where we are protected on the whiteboard behind me, right? So that we want to get a holistic view, in this case it's customer, of internet of things streaming data from one of their products, from social media data, also make sure it's the right customer for a policy, right, so this is an insurance company. So part of that lives on the lake, I would definitely want to land some of the social media data, I might not know how to use that, but I can't leverage that big data unless I have a master data. So I see the master data living outside the lake, or depending on how you define your lake, if it's a loose ecosystem, I wouldn't put your master data on Hadoop, or there's a different use case, or AWS bucket, right? The master that sort of needs that either relational or graph or that logic behind it, but then you can integrate some of those bigger data artifacts into your master data. One more success, we're actually a different customer, but also an insurance. They did this really interesting big data lake, screen scraping of some of their high net worth customers, well it could be creepy. What are they doing online? Are they getting lawsuits? Are they owning the companies? They did all this great analysis, problem came when they tried to match it with the actual customer. Is this Bill Gates the billionaire, or Bill Gates that lives on the 101 Main Street is in the debt? And the reason the lake part broke down is they just have good master data matched with. So I see them as separate, don't mix the two, but they definitely augment each other that the master data could help feed that lake and do some analysis on your customers. Sometimes the MDM discussions sound best suited to a warehouse environment, but for companies trying to govern a big messy data lake, what effective strategies have you seen? I would not agree with that first statement. It's not only for warehousing, it could be for real-time operational systems. It could be for lake type information. I wanna get customer sentiment analysis, right? And I wanna under, but you still have to master somewhere who your customers are, right? So I do think that core logic of, you could do it in a very lightly high or something, I wouldn't recommend it, but wherever you do it, you have to have very specific rules and governance around what rules we match on, how do we do the survivorship, et cetera. So I don't see it as an old, only for data warehousing. I see it, I think some of the drive for MDM is ironically, and then ironically, but interestingly, because of some of these new technologies, the more I'm using customer data, I have to pretty much make sure that I have one record for my customer, single source of truth. Does that make sense? So in your experience, at what level do you normally see a champion for pushing the need for metadata management across an organization? I will assume they mean master data, but I will put them both together. But those words are so similar, but obviously they're different things. So I would think it has to be driven from the executive level, has to be top down for anything. It could be metadata, it could be a master, it could be anything, but it can't stop there. And I've seen both, it has to be at the very top level, it has to be at the management level or implementation level, because those are the people at the coal phase, so to say, that are actually doing it every day. And it has to be at the actual, even from the data entry of the clerk at the front level. Everyone has to understand this, because I've seen success from the executive level and they say, go make it happen. But if the soldiers aren't listening and the general says it, it's not gonna work. And if all the soldiers saying it, but the general isn't bought in, it really has to be across the board. Obviously at a different level, but it's just, you know, hopefully that clerk in the beginning, MDM just makes his or her job easier and they just see the results of it. But in some cases they are involved either in the looking at the fields or making sure the fields are putting correctly, et cetera, et cetera. So it's across the board, it's all pieces. And from the technical standpoint, what challenges could one expect in an MDM implementation? I, so it could be, make sure you're getting all the right sources and you haven't forgotten one, which is kind of a process, but also a technical. I think making sure that you get the right set of data elements, that the data types are right. I mean, some of this is just kind of boring housekeeping, but it's so important. Do I have, what's the longest length of my surname or last name, right? You can go things wrong there. I think the trickiest one though, is this idea of the survivorship, the matching rules? How tight you wanna get that? So for example, I could say I'm Donna Burbank and I live at 101 Main Street and then there's a Donna L. Burbank. Well, probably 95% probability it's the same person. We can auto-match that, right? And that could be fine, but maybe I have strange parents and a sister named Donna Louise. Actually, a guy I dated, too much information, a guy I dated in college, he had three sisters and they were all named Maria. It's their first name. It was a Portuguese culture and they all had different middle names. So that might be a great example. There was Donna Louise and Donna Mary and Donna Elizabeth and they would have had a very poor match, right? So you need to understand your customers and you don't wanna over-match that then all of his sisters would have had the same email and then they're not, they're different people. You don't wanna under-match. I also had the case where they made the rules so loose that they had poor business people checking a thousand entries every day and it failed because people were sick of having to check that many. So I think where it gets tricky is all, everything else I said, you probably nodded your head. You're like, yeah, whatever, obviously. But I think where it gets hardest is getting that matching right. You don't wanna be so tight that you make people review too much. You don't wanna be so loose that you over-approve and get the wrong match. And one more quick story. Sorry, protecting the innocent names but it was actually a healthcare company. We had a very junior person and his role was to check the matching rules. He's like, no problem. I think there was only three that were wrong. And that's not bad. We had a million patients. I'm like, yeah, but this is a patient going into surgery. I wanna make sure that if they're cutting off my leg it's the right Donna Burbank and not somebody else's leg. So in some cases, I mean, for business reasons, you have to have absolute, maybe you do want everything reviewed in that case. So that I think is the trickiest thing to get right technically is that matching rule. Sure, so do we need MDM if we don't have any or little silo information? That is a good information. So in some cases, and I'm just talking about this before this call, you may have, I really only have a CRM. I absolutely am a small company and this is the only system I have. It doesn't integrate with anything else. You probably could get away with that because you need to understand that. Is there data quality rules on that? Or maybe I just have, I'm really small and I have a SQL server database. It has all my brokers in it, all my sales people in it. I know it's right. That's all I need. I don't need to push it out to anything else. Those are some of the, do I need to integrate with any other system? If no, not. Do I have the right matching and cleansing rules on it? And I'm doing the right, if more than one people are searching on it, entering it. Fine. And is it complete and consistent and accurate? In that case, it may be yes. You don't want to over engineer if it does, but I would just be careful that there really is only one system. It's only used by, and I've found that to be rare because even if you have, you think you have a CRM, but then someone's pushing it out to the constant contact marketing system, et cetera. So part of it, when you start to think of it more of a hub to push out, that might come in. But yeah, you don't necessarily need to over engineer. It's, but you don't need to do it for every domain. Maybe for customer, I want to master, but for my locations, I know the locations of my store, they're in a database, it's fine. There's no question. Don't over, perfect world you would, but you don't need to for every single domain. Just pick your battles, if you know what I mean. Indeed. So, you know, Donna, I love this question. New MDM tools are changed to be called MDG, master data governance. Should MDM and data governance be combined into one function? They're related functions. I see them as a bit, however we word it, they should be closely aligned. In some cases you want an enterprise governance and then there's master data governance that's different because that might be different than your application development governance for et cetera, et cetera. So I see them, there's different roles within MDM, but governance is a strong part of it. So I don't want to say it depends, but I do get me busy as the architect or part of MDM, but they should be aligned with governance. So that doesn't bother me that they're calling it the same thing. I think if it's giving more visibility to governance and you're making sure they're aligned, yes. Are they slightly different things? I think governance will be broader than just MDM. I'll probably be my answer to that because you're looking at policy and procedures and across the whole organization. But the fact that they're aligned, 100% aligned, that's a good idea. Because you can't do them separately, it's worse to not have governance. So, yeah, aligning them together is fine. So do you think that managing MDM in a database focused on relationships like a graph database would facilitate matching? It doesn't facilitate matching, but it's a good idea. So there's the, I think there was a webinar we did a few months ago that actually talked about this. So how you match is still gonna be difficult or the same questions, because you have to sort of match up. If that's almost as more of your classic relational, how do these fields match up? But the beauty of a graph database is to be able to, once you've found those matches to get some hidden relationships, I think, that maybe householding, for example, I know these three people are related in a pattern or I'm seeing that phone call patterns to one group, et cetera, or fraud detection and things like that. I don't think it helps with some of that core matching because to me, that's a logic. That said, I'm a big fan of graph because you can get some of those relationships. It's almost like you do the matching and the more traditional mindset, I mean, relational mindset and then the graph helps you once you have that. It's almost like that big data question in my mind earlier. You have to do the hard core and then you can start linking it to everything else. But how I match Donna Burbank, whether she was born on May 1st, then that's sort of beyond graph. That's just kind of how you match the fields, if you know what I mean. All right, Donna, with us, all the questions we have today we're very close to the top of the hour here. So just a reminder to everyone, I will be sending out a follow-up email by end of day Monday for this presentation. It links to the slides, links to the recording. And Donna, again, thank you so much for another great presentation. We hope that we can see you all next month. And thanks to all of our attendees for being so engaged. I love all the questions that came in today. And I hope everyone has a great day. Thanks, Donna. Thank you, always a pleasure. Cheers. Bye.