 My name is Shannon Kemp and I'm the Executive Editor of DataVersity. We would like to thank you for joining Julie's installment of the Monthly Data Webinar series, Real World Data Governance with Bob Siner. Today we'll be discussing governance for master data. 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. For questions, we will be collecting them via the Q&A section 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 RWDG, Real World Data Governance. As always, we will send a follow-up email within two business days containing links to the slides, the recording of this session, and additional information requested throughout the webinar. Now let me introduce to our speaker today, Bob Siner. Bob is the President and Principal of KIK Consulting and Educational Services and is the Publisher of the Data Administration Newsletter, TDAN.com. Bob has been a recipient of the Damon Professional Award for significant and demonstrable contributions to the data management industry. And Bob specializes in non-evasive data governance, data stewardship, and metadata management solutions. And with that, I will give the floor to Bob to introduce the webinar and today's presentation. Hey, hello and welcome. Thank you very much, Shannon. I think the heat's getting to all of us. Actually, good afternoon, everybody. If it's afternoon where you are, I hope you're staying cool. I'm in the eastern part of the U.S. and it's my computer. It's 93 degrees outside. So it's pretty hot, but we think that we've got a pretty hot topic for the Real World Data Governance webinar today. I'm talking about governance for master data and if the number of people that have registered for this event is any indication and the popularity of a session I gave last year somewhere around this time was any indication, it's certainly still a hot topic. So what we're going to do today is we're going to spend about an hour talking about governance for master data and I'm going to try not to repeat a lot of the things that I shared in the previous webinar on a similar subject to this, but I'm going to use potentially a couple of the same slides and maybe expand on them a little bit to the point where people really understand the relationship between governance and master data. So let's get started with the session. So again, thank you very much for attending today. Before we start it, I just wanted to give you an update on the sessions that will be held, the monthly installments, as Shannon mentioned, of the Real World Data Governance webinar. These are the rest of the sessions for the month of the year. I think that next month is going to be a really interesting session. If there was any indication from the Enterprise Data World event, which is another Data Diversity event, when they give you a presentation, a half-day presentation of the same title, good data governance to great data governance will be a little bit of a play on the book by Jim Collins, which was Good to Great, and he talks about why some companies are able to successfully make the leap from being good to being great, and I'm going to talk about it in terms of data governance. So how do we make the leap from good data governance to great data governance? You can see the September, October, November, and December sessions are quite interesting subjects. So I'm hoping that you will be able to either find time to register and attend the sessions or certainly look up the information on DataVersity.net, and then pay any visit during the session and provide some feedback on what you think about the topics. Actually, and when I start to define the topics for next year, I'm hoping that we're going to proceed with Real World Data Governance for next year. I'm looking for ideas from all of you who are listeners. Some of you, this may be your first time. For some of you, you may be regulars to this monthly webinar, but I'm looking for ideas for any types of webinars or subjects around data governance for this series, so please share that with me. What I do oftentimes in the webinars that I hold, I start out with the abstract. This is the abstract that I use to hopefully gain your attention and to get you to come and to participate in this webinar. So I want to talk a little bit about the relationship between master data and data governance. In fact, I had somebody tell me a while ago that everything about master data screams for data governance. And in fact, if you think about it and you look at where you find information about master data being published anywhere, they always talk about data governance in relationship to the development and the deployment and the delivery of master data. So if you think about it, it makes a lot of sense that there really needs to be governance around any data that we're going to call master data. So certainly you want people to consider the master data to be a reliable source of information, perhaps even certifiable source of information that can be shared across the organization. So you always tend to see data governance mentioned when master data is mentioned here about master data when you talk in terms of data governance, but certainly it is the other way around. When you hear master data, it changes to one of the hot topics that people like to talk to about master data is data governance. So we're going to direct people to this master data source. We want to make certain that the data that is in the master data resource is being governed, but the processes are around governance itself and around the development and delivery of the master data that those processes are governed as well. So here is the remainder of the abstract. We're going to talk about solidifying that understanding of what it means to govern master data or govern data in a master data environment. We'll talk about what I talk about fairly often because I break it down to simplify things into the definition, the production, and the usage of the data. And in this webinar, we're talking about the definition, production, and usage of master data. And not only govern the governance of the data itself, but the governance of the processes associated with that data. So that will be what we are going to talk about today. How many of you are new to this series? I'm hoping that there are some of you out there that this will be the first time for you and that there's some things I want to share just kind of straight out of the gate, which is the definitions that I use for data governance, the definition that I use for stewardship, and a little bit about the non-invasive approach to governance that I talk about all the time and that Shannon mentioned when she did my introduction. So I use the definition of, for data governance, I use the execution and enforcement of authority over the management of data and data-related assets. And a lot of organizations look at that definition and they cringe a little bit and they say that it's worded too strongly. And in fact, I just came out of a meeting here at my client with a couple of people and we talked about the fact that at some point in time you may need to stick, you may need the club to get people to do things, the enforcement of it. But I often say that we can do it in a, we can do data governance. We can put governance in place in a non-invasive manner, meaning that there's already levels of governance taking place in your organization. There's already people that have perhaps informal accountability around the data. So what we really want to do is we want to formalize that accountability and not make it feel like we're giving them a ton of additional work without giving them additional time to do it. In fact, the goal of data governance is typically exactly the opposite. We want to make things more efficient and more effective for people. And if we go around telling people what to do and we go around adding to their responsibilities and giving them new titles, their first perception is going to be that this is going to be over and above the existing work that they have to do when in fact, in a lot of situations, these people are already governing data to some degree. Sometimes it's informal, but they're governing the data. We just want to record who those people are. We want to engage them at the right time to do the right thing, to get the data in the right way, and to make the right decisions and all of those types of things. But we can do that in a non-invasive way. So non-invasive is applying formal accountability and behavior through non-invasive roles and responsibilities to existing and new processes. It's basically taking what we already have in place and formalizing it. Formalizing the roles, formalizing the activities in such a way that it doesn't feel threatening to people in their organization. So governance does not have to be like you're going around hitting people over the head with a 2x4. Governance can be done in such a way that people want to sit forward in their chair and understand how they can participate and what can they do to help because virtually everybody in your organization most likely has some level of issues around the data, whether it's the definition of the data, the production of the data, the usage of the data, the access to data. A lot of people have issues and we can get them to speak up and tell us what those issues are. We're together to solve the problems core body into data governance a lot quicker than if you go and throw it at them and say, besides for everything that you're busy with, 125% of the time, we're going to give you additional work as well. If you don't like that, I wouldn't like it. I'm sure that you would like it as well. So keep that in mind when you're defining your approach to data governance and specifically when you're applying your approach to the governance through your master data resources. So that's what we're going to talk about but I wanted to start about with these definitions because rather than saying that governance is about harmonization or the orchestration of people in process and data which sounds all well and good, the truth is at the end of the day we need to be able to execute it into force authority over the management of data and to me that is truly what governance is all about. So I wanted to also share with you a definition real quickly of master data and this comes from a friend of mine, David Loshan who probably a lot of you are familiar with. Did David Loshan define master data objects as being those core business objects that are used in different applications across the organization along with their associated metadata, attributes, definitions, roles, connections, and taxonomies. And so he talks about master data as being something that's certifiable and in order to certify data and make it something that people believe that is accurate that they trust it and that they can count on it to have a certification process in place and I'll share with you kind of a high level certification process that an organization that I'm working with has looked at so how can we put certification in place around master data and what is the level of governance that is required in order to be able to do that. Similar to a slide that I used in the last session that I gave around master data. In fact I've kind of changed it around a little bit from the last time in the last session. In fact in the last session I talked about these things as being avoidable mistakes. What are some of the most avoidable mistakes taking kind of a negative perspective on what kind of organizations prevent themselves from doing in order to be successful around master data and to be successful around the governance. And I had several people get back to me and say that it really would make sense to put more of a positive spin around that. So here's what I'm going to do is in this slide I want to talk about what are some of the top considerations for master data. And this is kind of the positive spin on things. We know we need executive and strategic level understanding and support. We know we need accountability and responsibility. We know we need best practices and all the other things that are listed on this slide. And so if you go into your organization and say these are avoidable mistakes they may look at it as being negative but if you put a positive spin on things oftentimes things are better accepted in the organization. So just to kind of dig that point one step further I want to share with you the original slide that I used in the last session or the last master data and data governance session that I did which was the top avoidable master data mistakes. They were not in any specific order but if you could notice they are all having the negative approach to it I would rather put a positive spin on it. So these are the things that we should look to do. Things that we should be considering when we're not only putting a data governance program in place but we're putting a master data program in place. So those two slides if you can see they're part of the negative around governance for master data basically. So I'm going to do something different here because it's really hot in most of the country at least I know in the eastern part of the country everybody's all tight about the heat and the humidity and the frustration of having to deal with that. What I wanted to do was I wanted to kind of do a deep breathing exercise in a couple different parts here to kind of kick off the session. So I'll be interested in your feedback as to whether or not this is something that's useful to you. So I put it here in the deep breathing exercise that you should sit back in your chair wherever you are in whatever part of your country in your air condition office hopefully or wherever you're listening to this session and close your eyes and just listen to my voice as I ask you to think about several things in terms of your master data in your organization and I understand that in some organizations they may not even have star organizations they may be very early on in the process of putting together a master data initiative. In some organizations they may already have extensive master data in place but I want you to close your eyes and think about just being in your master data only in your master data for a minute and if you don't have a true master data resource think of those resources in your organization that you direct people to when they want to know about a specific subject matter of data. Kind of a go-to place for your customer data a go-to place for your playing with data if you're a health care company your oil and gas and your wells if you're an oil and gas industry your students if you're an education industry and think about your master data think only about your master data for a minute and think about all the people that are associated with that master data not only the people that define that data but the people that take that data and move it to places where people can actually get access to it and make use of it. So think about all of the people that are associated with your master data and think about all the hard work that's associated with whatever work you've already done around master data Think about all the technologies that are associated with your master data. Think about all the users of the master data. Just think about all the work that goes into taking your data and creating that master data resource that people are going to start to rely upon. The certifiable data in the organization, the go-to places for data in your organization. I hope I'm not putting you to sleep here by having to close your eyes, but there is a point to my madness here. So think about, would you really be able to deliver master data without data governance? So just talk about that for a second. Is it possible to put a master data solution in place and have absolutely no governance associated with it or no formal governance associated with it? And I think you're going to be surprised as to what I think the answer to that question is going to be. The question is, would you be able to deliver master data without data governance? Would you still be able to define, produce, and use your master data without formal governance? So talk about all the activities associated with the master data and whether or not you could deliver master data without governance or without some formal level of governance. So how are you sitting there? I can picture you all. I don't know how many of you are actually sitting there with your eyes closed and actually thinking about it, but just think about all of the details, all of the things that need to go into creating a master data solution. And then at the same time, also think about all of the things that are not necessary to put together a data governance solution. Or is there such a thing as, again, I just had this conversation in a meeting prior to this webinar, is there really even meta governance? Is there really governance of your governance process? Governance of the way that you go about defining your roles and responsibilities and those types of things. And how does that relate to development and delivery of true master data, certifiable, high quality master data within your organization? So again, you're thinking long and hard about this and again, there's a reason I'm asking you to do these things. So now let's start with part two of this deep breathing exercise for you to speak here. So now we're thinking about things other than your master data solution. So I'm thinking about your data warehousing and your business intelligence data. So I would say that probably the majority of you have some level of BI program or data warehousing in your organization. So for your package implementation, so many organizations have implemented SAP or PeopleSoft or Banner or whatever industry software there is for your specific application in your specific industry. So think about those package implementations. Think about the application development efforts. If you're a shop that develops things internally first and you always want to build before you buy, just think about your application development efforts. And while you're thinking about those types of things, think about whether or not governance is applied to these efforts. Ever any governance, did you work specifically to identify to get the right people involved at the right time? Do you have a way of taking your decisions and escalating them to a strategic level of your organization? Do you do all of those types of things or any of those types of things with your data warehousing or your package implementations or your development efforts? And think about whether or not these initiatives, the warehouse, the package implementations, and the application development, think about whether those initiatives were successful or not. And whether or not those initiatives are still being used today. So I really think that those are two separate things. If they're successful and whether they're still being used today. So in a lot of organizations, they have successful data warehouses, or at least they build the data resources for their data warehouse, or they build their resources for their master data solution. But the question is how long do they sustain? How long are people able to use them? Are you delivering the things with the data itself in order to make that data most useful to people within the organization? So think about the levels of governance that were applied to those efforts. Even if you didn't have formal governance, and in a lot of organizations, business intelligence and data warehousing predates their initiation of their data governance programs. Same thing holds true with package implementations and certainly with application development efforts that we've been doing over time. So think about the levels of governance that were applied to these different types of solutions. And then as a last thing here, think about how you don't want to go through some of those processes that you went through to build your BI environment, to implement your packages, to develop your applications, how you don't want to go through those difficult times again. We want to formalize the process. We want to formalize responsibilities. And we're going to talk about that being a big part of the relationship between master data and data governance is that the master data, the data itself, it has to be governed. We have to govern the definition of the data, the production of the data. We need to make certain that we're collecting the metadata associated with the master data itself. But we also want to make sure that the processes that we associate with master data are also being governed as well. So now open your eyes and start thinking about the relationship between governance and master data. You know, it's kind of funny when I was putting this slide deck together, I looked for pictures of men who were meditating as well and doing deep breathing exercises. The problem was that I really couldn't find any pictures of men doing these deep breathing exercises. So that's the reason why I have pictures of women there. But think about the governance of all the work associated with the master data, the governance of the people associated with it, the data itself, the processes, and that's what we're going to jump into here in one second. So the question becomes why do we even do this exercise? Why did I get you first thinking about master data and the levels of governance that you may have applied or the need to apply governance to your master data? But then I wanted you to think about the BI initiatives and the package implementations and the application development efforts. And since they predated, in most cases, data governance initiatives, what things can we have avoided out of those efforts? What can we avoid when we're putting together our master data solution? The issues that we came across in those three different types of initiatives. So I wasn't not cracking up here at all. I just thought it would be kind of a neat way on a warm and steamy Thursday afternoon and the dog days of summer to kind of do that type of an exercise first just to get you in the right mindset. Get you thinking about the fact that governance and master data have to be together. If we're going to tell people this is a master data resource, we need to tell them that the data has been governed and be able to highlight for them and show them examples of how data has been governed to make it certifiable, to make it believable and trustable across your organization. So the question is, has Bob finally cracked? Well, I think the answer to that question is no, but I guess it really all depends on who you ask the question to. But I've started, like I said before, it's just a simple way to kind of kick this thing off. And I wanted to use it as a precursor to exploring the relationship or all of the relationships to the benefits of applying governance for your master data. So what I want to do next is I want something that's kind of easy and something to take away. I know in the last webinar that I did about master data and data governance, I talked primarily about master data as a process. But in this session what I want to do is I also want to relate master data just to the fact that it's data, that we need to have governed data definition, that we need to have governed data production, that we need to have governed data usage. And then we'll talk about some of the processes and I'll share with you a whole bunch of different templates and highlights, some things that you may have seen before, some of them that are relatively new, that actually can help you to apply governance to the initiatives associated or the processes that are associated with developing your master data solution. So we'll talk about the processes of defining data, producing data, using data, as well as a whole bunch of other processes. In my experience I have found to be very helpful in putting a master data solution together. So the first relationship is master data as data. Let's kind of keep process out of it here for a second. Let's talk about how we need to govern the even the metadata that's associated with the data structure and the data design, the entities and the attributes and the naming conventions we use and the definitions that we use, especially the definitions that we use when we're defining the data. So many organizations I've seen that use something and I've referred to it before as cheeseburger definitions. Well, what's a cheeseburger definition? A cheeseburger definition? A definition of a cheeseburger is it's a burger with cheese. The definition of a patient address is the address of the patient, where the definition doesn't tell you a whole lot more than just the words that are in the term that you're trying to define. So when we're governing the master data as data, we also need to govern the master data as metadata as well and make certain that we get the right people involved at the right time to get the right definition and validate that definition through the business areas to make certain that the ultimate end users of the metadata have a quality product as well to be able to look at. So again, if you use definitions that a patient account is an account for a patient, it doesn't really tell people much about it. But if you go into more of a description and governance by governing that process of doing the data structure and the data design and the data modeling, we can make certain that at least the definitions for the pieces of data that are most critical to us, and then maybe the master data in the organization, that at least that data has the definitions that the end users in the business community that take advantage of that data have valid definitions that they can truly understand and that mean something to them in their daily work effort. Same thing holds true for the data movement effort. I've seen a lot of organizations that do the data mapping from source to target and the metadata that's associated with that movement of the master data is stuck in a spreadsheet somewhere. And then when they write the programs to move the data and extract and transform and load the data, but they should be able to get that metadata out or make sense of that metadata in such a way that the business community and the business end users can take advantage of it. So again, think of the master data as data. Think about it as the data structure and design and I'm going to talk about each of these things real quickly in the next couple of slides. We're talking about structure and design. Let's see if I can get my... There we go, check marks. The structure and design, the data movement, the data quality, storage, security, usage, communication. There needs to be governance applied to not only the master data itself, but also to the processes associated with that. And then the second aspect that we're going to talk about in the latter part of this webinar is master data as a process. So normally the process of obtaining design requirements and metadata requirements, but also the importance of identifying the appropriate governance roles. So that's kind of that meta governance that I spoke about a little bit earlier. Also identifying the appropriate people into the roles. We need to make certain that we have a sound process for being able to do that. And then if we govern that process or we define formal steps for following that process and we get the right people involved at the right time, that is a good laying of groundwork for a data governance program for your organization but even more specifically governance of the master data in your organization. We're going to talk about master data as a process of developing and delivering communications of the PMO process. So whenever you have initiatives to do anything in your organization where your project management office is involved, we want to make sure that we apply the appropriate people at the appropriate time. So we're really governing the PMO process, the development processes, the metadata processes, and the last thing I'm going to talk about will be the certification process of the master data or the data warehouse data within your organization. That being said, let's kind of jump into master data as the data itself. And so that's the first relationship that I spoke about before. Let's talk about the governed data and the governed structure and the design of the data. So we want to make certain that we start conceptually and we move to logical and we move to the physical design of the data. We name the fields appropriately and we work consistent and we use standardized definitions for data or standard elements of data and pull it from the best possible places in the organization. We want to make sure that we include the metadata and I'm going to keep harping on the metadata for as long as this session goes on because when we deliver master data, yes, we need governance as well, but I guess if there's a third leg to that stool, that third leg to the stool if you think of things that way would be the metadata. So yes, we want to have formal accountability, formal processes. We want to make sure that the master data is certifiable, but one of the things to kind of keep in the back of your mind if not in the forefront of your mind is to have that metadata associated with the data structure and the data design. And not only that, but include governance around the processes and getting the right people involved and what's that taking before we say that yes, this is the data structure we're going to use or yes, this is the model that we're going to use. We want to govern the accessibility to the data, where we store that data, the data certification process, which I'm going to talk about a little bit more in the future here, but here as well, I also wanted to show you this little mouth that's appearing on the left-hand side of your screen. That's just going to be that constant reminder that metadata associated with each of these things is going to be very important to your organization. So we think about master data as data and as being that reliable place to go. I don't think that we would dare in our organizations to let people know that this is the master data resource, but we don't have any. We can't tell you the process that we took to get it the way that it is. We can't tell you the people that we involved. I would think that at some point, people are going to question the data, even the design of the data and the definition of the data in your organization. You want to be able to say, well, we governed that data. We governed that metadata, and that's why you can almost assure them that the quality of that master data is there for them when they go and try to access that information. We're talking about governing data movement. We talk about the selection of the data. What data is the best data for us to use to manipulate our master data resource? How are we extracting that data? What were the transformation rules that were associated with moving that data not only to a master data resource, but also to any user place where people are going to want to make the use of the data? We have a master data solution. We want to make sure that we govern the steps that we take to identify what the most appropriate data is to populate our master data solution. But then we also govern, what data do we select and do we extract? What data do we transform? What are the transformation rules? See, all of that, and again over here, I kind of have this face here on the hand side of the screen. It's just very important that we think about the metadata that's associated with the data movement, and we collect that information and we make that available to people across the organization. Let's talk about governed data quality. So from a quality and a certification of the data, the definition of standards and values, the collection publication, the recording of quality issues, the process of resolving the data quality issues, all of that is the governance of the quality of the master data. And I would guess that if I did a show of hands and it's not necessarily very successful through a WebEx session to do that, but by a show of hands, how many of your organizations don't focus on data quality when it comes to the delivery or even the definition of requirements associated with your master data? In most organizations, again, you would also hear data quality as being something extremely important. We want to make sure that this matters master data resource that we're directing people to, that it has a series of high quality and that we can demonstrate the quality and we can demonstrate where it came from and how it was defined for the organization. Let's talk about governing the storage of the data. Let's talk about thinking about when it comes to a master data solution or even a BBI solution. What do we need to look at as far as what the present volume of the data is going to be? How is that data going to grow over time? How are we going to make certain that that data stored in that place is secure and that we can get the right people to have involvement or have access to the data when they need to have it? The retention and the lifecycle of the data. I know there's laws that tell us how long we need to retain data. Well, if we put the data in the master data solution, is it going to be just the present data? Is it going to be historic data? It really depends on your organization, but we want to make sure that we take into account the retention and the lifecycle of the data in our master data solution. We want to talk about the backup and the recovery of the data. I know one of the things that's a really hot topic and a lot of organizations is disaster recovery. With all the issues that we've had with the wildfires in the Midwest and the West and the flooding in the East and the tornadoes in the central part of the country, organizations more and more are taking their disaster recovery situations seriously. I know they've been doing that for some time, but even more now, organizations are somewhat concerned about making certain that people in the organization are coming to realize that this master data is the place that they want to go as Mr. Loeschin said in his definition for reuse of that data across the organization. We want to make sure that that information is backed up, that information is recoverable because a citizen of the organization would go back online and decisions need to be made and they would need to get access to that information. So we want to govern not only the definition and the quality of the data, but we also want to govern the backup and the recovery of that data and making certain that that data is available at the highest rate or highest percentage of time that we can possibly have within our organization. Security of the data. Again, we're talking about master data as the data itself. We want to make sure that we classify the data, that we know what data is highly confidential or confidential or sensitive or public by nature. Some organizations find the data that they work with. If you're in the healthcare industry or if you're in the education industry, you know that a lot of your data ends up being public. We want to make certain that we can get the right data into the right people's hands and the same thing would quote true for your master data. We want to make certain that we govern the data security associated with wherever we store this data off and make it available to people across the organization. And I think there's one more. There's master data as data with the governed data usage of the definition and the production of data and the availability. We want to make certain that we can get the appropriate data into the right people's hands at the appropriate time and that we can not only deliver the master data that way, but we would also deliver the metadata that's associated with that master data at the same time. So think about it. We're typically delivering master data along with the metadata that's associated with it. How are we going to get people in the organization to trust that the data that they're using, that they become dependent on in their day-to-day activities, that it's something that they can trust. We want to make certain that we deliver not only the governed data itself, the governed master data, but we also want to deliver the governed metadata as well to make certain that before we start letting it loose or opening it up to the public in the organization, that we validate and we even certify the metadata because it makes sense that we don't want to confuse the heck out of people when they go to the master data resource. We want to make sure that we provide them with valuable information that is going to answer their questions. And again, I've mentioned this in other webinars. If we can anticipate what questions we're going to get from people about the data, that's a great way to start to understand what your metadata requirements are and what metadata you may need to collect. And in fact, had a situation earlier today here at this client in Ohio where we started with kind of a laundry list or a wish list of metadata that would be associated with different aspects of data in their organization. And we're working on trying to kind of come up with a brainstorming list, but then they'll go down and prioritize it and select the appropriate metadata that will need to be delivered in association to the master data that is going to be an upcoming initiative for this organization or their Enterprise Data Warehouse, which is a ongoing concern but also an ongoing opportunity for this organization. So is there one more? No, there's not. So that's the last one. When I talk about the relationship, we think about master data as data. What I want to do is I want to kind of switch gears a little bit and I want to talk about the master data processes and then I want to share with you those templates that I mentioned before that might help you to apply governance formally to your master data initiative. So if you attended almost a year ago about master data and data governance, you may recall this slide right here. This slide basically shows some high level steps that organizations take and that organization took. That came from an old client deliverable that wanted to have their master data governance diagram something that was an easy to understand flow chart. And if you're interested in seeing a copy of this, it's a little bit outdated but I'd be glad to share that with you. Is that something that you'd like? Same thing holds true for all the templates that I'm going to discuss in the next 10 minutes or so. Just to share with you, I can put those all together and Shannon will make sure that we send those out to everybody within the two business days. So if people should be interested in some of these and if they are of value to you, please let me know that and I'll try to get them to you as soon as possible. Talk about master data as a process now. We'll talk about the process of defining functional requirements. Of documenting and making sure that we document those requirements that we improve the, go through the level of approval for the functional requirements that we meet these functional requirements through ongoing testing throughout the process. So organizations that deliver functional requirements associated with their master data, we want to make certain or I would suggest that you would want to make certain the steps for defining even your requirements around your master data solution. Those steps and those processes are all governed. You may have a separate process defining your requirements that you do for documenting your requirements or be those would be together. Approval of the requirements and utilizing a governance structure to identify who the appropriate people are to kind of bless those requirements for your master data before you actually start to develop your solution and make certain that when you deliver your master data that it meets the functional requirements that you've defined previously. And I'll talk about that little mouth in from the left-hand side as you can see over here that there's metadata that's associated with the functional requirements. And if you're putting together a data governance documentation platform that's going to be valuable to people within your organization, are the functional requirements something that you want to deliver? I wouldn't say that there's a single answer to that question, but in a lot of organizations, the people that want to use the master data, one of the things that they may look at may be, well, did we do functional requirements? Did we follow a governed process in order to build our master data solution? And oftentimes the governed process is, believe it or not, they start with functional requirements and sort of people that have been around developing applications and data warehouses for many years, I don't know what I mean. You know, it's very important to define those functional requirements first, but we have to make certain that we govern that process. We get the right people involved that we document it. We make it available to people throughout the organization. And this is what data and system requirements. Again, I don't want to get through all of these in too much detail, but the definition of the system requirements, the documentation of the requirements, the approval of the requirements, the design constraints, performance requirements, all of these things become very important when you're defining your data and system requirements even for your master data solution. So a lot of organizations don't think of their master data solution as being a system, but for a lot of people in your organization, a lot of the business users, they're going to think of it that way. I don't want to make sure that the I's were dotted and the T's were crossed and that they could have a high level of confidence. In fact, confidence level is one piece of metadata that a lot of organizations these days are starting to consider. How can we come up with a number that helps us to identify the confidence level that people within the organization can have with that data? Oftentimes, that becomes part of the requirements themselves when you're delivering your master data solution. You talk about metadata requirements the same way, the same thing. We want to make sure that we have a process that we go through to identify a laundry list of metadata and narrow it down and prioritize it and get it approved and make certain that we are working about it from a technology perspective, as to how are we going to deliver this metadata alongside our master data again to make people or to help people to understand where this data came from, how it's defined, how it can be used and all of those types of things. So you want to govern the process associated with developing your master data requirements as well. In addition to that, let's talk a little bit about this meta governance which I kind of talked about a little bit earlier. At some point, it becomes an interesting subject and it's interesting to put an article or presentation together on that on even governing the governance process. I'm not sure if people think of it in terms as such, but I know that when I'm back in the days when I was a data administrator and I was focusing on metadata management, we did talk about meta metadata which is the metadata about the metadata. And if you think about that in terms of data governance, you can certainly get people to fall asleep when you start talking about the governance or governance of the data governance process. But let's talk about it here just quickly for a second. The process of identifying roles associated with the management of the governance of the data, of governance of the master data. So now you've probably seen this slide before and I've used it for me often. I tweak it every once in a while from time to time. So it may be a little bit different than what you've seen before, but organizations oftentimes look at this and they say, wow, that's very bureaucratic. You've got all of these different levels. That's where the next part of this slide kind of come in handy. The truth is that all these different levels of a governance framework or a governance operating model, they're not all new to your organization. I'd like to hold a conversation with me in more detail about different roles associated with master data and master data governance. I'd be glad to have that conversation with you. But if you look through this diagram, you can see that the data governance team may be new or it may already exist and you may have somebody associated with that role in your organization. IT, well, it already exists. So we can count on that. Exam level, it already exists. Exam level, it already exists. There's people day to day defining, producing, and using data in the organization. We need to know who they are. We need to not only identify the appropriate roles and put governance around those appropriate roles, but we also have to have an appropriate way to manage and to record that information. As you probably heard me say time and time again, this level right here, the tactical level, the enterprise data stewards or the data domain stewards as I've referred to them in the past, they play a critical role. That's actually the largest hurdle from those organizations to get over is to make certain that we have a strong tactical level. So we may need to govern the governance processes as we're defining the roles associated with governance in our organization, whether it's related to master data or metadata or business data or analytical data or whatever data it is you're applying to. We want to make sure that the roles that we have defined for our organization around governance are appropriate. So that's another process instead of the master data is making certain that we go through an appropriate process for identifying roles. They also need to go through a process of identifying people into roles. So if we follow the noninvasive approach to data governance, my suggestion is that we're not going to go around giving people new titles, we're going to identify what they're doing and we're going to slot them into that framework that I showed you on the prior page. But the interesting thing, I know this is a very difficult slide to read and for that reason, I kind of blew it up a little bit so there's a little bit closer of a version of it but basically it's very simple. It's down the left-hand side. We have different subject matters of data. Across the top, we have the different parts of the organization and if we know who does what with what data and what parts of the organization, we can start to govern data a lot quicker than if we don't have that information. We can figure that we can communicate regulatory compliance concerns, security concerns, development concerns. We can communicate to people where the metadata is associated with master data but at some point in time, it's going to become very important for you to be able to collect the information about who does what with data across the organization. We can figure out the people's names that would be identified are associated with subject areas of data. So those are the rows and the columns are basically associated with the different areas of the organization. And I have my client, my recent client, tell me that this is not an easy thing to fill out and the truth is it's not necessarily an easy thing to fill out. But when you are delivering your master data, people are going to want to know that we engage the appropriate people at the appropriate time. And how are we going to do that? Well, first we're going to ask people who the right people are and we're going to identify them with or without governance. My suggestion is that with this common data matrix as I've called this in the past and I tend to continue to call it, it's just a tool. It's a very easy template that you can create within your organization that will help you to put your arms around who does what with the data and that you can then take back to your organization and demonstrate we've got these people involved in this process and therefore we feel more confident that the master data is addressing all of our concerns across the organization. I'm going to leave a little bit of time for questions here too so I've got a little bit more than a handful of slides left. The last few will go really quickly but here's another one of those templates. I always view things in forms of templates but the process of developing and delivering data communications about your master data. That your master data exists. What subjects, areas of master data? What was the process that we went through in order to call this master data? All of that goes into the process of developing and delivering data communications. So again, if you're interested in a copy of this I'll just send you a list of all the different templates and see if you can make use of them but this is kind of a very easy to understand chart because we want to communicate these things with these audiences recognizing that we can't communicate with this audience the same way we communicate with this audience or with this audience. So the idea is that we wanted to govern the process of developing and delivering data communications associated with our master data. We wanted the PMO processes as well and you may have seen a slide like this one or maybe even this slide before where there's kind of a handful of processes that a lot of organizations put in place around the governance of data and the governance of master data. If you can provide something like this you could, I've seen organizations have where you can actually click on one of the hyperlinks that you see on the left hand side of the screen and it will give you a detailed walkthrough of what are the steps associated with that action. These are the different roles associated with that action. What do they do? Are they responsible, accountable, consulted, informed as they go through the steps of the processes? Again, what we're doing is when we're talking about the PMO processes associated with our master data we want to make certain that we apply governance to those processes. The same thing holds true for kind of building out your governance proactively and reacting to problems. So if you develop and deliver your master data solution and you've got issues associated with that data we want to make sure that we have a preferred manner to go ahead and to resolve those issues, to document the data quality issues and to resolve the issues as well. A couple of ones here real quickly. One is, and this is again associated with the development process where we take the different steps of a system development lifecycle methodology, the different roles associated with governance in your organization and we cross-reference who does what and when they do it and in fact get an organization and I know that the organization that I'm working for here right now we had the conversation that we just need to add a sign-off to different steps that say have we answered these questions about the data before we certified it and made it available to the organization? This master data resource that's becoming so important for so many organizations. Again, we can also apply governance to the metadata processes related to the master data. Since I'm running out of time what I want to do is kind of jump through this one quickly to this last matrix that I want to share with you and that's kind of a certification process that would be related to master data. So if we find the steps of certifying master data or we define the steps of certifying enterprise data warehouse data we then identify associated with the roles that we've defined in that pyramid diagram associated with our data governance program that we identify who is informed, who's accountable, who's responsible, who's consulted all of those such things. Who's supportive? I've seen a lot of organizations now that have added an S to the standard RACI so as far as it being RACI it's RASCII for responsible accountable supportive consultant or informed. So again, it's just another type of template or tool that may help you to apply governance to your certification processes related to your master data. So basically, we're almost five minutes before the hour so we're going to take some questions here in a second but basically to summarize really quickly we talked about master data as data and making certain that we apply governance to the master data as the data itself but we also want to make sure that we apply governance to master data as a process as well. And I gave you a whole bunch of different examples and hopefully some of those templates and things will be helpful to you in the future. And before we go into the questions just again a reminder of the webinars for the next several months the one that I think will be quite interesting to start is the good data governance to great data governance if you've read the book or if you've heard of the book and it's been a number one best seller on the business best seller list for a few years. I think people get a kick out of some of the things that the ways that I compare things that Jim Collins talked about in that book to moving from being a good data governance program to being a great data governance program. And with that Shannon I'd like to turn it over to you if there's any questions that we can address in the remaining time we have. There's quite a few questions and everyone just to remind you Bob's great about answering the questions in writing and so we'll get those if we don't get your questions within this hour we'll definitely get you a written answer in the follow-up email that'll go out within two business days which will also contain links to the slides and the recordings and as well as the matrices presented throughout the presentation. And the first question actually comes via Twitter and it says for M.D.M. governance webinar it must tell the meaningful definitions and metadata so why isn't that a result of M.D.M.? Waiter can you restate the question? Yeah M.D.M. governance is so in your way so you just have valid you've stated you must have valid meaningful definitions of metadata so why isn't that a result of M.D.M.? Well it's actually more than just a result of M.D.M. it's kind of a partner it's kind of like a parallel path as well as we're creating the master data we want to make certain the definitions that we provide for that master data that we've governed those definitions as well it's very much an easy out for organizations to put weak definitions to the data often times data modelers their interest is to meet with with the data people in the organization to get true understanding of what the data is and how they can even put that definition to the organization so I'm not saying that it is part of the master data process it's part of the master data as data it's almost like you have master metadata to go along with your master data but again I'm a little bit foggy on the way the question was answered but I'll take a look at how it was written and I'll try to address it again as best as I can in the written response that we provide So in the next question in the Gartner Height Circle Cycle for Enterprise Information Management master data management is marked as to reach the plateau in 5 to 10 years what do you think about that? Is that really something just for companies with a very high maturity in information management today? Well, I actually believe that you can reach a level of master data management a lot quicker than 5 to 10 years I do believe that levels of governance need to be in place obviously as I've talked about throughout this session here in order for you to be successful in delivering master data I'm not sure what Gartner was saying when they said 5 to 10 years to reach the plateau in your maturity certainly it takes time certainly governance is not something that is part of what people do now or what they think of it as being part of what they do but if we can get to a point where people consider the governance aspect of it and the governance aspect of your master data to just be built into what we do every day or built into what we do as part of our process of identifying this thing that we're calling master data then I think that we can start to provide master data in much shorter of a time frame but we need to start small we need to think about doing it incrementally rather than trying to do a big bang and releasing all of the master data at once because I believe that these processes that we're talking about to apply governance to the master data and to apply governance to the processes associated with the master data it takes time to mature and you might want to put some feelers out there for this is what works for us we can try these things and if it doesn't work we can't be afraid to change it but I would say I guess the point I get from that question is the master data maturity certainly does take some time but it's something that we can be starting on now as we're defining our governance initiatives we can also be identifying well what's that core data that we need to view as an enterprise asset that's the know-all and be-all place for people to go to get that quote-unquote master data we just want to make certain that we can support even the use of the term master in the master data and I could say that I think that we can get to that point a lot quicker than five to ten years but it takes resources and it makes sense to do it incrementally it would be better to start with the data governance program before starting a master data management initiative well I'm not sure it's necessarily a worse before the corner the chicken and the egg thing I'm not really sure that there's a simple one answer to that question my impression in most organizations is that there is already some level of governance taking place data governance does not have to necessarily be introduced as something that's brand new to the organization in fact my suggestion is that we do kind of a different approach to it and that we say you know we've got governance in place so let's take advantage of that and the right people that we know are associated with the data and just get them involved in the master data solution for defining requirements all the way down to defining the metadata as well I think it really makes sense that we can do these things together I would say without a doubt you don't need to have a full-fledged data governance program in place to start your master data initiative and even going back to my breathing exercise that we started talking about earlier on in this session the fact is that there's going to be governance in a team place and you've already done things like deliver the data warehouse and packages and developed applications without formal governance yeah you can deliver a master data without governance as well but would it be valid to call it master data if there is no governance applied that's really the question that I was trying to uncover so that's it and then we are right at the top of the hour here thank you Bob for another fantastic presentation again everybody if you have more questions that you want Bob to answer just go ahead and submit them there in the Q&A section and I will make sure and get them to Bob and we'll get the answers out to you within the next two business days so by Monday, Monday with the links to the slides the links to the recording and all the fantastic materials that Bob has presented today Bob, again thank you so much for another great presentation and everyone thanks for attending everybody stay cool we'll talk to you next time bye sounds good