 Hello and welcome, my name is Shannon Kemp and I'm the Chief Digital Manager of Data Diversity. We hope everyone is staying well and safe out there and 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, we'll be discussing data governance roles and responsibilities, 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. If you'd like to chat with us or with each other, we certainly encourage you to do so. You can click on the chat icon in the bottom middle of your screen for that feature. And for questions, we will be collecting them via the Q&A in the bottom right hand corner of your screen. Or if you'd like to tweet, we encourage you to share our highlights or questions via Twitter using hashtag RWDG. 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 series speaker for this, 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 DAMA Professional Award for Significant and Demonstratable 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. Hey, everybody. I hope everybody's doing very well and you're safe and healthy wherever you are. I'm glad to be with you today. As Shannon mentioned, today we'll be talking about data governance roles and responsibilities. And this is a subject that I like to talk about a lot and there's a lot to be said about the importance of data governance roles as we're setting up our data governance programs with the hope and the intent that we're going to be successful in governing the data for our organizations. Just a couple things to start off with before we get into the material for the webinar today. I want to let you know that this is a monthly webinar series. It takes place on the third Thursday of every month in the month of September. I will be talking about data governance and three levels of metadata management. But I've also got a hint for you here. There might actually be a fourth level of metadata management that I'm willing to talk about. I'm going to be introducing a new metadata semantic framework during that webinar. So I hope you'll join us for that one as well. I talk a lot about non-invasive data governance. If you're interested in more information about non-invasive data governance, there's a book that I authored several years ago that's available at your favorite bookseller. I'm speaking at a couple of virtual online dataversity events coming up in the balance of the year. I'll be speaking at Enterprise Data World and that will be in October. And in December I'll be talking at the data, I'll be speaking at the data governance and information quality conference. And actually I'm going to be giving a longer presentation on roles and responsibilities at that event. So I hope you'll join us for that event as well. Big news coming soon, a new course, an online set of courses as part of a learning plan with dataversity. It's going to be called business glossaries, data dictionaries and data catalogs to go along with my non-invasive data governance learning plan and my non-invasive metadata governance learning plan. Sharon mentioned the data administration newsletter tdam.com. If you haven't been out to visit it yet, it's a free resource. It's got a lot of articles, columns, blogs, features on the subject of data management and data administration. And that gets published twice a month on the first and third Wednesdays of the month. And also then last but not least, there's KIK Consulting and Educational Services, KIK stands for Knowledge as King. That is what I refer to as the home of non-invasive data governance. So please go there if you're interested in more information about non-invasive data governance. Today I've got a pretty packed agenda to fill the hour or part of the most of the hour. Certainly we'll leave time for questions at the end if you've got questions. But the things that I'm going to talk about today are really important when it comes to developing a solid set of roles and responsibilities associated with your data governance program. As I mentioned earlier, the roles and responsibilities happen to be the backbone of what really makes your program successful. Everything from process to communications to metrics have to do with the roles and responsibilities. So the first thing I'll talk about are the different levels of roles and responsibilities that are part of an operating model that I will share with you. And then I'll talk to you about how you can customize that operating model to fit to your organization. I always say that rather than trying to plug into somebody else's operating model, if you can take an operating model and overlay it over what exists in your organization, that's a less invasive approach and one that might be more acceptable to your organization. I'm going to spend a bunch of time going through each of those levels and detailing out the responsibilities of the people in the organization that are governing data or have governance responsibilities at each level. We'll talk about who are the people that participate at each of the levels. And then at the end, I will be talking about using working teams to start to implement some of these solutions to actually make the rubber hit the road for data governance and demonstrate value and demonstrate improvements to your organization. So I want to start out by talking about the different levels of roles and responsibilities that are necessary in order to be successful with your data governance program. And I'm going to show this slide a bunch of different times, a bunch of different ways during this webinar. But if you can kind of commit this to your memory or think about it in terms of the fact that there are different levels of roles and responsibilities, there's an executive level, and they have some responsibilities. There's a strategic level. People talk about the data governance council. There's the tactical level. That's the data domain stewards and the subject matter experts for the data. And then there's the people at the operational level who are your day-to-day, daily data stewards and that they define and produce and use data across your organization. On the left-hand side of the model, there's different roles. There's different support roles. First of all, somebody needs to guide the program. So whether it's calling a data governance office or an administrator, somebody needs to take that role. Then there's the data governance partners. There's the functions within the organization that are already governing, not necessarily governing data. They could be governing risk. They could be governing projects. They could be governing illegal aspects of your organization. And these folks already exist within your organization. I'll talk a little bit more about that as I get a little bit further into the webinar. And then there's the working teams. Those are the people that are brought together to solve tactical problems within the organization. So I'll be referring to this diagram quite a bit. And there's a lot of information about this already on TDAN. And please reach out to me if you would like additional information about the operating model. So the first thing I'm gonna talk about are those five levels. And we think about the fact that it's gonna be critical to our organization that our senior leadership support sponsor and understand what the heck it is we're doing as we're implementing our data governance program. So the executive level, they don't necessarily have that day-to-day operational role, but we know that we need to communicate effectively with people at the senior leadership level. And they're the ones that have the enterprise perspective. And then there's the strategic level. A lot of organizations will refer to that as the data governance council or the data governance council. And they're the ones that are really taking that organizational perspective where we're looking at making certain that the data is consistent and that it's defined well and that it's high quality for the entire organization. There are the tactical roles of the people in the organization that already play a role in understanding and helping to make decisions associated with specific subject matters of data. There's an operational role. Again, those are the day-to-day people that are within the specific business units or organizational units parts of your organization and the support roles. And the most important thing as we get started here is to make certain that you identify the appropriate number of levels that are associated with your organization, the ordering of the levels. I had a client at one point that said, no, no, no, you've got the tactical and the operational mixed up and we at our organization, the way that we talk about it, we would typically have the strategic then the operational and the tactical. Again, you wanna make certain that the model matches what is already presently happening in your organization, but you need to make certain that you're addressing each of these different levels as we're building out the roles and responsibilities. Now, I've given a webinar earlier this year and I think I've talked about this in other webinars where I talk about a data governance framework. And this is not what we're going to spend time talking about today. We could spend the whole hour easily talking about this framework and the important pieces and components of the framework and why they're important. There's a couple of things that I wanna point out to you about the framework, however. And the first one is that lockup in the upper left-hand corner that you can't read very well because it's fuzzy or because it's too small for you to be able to read on the screen. I wanted to highlight that so you can understand that there are different components that are necessary to the framework of your programs. And then there's the different levels that I just spoke about, the executive all the way down to the support level of the organization. And if you notice, one of those core components that I talk a lot about are the roles and the roles and responsibilities. And that's the second column from the left and it's highlighted in red. And that's what we're gonna talk about today. We're gonna talk about each of the different roles as they're associated with the executive level, strategic, tactical, operational, and support levels of the organization. So the first question that a lot of organizations have is, well, what should we call the people that are part of the data governance program that exists at these different levels of the organization? And oftentimes these groups already have a name. So make certain that you look to see if you have a steering committee or you have an asset management council or something at the executive level that we want to call it, whatever they're already called. This isn't necessarily going to be a new team that you're developing specifically for data governance, but they are gonna play the role of steering the program and making certain that the program is addressing the appropriate things in your organization. At the strategic level, there's the data governance council. I think that's the name that most people are used to referring to, the strategic level as I've had other organizations, one that I'm working with now that calls it a data council, one that called that the steering committee at the strategic level. So again, pick a name that's gonna be most appropriate to match what's going on in your organization. At the tactical level, I oftentimes refer to them as data domain stewards. So if you think of a domain as being a subject matter, a subject area of data, we need people in the organization. We need to recognize those people that already have the knowledge and the smarts and potentially even are the decision makers, associated with that specific subject matter of data. I refer to them typically as data domain stewards. I had a client say to me, well, aren't they really the data subject matter experts around the specific subject matter of data? And I said, yeah, that's pretty much what they do. And they said, okay, that's what we're gonna call them. So again, call the different levels at the terminology that you use and that makes most sense for your organization. At the operational level, I do find that a lot of organizations refer to those people as the data stewards. And I've done webinars on one that I refer to all the time that's called everybody is a data steward and that we can need to get over that fact. And that's really the only way that we can have complete coverage of the organization. And then there's the support level part of that pyramid diagram that I showed. And they've already got names. You might have a project management office. You may have a risk management office. You may have IT security. We don't need to rename them. All we need to do is recognize that they have a relationship to data governance and that we want to take advantage of or at least leverage what they are doing around governing the data and governing the most important assets that your organization has. So let's think about what we want to name the different roles. And again, don't try to use the model that I shared with you and necessarily use the names that I've provided. Just make sure that it makes sense for your organization. And recognize that each of those levels that I talked about are very important. I've had organizations look at that pyramid diagram and say, wow, that's really bureaucratic. Say, well, how is your organization set up? And a lot of times the organization is set up to have each of these different levels. Again, that might not be the name that you call these levels, but there's executives all the way down to the people that day-to-day are rolling up their sleeves and are entrenched in the data of your organization. So each of these levels is important and they should be called out in some way, shape, or form in the operating model that you're using for your organization. The senior leadership, as I mentioned earlier, they need to support, sponsor, and understand what it is that we're doing with data governance and with the data governance program or our program becomes at risk. If they don't support, they don't sponsor, we know that's a problem. But the truth is that if they don't understand, that's where the real problem kicks in. And it's always best to communicate to them the approach that you're taking to governance, why you're taking it, the things that you're doing, and what level of success you're having or how we're progressing as an organization when it comes to governing the data. So without a strategic level, that data governance council level, typically data governance is not gonna become a priority within the organization. So we want people that are going to meet with us once a month or however often your council meets to help us to set priorities and to agree or to approve the things that we bring up to their level. Then there's the owners or there's that tactical level which is really important as well. We need owners, although I don't like using the word owner, I like using the term domain steward or subject matter expert instead of owner because owner implies that it's their data when it's actually the organization's data. So without the owner or the SME, the data's gonna continue to be viewed as a siloed and an uncovered asset within your organization. So it's really important that we focus on that tactical level when we recognize who those domains stewards are or whatever you call that role for your organization. Then there's the operational level and we know that that's important. And these are the people that day to day are defining and producing and using data as part of their job. If we're holding them accountable for what their relationship is to the data. So for example, if somebody uses data that needs to be protected and that's sensitive and we're holding them accountable for how they use the data and following the rules that depend on the classification and the handling rules that are associated with that data, they're stewards of the data. So we need to make certain that at the operational level we know who does what with the data and that we have a method in place for holding those people formally accountable for what they do. And as I mentioned before, the support level, they're already governing data. They're already doing things, maybe not governing data but governing something specifically important to your organization. So you wanna be able to call out who your data governance partners are. So some of the things that I just said on these last two slides, the executive level is important. The strategic and tactical level are really important in the success of your program. The daily, the operational people, the support people, they're all important. So your operating model or how you define roles and responsibilities for data governance in your organization should at least address all of these different levels. So now I wanna talk a little bit about why the pyramid is set up as a pyramid and why it's not just a bunch of blocks that are disconnected or would have you. So there's a method to my madness for how I set up the pyramid diagram. And the first thing that I wanna call out is that the space at each of the levels of the pyramid so that peachish or oranges level up to the yellow level, up to the pinkish level, all the way up to the executive level, that space, the amount of space in each of those layers mean something. And that is typically something that would be conceived as the percentage of the decisions that are gonna be made at that part of the organization. And if you look at it, most of the most organizations that I've come in contact with, they wanna push as much as the decision-making down to the operational level as they can, but when a data issue starts to cross over parts of the organization and becomes a cross business unit issue, it gets escalated up to that tactical level where those subject matter experts get involved. And if they don't have the authority to be able to make the decision, it gets escalated up to the strategic level and that is why we have a data governance council so that they can make important decisions that are brought to their attention for the organization. If you notice, there's no space in the tower that sticks out of the top of the pyramid because we don't typically take data issues to the executives of our organization. So it's just a tower. There's no space in it. So that space within each of those levels of the pyramid, that means something in your diagram. What is that specifically called out? At the top of the pyramid, there's no space in the executive level. So basically what we're doing is we're moving from a business unit way of resolving issues up to a cross business unit way of resolving issues and addressing opportunities to an organizational perspective and then to the enterprise perspective. And when I go and show you the large diagram again, you'll see that that first arrow to the right says escalation path and that's the direction that's going to move. So we're looking to break down the silos. We're looking to be consistent in a way that we define data across the organization. And so we need to represent the organization appropriately in our operating model of rules and responsibilities. Now I say consistency in color too, because if you've attended other webinars that I've done as part of this series or presentations I've given at Dataversity events, you'll know that I share a lot of different tools. I share a tool I call a common data matrix, a communication plan matrix, a race each chart, which a lot of organizations use. And I say that it really makes sense to be consistent in the way that we use colors in these diagrams. So if you can see yourself in the operating model, you can find yourself in the race. You can find yourself in the communication plan. So being consistent in the colors helps for the organization. And I have a client presently that decided not to use the color scheme that I had selected. Looks more like a rainbow in the one that I use, but they wanted to use the colors of the organization, the RGB colors to make certain that it followed the logo in the color scheme that is set up by that organization. So again, the message is take the model, make it custom to your organization, use the colors that are most appropriate for your organization and be consistent in the way that you use those colors. Another thing that I mentioned occasionally is that the way these different parts of the operating model side up against each other, the borders between them, they represent something too. And on the left hand side, that middle piece, that greenish slice is the data governance team or the data governance office or lead or administrator or whoever that is that has the responsibility for your program. And you notice they basically touch every part of the organization. They're the ones that are, they're captaining the ship, they're making the program happen. They work specifically with the partners, which are the outer parts, the far left slice that you see in the pyramid. They work with the working teams, which is the blue slice. And the blue slice of the working teams are made up of people at the tactical level and people with the operational level. So again, the way the different sections side up to each other and border on each other, that has meaning as well. And typically again, the data governance office or the data governance lead or administrator, they're working with everybody in the organization. They facilitate the working teams. And as I mentioned, the working teams are typically made up of the subject matter experts or the tactical level stewards, as well as the operational stewards of the organization. I think I'm going the wrong way. Okay. So there's additional things that I add to the operating model. And those are qualifiers on the outer parts of the model. And if you can see, that says new or leverage or exist. And the first thing that happens when people look at the model is, there's this sense of fear, oh my God, we got to put all these things together for our organization. It's going to be so bureaucratic. Well, let's mitigate that fear as well as we can. Let's add to the model, hey, we already got an existing steering committee. The council is going to be new. We're going to leverage those people in the organization that are the subject matter experts. The stewards are already, at least we hope, stewarding day to day today, but certainly that's one of the things they're certainly defining producing and using data as their job. So they already exist. On the left-hand side, if you or somebody in your organization has the responsibility for running the program, that's the top level there. You certainly can leverage the partners and you might say that the working teams of your organization are new because we haven't used things like that for data governance before. But you can mitigate the fear and you can minimize the people's view of this as being bureaucratic by adding different components to the operating model. So these are all different ways that you can go take this model and make it more custom for your organization. So what I wanted to do is to share with you again what the model looks like. So now that I talked about all those different things, you can see some of the things that I have talked about, including the escalation arrow, the communication arrow along the right-hand side of the operating model. So again, don't try to plug your organization into the operating model. Take the operating model and overlay it over what exists already in your organization. Again, the idea is we're already governing data, but we're doing it very informally. And because we're doing it informally, it leads to inefficiency and ineffectiveness when it comes to the data of the organization. So think about those things as you're creating the model. And the next thing I want to do is I want to go through each of the different levels that I've talked about and give you an idea as to what the specific responsibilities are to the different people at the level. And so what I've done is I've minimized the diagram at the bottom. And I'm going to point to each of the different levels that I'm talking about with the verbiage that you're finding on each of the screens. So the executive responsibilities, the data governance steering committee, they may have some specific responsibilities in your organization. They may be the ones that identify or recognize people that are going to play our role at the strategic level, at the data governance council level. Now these folks don't necessarily have day-to-day responsibilities or activities associated with data governance, except for the fact that they need to be reported too. They're the ones that need to know what it is that we're doing within our organization when it comes to governance. And they get the report from the council, from the data governance lead as to the activities and the status of the activities that are taking place within your organization. Their responsibility is to support sponsor and understand your program. And oftentimes there's a line item at their meetings or every other one of their meetings that has to do with data governance and that the council is represented. So typically for people at the executive level, they're not necessarily involved day-to-day in the operation, but they play a critical role. It is best practice that they support sponsor and understand what it is we're doing when it comes to the implementation of our program. The data governance council plays a vital role. And the first one of their responsibilities is that they become educated in what data governance even means and how it can and how it will work for the organization and how it is important that they embrace the concepts associated with data governance. And they may even be the ones that recognize for us or help us to validate or select the people that are gonna be at the tactical level. Those people that are breaking down the silos that are making decisions for the organization rather than a specific business unit. They approve things that need to be approved at that level of the organization. It could be a policy, it could be your role framework or your role model that we're talking about here. Methods, priorities, they push governance down into those areas, into their area of the organization by actively promoting the practices that are taking place. The data governance council makes decisions at the strategic level in a timely manner. We don't necessarily want them to only make decisions when we come to them for the council meetings. We wanna make certain that we can take advantage of their knowledge and their expertise and their responsibility when it comes to governance in a virtual manner. So we can reach out to them when we've got questions that they can answer or priorities that they can set for us. These folks meet fairly regularly or they send an alternate. I have many clients that have people that make up their data governance council that also have an alternate in case they're on vacation or they can't make it to a meeting, somebody who is also copied on the meeting invitations. But we want to make certain that each of the different levels of the organization are represented on the data governance council. And they need to read the minutes that are being provided to them, stay informed of those things that are taking place within data governance. Oftentimes they have the responsibility of identifying and approving critical roles that are part of your program. Like the enterprise or cross enterprise data domain stewards and the coordinators of which I'll talk a little bit about in a second that that tactical level, there's also a role called coordinator. Some organizations have it, some don't, but I just wanna share it with you in this session. So if you can understand and figure out whether or not you need that role for your organization. Oftentimes the data governance council, there's somebody on the council who's the owner or the key person, maybe it's their admin that has the responsibility for scheduling meetings. But we want to make certain that the council itself advises that owner on the appropriate ways that governance can add value for the organization, whether it's risk management compliance or any other business unit specific interests that they may have. It may be system integration, it may be building an analytical platform, it may be data protection and information assurance and those types of things. So the council has a very important role and we'll talk a little bit in a second here as to what amount of time we should expect from people at that level. Then there's the data domain stewards, the enterprise data subject matter experts, the data owners you might call them but I typically don't use that name. This is the most critical role of your program. This is where, again, we break down the silos, we don't have data defined different ways and different systems that the organization goes crazy when they ask questions, when the senior leaders ask questions and they get different answers depending on who they ask because the data is defined differently. The data understanding is different from people using the same system. So the data domain stewards play that critical role, that tactical level is critically important and oftentimes it may be that it's a position within the organization. So whoever the person that's in that position, they would play the role of the data domain stewards or maybe it's a person. We know we always go to Joe when we have a question about customer address information. Well, maybe they're the customer data domain stewards for our organization. But typically when they're playing that role, their affiliation to their business unit really becomes secondary because you don't want them to come to the meetings or to make decisions that are only based on the things that are gonna be helpful to their business unit. They're really viewing the data as an enterprise asset. So when they're acting in the role of this data domain steward, their affiliation to their business unit really becomes secondary. And they're involved, they're actively involved in facilitating the resolution of data issues, whether it's a definition production or usage data issue. They're also the people that have the responsibility for making certain people are engaged in solving these problems. And they may or may not be the decision makers within your organization. Sometimes it really depends on their position within the organization. They're responsible for a bunch of different things as well. Escalating documented issues to the council for documenting data classification rules, compliance rules, business rules, for making certain that these rules are being communicated across the organization. They're also responsible for engaging in these working teams that I spoke about earlier and I'll talk about again here in a minute. Yes, so these people, you know what they're already involved in a lot of these things. When you're integrating systems, you're gonna bring the subject matter experts into the fold and get them involved. So the data domain stewards, again, the idea is to recognize who they are, first and foremost. You don't really wanna assign people because that feels a lot more invasive. It sounds a lot, should I say, a lot more threatening, a lot like command and control. We wanna recognize who they are, which has more of a natural fit to our organization. And so what are some of the traits that I see to be common among good data domain stewards well, first of all, they have a vision of what data, the future of data looks like as an asset for the organization. They're looking for ways to improve things. They have the ability to motivate the organization and set examples of data related behavior. They're team players, they're diplomatic. These are just again traits of people that would make good tactical level data stewards for our organization. And they have the personal interest and the intuitive ability to help to facilitate things to a win-win situation within our organization. The data stewards coordinators are another role at the tactical level and they're basically doing what their name says. They're coordinating the activities of stewards within their part of the organization. They act as a point communication person for distributing rules, for helping us to recognize who the stewards are of the data, who's using what data in the organization. I talk a lot about a common data matrix and if you're fleshing out a common data matrix, you're getting those people involved in defining who the people are in the organization that are doing, taking action with data is really important as well. They identify the operational stewards of that data per the domain within their business unit. They work with the data domain stewards. They typically don't have any decision-making authority but they do play a pivotal role if you're leveraging this role within the organization. And then there's the data stewards themselves. They participate in a lot of different activities and I don't really wanna go through them all one by one because we're gonna run out of time really quickly here but you can see they do a lot of different things. They are the people that date today are defining, producing and using data as part of their job and we need to know who these people are, believe me. That is one of the most critical things that we need to do is know who the people in the organization are that use data that needs to be protected that can build on the quality of the data. They identify and document the issues associated with the data. They share knowledge with other stewards. Two of the most important responsibilities they have is communicating new and changed business requirements and concerns and issues to people within the organization that can make a difference in improving the way that we're governing data as an asset. So typically I break the data stewards into definers, producers and users and yes people can be definers and producers or definers, producers and users or users and producers but we want to know who does what with the data across the organization so recognizing them as definers, producers and users that's going to help you to recognize who the stewards are, certainly use that information and so it takes doing a little bit of research to determine who's defining the data who has responsibility for producing it and who's using the data. The data governance office, the first level of the support that I have listed on the left hand side of the pyramid they are the people that are guiding the ship. They have the responsibility for the program and they do all the things that are mentioned here. They oftentimes they may start as a planning team that evolve into a program team. They administer the program. They facilitate the council meetings. The office has a very specific set of responsibilities and we need somebody to run the program as we're moving the program forward and again they participate in the delivery of education and awareness, they report the results. Now these are the people that participate day to day in making the things happen that are required for our organization when it comes to governing data. They assist in defining the metrics. They support the data quality issue resolution to make certain that we're going to focus on that most specific data, that critical data to the organization, that strategic data that we need to get right across the organization. They conduct audits. The data governance planning team or the office or the administrator are critical in the success of your program. And the next class role that I want to talk about is the partners and these are people that are already doing things associated with governing within your organization. It could even be HR who are governing the human assets of your organization but certainly IT security, risk management. You know, we need to call out these people and make certain that we're working appropriately with these people and we're not stepping on their shoes when it comes to governing data in the organization. They're already doing it. So I say all the time, you know, non-invasive data governance focuses on formalizing governance for data. It doesn't need to be recognized as something that's brand new for the organization. We're already doing it. We can do it more formally within the organization. They ensure that policies and metrics are in place. They ensure, at least from a data architectural perspective, that strategic data is modeled. They ensure that the project sources, that project source and utilize data from the appropriate places, from the designated systems of record. So data governance partners, IT, is a perfect example of a data governance partner. They're governing the systems and system development and system enhancement and the implementation of packages within our organization. But we don't need to tell IT what to do. We want to make certain that we're working with them as a partner of our data governance program. And so that's why I call them data governance partners. Seems to make sense to me. And they are doing what they do and we just want to make certain that they recognize themselves as being somebody that we're counting on for their advice and their guidance in what we're doing. They provide technical support for data quality, for data governance and cleansing of the data. They ensure that the metadata, perhaps, if that's what you're focusing on, data catalogs and business glossaries and data dictionaries, that that metadata is being collected and that it's also being made available appropriately to people in the best way possible for the organization. So I know I went through those very quickly and please go back and look at this presentation or check on tn.com for the roles and responsibilities or the responsibilities that are associated with these different roles. I know I went through them pretty quickly, but we want to get through a couple more things before we take questions at the end of the webinar. So let's talk for a moment about who participates and how much of their time is going to be necessary at all of these different levels that we talked about here within the operating model. And so, as I mentioned, the executive participation, we're not necessarily asking for any additional time of theirs. Maybe we become a line item on their meetings, but the committee may already exist. It's made up of people at a very high level of the organization. And again, they need to support sponsor and, most importantly, understand what we are doing from the administration of our data governance program. At the strategic level, the data governance council, oftentimes it's important to have those stand-ins that I talk about or those alternate people that are part of the organization, but we want to be very careful as to what expectations we set for the use of the people's time at the strategic level. We can't say we want our council to participate 25% in our program because when they're done laughing at you, because they don't typically have eight hours a week or what's a quarter of the time, about 10 hours a week to focus on data governance, we're going to utilize them as we need to strategically in the way that we are leveraging what they are doing as the data governance council. So it's made up of strategic business representatives. It's made up of people that are representing information technology as well. And as you can see, there's a list of things that we require of those people. They're going to help us to coordinate the data governance activities across the divisions of the organization, foster cooperation across the organizations, help us to communicate across the organization, make certain that we're managing risk appropriately, being consistent in the way that we're applying governance across the organization. So we need a data governance council and we want to make certain that we set the appropriate expectations as to how much time these people are going to need to spend for data governance. So rather than saying it's going to be 25% of their time or 10% or even 5% of their time, let's try to put a number on how much of their time is going to be necessary. So let's think about for these data governance council meetings that we're holding monthly or perhaps bi-monthly or perhaps quarterly within your organization, those meetings are going to be 60 to 90 minutes a month. So we know right off the bat that we're going to need that amount of time for them to participate as a data governance council within the construct that we're defining for roles and responsibilities within our organization. Besides for the meetings, we also want them to make certain that they have time allocated to review things that we're going to share with them. For example, if we're going to take a data governance policy or some type of data policy to them, we want to make certain they have time to review those things before the meeting. So we're not spending the meeting introducing them to it. You know, we want them to look at the roles and responsibilities, how we're going to proactively and reactively govern data within the organization. So may say that we need another 60 to 90 minutes a month. So now we're talking about two to three hours of these people time per month, not 10 hours per week of their time because we know that at least we would expect that these people don't have that amount of time to be able to allocate to data governance. And the last thing about them is that they need to be available to resolve issues that are escalated to their level whenever those issues are escalated to their level. And so if you have your council meeting on the second, let's say the third Thursday of the month, like the real world data governance webinars, but on the third Friday of the month, there's a data issue that needs to be viewed and resolved by them. We don't want to wait for that month to come around. What we want to do is make certain that we have a way to be able to engage them virtually and get them to participate as well. So it's really hard to say how much of a time commitment it's gonna be for this piece of it. But the fact is that if they don't have the time to allocate beyond the meetings and reviewing the things that we send to them, how are we really gonna be able to activate the data governance council? And it's really important that we activate the data governance council and get them involved. At the tactical level, the data domain stores, as I mentioned before, I don't like the idea of calling them owners. We recognize that these are people that are already involved in decisions associated with specific subject areas of the organization. So we're not actually saying that we need 10 hours of their time or five hours. Their engagement is going to be related directly to the activities that are taking place within your organization. If you're gonna solve a specific data problem associated with data in their domain, then you wanna make certain that you're utilizing the appropriate people and these would be some of the appropriate people. They are truly the most important level of the pyramid. They are where the silos of data are broken down for your organization. These are the people that have formal levels of accountability and responsibility. Sometimes the organizations have policies that state who these people are and what they do associated with the different subject areas of data. For example, at a university or an institution of higher learning, the registrar might be the person that has, is the decision maker when it comes to student data. The bursar might be the person that has responsibility for the financial information of your organization. So we're not necessarily gonna say we need X number of hours of their time. We're gonna know that we need to leverage them as necessary for our program and that they play a vital role in the success of our program. Again, if we're looking at the fact that we have siloed data and we're trying to bring that data together so there is understanding, consistent understanding of that data, the data domain stewards are gonna be actively engaged in that. And so these are people that they're gonna help us to understand who the people in the organization at the operational level are who have relationships to the data. Whether we're calling them business data stewards or just users of data or definers or producers or data stewards, operational data stewards is the name that I typically refer to these people as. I've had organizations define them as deputy data stewards but the fact is that if we truly want to cover data governance across the organization we need to recognize that potentially everybody in the organization is a steward and we need to get over that fact and we need to find a way, yes, it's going to make our program more complex but we need to engage everybody and help them to recognize themselves as being data stewards of the data. As far as the participation of the planning and program team in the office this is gonna be their responsibility. So you would expect that that would be a large percentage of their time with the program moving forward. The partners, they're already governing whatever it is that they're governing whether it's IT or risk or projects or information security. So we know that the partners are already doing this and again we're gonna leverage them to whatever extent we can as we're moving our program forward. The working teams, we're gonna pull together the appropriate people in the appropriate way as you probably are already doing in your organization make certain that the stakeholders of the data the stakeholders of the issues pertaining to the data or the opportunities to improve the data that they're well represented on these working teams and that we need to gain that appropriate participation and we wanna make certain that we're not leaving anybody behind. Yes, certainly the working teams could be fairly large sometimes they're not as large if there's not as much of the organization it's going to be impacted but you certainly don't wanna leave anybody out and come to them with a solution that they didn't potentially have an opportunity to speak their mind or to offer anything to that solution. So the working teams work a specific opportunity it's not always necessarily a problem that you're trying to solve it might be an opportunity to use a type of data better but the role of the working team is certainly where we are going to operationalize data governance moving forward. Their responsibility is to do a lot of different things and organizations use working teams in a lot of different ways to improve definition of specific critical data elements as they are referred to or that strategic data that's being used across the organization they help you to focus on improving data production and collection usage and understanding all of these things. You can develop your working teams and leverage your working teams specifically to focus on the things that are most important to your organization. And again, how much of their time is getting necessary? Well, it depends on how quickly you wanna resolve the problem and it also depends on how much time and then what they have to participate in these working teams. And we're gonna use these working teams as I mentioned before to operationalize your data governance program. We're gonna use the team to achieve results and business outcomes and recognize that the results and the outcomes will not come without pulling together the appropriate people into these working teams. I've been known to say and I wrote an article on TDAN recently that's called the data will not govern itself. We need people to be engaged in governing the data. The metadata is not gonna create itself either. We can't sprinkle pixie dust over the organization and all of a sudden have the metadata and the understanding of the data made available to people. So oftentimes data governance doesn't really add value to your organization until you have taken it from being something that has been written about and spoken about and you start to operationalize that across your organization. So again, I just wanna share the operating model with you one last time before I turn it back over to Shannon to see if there's any questions from today's webinar. But think about this, think about taking this model and overlaying it over what you've already defined for governance roles and responsibilities within your organization. That is the approach that is going to be less invasive and more practical and pragmatic when it comes to implementing governance across your organization. So in this webinar, I spent a bunch of time going through the different levels of the roles that are within that operating model and gave you some tips and techniques for how to customize your operating model to fit specifically your organization. I talked specifically to each level of the operating model and detailed out what their responsibilities could be for data governance in your organization. I defined who participates at each of these levels and last I talked about using the specific working teams made up of the operational level and the tactical level stewards and using those working teams to implement tactical solutions. And so with that, I would like to turn it back over to Shannon to see if we have any questions for today. Bob, thank you so much for another fantastic presentation and just to answer the most commonly asked questions, just a reminder, I will send a follow-up email for this webinar by end of day Monday with links to the slides and links to the recordings of this session and anything else, including Bob's matrices out to everybody. So dining in here, Bob, data governance experts say that IT should not be the owner of data, but when they are, is the goal to shift ownership, subject matter expert to a high volume user of the data and how to make that transition if that's the best practice. Yeah, and I've experienced that too, that people refer to IT as being the owners of the data, but really they're the conduit to make certain that the data is right and that it's available and that it's protected within the organization. Typically I would not say that IT would be the owners of the data, just like they wouldn't necessarily be the ones that own a data governance program, but you can be successful with data governance in IT if you're leveraging who the business people are. So one thing that I didn't refer to in that pyramid diagram was that everybody within that triangle part of the pyramid, those are business people. Typically I suggest that IT is a partner of data governance, data governance can reside within IT. I would not necessarily make it the goal of the program to move the ownership of data from IT to the business. What I would suggest is that as part of data governance, we help people to recognize that IT plays an extremely important role when it comes to the data, but they're not necessarily the owners of the data or they could be stewards of the data if they use specific data, but that's not typically the priority to move IT from being the owners of the data. But if it is a problem that you're having, then part of your data governance program needs to be to communicate and to make people aware that the business plays a critical role in the governing of data in your organization. The working teams work with when most of team members are outside of an organization. For example, we have a working group that comprises representatives of the users of the data, most of whom are outside of the organization. It's the public sector organization. Okay, so when they say outside of the organization, while they're typically related to the organization, they're certainly not going to be, the working teams are not only going to be consistent of your data governance office. So when you say outside of the organization, I'm thinking outside of the data governance office, when you're thinking about people that are related to your organization, they're still stakeholders in the data. I'm not sure that they'll be the ones that will help you to solve the problems, but they can certainly chime in and help you to understand what you're doing and how it's going to impact them. So yeah, there's people outside of the centralized group that's creating, that's developing and delivering your program. Yeah, you've got to make certain that they understand the value that they're going to get out of participating. So your working groups can be made up of people outside of the organization. You just need to communicate effectively with them and help them to see the value that's going to come from participating on the working teams. Trends you see in the adoption of these robust practices at non-profits. As non-profits? Well, again, it's very difficult. Within a non-profit, first of all, we don't have a lot of money that we can focus on implementing our governance program. So take an approach, obviously, that makes most sense for your organization that fits your organization like a glove, so to speak, that you're plugging people or you're actually overlaying what they're presently doing and helping them to understand what it has to do with what their role, actually, is within the governing of data within the organization. So non-profits, they do present certain complexities to the program. But again, if you can convince them that they play an important role and help them to become better at helping you to make the data better for your organization, you're gonna have a much higher level of success with these types of folks. But certainly, non-profits are their own their own types of organizations. And we, again, just need to make certain that we are communicating effectively with people across the organization to help them to recognize themselves as playing specific roles for the data within the organization. Centric or Global is recommended to have a data management organization. Considering the roles mentioned, are some recommended to be reporting locally and some globally, and which ones? Yeah, that's a great question. I'm glad that you asked that question. So when you've got a global organization that might be set up to work regionally, and so you may want to consider taking, and I don't necessarily call this an approach, I say following a federated method of implementing data governance. So when you follow a federated model of data governance, there would be a central group that would have responsibility for governance across the global nature of the organization, but they might not have the authority to be able to dictate to each of those regional parts of the organization what they should do and what they shouldn't do or how they should know about doing it. What they can do in the federated model is provide minimal standards for the different parts of the organization to follow without dictating to them exactly what they need, the steps that they need to take, as long as they can create the metadata associated with the data that they're producing. Maybe that's enough, that they can get that metadata into a format that can be ingested into a data catalog tool or something like that. That might be all you need to do. You don't necessarily need to dictate to them exactly what they need to do. So if you take the federated model, you provide guidelines, you provide standards, you provide minimal standards to say, okay, you're part of the organization, the European part of our global organization, you need to follow these specific roles or at least follow these guidelines, but we're not going to dictate to you how you need to do it. Again, that is a lot less invasive than thinking that that central body has that responsibility for being able to dictate to the organization who does what. Consider a federated model when you're looking at doing things as a global perspective in the organization. And oftentimes there's already governance taking place in different aspects of the global organization. Again, maybe what we can do is we can share minimal standards with them and not tell them how to do it, but say this is what we're expecting from you. It's a lot easier to implement governance globally because of the different cultures and the different regulatory needs of the different parts of the world. So I would say consider taking a federated, following a federated method for implementing governance when you're talking about a global organization. I think we have time for one more question here. Lots of great questions coming in. Keep them coming. I will get any questions over to Bob and he'll write up the answers to be included in the follow-up. So keep them coming. But the clear message is use what you have to ensure we are non-invasive. This works in mature organizations. How can you progress in a company with very low level of maturity, very stretched resources? Well, and again, a very good question. So when an organization is less mature, but still it may be that that organization has been around 10 years, 15 years, 50 years, and they still feel like they're less mature when it comes to data governance and data management. However, that organization would not have been around that long. They wouldn't have been as successful as an organization with a complete lack of governance. So there are already people in the organization who know specific subject matters of data that we can take advantage of and that we can leverage their information. So even if you are immature when it comes to data management and data governance, there is still already some level of governance taking place within your organization unless you're a brand-new organization. And most organizations have been around for at least a little bit. I would still say take the non-invasive approach. Recognize who people are in the organization that have responsibility, even if it's not as mature. Yes, it may be that we need to spend more time working with them and helping them to understand what role they really play for governance in the organization. So I would say with the less mature organizations that non-invasive might be the only way that you have to getting people on board and getting them to help you to govern your data properly. Well, Bob, thank you so much for that. It does bring us to the top of the hour here. Thank you, everybody, for being so engaged in everything we do. I'll say I'll get all the questions that we have not had time to answer today over to Bob and he'll get those included in the follow-up email, which I'll send to everybody, which will also include links to the slides, links to the recording, and yes, I will include the links to the triangle and Bob's matrices in that email as well. So Bob, thank you so much. Thanks, everybody. Hope you all stay safe out there. Have a great day. Thank you. Thank you, Sharon. Thank you, everybody.