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.  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?  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 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.  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?  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.   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?  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.  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?  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.  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.


Greetings fellow truth-seeker! As the Chi Master, it's been my lifelong mission to seek out those who are strong with their force and help them to unlock their full potential. I know that many of you feel like you're destined for something greater, that there's a power within you waiting to be unleashed. That's why I'm here to tell you about this incredible new technology called Chi Energy AI. With this groundbreaking AI technology, you can tap into your life force energy like never before, connecting to the universe in ways you never thought possible. And the best part we're offering a free demo that will help you discover whether you're force sensitive or not. Our team of experts have spent years studying the science of life force and we've developed the technology to harness it.  So what are you waiting for? Join me on this journey and unlock the power of the force within you. Head to this website now and take your first step to your path of greatness. Use the Chi and prosper.


Hi everyone, my name is Chi-Lin. I am an undergraduate student. Today, I'm going to talk about the low response time of forks by extending the copy on right to the page table. In this presentation, I'm going to talk about the process address space, which will include the virtual memory area and the page table. Second, I'm going to talk about the first season code from the history of the forks to the improvement like on-demand forks. Finally, I will talk about the feedback from the IFC patch that I sent into the value list previously. In the Linux kernel, the process is described by the test structure and one of the members is the MM structure. It is the memory descriptor. The MM structure will store the memory information like the size of the reset page and the memory usage of the page table. And for the persist, the memory areas will be described by the virtual memory area and it is stored by MM and MMRB in the MM structure. The process page table is stored at the PGD member and the physical memory you used is described by the structure page, which will reset in the page table. Each memory area is described by the VM area structure. A VM area structure is a part of the process virtual memory space. It is a continuous block of address space. Each VMA will not overlap their virtual address range and all the areas belong to the same VMA. The VMA can become the anonymous memory or the memory map file or either the device memory. There are some flags through the statements of the VMA, like the VM read or the VM write. It indicates the both page may be writes or read and they have the flag like VMA read to allow the VMA read to allow VMA read seeds to the VMA, the correspondence VMA. The process used linked list to link their VMAs which were stored by the starting editors. It is a good way to travel the entire address space and it also uses the red-black tree to maintain this. Although the kernel uses the virtual editors for costing the log-on times to search their VMAs. But the red-black tree has some problems. It lets the developments to have some patch to replace the red-black tree with the map poetry. Since the red-black tree does not handle the log list implementation to do the balanced operation and the traversal is not as good as you think. So here is the layout of the linked list source of the VMAs. At first we have seen that the test structure I mentioned before and the member of the VMA will point to the M structure and the M map member will point to the first node of the linked list of VMA and each VMA will describe their areas which will be like the shared library or the data or the task. And you can use the process file system to get the information of each areas. Like here you can see the starting editors and the end editors and each the statements of the areas you can assist. On 64-bit architecture there can be five level fetch tables to describe the virtual editors in your process. Each level will use the part of the virtual editors to specify the layer index to indicate that the next level or the next physical patch where it is. And each patch table has 512 index with 8 bytes long value. It will store the next level's information. And for a huge patch, two megabytes huge pad will reset in the PMD entry and one gigabyte huge pad will reset in the PUD entry. Here is how you use the virtual editors with patch table to travel out the physical memory where it is. As first you use the MN structure's member. As first you use the PUD which is the MN structure member to get their own process patch table. You will get the top level of patch table PUD and use their part of the virtual editors to use the offset function to get their index and point out to the next level. And at least in the lowest level PTE table you can also use the offset to get the corresponds structure patch which is describe the physical memory. And at least you can use the lowest 12 bits of the virtual editors to get the triggers that the virtual editors will indicate to get the object you want. So the patch table will be protected by the read write system which is the patch table lock in the MN structure. And it does have provide the split lock of the patch table to improve the performance like the PMD and the PTE have their lock if you turn on your config. The patch table are located by the physical memory which is from the body system and it so it is not from the slept allocator or others allocator that's the kernel you used. To fill the patch table you can you need to use the free pg tables function and for remove the user patch in the patch table you will you you will need to use that patch range function and it will call to the unmapped single VMA functions. The patch table index entry have the present flick when you clear the flex it means that the next level or the next level patch table or the physical patch is in the swap or they never assisted. For PTE entry which is the lowest patch table level you need to first convert to the patch frame number then you can you can use the sum function to get the structure patch and it is related to the physical memory model which is out of the scope in this slide. We will not talk about it at here. So here we are starting to talk about the fourth season code. The history of fourth season code is the fourth season code is starting is first mentioned as 1963. It is simplicity and clear clear v at first which is as the unix version zero it is implement by 27 lines in pdp7 assembly. As last time the fork is simply and easy to do the concurrency usually it is used as fork and exclusive pair to create the newest new process but current in a modern operating system you need to consider a lot of things like the pin page or the locker and the timer or either a serialized IO. In the Linux kernel all the functions for creating the process were called a kernel clone and it uses an argument to specify what should be shared between the calling process and the child. For the user space they have three system code functions you can use to create the process. First the clone system code has the 32 bits flag and it's all used. So if you need more bits to escape more flag the development introduce the clone three-season code. The flag of the clone three-season code is wider it is 64 bits and it also can resize the argument to allow the more bits to represent the flag that if you want to use in the future and the v4 is useful in the performance density implementation and it does not copy the patch table from the parent instead it will reuse the parent's patch table and also it uses the wait for complaint mechanism to block the parent until the child finished their work but they have some restriction between the v4 and exclusive like it cannot do the allocation and the lock and in addition it has the the user space can also use the process spawn to create a new process and it's just like the v4 plus exclusive but it it's just the wrapper function. The process spawns use the clone system code and it uses the clone vm and the clone v4 flag which the clone vm will share the vm between the process and it just increase the reference count of the mm structure and the clone v4 will block the parent until the child releases it released and the process spawn is fast and lighted since it does not copy the memory from the parent and for the fork it will copy the virtual memory from the parent it's not it doesn't see the clone vm flag to the kernel clone and it will travel all the entire vma list of the process and for each vm if it is the memory map file it only just increase the reference count of the vm and add it to the shared area otherwise like the normalized physical patch it will call the copy patch range to travel through all the patch table and copy the corresponds patch to their for their memory areas and it need to hold the mm structure and main block and as usual it will copy the pgd p4d and pud table since the huge patch resides in pud and pmd entries it needs to consider whether the entry is a huge patch or a patch table and for a pt table doing it will do the copy pt range and for a patch it needs to handle something like a swap or iss date and the pt lock and a copy on writes the copy on writes it does not copy the entire physical patch when turning the fork and it will just copy the pt entry to the child process and see the representation on the both side and it does not do the copy on writes when the last patch is pinned by the parents also adds when doing the copy on write the patch the physical patch it will update the iss statements to the mm structure and it's need to maintain the reference count of the physical patch since it will be shared and the copy on write will defer the copy work from the copy pt range function to the patch force and when so it is when someone want to modify let's share page or the object the write force authors then they will do the break copy on write which means that he will copy the page and let's the corresponds process to reference let's copy the patch so in the x86 it will do the break copy on writes in the do write protection page function but they have some problem with the gup pinning which will fix as the recently patch series and we'll talk about later so the currently copy on writes of the physical patch will be like this it's after the fork the physical the physical patch will share between the parents and the child but the parents and child will have their own page table to describe their virtual editors and here is something we can improve it that we can explain the copy on write to the patch table to reduce the copy work during the fork and let's the copy work to the patch for like the physical patch let's do this before so the idea is come from the previous year's paper the on demand fork on demand fork is do the copy on write to the pt table which is the last level of the patch table and it's it's and it's does not do it on the shed or the brk or the nominance vma and you need to be careful about doing the copy on writes to the pt table multiple times during the single fork it will be the problem it will be the problem since you will do the copy on write twice or main or either the multiple times during the single fork and you expect that you will only do the ones times as one it's the same pt table so the on demand fork deal with this with editors with only a only do the copy on write to the pt table let's the tape the address range of last table is fully covered by the single vma and it's at the break copy on write to of the patch table in the handle mm fault so why the on demand for only do the copy on writes on the pt table because the latency problem is mostly reside in the pt table and the physical patch since you will acquire the pt lock and the copy of pt table and the pt table is most is the most used in the patch table since it is lowest level of the patch table and it's need to assist the like the reference count which is auto operation and the overhead of it is very expensive and to avoid this it will skip the assist to the pt and the physical pedal which is doing the copy on writes and it does not increase the map lock m does not increase the map comps of the structure patch and the map comps is doing the cop is doing the counting the reference from the patch table and it's use the reference count to control the lifetime of the shared table and the shared table will always become the read only and when the reference and when the reference count is zero it will free the shared shared table and the currently copy on writes physical patch mechanism will be reserved and there is some other information for sharing the patch table here when the address range of the vma does not cover all over the entire pt table then it will not do the copy on writes to that table like the left of two vma but when you cover the entire pte table and you can do the copy on writes like the right the right most size of the vma so what did i improve that i do some things based on the undemand folk but there's some difference the first i reuse the table when the reference count is one and i do something trick to let the range of the patch table available to the copy on writes and let the more larger range of the patch available available to do the copy on writes and it's still only implementation on the pte table and also excludes in the shared and brk vma and i introduce the ownership for updating the patch table states like the rss or the pg table bytes to their mm structure since it will reuse the table and the patch tables and because of this the patch table state of the child will not synchronize the patch table state to their mm structure and it will become more complicated than the undemand folk but the memory usage will be reduced since you did not reuse the shared patch table and oh and my patch my patch will allow the range of the vma can cross over the pte the undemand folk use the address address range of vma and the pte to avoid the multiple time of copy on writes in the single fork and my idea is simple because the patch table memory the memory of the patch table is allocated with the gfp0 flag and it will initialize that memory by zero so we will know that whether the destination ptmt entry has been met to the source pte table or not so as top side of the vma it will first assist the top level of the top side of the pte table so the top side of the pte table will be while doing the copy on write pte and when we travel to the next vma the next vma will assist the same pte table and switch it on it's already do the copy on write pte and it will not do it again since the corresponds pmd entry have the value and when that vma travel to the next entry and well and it will do the copy on write to the last corresponds pte table and will update the destination of the pmd entry so it's well fully copy do the copy on write in the two entry which will allow the vma across the pte table so here is the finite finite finite stand machine as here you can see when the normal process do the copy on write pte for the parents when the parents the shared the shared pt table statement statement you can see here the reference comes will be comes to and the owner will be will be the parents and the parents is that have it and the child does not update it and when the parents or the child fork and it will goes again to list statement but when the when the child want to write last shared pte table or the following physical page it will do the break copy on write and the reference count will be decreased and the child's RSS will be updated and after that when the parents also writes it the parents will reuse the shared page and will come back to the initialized state let's come back to come back to the shared statement when the parents want to write to the shared pt table it will release their his ownership and decrease the reference count and it will the child the child RSS statement will preserve since it does not know the parents do the right fault there but when the child want to write last shared pt table it will know that there does not have the owner and we will reuse last the shared copy copy on write pt table but when the child want to fork it will the child will get the owner and the reference count will increase and the child of the child the RSS statement will not update again since like the previously parents and the child relationship and it just look again so here is the benchmark of the one gigabytes mapping of the fork the following information is from the process memory information the total memory usage is 32 gigabytes and the left side is the default fork as you can see the page table memory usage will increase almost twice times but when you use the copy pt copy on write pt it will just increase only 100 kilobytes and the performers in my implementation the let us not in does not not reduce the latency or increase the time but from the on demand fork it does have the improvement from for the latency from the latency of the fork so it seems like does not have the the problem with my patch so I send the I see patch to the mailing list and I allow the user to use the clone flake to enable the copy on write to the pte table and here is I change here is the statements I change and yes I get the feedback and the first is that it's don't need to explore the copy on write to the user since the current currently the copy on my physical patch does not have it and why should you do it to the copy on my patch table so probably I will change the clone effect to the system control file or the kconfig and second it's lack of use case the developments are not confident yet since the one gigabyte mailing fork is not actually use case it is too far from the real world and even I provide the snap shopping of database use case from the on demand fork it still have has a better choice like the user for fd reportations and it's well that's the copy on write and the fork implementation become more complicated and they just have the bug of the copy on write physical patch with duping pin and have been fixed recently and the copy on write physical patch use the statement of the patch table and the structure page to control it and now I just propose the copy on write of the patch table so it's just more easy easy it's just make more complicated so what does the duping pinning do the duping pinning is it just called a function mac the get user page it will pin the user page in the memory and it just do the map the user space memory to the kernel space and it's pinning by increase the reference count of the physical page and since the copy on write and the duping is all dealt their implementation with the reference count it's have some problem when they come together so the currently copy on write implementation will skip the pinned page and it's they all have the bug but fixed recently and here is some discussions here and here is the user for fd of the write protection the user for fd system call will create a file descriptor for handling the patch for in the user space in the user space it will receive the user space the user for fd write protection will reduce the memory region with the list flag and it will receive the patch for notification when the write protection page page is written and it is a better way of improve the snap shopping presenting the cumulus already use it and the radius that I mentioned before the site that use the snap shopping of the database is tends to use this too and so when I make this slide I just saw the previous related discussion from the 2011 and the discussions topic is that as the process size increased a lot of folk performers will be plummeted the duplicates the duplicates the patch table from the parents to the child will affect the folk performers and in 2018 a conclusion was come up and it's just use a posse response to avoid a copy patch table and it the posse response have some problem at the 2011 and it just fix adds amount of the 2018 so it can use write snap and it was the better truth when you want to avoid the copy work from the parents from the folk there are still some other things need to deal with the copy on my page table like the interaction with the mapcom reference cons and the statement of the anonymous page and the get user page I need to deal with this too also the swap page table worker and other stuff that I have list in the following so I just now I now I just have idea to fix the mapcom and the interactive with anonymous page and the get user page and swap and the patch worker but the following that's just still in the to-do list so even we fix all above problems do we really need the copyright of the page table the the fork is an odd implementation of creating the process since the fork is simple as first proposed at first but it comes complex right now and still it's still need to consider the issues like the security that the child will replicate the entire virtual editor space of the parents which will have the same memory layout and the hacker well can easily more easily to attack the parents from the child from the information of the child and it is slow after the fork since the copy and write just deferred the copy work to the patch fault and when you when you are doing the break copy and write you need to allocate the physical memory and do the copy work which will cost time and as David said it just not convenience that when you are doing the sum optimized for this things that will increase the additional complex complexity and he also mentioned the Microsoft research that is a fork in the root age is discussed the fork from the beginning and he was development and how it is worst in the modern operating system and said that it cannot do the things for the fork which will affect our operating system design so what's going on next let's still have some choice to avoid using the fork like the policy spawn or the v fork but the fault is still in use in some other in some case and when the process patch table is big enough it will be slow however improve the performance with the copy and write patch table will increase the implementation it will increase the complicate of the implementation and it is not easy to maintain and it needs more realistic use case to preserve other developers that it is still have has a benefit for this patch when we include a maintenance work so it's still have a lot of room when the copy on write of the patch table wants to merge into the mainland and thank you for listening thanks


