 And here we go. Hello and welcome. My name is Shannon Kemp and I'm the Chief Digital Manager of Data Diversity. We'd like to thank you for joining the current installment of the Monthly Data Diversity Webinar Series, Real-World Data Governance with Bob Siner. Today, Bob will be discussing non-invasive metadata governance. Just a couple of points to get us started. Do the large number of people that attend these sessions. You will be muted during the webinar. If you'd like to chat with us or with each other, we certainly encourage you to do so. Just click the chat icon in the bottom of your screen for that feature. For questions, we will be collecting them by the Q&A in the bottom right-hand corner of your screen. Or if you'd like to tweet, we encourage you to share highlights or questions via Twitter using hashtag RWDG. And if you'd like to engage more with Bob and continue the conversations after the webinar, you can go to the Data Diversity community at community.dativersity.net. As always, we will send a follow-up email within two business days, containing links to the slides, the recording of the session, and additional information requested throughout the webinar. Now, let me introduce to you our speaker for this series, Bob Siner. Bob is the President and Principal of KIK Consulting and Educational Services, and 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. Bob specializes in non-invasive data governance, data stewardship, and metadata management solutions. And with that, I will give the floor to Bob to get today's webinar started. Hello and welcome. Hi, Shannon. Hi, everybody. Thanks, everybody, for taking time out of your schedule for today's webinar. Shannon mentioned that people know me for non-invasive data governance, and they know me for the metadata work that I do. But let's kind of mix some of them together. Let's put non-invasive and metadata governance together. And that's the topic for today's webinar. I'm real excited about this webinar. I think it's really important, you know, we as data governance practitioners know that metadata plays such a critical role in the success or failure of our data governance programs. And, you know, we know that the metadata, as I've been known to say, will not govern itself. We need to have people who have responsibility for the metadata. And that's what we're going to talk about today. We're going to talk about governing metadata in a non-invasive way. And before I get started, I just want to spend a quick second here talking about a bunch of things that are coming up in the industry. As you know, the real-world data governance webinar series, always on the third Thursday of the month. Next month, we'll be talking about glossaries, dictionaries, catalogs, and how they result in data governance. I talk a lot about non-invasive data governance, and there's information about how you can get your hands on the non-invasive data governance book. I will be speaking at a bunch of data-versity events coming up. In fact, one's coming up next week that I'm not really excited about. It's the fourth annual Enterprise Data Governance Online Conference. So please go to data-versity. I look forward to seeing you at that event. Also, I'll be speaking twice in San Diego, coming up in the first parts of the year, once at the Enterprise Data World, where I'm going to be talking about a complete set of roles and responsibilities around data governance. And I'll be speaking at the Data Governance and Information Quality Conference, the DGIQ conference on a bunch of topics, but one will be on how to get started in data governance. If you go to the Data-versity Online Training Center, you'll find two online learning plans, one in non-invasive data governance, one in non-invasive metadata governance, the topic of today's webinar. And of course, there's always the Data Administration Newsletter and KIK Consulting. If you're interested in learning more about data management and about KIK Consulting in general, and also about non-invasive data governance, so I look forward to seeing you there as well. If you've been to my webinars before, you know that I typically break down the topics of the webinar into a bunch of different categories, and then I go through them one by one. The first thing I'm going to talk about today is different concepts of what it means to be non-invasive when it comes to metadata and metadata governance. We'll talk about metadata as a valuable resource, aligning our data governance with our metadata governance, or we could actually look at it the other way around. How are we going to align our metadata governance with our data governance activities that are already taking place? We'll talk about implementing effective tools, and then we'll talk about ways to maximize accountability and maximize your resources for governing metadata as an asset also within your organization. I like to get started, typically, with talking about the definitions for specific terms, and the reasons I'm doing that today is because we're talking about metadata governance, and I want to relate it to the topic of data governance. I define data governance with pretty hard terms. I say data governance is the execution and enforcement of authority. Now, it doesn't necessarily reflect on the approach that you're taking to implement governance, but at the end of the day, what do we need to do? We may need to make certain that the rules are being followed, that the standards are being followed, and we need to execute and enforce that authority over the management of data. Data stewardship is typically formalizing people's accountability for data. So people define, produce, and use data as part of their daily job. If we can recognize who those people are, and we can help them to be accountable for how they define, produce, and use data, that's what data stewardship is all about. Particularly, I say that a data steward is a person that's being held formally accountable for how they are defining, producing, and using data. I've also been known to say that everybody in the organization is potentially a data steward, and that's pretty much true. Everybody either defines and or produces and or uses data as part of their job, and if we know who those people are and we can work with them to do a better job of defining, producing, and using the data, then they are stewards. They can't really say, no, we're not. If they have that relationship, we need to make certain that we're formalizing that relationship to the data and formalizing the accountability. Non-invasive data governance, on the other hand, is basically the practice of applying this level of accountability and using roles and responsibilities, and I'll share with you an example of a set of roles and responsibilities for data governance and metadata governance during this webinar, and we're going to apply governance to process rather than redefining everything as a new process. Again, trying to stay as non-invasive or non-threatening as we can, and we want to assure that we're producing, we're defining, producing, and using data appropriately to do all the things that we're trying to achieve with our data governance program, and that is to assure regulatory compliance, security, privacy protection, and certainly the quality of the data. Non-invasive refers to the approach that's being used, really, how we're applying governance. It doesn't necessarily describe the program itself, it just describes the approach that we're taking to implement governance in our organization. So I shared that definition with you to share with you my definition of metadata governance, and you can see that all I really did was replace the word data with metadata in each of these statements, because the truth is that in order for the metadata to be valuable to anybody in the organization, we need to execute and enforce authority. There needs to be some level of authority and responsibility and accountability for the metadata, just like there is with the data. Otherwise, the metadata is not going to be defined. It's not going to be produced, and it certainly won't be there when people need it to use the data in the most effective way. And metadata stewardship is now taking the responsibilities of people that are defining, producing, and using metadata and formalizing that accountability. So giving them the responsibility to make certain they're following standards when it comes to collecting metadata and making that metadata available to people across the organization. So I want to talk a little bit about the relationship between metadata governance and non-invasive data governance. So the first thing that you need to do is really understand what do I mean by non-invasive data governance. And there's lots of webinars, and as I mentioned before, there's an online set of classes through DataVersity that talks about non-invasive data governance. But the idea behind non-invasive data governance is that there's already governance taking place in your organization. There are already people that should be being held accountable for how they define, produce, and use the data if we can recognize who those people are and help them to do a better job of that. That's really the idea of the approach to implementing governance within the organization. So if you understand non-invasive data governance, you can begin to understand what it means for non-invasive metadata governance. What we want to do is recognize the appropriate people in the organization to collect the documentation and that information about the data that's going to add the context and make it information so that people can use it within the organization. And I oftentimes talk about the data stewards. Again, there's people that define, produce, and use the data. Metadata stewards are the people that are going to have that responsibility around the metadata rather than the data. I get asked the question a lot. Are the metadata stewards the same people as the data stewards? And the answer to that is it depends. If the metadata stewards, if your data stewards are the ones that are defining, producing, and using your metadata, then potentially they're the metadata stewards as well. But oftentimes, for example, the data modelers are the people that are creating the physical structures of the database. They're not necessarily business data stewards or stewards of the data. They become the metadata stewards, the ones that the people that have the responsibility for making certain that metadata is being collected and being distributed to the people that are going to be able to make use of it. So what we really want to do is we want to make certain that this whole process of documenting the data that we're applying governance to it. We're getting the right people involved at the right time. We want to make certain that we have the tools in place for collecting the metadata. But we want to apply governance to whatever sense of document, data documentation process we have. If we don't have a solid data documentation process, of course it's going to feel a little bit more invasive to you. But I'm assuming that within most organizations, especially sizable organizations, that they have some level of data documentation, whether it's in data dictionaries or in data models or in file layouts or things like that, there is metadata. We need to apply governance to that metadata and make it available to people. And typically, as I say with regular data governance, we don't want to go out and rush out and buy a whole bunch of tools. I'm going to share a bunch of tools and templates with you that might help you to start recording who does what with the data and helps you to record some of the metadata in your organization. We want to leverage what's existing before we go out and start putting our money into additional tools. Now, when we put the money into the additional tools, the fact is that that kind of ups the ante as to what people are expecting from us. So start with tools that you can develop or start with tools that you have internally before you go out and start buying new tools for your environment. Now, the one statement that I say a lot, maybe I say it too often, I don't know if I say it too often or not, but I say that the metadata will not govern itself. Just like I say that the data will not govern itself. Now, if we're expecting that we're going to have metadata to support the bright shiny objects that we're creating, the analytical platforms and the data lakes and the data warehouses that we're creating, we understand that we're going to need metadata in order for people to get the best use out of that information or out of the data that's in those resources and we know that in order that the metadata is just not going to magically appear. We need to have people that have accountability for that metadata. And so the same thing holds true when I say that data won't govern itself. If we're going to need metadata to support our data environment, we need to recognize that the metadata actions that we take kind of mirror the actions that we take with data. Somebody has to have responsibility for defining what metadata is necessary to support the end users within our organization. Somebody's going to need to produce that metadata. Somebody's going to need to use that metadata and you could insert the word data instead of metadata into any of those sentences and it would still hold true. We need to make certain that we're being deliberate in how we're doing these things and how we're just defining and selecting the metadata we're using, how we're producing it, when we're producing it, where and how we're producing it and certainly we want to make people understand or help people to understand what metadata is available and how they can use that to help them in their job. So we need to recognize who in the organization is at least or maybe already accountable for the metadata. And if we don't have anybody who's already accountable, then we need to step up and kind of formalize accountability. Who's responsible for the data definition? Who's responsible for the data production and the data usage and all of those things? We need to also make certain that we're going to measure whatever aspects of metadata management we put into place. I'll talk a little bit later about how do we align with people in the organization who are influencers over what money is being spent on and what's being budgeted. And we want to make sure that we're able to demonstrate to them the value that is coming from the metadata that we are managing. So as I said, we want to talk about selling metadata governance to the influencers. We want to make certain that we talk to these people and we understand what their requirements are, what information about the data is going to help them to get more value out of the data. And then once we've gathered those requirements, make certain that those people defining, producing and using metadata are aligning what they're doing with those requirements from the people within the organization who can influence change. We want to assure that the resources that these people who are defining, producing and using the metadata have time to govern the metadata. Oftentimes metadata, just like data dictionaries and data definitions, they seem to be an afterthought. Well, we need to change that. We need to make this something that's front and present in our activities around creating new data resources for the organization. And we need to make certain that people in the organization have time allotted to define what metadata we're going to use to produce that metadata as part of their daily job and to make certain that they know that the metadata is available to use the metadata. The problem is, there is so much data within our organization that if we're going to try to create and make available metadata for all of the data in the organization, that's going to take a long time. We want to focus on things that are most meaningful to the organization. And that's why I say focusing on things like critical data elements or those strategic pieces of data, pieces of data that are strategic to your operations, first we may want to start with defining the metadata associated with those critical data elements. And we want to take all of these concepts of developing metadata and metadata management in the data documentation, and we want to make certain that somebody in the organization has time to turn these concepts into reality. Again, the metadata management environment won't set itself up. The people that the metadata won't define itself, we've got to have somebody who has the responsibility for doing all of those things. And so let's spend a little bit of time talking about metadata as a valuable data resource. Most of us as data practitioners know that metadata is critical to the successful implementation of these heavily invested or these projects that require heavy investments around the management of the data in the organization. So what we need to do is we need to first, once we understand that it's a valuable resource, we need to start identifying what is the metadata that's most important to us that we can use. And there are these things that are called metamodels. If you're not familiar with metamodels, they're basically data models of your metadata. And what they do is they help us to explain to people what metadata is available to them or what metadata is available to us that we can manage and make available to them. So the purpose of the metamodel is for us to lay out and plan what metadata it is we're going to collect, where it's going to come from, where we're going to store it. And ultimately, I've seen organizations create metamodels or metadata databases that kind of mimic the metamodels that they're creating for themselves. So a lot of organizations may start their governance programs with metamodels that are specific to the implementation of their programs. What data is it that we are focusing on most and who in the organization are the owners or the subject matter experts for the data? Who are the authorities for that data? We want to make certain that we're creating a model of the metadata that will be most useful to people in the organization. So we need to ask them what information do you need that will make this information that's being provided to you more valuable. And then we want to make certain that we're aligning the things that we collect within our metamodel with whatever actions we're taking around governing data and governing metadata. That diagram on the bottom of the page, there's just a simple metamodel of some of the basic business and data entities, categories of metadata that we can collect and that we can make available to people. But most of us know that the metadata can go way beyond these things that are just being described on the page. There's a lot of aspects to our environment that need to be recorded that we need to know who has responsibility for and so on. So you might want to consider starting with the metamodel. You might also want to start looking at, well, what types of answers or what types of questions can metadata answer? There's a lot of different categories of metadata. As I mentioned before, you know, we may not initially focus on all of the categories of metadata. We want to focus on those categories of metadata that meet the specific requirements that we're hearing from people, not only the influencers, but the end users of the data. And we want to record questions for each of these categories. You know, one of the things that I have found to be very successful is when you sit with a business user, you don't go up to them and say, what metadata do you need? That's not the way to go about addressing your metadata requirements. You might ask them, what information do you need about the data that's going to help you to do your job? When you're going looking for information about the data, what is it? We don't need to necessarily use the word metadata when we're describing, when we're even asking the questions associated with gathering those requirements of the metadata that we'll need within the organization. So we don't want people to understand that we're going to try to manage all of the metadata in the organization at once. We want to set realistic expectations and start by limiting the amount of metadata that we work on and then create repeatable processes so that we can replicate the things that we're doing in other categories of metadata. So my guess is your first question is going to be, well, what are the different categories of metadata? And actually there's articles on TDAN, as Shannon had mentioned, TDAN.com. There's articles about the types of questions that metadata can answer, different types of categories of questions or categories of metadata. And so there's database metadata, which was somewhat reflected on the previous page and the previous meta model. There's data model metadata. What information are we entering into the data models, like business definitions and business names that are going to be useful to people in the organization? Then there's data movement metadata. Where did the data come from? What happened to the data along the way? There's business rules and data stewardship and access and all of these different types of metadata. What I want to do is I want to focus on the data movement metadata and provide you with a list of what are some of the questions that we might want to ask people to figure out what type of metadata do they need specifically about data movement. So we're going to ask the appropriate people for the requirements and we're going to determine what's going to be the best way to ask the question. Again, not asking them what metadata you need, but word your questions in such a way that it makes sense to them. And we don't only want to reflect the business metadata, there's technical metadata that are going to be important to people as well. So some examples of data movement metadata would be or the questions that you could ask to gather the requirements that you need for managing data movement metadata might be where did my data originate? What systems or database did it come from? What data actually? What fields are being used to populate this data? And how is the data derived? What are their calculations? Where are their derivations? What types of things do we need to provide to the business community so that they trust the data? They trust that they know where the data came from? How the data got to be the way it is that we're demonstrating to them within these investments that we're creating, within these analytical platforms and these databases within our organization? We also need to consider that there's multiple ways to manage our metadata. There's multiple ways to govern our metadata. We can have a centralized approach where there's one part of the organization that has the responsibility for defining what metadata we're going to collect for actually going out and collecting that metadata or we may take more of a distributed approach. In a distributed approach, there will be people in multiple parts of the organization that have specific responsibility for specific metadata. So the way that we collect our metadata, whether it's through a central group, a metadata governance or a metadata management group, or whether we have different pieces of the organization creating the metadata, depending on the needs, whether we're going to take a centralized approach or a distributed approach to metadata. And we need to look at, well, with each of these different ways of going about it, centralized and distributed, what's the impact that that's going to have on delivering effective metadata for people? And we need to weigh what are the advantages and disadvantages of each of those different approaches to setting up our metadata environment. And we want to describe to people how we're collecting the metadata, how the metadata will get into their hands, why they should trust the metadata, and make certain that the metadata is also certified. So that we're looking at the metadata to make certain that we're not providing metadata that's not adding value. I talk a lot about cheeseburger definitions. We want to provide true business definitions, a cheeseburger definition being a definition that uses the words within what we're trying to define in the definition. So a cheeseburger is a burger with cheese. We don't like a student loan as a loan for a student. We think it has been proven that the best way to define this metadata is in business terminology that's going to be understood by the people that are going to be consuming the metadata within the organization. We need to define roles and responsibilities associated with metadata. And oftentimes I share an operating model of roles and responsibilities, and I'm going to share that with you in a second. It defines the different levels and the different roles associated with governing data. And we should also take a look at, well, what are the roles that are going to be associated with governing metadata? And we need to embrace the fact that there's going to need to be people that have responsibility, the stewards of the metadata who are defining what metadata we're collecting, who are producing, and who are using the metadata. In fact, the key to metadata success is to embrace that whole concept of the metadata stewardship and recognizing who has responsibility for defining, producing, and using the metadata. We need to get these people involved in the process of improving data documentation. If nobody sees the value in the data documentation, it's going to be very difficult for that to catch any hold within your organization. We need to get the stewards actively involved in improving the data documentation. Again, because the metadata won't, this won't happen on its own. We need to have people with responsibilities for making certain that the metadata is being provided and that it's being made available to people within the organization. Now, I can do a whole presentation. In fact, I'm going to be speaking for several hours at ADW on the complete set of data governance roles and responsibilities. This is what I typically start with, an operating model of roles and responsibilities associated with data governance. You'll notice on the right-hand side, we've got executive-level steering committees. We've got strategic-level data governance counsel, and we've got subject matter experts and domain stewards at the tactical level and then the data stewards at the operational level. On the left-hand side, we can see that there needs to be somebody who's responsible for managing the data governance and managing the metadata and managing the processes associated with the metadata. And those people could be your metadata administrators, but let's also talk about data governance partners. IT is producing a lot of metadata. Project management, regulatory and compliance. There's a lot of metadata coming out of these groups. So if we take this basic set of roles and responsibilities and look at it from a metadata perspective, we can identify that there's a metadata administrator. There's metadata partners, people that are providing metadata across the organization. We may even have working teams that are focused on certain aspects or certain critical data elements of metadata. We certainly have metadata subject matter experts and I've talked a little bit about the metadata stewards. We need stewards for the metadata. That is the key to successful metadata governance is recognizing who in the organization is defining, producing and using the metadata. We need to, once we've recognized who these people are, we need to engage them. We need to get them active. So we need to integrate them into the business processes to make certain that metadata management is not just an afterthought. So we need to insert data documentation into the business processes and we need to use things like RACES to formalize the process within the organization. And I'm going to share with you an example of a RACES where it is focused on defining the metadata for a set of critical data elements, but we need to make certain that we're engaging the appropriate people at the appropriate time in the activities to create that metadata. We need to engage the data stewards in the business process and the metadata stewards in the business process. And we want to do whatever we can to collect our data documentation in a noninvasive manner. If people feel like this is over and above what they're presently doing, they're going to push back. The idea is let's try to build this into what they do as part of their regular job and make the collection of data documentation noninvasive to them. Make it something that's just kind of second nature to their job. We're defining a database. Okay, we need to collect the business definitions, the business rules, the classification, whatever the data documentation is to the data that's being created. Now here's an example of a RACES chart. I know it's kind of small on the screen, but the idea is that along the left hand side we define steps associated with data documentation across the top. We define the roles that are part of that operating model that I just shared with you, and then we specify who does what in each of the different steps of the process of governing that metadata for those specific critical data elements. So there's metadata even within the RACES chart itself that we need to govern and that we need to manage. Somebody has to be responsible for creating this RACES and for making certain that we're engaging the appropriate people at the appropriate time. We need to align data governance with data governance by measuring the value that we're bringing to the organization. So people don't understand what the value of the metadata is going to be and how we can improve on that. So for example, we may measure how much metadata do we have? You know, how much of the most requested metadata do we have? How complete is that metadata? How many people are using it? What are they using it for? What is the end result of them using that metadata? We need to find ways to measure the value and the success of metadata governance within the organization. So we need to select appropriate measures, develop benchmarks. A lot of this information is in the non-invasive metadata governance course that's available through DataVersity. But these are some of the things that we should be considering when we're setting up metadata governance for the data within our organization. We need to select the appropriate measures. We need to develop those benchmarks to measure the value and not only the value of the results but the benefits. And one of the things that I have found to be most successful is that if somebody in the organization can state the value that they're getting from the metadata, we need to use that information rather than us as practitioners always speaking about the virtues of data governance in the organization. If we're providing value, if we're providing success to some of these data investments that we're making in the organization, we need to measure those. We need to report those. And we need people to understand what the value is that people are getting from the metadata. Again, rather than us telling people what they should expect to get, you know, focus on your business community. Get them to state what metadata is valuable to them, what were they doing before they had that metadata and how the metadata has actually provided value and made things more efficient and more effective for them within the organization. Use the metadata to improve any communications that you have around metadata. Now I'm going to share with you a communication plan here in a second, but a communication plan needs to focus on making certain that we get the metadata that people in the organization know what information we have about the data that we're delivering to them. So we need effective data communications. We need to use the metadata to improve the value of the data in these resources that we're investing in. For example, if you're creating a data lake, one of the things that prevents a data lake from turning into a data swamp is documentation of the data and certification of the data going into the data lake. But certainly the documentation that's available for the data that's being housed within your data lake. So you need to get people to use the documentation and we want to stay non-invasive while delivering value. What I mean by that is we want to make it as simple as possible for people to access the metadata that we are putting our time and effort into defining, producing and using in our organization. Here's an example of a communication plan that you might want to, and typically I break a communication plan into three levels. The orientation communications onboarding and ongoing communications. And we provide these templates as a follow up in these emails. So I know this is somewhat difficult to read but in the onboarding, and that's that middle section of the communication plan, we recognize that data documentation needs to be delivered to people and how are they going to know about it unless we provide information about that metadata to them during the onboarding process. During the ongoing process we want to make certain that people understand what metadata has been added to the equation what's out there and what's available for them to use as part of their daily job and using these data resources that we're providing to them. So let's spend a few minutes talking about implementing effective metadata governance tools. So there's a bunch of tools that you can acquire on the market and there's also some that you can create yourself. So governing metadata you can create tools on your own or you can acquire the tools as I mentioned earlier, you might want to consider starting the tools you have in your environment or picking up some of the tools and templates that are shared in this webinar and in other webinars and start to create your own inventories of what tools you have and of what data you have and who's responsible for that data across the organization. One of the tools that I talk about a lot is something I call a common data matrix. The common data matrix is a way of inventorying what data we have in the organization where the critical pieces of data lie within those resources who has responsibility for it and that's one of the tools that I suggest for most organizations that they start with right out of the game is let's recognize what data we have who has responsibility for it and where the critical data within the organization lies. If we start by creating this tool the common data matrix now there's two versions of this on this diagram there's a kind of the blown up version that says okay we're starting with a specific subject matter or domain of data and then we're breaking it down into subdomains and even breaking it down further into critical data elements we need to know what data is important and where does that data reside across the common data matrix we can see in this situation that the campus code piece of data resides several places it resides in PeopleSoft and Archibus and Data Warehouse and there's different people in the organization that have responsibility for that data in that system. We as data governance practitioners need to make certain that we're collecting this information and so the part that's inserted below of circled in the peaches color is if you continue to work further across the common data matrix we want to know who uses that particular data from that particular system and if we define the different parts of the organization across the top and even if we just put an X in the block that says that this part of the organization uses this data from this specific place you know we then we can recognize well what type of metadata do we need to provide to those people who are going to use that type of data. Do these people even know that the data exists so we might want to even start with creating information for them about what are the data resources and what are the metadata resources that are available to them across the organization. So the common data matrix becomes an important tool for getting started with your program because if we don't know who does what with the data we don't know what data exists or where the most critical data exists it's going to be very difficult for us to demonstrate value with our data governance program. So we want to define our requirements for the governance of metadata. We don't want to just talk with the business community because there's technical people who need to be involved as well. You know when it comes to protecting sensitive data and how data is classified for example if you need to transmit data that is highly confidential there may be a business rule that states that that data needs to be encrypted before it's sent. So we need to figure out well what type of metadata is it that the people on the technical side of the organization will use and how they can use that metadata to help them to deliver the things that are most meaningful from their function within the organization. So for example IT security or privacy they need to be able to help us understand what data is classified, what ways and then make certain that the technical requirements address how that data is classified. So I mentioned earlier if we can talk to our business users and not use the term metadata to determine what the most valuable information is that they need in order to get the most value out of the data if we can do that without saying metadata and that's all the better. If we start asking people what metadata they need we can expect the gloss over and roll back in their heads. Metadata seems to be a very technical term. If we talk to them in terms of data documentation and what they need to help them to be successful that's a very important piece of information that when we're developing not only our business requirements but when we're collecting our technical requirements for the metadata that we're going to manage as part of our organization. And oftentimes organizations will start once they've looked at the tools they have internally and they've started to recognize what tools they can develop they decide that they're going to look to the outside. They're going to see what tools are available on the market that are going to benefit people across the organization. And what I suggest to organizations is that they demonstrate strength in how they're collecting their data documentation requirements. Otherwise when you send an RFP out to a vendor they're going to tell you that their tool can do everything and they're not going to focus on those things that are most specifically important to you. So my suggestion is if you're creating an RFP to go out and gain access or acquire a new data governance or metadata management tool that we develop decent or should I say strong documentation requirements for what we need out of the metadata. So again, give them a good list of things that you're looking for and have them respond to specifically the things that you need. And so be detailed in your process in your request for proposal when you send out that request these are the requirements that we are looking for. I have seen organizations send out RFPs that are very general in nature and don't really get to the main points of the things that they want to manage through their metadata tools. Evaluate the responses, measure the results and then before you go whole hog into using one of these new tools, select in a pilot or an area where you're going to test out the use of this tool within your organization. Deploy resources. We know that we need to have resources that are also associated with the metadata tools that we're analyzing. So select appropriate resources for the job. Who are the people in the organization that know what we need to do around the data to make it more valuable to people that know about the metadata that needs to be made available. Name the resources for whatever tools you're developing. Even the common data matrix will not create itself and populate itself. When we're looking to acquire tools we need to have people that have the responsibility for defining the requirements and then once we've purchased and implemented or started to implement these tools, we need to have resources available to educate people and train them in the use of these tools. So again, my suggestion is to be noninvasive in the use of the metadata stewards within your organization. Shannon, can I take two minute break please? Okay. We're going to continue on. Maximizing the metadata resources with accountability. We need to determine the resources that are going to be required in order to implement metadata governance across your organization. So this includes the people in the organization that are going to have responsibility for defining what metadata it is you're collecting for producing that metadata and for using that metadata. We need to include the resources for the tool and the template management. So like I said before, these tools are not going to create themselves. They're going to become very critical to people's understanding of the data and using the data across the organization and they're not going to maintain themselves. So we need to include the resources not only a person to administer the overall metadata management aspect of your data governance program but we need also to recognize not only that this will not be guided by itself we need to have somebody who is the metadata manager or in this case I call it a metadata governance administrator. We need to identify who the people in the organization who are defining, producing and using the metadata and those people that will have responsibility for the tools across the organization. And as I said before, metadata and metadata stewards are a critical component to a successful metadata program. So we need to apply a stewardship approach to how we're managing metadata. We need to make certain that people within the organization have formal accountability for how they're managing the metadata. So people that are putting definition to data need to not provide cheeseburger definitions. They need to provide business definitions with business context. We need to detail the responsibilities of these stewards. We can't just ask people to be metadata stewards without telling them exactly what we're expecting of them. What metadata are we asking them to collect? Where are they collecting that metadata? Who's validating that metadata? We need to detail all of the responsibilities associated with the metadata stewards. And certainly oftentimes the people that are creating the documentation almost as an afterthought, they look at themselves as not being that important. We need to help them to understand what the role is, why they are important in the scheme of things to improve the quality and the value of the data. You see providing everything as a service provide data documentation as an asset. That becomes one of the critical assets associated with the different data that we're managing within our organization. We need to make certain that we're applying these stewardship approach and formalizing accountability for the definition, the production and the usage of the metadata across the organization. One of the ways to do that is to build the metadata governance into people's jobs. Recognize where they touch the data documentation. Where would they define it? Where data documentation adds value to the work that they're doing. Provide easy access to that metadata and make certain that we recognize the people across the organization recognize what metadata is available to them and what data documentation is available to them. And recognize what's being used and why it's being used and share that with different people across the organization. Direct your efforts at adding specific value based on the different metadata that you're collecting within your organization. Promote your metadata governance success by measuring the value of the documentation and we as a practitioners don't necessarily know the value until we ask people in the organization that are using that metadata to help them with their job. Improve the understanding of the value of the data through the metadata that we're providing to them and communicate to people effectively what metadata is available to them in the organization. Follow the metadata governance success tips and I'm going to provide a bunch of success tips right here for you. Make sure that you follow some of these in order to be given the ability to even start to govern metadata as an asset in your organization. One of those things makes certain that people at the highest level of the organization understand the need for data governance. So we need to get them to support sponsor and understand what the metadata is doing and why it's a valuable part of getting a return on investment out of these heavy investments that we're making. Make certain that you have somebody that's responsible for metadata as the administrator. Make certain that metadata stewards are recognized based on whether they define produce or use the metadata. Measure and communicate the metadata value to people across the organization. That's really the way that I suggest to start to govern your metadata in a noninvasive way. So I know I went quickly through a lot of these slides. The things that I talked about today were the concepts of noninvasive metadata governance and metadata as a valuable data resource and governing metadata as an asset to the organization aligning data governance with your metadata governance or the other way around. As I mentioned, aligning your metadata governance with the way that you're governing data, implementing effective tools, and maximizing the resources that you have available to you to help you to govern your metadata more successfully. And with that, I'm going to turn it over to Shannon to see if we have any questions today. Bob, thank you so much for another great presentation and kicking us off in the new year as such. Just a reminder, and to answer the most commonly asked questions, I will send a follow-up email by end of day Monday with links to the slides, links to the recording, the matrices that Bob mentioned and other additional resources. So diving in here, Bob, can you talk about the importance of data glossary in metadata? Well, the data glossary is the business language that people use. So we need to be able to help people to understand what we have data about. And oftentimes, that's the different subjects of the different entities. So a business glossary is kind of the top of the food chain. It's the business semantics that we use, and oftentimes organizations create business glossaries that allow people to kind of dive down or say dig into where that data is located and locate the data dictionaries associated with the data that we talk about in the business glossary. Glossary is unrelated to the metadata describing databases in your model or your meta model. Would you expect those to be connected at some point as part of the data governance process? Well, I think the easiest answer to that is it depends. If we want to help the business community to dig through the business terminology and the language that we use, then yes, they're going to need to be connected. But I've seen organizations that have created glossaries that are separate from the data dictionaries just to get people speaking the same language along the same lines of semantics and terminology in the organization. So the answer is yes, they can be connected, but no, they're not always connected. So what percentage of the budget should be allocated to metadata management? That's a great question. Some, I guess that's the easiest answer. If we don't have any budget associated with it, there won't be any resources that focus on this. I don't have a number for you. I'm sorry. I would say that you want to make certain that enough budget is set aside to make certain that we're collecting the metadata that's going to help people to get the return on investment in these data investments. Yeah, it's definitely a tough question to answer. I don't know if there's the standard. But moving on here, data science and AI machine learning tend to get bigger share of the budget compared to metadata. Is that true and should it change? Those are the bright shiny objects that people are going to use. The problem is it's only the tip of the iceberg. It's what's showing above the surface. All the work that goes on behind the scenes, the information about the data that are going into these bright shiny objects are really important too. You're right. A lot of the budget is going into the analytical platforms and the data scientists. And we need to make certain that we're putting enough money into those supporting features that will make those investments worthwhile. And is there a place, Bob, where you can find industry references models? I think that there are. I know that some of the large consulting companies and large companies like IBM present some of those models. But I don't know of a metadata resource. There are books on metadata management from Adrian Tannenbaum, David Marco, to name a few that have examples of these metamodels and what it may help you to identify with the metadata that's most important to you. I also suggest going out to tdan.com and looking for the articles that specify what questions metadata can answer and what different categories of metadata are out there to be collected. And how important is an enterprise level data governance area? It depends on how big your enterprise is. I don't know. I don't see a whole lot of organizations calling it enterprise data governance, but there are some. Enterprise data governance would cover the entirety of your organization. And so oftentimes data governance initiatives start in a more localized place rather than an enterprise place. So I would say some organizations try to start large. I suggest starting smaller and working your way up to the large. And what kind of person or skill set is best for managing data catalogs? What type of background, developer, analyst, BFA? I would say all of those people are potential people that would do that. Oftentimes it's the people that are responsible for the governance program itself that are going to create that data catalog. You may look to your security groups and see what they already have cataloged and take advantage of things before we start creating things from scratch. I saw a question come in again talking about glossaries. What's the difference between a glossary and a dictionary? A glossary is the business semantic level and the data dictionary typically represents all of the data within a specific data resource. So you may have a data dictionary for your data warehouse. You may have a data dictionary for your data lake or for a specific application. A business glossary is not necessarily connected to those things. It's really the business language of the organization. So they are really two separate things even though some people use that language interchangeably. How important is data lineage as part of data governance? Well people want to know where the data comes from. And that's one of the first questions that people ask. If we're going to build their confidence in the data that we're expecting them to use they want to know where do the data come from? What happened to the data along the way? So I would say that data lineage and data movement data or data movement metadata are one of the most critical types of metadata that we can record or that we can make available to people. So Bob we get this question a lot in terms of responsibilities. Is metadata governance primarily an IT function? Could it be considered IT stewardship? That's a great question. I think it's a combined effort between IT and business. I mean IT may make certain that we have the things that are in place to collect the metadata but the business actually collecting the metadata, putting the business definition, putting the business rules, putting the classification is more of a business function than it is a technology function. So I'd say it's kind of a partnership between the two to provide the metadata that we need. And what role do you see data architecture having in this space? How important is it to metadata governance? Well the data architects are extremely important. They know a lot about the data. How the data is set up. How the data relates to other data across the organization. I often at times don't see the data architect, I'm sorry, too involved in the metadata process and actually what that's doing is it's like tying one hand behind our back. We need to make certain that we're taking advantage of those resources within our organization that have the most knowledge of the data to help us to collect that metadata. And so that's why I say that the data architect can actually become a critical component for the team of people producing the metadata. I love this next question. Do you have one or two handy dandy slides that are useful in a presentation to convince senior management of the metadata governance team and system and to help convince the investment will have a good ROI? I don't have them available to me right this second, but I'm sure that I do. And so the person who is asking that question if they can reach out to me directly or let me know that this is interesting, that they're interested in this, I will try to provide them to you Shannon so that you can provide them to the group. That'd be great. We get that question a lot what's the elevator pitch? How do we convince senior management? I love that it's a request for presentation. Do you have any other good advice on how to convince senior management? Well, I mean we need to have the basic question for them that in kind of a utopian environment in an ideal future state what information do they need about the data that they use that will help them to get the most value out of it. And if they can articulate that to you we can recognize that you know what, this metadata becomes valuable not only to me, but to everybody in the organization and we should expend some resources towards managing it. Perfect. So I think we have time for a couple more questions here you know Bob how can we leverage the metadata function to help us to enhance the quality of field level contents? Are people generating field level statistics of every input update and storing them in a table and putting guardrails around them to identify issues and corruption? I know that was a really long question but I'm going to ask you to rephrase it or ask it again. Sure. So how can we leverage the metadata function to help us enhance the quality of field level contents? That's the core of the question there. You know are people generating field level statistics of every input and update and storing them in a table and putting guardrails around them to identify issues and corruption? Field level metadata is extremely important. In fact in order to do edit checks to make certain that the appropriate data is getting in and that the data relates to other data within the environment is very important and that really starts and ends with field level metadata. You know and then add on to that you know we find that we have trouble identifying when a load update goes wrong I think the answer might be in metadata generation and management it is going to be in the metadata generation but it's just another piece of metadata that's important to adding value to the data in the organization. How is business architecture related? Well data architecture is a component of business architecture so it's important in getting the appropriate business people involved, getting the appropriate business information about the data involved. Business architecture if it doesn't include data architecture as a component it's missing one of the key components to the successful business architecture. We can start with business architecture but oftentimes it kind of makes more sense to begin with the data architects. That is all the questions that have come in Bob thank you so much for another great presentation and kicking off yet another year with us in the real world data governance webinar series. Great topic. Thanks all our attendees for being so engaged in everything we do. Love the questions, love the comments continuing to go on throughout. Again just a reminder I will send a follow-up email by end of day Monday for this webinar with links to the slides, the recordings and the additional information mentioned throughout. Bob thanks so much. Thanks everyone. Thanks everybody have a good day.