 Hello, I apologize. I'm my microphone was muted so let me start over. I was given this great presentation and the great introduction which you all missed. Hello and welcome my name is Shannon camp and I'm the Chief Digital Officer of the university would like to thank you for joining the latest installment of the monthly university webinars series advanced analytics with William McKnight. I'm going to be discussing why analytic leaders deploy master data management. Just a couple of points to get us started due to the large number of people that attend these sessions he will be muted during the webinar for questions we will be collecting them by the Q&A section. And if you'd like chat with us or with each other we certainly encourage you to do so. And just to know the zoom chat defaults to send you just the panelists but you may actually change that to network with everyone to find and open both the Q&A and the chat sections you can find those icons in the bottom of your screen for those features. I'll send a follow up email within two business days containing links to the slides the recording of the session and any additional information requested throughout the webinar. Now let me introduce to our speaker for the series William McKnight, the world's best known organizations his strategies for the information management plan for leading companies and numerous industries. He has a prolific author and a popular keynote speaker and trainer. He has performed dozens of benchmarks on leading database data lake streaming and data integration products. His name is a leading global influencer in data warehousing and master data management and he leaves McKnight consulting group which has twice placed on the incorporated 5,000 less. And with that, I'll get the floor to William to get today's webinar started hello and welcome. Hello, Shannon, and everybody, I am going to share my screen here. Take me just a second. Okay, hope. Am I sharing okay. Yeah looks good. Right well welcome everybody. Once again, my name is William McKnight and thanks for joining this webinar and this series this is a monthly series where I talk about all things related to advanced analytics and today that topic has come around to something that I enjoy talking about master data management. And I'm combining that with why analytic leaders are doing this thing. So, let's learn about this if we're an analytic leader, how it might have applicability to what we're trying to do. We possibly already know that master data management has great applicability on the operational side of our enterprises. But what about on the analytical side, why might they do such a thing. So, let's start out with that robust master data management is pretty much what you're doing on the analytical side, anyway, although you might be doing it a different way than through master data management techniques, you might be doing it as I like to say kind of the But once you have the subject the subject areas mastered that are relevant to the analytical application that you are building, then you are more than halfway of the way to the promised land of having an application working in production take for example, all these applications that I show on this slide, and then I have a list of enterprise subject areas over on the right. That's not meant to be exclusive by any stretch. You probably have a vastly different list of what enterprise subject areas are to you as a matter of fact I think I mixed up some industries in here on purpose, just to show you the breadth of what a enterprise subject area could be. And for some of you, what I show here is actually too broad customers too broad, potentially for some of you, if it's way too big to assign the business ownership, as we like to say, data stewardship to one person or a small department, then I like to break that up so whatever your enterprise subject areas are, they can easily be matched up to your application list so take a look at your current application analytical application backlog. And ask yourself, what subject areas do they need is there a way that then I can build that subject area out once make that data available as a service. And I can use it many times over the course of time, maybe across all of these applications most applications need customer. Most applications need product, and they're going to get it one way or the other. So we want to do it for them we want to do it to enterprise standards, and that's master data management. So I like to say master data is not really an option. So the question about are you doing master data management, not really a good question because you're probably doing it. Without a doubt if you have applications in production, but the question becomes, are you doing it in an MDM way, you need master data but without a discrete focus on it, you will not get it done well. You need data experts that to do this, and to do it most efficiently. Otherwise, if you're actually building master data for each application, you're building it to different standards, and you're building them inefficiently, not with data experts. This is creating technical debt within your organization, and we want to avoid that so therefore, any new stack that I get the opportunity to influence any new stack that we're building, or maybe existing stacks that you're questioning. I'm always inserting master data management into that stack now I know that stack is huge these days. You've got your dedicated computing storage you got your data catalog you got your machine learning a set of algorithms your data warehouse your data lake data streaming data catalogs if I didn't mention that already etc etc. There's a lot to it. Yeah, there's a lot to doing this. Mass machine learning right which is kind of a novel modern form of a lot of the analytics that we're doing. So, yeah. Maybe you don't like having another one in there. Now the cost is really growing isn't it. Yes, the cost is growing, but so hopefully is the value. And you'll need master data and the way I usually justify master data management. I've done this quite a bit is through total cost of ownership, because it's a lot less expensive, especially over time. To do it right once build it once use it many times then it is to do it on a repeat basis in and of itself. Master data management does not have a lot of return, right, you're just building a database full of great master data. And also what has to be curated in this process is who is going to actually do the integration I guess of the master data out to the various applications. So master data, unless you have subscribers to the master data. That's where you get the returns from, and you always should be heat seeking return on investment. So you can take that enterprise focus for master data management, if you want, you're trying to build out let's say customer for your entire company. That's great. And make sure that you are hyper focused as well on the initial application or applications that will use the data, make sure you satisfy that and know that even though I'm here saying build once use many times. Know that every time that you take on a new subscriber, a new application, you're going to have to add a little bit of time to that. Whatever as clean cut as you would like to believe. So when you build it out that first time, you want to also look into all the possible attributes that you might need for this master data, and try to build that in initially. And it's, it's a, it's a long extended judgment call or calls about how to build master data management. So, you have to keep your creative head on. You have to keep your leadership out on and your judgment had on as you go. So you might have that enterprise focus but I encourage you to also have an application focus, focus on the applications master data needs first. We just, I just showed you a little cross referencing activity that you could do to the master data that might be needed for an application, you definitely want to get ahead of the applications need. The application gets to a point in its build cycle where it needs that master data and you don't have it. Chances are it's going to go off and roll its own, and it'll probably take them longer to do than, than for you to finish it up. But nonetheless, that is what happens inside of enterprise. So we want to be aligned with our company's roadmap and have a little, have a little organizational direction over to the master data management program so that everybody's not out there building their own. So you need master data but without that discrete focus on it, you will not get it well. I'm repeating that do it with data specialist data modeling specialist data integration specialist data quality specialist. Yes, hopefully you still have those around at your enterprise and people are still hyper focused on it because it's still very important. I say use a tool I definitely lean into a tool. If you're not really interested in the 10 things that MDM can do for you. You could home grow that do it with code, but even at that point I would be hard pressed to find value proposition for that so I'm thinking hard about a tool for you. MDM is operational and real time MDM is operational but it supports not only operational other operational applications, it supports analytical applications as well. And ideally, the data comes in in real time as soon as it's formed, maybe you're even using the governance capabilities of master data management hopefully you're using them to actually build up your master data. You are hopefully distributing that data in real time. The only time that I don't distribute in real time from an MDM hub is when the subscribing system cannot handle it. And that does happen, especially when you're dealing with some really old systems out there that have to be loaded in batch and that sort of thing. And this also brings to mind, well what data am I pushing out to these analytical applications. All of my subject area customer let's say all of customer or a subset of customers usually a subset. It's usually what they want what the application wants very few applications will come to me and say well just give me all you got. If they do I think that they're just probably going to take it and then do some more work on it so that it works for them and I'd rather do the work myself and do it once for many uses. I don't want them creating additional technical debt additional data architecture out there in the application arena. So how does that hub create analytical or what I call empowering elements and I'll get to that in a little bit. Make it a discrete project with a high number of touch points with applications. So have some joint meetings with the application owners all along the way of the build out of MDM and the applications to make sure that you're in alignment. So let's focus on the total cost of ownership first for justification, as I mentioned, that's really the way to go when you're trying to justify master data management and build to scale because it really doesn't take much longer to consider. And I didn't say implement but I said consider all known requirements, you might make a heads up decision not to take up the effort to implement those attributes that application number 10 is going to have of the MDM. subject area. You might just do the first couple that's okay, but you, you have to make a judgment call about that. I say, select that information so that you know what it is and where this master data hub is going, and you know how to scope the effort when you get to that application. Sometimes there's no additional attributes to be added and all you have to do is integrate the data from the hub to the application. Somebody has to do it, either the MDM group or the application group will get to that. But that's all that needs to get done. And sometimes there's additional attributes to be built additional calculations to be done. We don't like the way you did that master data do it this way for us, etc, etc. So the real decision points continuing that theme, you're trying to roadmap around who's your sponsor and sponsor. It should move over the course of time in an MDM effort, because your subject areas move and no sponsor is really going to be knowledgeable enough about every subject area that you're going to master. You could have a sponsor for quite a while but be sure you're ready to have that baton past road mapping around subject area. I like to roadmap around subject area. I like to try to build out a subject area as completely as possible for the applications that are going to need that subject area and all that's coming right up. And use the workflow. Don't forget third party data. Third party data is really hot right now. Everybody's collecting third party data. And we are actually becoming people that build data products. And I predict that in due time, maybe a 25% or so of us data builders are going to be building data products within our organization. So where are they going to go maybe they'll go into the data cloud, and we'll be bringing that data in because we're interested in that data. There's a whole lot of third party data out there, and I won't belabor it, but I am of the opinion that most of it belongs in MDM because most of it's really master data. And then you have subscribers. Again, we're trying to build out your roadmap for MDM the subscribers the AI applications. Especially in the analytical area these days are AI based their machine learning base. And so that's why I can call it bad and don't forget common artifacts, like your data warehouse your data lake, and different operational data hubs and and databases right but your data warehouse and your data lake, or lakes as the case may be. These are your prima fascia analytical data stores right. And the third master data to they need it to chances are when you start your MDM program. Your data warehouse already has done some of this work and already has a customer, what we might call a shared dimension within the the modeling of the data warehouse. And here you go off somewhere else building an essentially an enterprise shared dimension in master data management. Yes, that presents two sources of the truth that we don't want right. So I say that you need an effort to change the data and the data warehouse in those dimensions to the data that's in your MDM subject area, and be pushing the data from MDM to the data warehouse, replacing that conformed to what you have in MDM so that it's consistent. And therefore, the data warehouse becomes another subscriber to MDM, just like all the operational analytical and analytical applications that you have same goes for the data lake by the way, although you probably don't have the burden of already having that data mastered in a data lake, although I could be wrong. We're going to communicate about the date about about MDM to the organization. Remember, they're all thinking in their minds about what what does this mean to me. And maybe they're interested in a subject area that you don't have in MDM. That's okay. If you start to present MDM to the organization as MDM is for a variety of subject areas, it's not just for customer I know that's what we're building now, let's say, but it's for a variety of subject areas over the course of time. And what I've experienced when MDM is successful, that's most of the time, after a subject area or two is built, the organization really picks up the baton and decides, we should do this process, because it's so efficient we should do it for these other subject areas that nobody thought about on day one certainly not me coming in from the outside. I can talk about your customer and your product, of course, and several others, but only an insider would know what that 10th subject area is that could be mastered. And so keep an open mind about it. Keep data governance talking about it. There are indications going about it like this. And also, you have to build up data governance and stewardship it may not be all done fully fleshed out on day one of master data metric you may only have for example, data stewards lined up for the subject areas that you're working on today. And that's okay, but it's better if you have stewardship coverage of the entire enterprise of all subject areas in the enterprise which kind of implies that you know what they all are, which hopefully implies that you need to have done, at least a conceptual what we call a conceptual data model of the organization as you step into master data management. So this enterprise data in master data management. It's ready enterprise data is generally ready when it's in a leverageable platform. Now, to me, a leverageable platform is something that you're building once you're going to use it for many different things inside master data management is certainly a leverageable platform. The data warehouse is certainly leverageable to multiple applications the data lake. Yes. But one off databases, even analytical databases, not necessarily doesn't mean they're not important doesn't mean I would never do them. Nothing of that sort. But it does mean that when it's in that enterprise data is ready when it's in the most leverageable platform for the data. And oftentimes it is master data management, and it is the data warehouse I really encourage you to add master data management to your ML stack for this purpose. And that has to be in an appropriate platform for its profile and usage. There is no one size fits all. There is no one place where all data goes and that's it maybe that day will come in our lifetimes. Again, but it's certainly not here now. And as I mentioned before you need a really long list of component tree in order for Matt to do effective machine learning inside an enterprise. It's going to be a whole other webinar. And I think actually I've done that with high non functionals availability performance stuff scalability stability, durability and it's secure. Okay, that all kind of goes without saying but I wanted to say data captured at the most granular level, but you're sitting there saying well, the business isn't asking me for data at the most granular level. It's not asking me for all data to be under management. It's asking me for this little slice here. It doesn't know what to do with that other data if I were to master it. And I think that's kind of part of the problem. And if you are not, if there is not more demand for data in your organization. If you're if you're way on top of it, and users aren't asking for more applications aren't asking for more that's kind of a problem because there's so much that can be done with data. If you're only doing the same things with data, they were doing five years ago. That's a similar type of problem. So we people on this webinar and data professionals in general, are really need to carry the church for the organization. We really need to have representation where these decisions are made about what we're doing. And in many cases, only we know what the possibilities are, especially when it comes to AI and advanced uses of data so be assertive. Get that information out there capture data at the most granular level, and bring the data to a data quality standard of all artifacts in the enterprise. The one that has the highest data quality standard has got to be master data management, because that is, first of all, it's your, it's the data that all the applications are going to be interested in. And it's going to be the most leveraged for that. And projects then become a series of subject area mastery. So you cross reference your applications to your subject areas you build out those subject areas. And yeah, there's still work to be done. But imagine if you're trying to upsize or level up your supply chain management to machine learning from whatever it is right now. And you already have customer you already have product. You already have part you already have site. You already have machine etc etc master. Aren't you so much further along. And isn't everything going to be changed over to machine learning in the next few years. I think it is. And so master data management is an important core component of where things are going here's what we're doing with MDM now. They're great. Don't get me wrong. Customer deduplication name and business matching customer profiling for marketing and operations, product catalog supply chain management, network management and identity management. Okay, great. Our great starters for MDM and a year or two ago they probably wouldn't have been starters they would have been advanced uses of MDM but now we've got to move along into machine learning and political applications. And some of the things that I'm going to get to as we get along in the presentation. So, you say well I already have MDM in place it's doing some of these things that you just talked about so what do I need to do. Okay. And MDM futures for you, add the analytical or empowering as I like to say attributes to your model. Most MDM is operational in nature right now. And that means that it's a great place a database basically where the data is collected and distributed from, and it's eliminating the point queries and point to point data integration, and that's a great thing. And that pays for MDM by itself. So that's all great. But we're trying to go on from there. And so analytical attributes can be calculated at the MDM hub which is great. And added to the model. And after then, all those attributes being added out at the application level, where it's not leverageable. There's that word. So, let's do it in MDM word is leverageable. And to this end, I like to bring in transactional data to MDM. I know that's kind of hearsay. I'm not saying I'm going to store it though. I'm not saying I'm going to bring it in. And I'm going to use it there to glean the analytical value out of that and add those attributes on to the MDM database data model let's say for customers say this is the last purchase date. Isn't that a great analytic last purchase date. Well you don't have it unless you're collecting the transactions, or maybe you're allowing some other analytical system to develop it, and then you're collecting it out of there. Well, there are cases where I might say that's okay but generally I like to, we're possible. I like to have the analytical attributes in MDM and have them distributed from there for all the reasons why you want to do MDM in the first place. And this we call analytical MDM, but it's still an aspiration for many of you add more subscribers. What about the data lake being a subscriber to MDM. I say this a lot I don't see it happening a lot. We put it in our road maps we try to build that out for our clients. So, the data lake data to the data lake. Yes, I know the data lake is, it's supposedly for data scientists. But many of you are using the data lake for many more things. Now that you found many more things to do with the big data that we're putting in there we're finding it's not just for data science anymore. And so the more pedestrian uses that are happening to that data need master data. And so it's a great place to put it you may not be doing that yet. How about at the edge in the IO in your IOT architecture. That's another great place for it because out there, we're not just storing flat files we're storing databases, we can store MDM data, and we're also doing a lot of processing at the edge today that's a really fun place to be. But MDM is definitely a part of that as well. So I'm not going to know that you're going to get into this conversation sooner or later, and we're not going to solve this here today because I clearly lean into MDM. Others may clearly lean into something else like CRM. And if I've run into situations where if you over rely on CRM, or master data management functions, you could get in trouble, like for example for CRM systems have different customers, or to the point where one client could not send out correct invoices only 40% of the time where the invoices correct that's a big problem customer names were different. You can't roll up. That's what solely relying on CRM for MDM will do to you. So, I'm going to lean into MDM and suggest you're going this conversation maybe in your near future. If you're an MDM advocate for your organization. If you're more operational I'm not saying don't do it, of course, but I'm saying even it should get its master data from MDM. There is a lot of functional overlap and that's why there's confusion, by the way, these are some sample applications that you can improve with MDM. So, I may not have your industry here but I have some for retail healthcare manufacturing and financial. Some of the industries are doing things like let's take, for example, healthcare. These are some of the subject areas that we see mastered in healthcare patients providers locations supplies donors and reference data, and the applications are around clinical practices, enabling the best clinical practices to get the best outcomes. And drilling in on that a little bit further. The objectives with MDM today are to enable data sharing for research and operational efficiency. These are some of the things that they're doing in healthcare that utilize MDM really MDM is alive and breathing and well, and a truly a part of the valid ecosystem of today and tomorrow. So, that being the case there's a lot going on with MDM in retail for example, these are some of the objectives that they're targeting analytical objectives improve the average order size, a foundation for a program CCPA compliance, enable the online ordering fraud detection real time recommendations, yeah all this, you need MDM for one would only have to spend about a half an hour for each of these cross referencing them to subject areas to know that these are based on subject areas. So for example, customer fraud detection, looking at that most fraud detection today is very transaction heavy they look at the transaction on the face of it and decide whether it's fraud or not. Okay. So if we break it down, we sync MDM out to the edge there are different customer attributes that we can include in process at the edge. The last end transactions, average high low transaction profiles, the state the customers in and I don't mean Florida or Georgia or whatever I mean, the state that they're in, well those actually may have applicability but I'm talking about whether it's a new customer an advanced customer, maybe gold silver kind of thing you might have or maybe an attrited customer. That sort of thing the state that the customers in with you maybe they're unhappy or maybe they're really happy customer financial profile, and their ability to consume your products in multiple areas and so forth. So what subject areas are data domains. Would I build out for that particular application customer product store contract and policies. Okay, probably more you're probably looking at this list and going well, I can see different things assets equipment I can see all that being necessary yet. You can get to that level, and that that might help out quite a lot with customer fraud detection, but I've circled the basic ones so these are the ones that you want to have mastered for customer fraud detection, or the application is going to do it on their own it's going to be less interested. Long term. So real time recommendations. If that's your application your analytical application, you want them to be the recommendations to be real time and relevant. You want to combine customer demographics purchase history and activity and match the historical and session date. So you're looking for probabilistic models, and the accuracy and the scope increases with more data being brought to bear on the recommendation. The recommendation can be shallow and look at transactions that haven't been processed and turned into analytics. That's, that's not interesting. You want to know that customers transactions over the course of time. Like I said, bring the transactions into MDM, glean out the analytical value, add that to the, the subject area, in this case, customer. And, and then let the transactions go on to the data warehouse or the data lake wherever they're going okay we're not trying to store the transaction, but we can get this kind of value. Out of it. How about anti money laundering. They need subject areas like trading partner company creditor customer. So the schemes today are sophisticated it's no longer walking in the bank stick them up. Okay, some of you remember that kind of bank robbery right, but it's way more sophisticated than that. There are multiple criminals working together across the world. So we need to look at patterns of activity in real time. And we need to look at transfers and things like smurfing and that sort of thing. We mustn't also meet anti money laundering compliance, if we're in that industry, and we need to pursue cases faster all these reasons mean that we need this data master. What about supply chain management. Well, supply chain management is interesting because it's one of those that you can, you can do a lot with a little with a few subject areas mastered. You can really do a great job in your supply chain and these are some of them shipment carrier delivery transport material material group, these are there's a lot of these are smaller in nature, then some others. And customer could clearly also be a part of this which would make this huge, but you can get by with a lot of the smaller subject areas that you see here now some of you might say well that's, that's reference data. Yeah, okay, we can call it that, if you like, to me reference data is master data, just maybe smaller scale master data, maybe one that I don't have to assign a data steward for and hold jazz meetings and this and that and the other thing to make it happen. Maybe it's pretty straightforward like geocodes maybe you're just buying that from a third party. It's just continually kept up to date with the third party. There's not a lot of controversy around geocodes and whether they're right or wrong. But when you start to embrace controversy around the build out of a subject area, then you need your data stewards, because you as a builder of MDM and I assume that most of you are, if not excuse me but for builders of MDM. We shouldn't be making business decisions around what actually constitutes the master data. So where do you look for MDM opportunities. Well they're all over the place. The products you make and the services you offer the supply chain for those products and services. Business operations, how you design your product in your service set, your marketing and approval funnel and so on. So really there's a lot of places you can look for opportunities for master data. Pretty much what I like to do is look at what do you have implemented and what's on your roadmap, because we can always re-engineer and level up what's already implemented. And we can always engineer what's coming down the pike in a better way. So here's a little reference architecture. This one I am using some Azure components here but obviously MDM is for everybody. This is a Dynamics 365 example where the MDM metadata is published to the data catalog. The data catalog is then populated with lineage information from the Azure data factory. MDM can then leverage that data to display it and MDM can also publish master data to the dimensional data models of the data warehouse and the data lake if that's the case. Now this is a very simple architecture. What I like to do is teach a full machine learning stack and there you can see how it fits with everything going on, including the Kubernetes application environment and all that sort of thing. But this really gives you the idea of master data management and where it sits in the grand scheme of things. There it is. I forgot to click that in there but right there in the middle of everything. Right there as the heartbeat of data for the enterprise and the important data for the enterprise too, I might add. So, is an MDM tool needed? I already tipped my hat a little bit earlier, didn't I? And I said that I think you need a tool. But these are the relevant questions that you might get asked or you might want to ask yourself before you go too headlong into this. Is there an existing system in our organization that can serve the need? Well, I'm always going to play devil's advocate on these questions and say that probably it's serving the need but maybe not as well as MDM. And MDM does it very well, does what it does very well, originating the data, distributing the data, cleansing the data, having a great data model that's built for the enterprise and so on. Are our data management processes and governance established and effective? These are something you need for MDM and I would say if not, then that's just that just becomes part of your work doing the MDM project. And maybe when you are tasked with doing MDM, quote unquote, doing MDM, that's a different scope entirely from when the person at the company across the street got tasked with doing MDM. Because maybe they have a great support system around them. They have full data governance already in place. They have great DevOps. They have a data quality culture. They already have a data warehouse, etc, etc. And their work is just building the MDM hub. And oh, by the way, all the applications are eager to roll their sleeves up and come into that MDM hub and pull out the master data that they want. But you have none of that. And so all that becomes part of your project. So it's really hard to compare. You know, I get this question a lot about how much it costs on the people side of things. Well, I got to ask you 20 questions back before I can do that effectively. If somebody's just thrown a number around without asking questions like this, then you really can't trust it. Do we have clear and reliable data stewards we can depend on? Is it worth replicating the functionality of an MDM tool when we're close to meeting the needs without one? You might get these questions. I don't think they're great questions. I think we have to come back on these with how much better MDM is, but nonetheless. Is there a great centralization in place? So a great centralization means a great MDM outcome, because honestly, I know it's a dirty word, but we are centralizing here with MDM. I don't shy away from it. A little bit's okay. In an organization, I know we're all moving to data meshes and decentralizing everything, and we might even decentralize MDM. There may be bits and pieces of MDM out in various business departments that make sense for them. I've got no problem with that if that's what makes the thing get moving. And maybe that's what's right in the long run for them, and maybe MDM itself has to be distributed. But we start with a centralized MDM for the company. And we back off of that as needed. Okay. So here's a bit of an MDM roadmap. This is how I recommend MDM gets rolled out. Now that you've, your appetite is wedded for MDM. So I have some of the preliminary stuff on here won't belabor that tool procurement and installation, business prioritization essentially it's doing the roadmap stakeholders and the roles because business has a lot of roles in MDM. First, I will belabor this point because it's important. If you're tasked with doing MDM, but nobody on the business side wants to contribute to that project that is a red flag. That is a problem because this is pretty heavily business role dependent so you got to get a few cycles from them so to make sure to make sure you build out the workflow right to make sure you build out the data model right. So the data quality rules right because if not, they'll know when you spring it on them, and you'll be doing it over again. Okay, what kind of architecture are you doing workflow and data flow etc MDM lifecycle planning but here's what I want to get to noticing q3 we're starting with customer. Now I'm not saying by any stretch of the imagination. I know for a fact that customer, the customer build out for you is going to be two and a half quarters. No, I'd have to ask you. I think 40 questions in order to get to how long it's really going to take and how much it's really going to cost. But at some point of the point of this is at some point during that cycle. You see the value. You see the finish line. I love it when I feel like I see the finish line to me it's it's done it's a done deal at that point. That's the time at which hopefully the organization will want to bounce some of the resources the MDM resources offer customer and under product. And hey, it might it might be a totally different set of business folks that are involved when you bounce to product that's okay. I think there's some strong leverage from the build team that did customer because essentially it's the same thing and at some level. At some level the technicians need to just concern themselves with fact that they're doing MDM for data. Now, you or somebody like you needs to know that it's customer data and all the intricacies of that. And that's also why you have business participation from that particular subject area. We move on from customer to product and supplier. Well, how did I, how did I get there in the first place how did I pick my targets in the first place well. I look at the roadmap, and I look at where the business value is primarily that's number one but there's a number two and a number three here. What's easy to do I like easy. I like easy wins. Let's put that on there. And what's a prerequisite for something else. Some of these subject areas naturally come before other subject areas. And so you we don't want to do them quote unquote out of order so. Anyway, what I'm not building into the roadmap you see here what I haven't built in is time for subscribers, you will have to allocate some time. For each subscribing system, more upfront early less later on in the program. And by the way, I say program. I don't know, and I am teaching you here today, Enterprise MDM, not application oriented MDM. I'm teaching you to build once use many times. And so my point that I was going to make is that what was it we're trying to stay ahead of the build cycle for applications by building these subject areas out was we're going to have to come back and tend to them for probably at least the first year after it's in production. Maybe even on an ongoing basis, the point I was going to make now remember is that I don't know if anybody that's done with their MDM program they go on. Some programs have been around now, what six, seven years, maybe even longer. But even those programs are still moving on they're moving on into new subject areas, my very best programs, the ones that that I know are really knocking it out of the park with MDM, the their heroes of their organization, as it were. They're moving into new subject areas. By now, the early subject areas that they build out are pretty solid, because they thought about enterprise requirements, and they did as much as they could every time that they touched it. And they, they put a footprint down in the organization that this is where master data is. This is where you come and get it. So quit rolling your own out there, come and get it here from the MDM hub, and that feedback loop has really helped make their MDM super solid. If you don't have that feedback loop, they just have one application using it, and maybe they're grabbing your data and then taking it off into all sorts of gyrations before it works for them. So that's, that's a lower level of maturity for sure type of MDM, but all kinds are out there. We are building with master data management data as a service. And so, we have to think about our service level to the company to improving for improving those analytical applications with MDM so how far do we go. We the build team how far do we go. Here's an SLA for the master data. Here's how you come and get it. Here's how you get on our roadmap. Okay. Budget is part of that here's how that's how you get on the roadmap, MDM communication and center of excellence type approach. Yes. Integration planning that's a that's the big question here. Who's going to do the integration. You might think that I'm spending way too much time talking about this point. It's a great time experience. The MDM build team thinks that it's come and get it. And the application team thinks that you're going to, you're going to give it to us, push or pull right. It depends on which perspective you're, you're, you're in here. And personally, I think most of the time for me anyway, it's, it's fallen on the MDM team to do the pushing of master data and the integration out to the application. Unfortunately, that means that we have to learn a bit about the application which well the application team already knows so this may not be the most efficient place to put it. So either way, there's some work to be done. The hub model and rule expansion how do we get into new data, how do we get into new rules, etc. mapping the elements which comes before the integration right doing the mapping, what elements do you need. I found it very few and far between that I've been able to push the whole subject area a whole subject area out into the business into an application. The application usually has specific needs, and we got to collectively we have to learn them and meet them. customization of elements and the data quality rules for the subscriber we want to be sure that we're exceeding the data quality expectations of every subscriber down the line and every new integration will have some of this. Every new integration will bring change. And that's okay. We're really on. You want to minimize it, but you can't be perfect about this and you know that some changes going to come to it. Now, all that being said, MDM data is relatively small it's not big data. MDM is not big data, it's part of the big data ecosystem, but it's not big data, it's small data, it's quality over quantity, I like to say, it's nimble, which means it can sit on the edge, it's accessible, shareable, it's high quality. The hub itself is a touchstone for the enterprise, including out to the data lake and with MDM you eliminate point to point integrations. Hopefully you're doing that. So I talked a little bit about this before here's a graphic on it so on the left you see a bunch of what I call core attributes. This is these are operational attributes. These are attributes that are basically one on one to the subject area whatever it is in this case I guess customer customers birthday, first name area code things like that. They probably only have one of them, but they may only have one of the empowering attributes as well but it's more complicated than that. These are more complicated to build out like just take a look at. Oh, I don't know lifetime spend that can increase any second now anytime they're making a purchase that can increase. So it's harder to do, but it provides a lot of value and frankly that's where the value proposition is today for MDM in these analytical applications. It's not in the core attributes that hopefully is is done. It's in the empowering attributes. And this is where I mean the processing always always has to go into more complex areas. And this is it. Take a look at some of these propensity to churn. This is obviously for kind of a retail customer but I'm sure there's applicability here to where whatever you do propensity to buy a particular product propensity on social propensity is one of those things that I hope machine learning is doing that I hope we're using machine learning algorithms to sort through all of the data and figure that out. And bring that into MDM. So, another reason, a big reason why analytic or analytic leaders are deploying MDM, it's where MDM is going. And these are some of the great things that is happening to MDM, and that will be bringing additional functionality to MDM in situ matching is matching of data sets using geography boundaries and attributes in GIS software. MDM will use government governance policies from the catalog and governance platforms and enforce them within the business application, which means active bidirectional flows are required. Often, these policies recommended by AI, these policies I'm just talking about here, they are recommended by AI more and more frequently. So, there's also integration with data catalogs and governance platforms, many of which you all have deployed, and you've been looking for this third party data sharing on the blockchain. I thought blockchain was dead, I thought it wasn't taking off well, I think it has some real applicability here with MDM with data integration in general but with MDM blockchains will be slowly integrated to allow for consensus of the data quality rules of the workflow items. So whatever you're bringing into MDM, oftentimes there's a process, the workflow process to it right. Well, what a blockchain can do is add a voting mechanism into that workflow do we want to bring this in is just the right way to do it. And that sort of thing. So it can support real authentic and validated types of analytical attributes in MDM and multi dimensional hierarchies. AI supported and decentralized stewardship and adaptive data governance and modeling, which allows for governance policies to be to be dynamically applied at the point of creation. There's a lot of consumption of the data based upon the recommendations coming from the governance platforms with or without human oversight. So, I think a lot of data integration, as well as master data management is going the way of artificial intelligence. I think that a lot of the workflows that we're building that we should be building, by the way, but a lot of that will go away as AI starts to take over how master data is created and sort of does it the right way without a lot of human intervention so wherever we have a lot of human intervention. I think that's kind of ripe for MDM and certainly for AI, and certainly there's some of that in what we're doing here in master data management. So, that has been the formal part of my presentation. I see that there, there is some Q&A Shannon so turn it back to you for that. That is indeed William. Thank you so much for another great presentation and just a reminder and answer the most commonly asked questions that we will send a follow up email by end of day Monday for this webinar with links to the slides and links to the recording along with anything else requested. Diving in here William on the slide with the real decision points on in the title. What are your thoughts on data mesh and data fabrics considering you're talking about data lakes and edw. Let me find that slide. So, I assume this is the slide. So, these decentralized forms of organizing your data like the data mesh the data fabric data lake house, even the data cloud, and these are, they're not, they're not mutually exclusive, we could be doing many of them we could be gleaning ideas from all of them. In our architecture and that's really what I encourage us to do not, not try to even think that there's some some global standard for what a data mesh is and even really caring about that we should be caring about being successful as a business and supporting the business and to the degree that those things help. Great. So, how would it work. How would we have and I'm going to pick on the subscribers, the data warehouse might be a subscriber I said here the data warehouse might be a subscriber to master data management data. And if the data warehouse is organized let's say in a data mesh fashion well that just simply means that there are departmental level or domain level as they like to say data warehouses out there. Probably all of them need the master data. So just, it just means multiple data warehouses that need to get the data from MDM so wherever that master data is going to be needed. I want it to be the data from the MDM hub. That's kind of the bottom line. And if it's the data warehouse or the data warehouses or the data lakes or anything. I want it to come from MDM. I don't always get that, at least not initially got to prove your metal a little bit and do one or two with high touch, but sooner or later, hopefully you cross that chasm and all of these artifacts that are that get built that need this data come to you for that data. Yes. And so, can you give a client example of when edge products is a subscriber to MDM, typically, Internet of Things data structures are more minimalistic, for example time series most of the time IOT data is joined with MDM data in an analytical use case. Yeah, that's that that is true. But I can think of at least one where it's a toll tag company and out at the edge where they read the toll tags. Now they're pushing data from MDM about the various license plates that are that are registered. And so that they can triage that to the time that the car is crossing the threshold for the toll, and then they can cross reference that back to the billing system that's not all done at the edge don't get me wrong but that processing is done at the edge. And so the matchup is done at the edge if it was a car that they don't have the information on, then they're actually able to do something in real time, more or less about that. And I think we have time for one more question here at least. So what role does CICD continuous integration continuous delivery have with master data management. It's not really in my belly wig of things that I feel like I'm any kind of expert on so I probably shouldn't say very much about it. I don't do it. I subscribe to the concept but not some of the principles of it so I know it happens in at my clients but it's not something that I've had any interaction with. I like it and that does bring us to the top of the hour and there is a request in here and William for a future webinar which I will pass on to which I love with for MDM tool mashup. I love it. Well, William thank you so much for another great presentation thanks for all of our attendees for being so engaged in everything we do again just a reminder I will send a follow up email by end of day Monday with links to the slides and links to the recording of this session. You all have a great day. Thanks everybody.