Rocket science of being a teacher. Teachers are arguably one of the most important figures in society. They are the people that shape and influence society. Teachers have been around since the beginning of time. Some remarkable teachers such as Jesus and Buddha, continued to leave their influence on society today. Many great teachers have similar qualities, it doesn't matter where they came from. What made them great, was that they had a passion for what they taught, led by example, and had a sincere desire to make a difference. In my opinion, the role of a teacher is to have these three qualities and the rest will follow. Teacher's attitude. If teachers have a passion for what they teach, it will have an effect on their students. Passion can be contagious and the students will feel more inspired to learn. By having a passion, the teacher will always be reading and updating himself or herself. They will always be updated with what the best teaching methods and strategies are. In an ever-changing world, a teacher's role is to be constantly updating themselves. Students are continuing to change in their needs and teachers need to adjust. Furthermore research will continue to change on what the best teaching methods and strategies are. Role Model. The next teacher's role is to lead by example. For example if a teacher is teaching a second language, they should also be trying to learn a second language. How can they convince their students that learning a second language is important, if they are not learning a second language themselves? Furthermore it helps them to better understand the difficulties students go through in learning a second language. Teachers will know what methods help them to learn a second language can also help their students. This will make them a better teacher. Lastly, a teacher needs to have a sincere desire to make a difference. Teachers have to do a lot of research and back work that they will not get paid for. However a teacher that wants to make a difference will do these things without being asked. A teacher that cares about his or her students learning, will do whatever it takes to make a great learning experience. This may mean buying learning materials with his or her own money, or spending unpaid time to continuously educate and update himself or herself. A teacher that sincerely wants to help, will not keep score of these things. Do you want to teach English abroad? Take a TEFL course today. When the teacher has the three qualities listed, his or her role will become obvious. The teacher's role is to do everything in their power to become the best teacher they can be. This means constantly reading and updating oneself about great teaching methods. This means constantly educating oneself on the material that they are teaching. Lastly teachers need to care about their students. By developing a rapport and getting to know their students, they will know how to cater to their individual needs. The students will not feel afraid to communicate their struggles, and the teacher will be able to help them better. This is what I feel the role of the teacher should be. Thanks so much for watching. We are ITTT the leading provider for TEFL and TESOL training courses. If you like this video, please subscribe by clicking that button down here and click on any of the videos here on the left for more interesting teaching tips for getting certified to teach English abroad and online.