 And here we go. Hello and welcome, my name is Shannon Kim, and I'm the Chief Digital Manager of Data Diversity. We would 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 data governance roles as the backbone of your program. Just a couple of points to get us started. Due to 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. And for questions, we will be collecting them by the Q&A section. Or if you'd like to tweet, we encourage you to share highlights or questions via Twitter using hashtag RWDG. And to find either the chat or the Q&A panel so you can find those icons in the bottom middle of your screen for those features. And as always, we will send a follow-up email within two business days containing links to the slides, the recording of this session, and additional information requested throughout the webinar. Now let me introduce to you our speaker for the 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 Dame of 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. Good afternoon. Hi everybody. I hope everybody's having a great day, wherever you are. And I'm really very happy to have you with us today. This is a great topic, a topic that we share every once in a while. And people who are building data governance programs recognize that the roles and responsibilities that they define as their program are really that backbone of the program. And they're really important to pretty much everything that we do associated with data governance within our organization. So I'm looking forward to sharing with you information about how the data governance roles are the backbone of your program. Before I get started, it looks like I've been a busy guy. Well, that's because I've been a busy guy and I'm telling you that July is going to be a very busy month. We've got a couple of things coming up in July. I wanted to share with you information about one is the data architecture online event, which is a data diversity online event. And I'll be speaking at with a good friend of mine, Anthony Alvin on July 14, and then on the third Thursday of every month, I do this webinar, and I'll be talking about data governance and information governance in my webinar in July. I talk a lot about noninvasive data governance. So if you're interested in learning more information about noninvasive data governance, there's a bunch of places that you can go. There is a book that I wrote on the subject from several years ago. There's online learning plans available through diversity, one on noninvasive data governance, one on noninvasive metadata governance. And there's also the one that was released most recently, which focuses on business glossaries, data dictionaries, and data catalogs. As Shannon mentioned, I've been publishing the data administration newsletter tdan.com for parts of 25 years. I've been around for a long time. Please go out and take a look at tdan.com for more information kik consulting and educational services kik consulting.com is the the home of noninvasive data governance. It's a great place for you to go to learn about noninvasive data governance. And then one of my most recent activities is I have now become an adjunct faculty member at Carnegie Mellon University for their CData O postgraduate program. So if you're interested in learning more about that program, please reach out to me as well. So what are we here to talk about today there's a bunch of subjects and I really like the way that the subjects flow today because I think it really for organizations that are getting started or have already developed their data governance roles. I hope that you'll use this slide deck as a resource and go back to it and help you to determine what roles are necessary for your program, what you're going to call those roles what the responsibilities are going to be. I'm going to share with you. First of all why I believe that data that the data governance roles are really that backbone of a successful program. I'm going to share with you an operating model that I've used, and I've been using for years and that just seems to be getting better year after year, as clients are looking for ways to be able to customize it specifically for their organization. I'm going to share with you some hits hints and tips about how you can customize the operating model I'm going to share to mimic your existing structure and to best represent your organization. I'm going to talk to you about the method behind the madness of setting up the operating model that pyramid diagram so the meaning behind the way it is set up. There's a decent amount of time going through each of the different levels of the operating model and describing in pretty good detail as to what I've seen organizations use and what the responsibilities have been of the people that are fulfilling these roles in an effective data governance program. So how can we help by talking about well how can we use this model that I'm going to lay out for you today. How can we use that to influence how well data governance is accepted within our organization. So if we want to start by talking about data governance as the backbone. I did a quick search on what is the, what's the definition of a backbone besides for, or for the obvious. What I found is that there were a lot of statements about the backbone really being the strongest part of something. And like I mentioned before with the data governance program, the roles and responsibilities are going to be involved in the processes that you're governing and the data that you're governing the communications. The tools are really going to depend on which level of people within your organization which roles you've defined for your program. So again, the this really becomes the backbone of all the different moving components of a successful data governance program. So and I say it's the strongest part of something while your data governance roles should be really at least one of the strongest parts of your data governance program. It needs to be firm. It needs to be resolute. It needs to be intentional within your organization. This is going to be the thing this operating model these roles and responsibilities are going to be the key that everything else in your programs going to depend on it. And in fact, you know, if you look up in science, they have different types of forms of life. Some of them have backbones and some of them don't. Well, your data governance program needs a backbone. And I believe that the roles and responsibilities are what become the main thing that people see and understand when it comes to the actual the act of governing data within the organization. In my webinar series in the webinars that I've been doing over the years and in a lot of the presentations that I give, I talk about the bill of rights a data governance bill of rights, and instead of it being the rights of the people and what they can do. It's the word right within quotes so getting the right people involved in the right activity at the right time using the right data so this is, you know, what is the definition of right within your organization. But the fact is, just to be even the beginning of the data governance bill of rights focuses on the people focuses on the role they play, what activity they get involved in. So again, it just kind of cements the idea that this operating model of roles and responsibilities is really the backbone of your data governance program. I oftentimes break the different components of data governance into six, what I call the, well, the, the most significant components of a successful data governance program. And those are data and the roles the authority that people have in different positions the processes, the communications the metrics and the tools. And I'll share with you my framework that I've shared before that basically highlights these as being the most important components of a successful data governance framework of which you're going to base your program on. And what I wanted to kind of highlight on this slide was what do the roles have to do with each of those components. So when we talked to when we talk about the data component of a data governance program and what data. So what we're going to govern be it structure data unstructured data data in different platforms that you have in the organization, we need to be thinking about the data that is going to be important to people at the different levels of the organization And finally, we're starting thinking of, you know what do the executives need. What do the strategic people need, all the way down to the operational people day to day what data, do they need to fulfill their job function. Then there's the authority and the roles themselves that are a component of the program, and that'll become more evident here on the next couple of slides, where I highlight really how important the roles and the different levels of roles are to the success And then there's the processes, you know the different processes of the organization are going to matter to different people at different levels and we need to recognize that when we're building on our program. Same thing with communications we can't communicate to everybody the same way the metrics mean different things to different people across the organization. So let me kind of jump away from this slide and into a slide that I use quite a bit, which is my data governance framework slide. And the way that it set up is across the top of the framework. I've defined those six core components of a successful data governance program. Down the left hand side of the framework, I list the different levels of people are going to be worried about governance are going to have a concern about each of the components. So we've got the executive strategic tactical operational and support. And when we look at this a little bit closer. When I'm going to outline the the operating model of roles and responsibilities, I'm going to walk through it by level. I'm going to start by focusing on the executive level, and I'm going to end by focusing on the support level. And I'm going to detail out what each of the different roles how they participate at each of those different levels, you can actually take this framework. And you can start to define the same thing for all the different levels for each of the core components, the data, the processes, the communications. I know that very often we attach a white paper that outlines the data governance framework to the email that Shannon sends out after the webinar will make certain that we do that for this webinar. So if we look at the framework one step further, if we start to fill in each of the blocks so where each of the components each meet each of the different levels. You can say, see that everything every component is truly based on the roles and responsibilities if we're going to be defining them by the levels that are on the far left of the framework. So if we look down the roles column, you can see we've got executive leadership as, as a role we've got a data governance council, or somebody and some advisory group that oversees your data governance program at the strategic level. At the tactical level we've got what a lot of organizations refer to as data owners or subject matter experts or I refer to them often as domain stewards at the operational level we've got everybody in the organization that defines produces and uses data as part of their job and I refer to them all as being operational data stewards, because if you define and or produce and or use data as part of your job, and you're being held accountable for how you do that. You're a data steward you can't really opt in or opt out. And then there's all those support roles that I'll talk about here in a little bit including who has the responsibility for managing the program and administering the program. Are we going to create work groups and working teams to focus on resolving certain issues or addressing certain opportunities, and then there's the role of the data governance partners. So you can see that just from looking at the data governance framework, the importance of the roles and responsibilities to the program. I mean, we could go and we could break down any one of these columns we're not going to do that in this webinar, because we don't have time, but they're all associated with the different levels perspectives of the organization. So to speak the executive all the way down to the support level of the organization. This is the model that I'm going to dissect basically for the rest of the webinar today. I want to talk and as you can see, it's broken down by the executive level strategic all the way down and then the support levels on the left hand side. The first reaction that a lot of people have when they see this operating model is they think it's very bureaucratic. They think it's, it's not going to be easy to implement. When in reality, some of these things already exist within your organization. So if we're going to take a non invasive approach to data governance, we're going to recognize who's already doing these things. Because your model need to look like this with all the arrows and all the pieces I guess that's up to you. And I'm going to spend a little bit of time in today's webinar talking about how do we customize this model to make sense for your organization. And there's a reason why each of the layers have a different amount of volume in them. And there's a reason why things are lined up next to each other. Let me walk through that as I walk through, you know how we can customize this model to fit the organization. What I'm going to do is I'm going to have a smaller version of this pyramid diagram showing on a lot of the slides that I'm going to share with you. And I'm just going to want you to keep it in mind that, you know, the idea of a non invasive data governance approach is not to take your organization and plug it into this model. In fact, it's exactly the opposite. I suggest, take this model and overlay it over what already exists in your organization and say you know what we've already got a steering committee we don't need to create another one. We've already got operational stewards we need to help them to recognize that they're stewards, but they already exist within the organization. So the data governance office or the data governance administrator may already exist. Again, the idea is to take this model and overlay it over what you already have in your organization, and that's going to be a lot easier to get people to accept in your organization whether you know versus trying to define everything in this model as being something that's new to your organization. So when we break down the levels that I shared in the framework the executive level down to the support level. If you have those types of things in your organization, take a look at what they're already called. Is your executive level called your ELT, you know your executive leadership team or senior leadership or the C level. This is the part of the organization that really has the leadership perspective. We don't really need to redefine that what we need to do is define what their responsibilities are when it comes to governing the data of the organization, and they're not going to be involved day to day, obviously because they're at a level so high in the organization that we're not going to ask them to be involved day to day but they need to support sponsor and understand what we're doing as an organization so call that level or in that level, whatever you're referring to that in your organization as at the strategic level. Typically that's the enterprise perspective at the oftentimes and I'll talk about this in a minute. There's a data governance council that resides at the strategic level. Well, and the strategic and the the council has representatives of different parts of the organization. This is truly providing the enterprise perspective for the organization. You call it call the level whatever you want to call it, but typically in an organization there is an executive level. There is a strategic level. The tactical level. That's where, you know, when we try to break down the silos of business of data within different business functions and we start to look at data across business functions. So finding those tactical level stewards who either are the authority or the subject matter experts in data across business functions. That's not an easy thing to do, but it's also perhaps the most important role of the data governance program. They reside at that tactical level where we're now breaking down silos and we're starting to look at data across the organization. Then there's the operational level which is basically the business function perspective, and then the support level, and I'll share with you examples of the support level. These are groups in your organization that are already governing. They're not necessarily governing data but they're already governing and they're true partners of data governance. So what are we going to call these things that we have at these roles. Now the first thing we're going to do is, if they already exist, we're not necessarily going to change the name. But if they're already called the steering committee or the leadership team, let's keep that name. Let's not introduce new language to the organization. The data governance council or data governance committee or advisory group. I had a client recently that referred to it as D gag DG AG, the data governance advisory group that again had representation across all the different business functions. At the tactical level, I oftentimes refer to them as domain stewards, people that have knowledge authority potentially, and certainly are facilitators of decisions that are made around domains or subject matters of data across the organization. A lot of organizations refer to those people as as owners. I try to stay away from the word owner because it implies that it's mine, and I can do with it what I want, when typically the organization owns the data, not any individuals so I like the idea of steward, or domain steward or subject matter steward, rather than calling them data owners, just because of what the term data owner implies. At the operational level organizations refer to them as data stewards data consumers data stakeholders, again, make the names that you're applying to these roles work within your organization. You know, with the person who's running the data governance program whether that's you or somebody else, are they the data governance administrator the manager the leader to have a data governance office. Again, use the names that you're already using within your organization. And when you're creating your operating model, make certain that you state in the model. It's people that are going to participate at each of the different levels. And if you notice in the diagram, there's a little bit of verbiage that's applied there that says, you know, often states who are the people that are going to participate at the executive level. Here on this slide I have, it's people at the top of the organization. You know it's going to be your C levels it's going to be your executives. At the tactical level, you know defining that we're going to have representatives of each of the business functions at the tactical level that we're looking for subject matter experts. We may know who some of these people are some of them might be not as easy to determine within the organization. So we need to define within our operating model. We also need to define at each of these different levels and what role they play in the overall governance of the data. We also need to define within our operating model, how much of their time is expected. So we need to set reasonable expectations people with the executive level. We wish that we can become a line item on on their regular meetings, so that they can be given updates on what data governance, what's happening in the, in the world of data governance within your organization. We're not going to be asking for a lot of their time, but we want them to support sponsor and understand what we're doing so whatever time it takes to get them to support sponsor and understand is the amount of time it's going to be necessary from people with that level. The same thing should hold true for all the different levels we need to define, you know how much of their time is going to be necessary, how often will they meet, for example the data governance council might meet monthly. Excuse me or quarterly or whatever the cadence is for your organization. Some of these roles act more independently and some of them work with other roles. So a little bit more about that when I'm talking about customizing the model. And then in the most important thing perhaps in the operating model as you're filling it out is, what are the specific activities what are the specific responsibilities of each of the roles and I'm going to detail those all out to you. I hope that when you get a copy of this slide deck that you may refer back to this as you're building out your roles and responsibilities, and recognize that some of these people work independently some of them are involved in working teams. Oftentimes organizations document, you know what these folks do already, and then formalize it as part of their roles and responsibilities for their data governance program. So let me talk to you about why the model is set up the way that it is set up. And so the reason that it's a pyramid is there's a reason for that. The amount of space within each of the levels of the the right hand side of the pyramid represent approximately the percentage of the decisions that are being made at that level. So organizations they say we want to push as much of the decision making as possible down to the operational part of the organization but you know once in a while, or maybe more than once in a while. We'll have decisions that need to be made at the at the tactical level across business units. So we'll take some of those issues and we'll escalate them up to the tactical level. And before the people at the tactical level they may or may not have the authority to make a decision. Those decisions might need to be escalated up to the council. So there's even less space in the little orange or little pink triangle for the strategic level for the data governance council, because we're not going to take every decision to our council. And say we wanted to escalate five to 10% of our decisions to the strategic level. If there's more than that, then they're going to get overburdened and we've got some serious shortcoming at our tactical level. If you'll notice that there's no space at all in the tower that sticks out of the top of the operating model. That's because organizations typically don't take data decisions to their executives. So we don't need to have any space there. We do need to acknowledge them in the model. But if you look at the escalation path along the right hand side of the pyramid, it stops at the strategic level. That's where the decisions are made. The people on the council, they may have been delegated by people on the steering committee or on the leadership team. But we're not going to take day to day data issues or data opportunities to our executives. Typically the decisions will need to be made at the council level. The top of the pyramid means something. If you notice when you work from your bottom from the bottom to the top of the pyramid, we're going from business function specific to cross business function to enterprise to the executive level of the organization. So you're seeing we're, you know, more and more people in the organization are being addressed but we're taking less issues to that level because not every issue pertains to the entire organization. So there's also a method to my madness when it comes to the colors in the operating model. I'm not going to be sharing with you other tools, like a common data matrix or a racy matrix but I use the same color scheme in the other models and the other tools and templates that I use, because if you can see yourself in the operating model, I want you to be able to see yourself in each of these other tools and templates and things that go along with operationalizing your data governance program. Another thing that I added to this slide deck relatively recently is the fact that how these pieces of the model border up against each other. It really represents that there's a level of coordination and cooperation between those levels. It's on the left hand side and it may be somewhat hard to read but the data governance team slice, they basically touch everybody, the facilitator the manager of the data governance program the administrator. They're typically working with the council, they're typically working with the working teams, working with the partners, you know, typically the working teams are made up of people with the tactical and operational level. The idea is that, you know, the things that border up against each other they mean something to the organization as well. And if you feel that it's important, please describe that when you're, if you're planning to share this type of model with people at your organization. When people see this model their first reaction, a lot of the time is that this is pure, this is very bureaucratic. And so what I found with a lot of organizations is that they add this verbiage to the sides of the model to say whether or not this thing already this part of the model already exist or does not. So for example in the, what's being shown on the screen in front of you, the steering committee it already exists within in this example. The council is new we've already got subject matter experts that we're going to leverage, and we've already got stewards we just need to help them to understand that they're stewards so the first idea is when somebody sees this as they think it's all going to be brand new, it doesn't have to be all new. Again, overlay this over your organization and see what already exists. Just like on the left hand side. If you're the person who's administering your data governance program, you already exist, you've already got partners and I'll describe to you what the partners do here in a couple minutes, but we need to leverage them we need to engage them in this program and the working teams might be new or they might be the way that you already operate within your organization so make it as easy for people to digest as you can by making certain that you let people know what parts of this are new what don't we have what do we have what can we leverage. Again, it reduces that fear factor when somebody sees this model. I can tell you that I had a client at one point that instead of having those three main layers of the operating model, they had nine layers. And they spent a lot of time trying to describe to people the difference between layer six and later seven and layer three and layer four. Well, most organizations are set up as executive strategic tactical and operational. That might not be the words that you use to describe it, but they're typically set up this way. So don't try to make this more complex than you need to. You could remove a layer I certainly wouldn't remove. If I was going to remove any layer would be the executive layer but they are an important part of your, your data governance operating model. So I'm going to show you the model and its entirety again, just to give you a second to look at it. And now I'm going to walk through each of the different pieces of it, and give you a list of responsibilities that potentially might make sense to your organization. Again, customize these make these fit for your organization, do it in a non invasive way, and try to leverage those types of things within your organization that already exist. So let's start with the executive level so like I said I'm going to keep showing you that model it's going to be ingrained in your mind by the end of this webinar. I'm going to point at specifically the part of the model that I'm talking about so you'll see this model continued to appear on each of the slides so we're going to be talking about the executive level here and there's not a whole lot to say about what the executives are trying to do there. They may be the ones that determine who go into your data governance council. They don't have any specific day to day or monthly activities, except to be on the receiving end of knowledge and information about the program. Particularly the very first best practice that 100% of my clients use is that the senior leadership needs to support sponsor and understand data governance so we need to make certain that we're getting that communication to them so that they will support sponsor and understand what we're doing. And if we if we ever get to a point where they don't support sponsor understand our programs going to be at risk. And you know we really hope that we can become a line item on their agenda at their meeting so they can hear what's happening about data governance within the organization. What are the responsibilities of the data governance council at the strategic level well the first one is that they need to become educated in data governance. So we're going to if they're not educated in data governance we or the person who's the administrator or the data governance office needs to make that one of their responsibilities is to engage this group and get them to understand what role they play. So they need to be educated in data governance, they need to approve things, especially approve things before they would be brought to the executive level for for signature. For example, if you have a data governance policy, or a data policy, it might be crafted by the administrator of your data governance program, we're going to take it to the council to review and get their, get their understanding of it and get their feedback before we would take it to the executive level for the overall sign off so the council level is going to approve things that we're doing. Some of them which may be taken to the executive level some may not, but they are again the ultimate decision maker when it comes to data governance. The data governance council also has the responsibility of pitching data governance into their parts of the organization. They're kind of the representative of that part of the organization for data governance. People on the council make strategic decisions in a timely manner they meet regularly or they send an alternate to their council meetings, stay abreast of what's happening within the governance by reading the minutes, they identify and approve the different roles. They advise potentially an owner of the council on the activities that need to take place from their part of the organization when it comes to the council getting together. So the council plays a role and again it's not a daily role, but they play an instrumental role in the data governance program because that escalation arrow goes up to them, and it doesn't go any further than them so again the buck stops at the data governance council. At the tactical level, as I mentioned before that's one of the most difficult and the most important roles of your program. And typically, if you think about it oh we always go to Joe for questions about this or we always go to Mary for questions about that well maybe those are the people within your organization who are the go to people who are the subject matter experts for domains of data. And oftentimes when they participate as a domain steward at the tactical level, if they're a my way or the highway type of person they're not the right person for the role. They're really there to make decisions for the organization that are going to impact across business units. They're involved facilitator they may or may not be the authority in the case that they're not the authority, typically then a decision would be taken to the council. They're responsible for the ability for escalating well documented issues to that strategic level if they can't make a decision. They're responsible for documenting the rules associated with the data. They're responsible for making certain that, and they may delegate that activity to somebody but you need to make certain that for every subject matter. The documentation is being provided so the classification rules compliance rules and such, but they may not be the person that does it, they may delegate that. They're responsible for making certain the roles are being communicated. They participate in these tactical groups when opportunities are being dressed or issues are being resolved. And what are the traits of somebody at the strategic that I'm sorry at the tactical level of the model. Well, they have a vision of what the future of data looks like they're looking for ways to improve the status quo. Like I said if they're a person that comes to these meetings and says well I'm looking at this data for the enterprise but I'm really only carrying about my business area. They're not the appropriate person to be the domain store they need to have a vision of what across the organization. This data needs to look like. That's why I said they're an instrumental role of data governance, and it's not necessarily easy to figure out who those people are. In the other model I also outlined a at the tactical level, a steward coordinator role. So if you believe where you start to think that potentially, there's a lot of people that are defining producing and using data within a specific business area there's a lot of stewards within every business area. How are those stewards going to know what to do when to do it, how to do it. And their activities need to be coordinated. So a lot of organizations at that tactical level will define people in the role of the steward coordinators, they act as the point communication person for distributing rules. They're also the point person. If the people if the stewards of that part of the organization have an issue that need to be addressed, typically it's channeled through a coordinator to get to the data governance administrator. And it becomes a potential opportunity that's going to be addressed by data governance. So a lot of organizations don't necessarily include a steward coordinator. But if you subscribe to the idea that everybody in a business unit potentially is a data steward, and that they need to be communicated with it you may want to be a steward coordinator, which is really a functional or a divisional or a departmental role to make certain that all the activities of the stewards are being coordinated. This isn't typically a full time role, but it can be really important depending on how large your organization is, and how you're going to be engaging in activating the stewards of your organization. So those are the data stewards themselves, those are the people that every day are defining producing and using data if they're being held formally accountable for what they do, their data stewards, what types of things do they get involved in. Again, I don't want to read them all off the screen to you, but they're involved day to day in decisions that are being made around what data is necessary, how that data should be defined, how that data is being produced. And those are the ones that are using that data. So we don't need to call everybody in the organization a data steward, but we need to recognize that people that have relationships to the data. If they're being held accountable for those relationships to the data, they're data stewards, we want them to recognize themselves as data stewards, and we need to activate them and engage them in order to really operationalize our data governance program. What other things do the data stewards do they identify and document issues, they share knowledge. These last two bullets on this slide are really important that stewards as the eyes and ears of the data in your organization. They're the ones that are communicating the business requirements, communicating issues problems opportunities to improve the data. They need a channel to be able to report those things or to get those things addressed. Typically the data stewards will go up through their steward coordinator if they have one, or they'll have a mechanism to be able to support their opportunities or their issues. If they're the ones that are seeing problems with the data, they are going to be a part of the solution as well but we're going to activate them, we're going to get them to start recording information about the data and oftentimes I break the data stewards into three categories there's producers and there's users at the data steward level at the operational level, because the accountabilities are different for somebody who's defining the data. You may not want to include cheeseburger definitions you know the what I talk about all the time which is a cheeseburger is a burger with cheese, we want better business definitions for that. For people that have or for what a cheeseburger is or what a student account is. You can't say that a student account is an account for a student that definition doesn't add any business value. Perhaps one of the responsibilities of the definers of the data is to put a better business definition to the data. And then there's the people that produce the data and the people that use the data. If they're being held accountable for how that data is being produced, how that data is being used. Those are different levels of accountability, but their accountability nonetheless so we know that we've got people in most organizations, they don't break them down by definers producers and users. They call them the data stewards the operational stewards. They call them different names, but recognize that depending on people's response depending on people's relationship to the data, their responsibilities may be a little bit different. Let's talk about the left hand side of the model the support level roles. We've got somebody has to have the responsibility for the program. Oftentimes there's a planning team at the beginning that planning team evolves into becoming a program team a more permanent group of people, or at least permanent for it for a time group of people that are really helping to evolve the program. They participate in the program development they architect the solution. Basically, the data governance administrator is the captain of the ship. They're the ones that are saying this is these are the activities that we're going to put in place. In fact, I mentioned as a best practice that the senior leadership supporting sponsoring and understanding is the number one best practice that organizations use the number two best practice has to do with. We need somebody who has the responsibility of guiding the program. If we don't have that, we're going to be at serious risk. I mean if we don't have somebody who's leading the these activities and even more activities. The program is going to become at risk right away. So what are some more of the things that a data governance administrator does they they participate in the development of the education and the awareness materials. These materials are not going to present themselves they're not going to create themselves somebody has to have that responsibility. Well, typically it's the responsibility of the administrator of the program. Oftentimes this person reports to the data governance council or they participate in working teams to make certain that we're defining and we're developing and delivering the policy standards and guidelines that we need for our organization. There's lots of roles in the program isn't it but these are things that are common sense and that makes sense to your that should make sense to your organization. Some more things that the administrator does they define the quality metrics. They support any strategic plan for the organization they conduct audits to make certain that the program is doing what it needs to do. Somebody needs to be the captain of the ship. Somebody needs to be the administrator or the office or program is oftentimes going to be immediately at risk, or it's not going to have the level of attention that it needs. I mentioned a resolute effort. Each of these roles we want to get people engaged and working towards a successful implementation of governance. Another support role that I want to talk about are the data governance partners. Now there's already data governance partners in your organization they're not called data governance partners, but there's people like your data security information security folks. They're governing they're governing the human resources of the organization. There's legal there's audit. There's your corporate communication specialist. There's your project management folks who are all governing something the PMO are governing projects within your organization. We need to recognize that there's already parts of the organization that are doing governance. We don't want to step on what they're doing we don't want to interfere with what they're doing but we want to engage them at the appropriate time. So the data governance partners they're there it's not a group of people. There are separate functions like security HR legal that we're going to engage when we need them to be engaged but they play a role in governance and that's the reason why we need to include them within the operating model within the roles and responsibilities that come to data governance no we're not going to tell them what to do, but we're going to leverage them. So security may know what data people are accessing and it may have rules around who gets access to the data. That's a form of governance we need to leverage that and take advantage of that. So what are some of the things that partners do they focus on consistent protection of the data responsible for technical handling it is a partner of data governance typically potentially your program resides in it but if it doesn't, then we need to engage it when it's necessary and all the time, actually, so it can be also included there as an example of a data governance partner. So they secure the infrastructure, manage projects responsible for championing data governance within the methodology that you're using, ensuring that policy and metrics are in place. So data governance partners play a critical role in data governance and we need to acknowledge them as part of the governance structure as part of the operating model. If we're defining the backbone, and these folks are part of that backbone, because we're going to rely on them for the governance that they're already doing within the organization they provide technical support for for everything. You know, you can define the partners as it makes sense in your organization, but just recognize that they exist and that they play a role and define for your organization what these folks do in relationship to data governance. All right, so the one role I just noticed that in the model that I didn't really go through was the working teams because the working teams are exactly that. They're made up of individuals who are knowledgeable about the data. You're already creating working teams you already have project teams that are assembled of subject matter experts system subject matter experts data subject matter experts in fact I tell organizations that they can recognize who they're who's playing the roles in their organization, looking at existing projects that are taking place. So, I mean there's a lot of different roles but you're doing a lot of these roles already the working teams are like I said something that I find to be used at a lot of organizations already. I just didn't include them in the detailed description because what they do really depends on the opportunity that they're addressing or the issue that they are resolving. So the last subject that I want to speak to you about before we turn it back to Shannon for questions are how can we use this model to actually influence the way that data governance is being accepted within the organization. Well, again I talked about using the model that I shared and overlaying it over your organization. Let's see what already exists before we start defining new roles, giving people new titles. And ideally we're not going to give people new titles they have a role that they play for governance, and they have a title for what their job is within the organization. But people in different titles can all be stewards, people in different titles can certainly be subject matter experts. If we leverage what people are already doing, there's going to be less resistance, and there's going to be greater success of your data governance program, at least from my experience. The book that I wrote on non invasive data governance the subtitle of the book is the path of least resistance and greatest success. And let's start with a premise that we're already governing data we've already got people in these roles we need to formalize that rather than data governance is brand new it's going to interfere with what we're doing. A lot of it has to do with the messaging that we're sharing within the organization. I like the roles that are new highlight the roles that are already being filled. And introduce the model during your onboarding process of getting people engaged and asking them to actually do something to use that as an opportunity to show them the model, and to get them to understand where they play and where they fit in to all the roles associated with the data governance program. And we can really win the data governance game if we get to the point where people recognize themselves into the roles that we're talking about in the model. I mentioned earlier and I want to mention it again the idea of overlaying this model over your present organization. So, look to see what you have at the executive level and you might already have a group that represents each of the business functions at the strategic level. Maybe you don't need to create a new council. You can leverage something that already exists at the tactical level recognize those people that people go to the subject matter experts, you may call them subject matter experts instead of domain stewards. Certainly, rather than calling them owners. At the traditional level it potentially could be everybody in your organization. So we need to set up our program to address everybody in the organization. And then the support level, as I mentioned there's parts of the organization that are already governing that we want to take advantage of to say, you know what data governance isn't brand new to the organization. We're doing a lot of this already let's show you how we're doing it and how we can do it better. We're going to create the different roles through those working groups that I talked about. A lot of organizations are using their data catalog to activate the stewards of the organization to activate them through how they're defining the data and giving them a place to define it in the glossary, the dictionary and the data catalog. And making certain that we're documenting who has the responsibility for documenting the data. Who's using the data. If somebody makes a change, and we need to know everybody that's going to be impacted. Aren't we going to want to know at some point in time, who's defining producing and using that data. The data catalog is a great place to collect that information. The only data matrix that I share often is also a tool that can be done to do that, but the data catalogs are typically easier for people to access and to take and to make use of. We're going to activate the roles through existing projects and recognize people in existing projects to be data stewards. We're going to make sure that we have an auditable way to protect sensitive data. I've worked with several clients that have been written up by examiners to say that people don't know how the data is classified. They don't know the handling rules associated with it. Use the operating model to help people to understand that everybody in the organization, if they have a relationship to the data is being held accountable for that data. The last thing that I want to talk to you about is when how are we going to activate the different levels of the model, what we're going to need to communicate very strongly with them. I always talk about the three O's of communications as being orientation on boarding and ongoing. So if we talk about orientation, you know the message is typically tailored as I showed you in the operating in the framework diagram earlier. We're tailored to the levels. We're going to introduce people to the program, why the program is necessary. You know, all the things that they need to know about the data governance program can be included in their orientation to data governance. And then there's onboarding. We're actually asking people to do things. You know, so we're going to tailor that message to the specific audience to the specific level as well. You know, first of all, we can communicate how they were recognized into their roles, what their responsibilities and accountabilities are, what the expectations are what tool job aids and tools are being provided to people. How we look for ideas from them as to how we can make this interesting to the organization. How can we gamify data governance within our organization. This is the last part of communication. So I said there's the orientation, there's the onboarding, and then there's ongoing communication, where again we're going to tailor the message to the different level within the operating model. Again, the operating model, being that backbone of the program. We're going to focus on role based successes. We're going to to communicate on an ongoing basis the status of the program, different activities that are going on the value that is coming from it and the measurements that we're using to determine if our program is successful or not. So I know I spent a lot of time going through the operating model with you. And I just want to emphasize for you that that the roles and responsibilities that you define for data governance are going to be critical are going to be a primary part of your data governance program. So we need to make certain that we define an operating model that's going to be able to act that way. It's going to be a resolute effort. It's going to stand behind all the different activities of data governance. I shared the operating model with you and how we can customize the model to mimic or to match your organization and why the model, the pyramid model is set up the way it is. I went through in a good number, a good amount of detail, what the responsibilities at each level are. If you have questions about those, feel free to reach out and we can extend the conversation. And then I talked about using that model to influence the way that governance is being accepted within your organization. And with that, Shannon, I'm going to turn it back to you to see if we have any questions for today. Bob, thank you so much. And just to answer the most commonly asked questions just a reminder I will send a follow up email to all registrants by internet Monday with links to the slides and the recording and lots of other things that Bob provides for everybody. So, diving in here Bob. What type of positions are typically involved in the council solutions architects database administrators, etc. At the council level know I don't see those roles as being actively involved typically its leadership from it's a leadership position from different parts of the organization. So they're representing marketing they're representing finance they're representing it in HR. So they're not necessarily going to be the architects I would typically put the architects as a partner role. Because they're governing they're governing the architecture that the data architecture the information architecture of the organization. But I wouldn't put them typically at a strategic level they're not strategic decision makers, and less people that are in those leadership positions in each of the parts of the organization, have those skills. It doesn't always work that way. Which level do we have to start to get a quick win and quick value. You know what if you start to, first of all, I always suggest that you start incrementally you don't try to to unveil that whole model on the entire organization that you start out by any small part of the organization. Oftentimes, I start out with, well there are some organizations that start with the council to create a council to have a quick win of a strategic level that understands the importance of the organ of governance to the organization. So I look at utilizing the operational and the tactical levels early on to say okay these are the people in this part in this slice of the pie that we're going to start with who are defining producing and using this specific data that we're focusing on, and then also is what subject matters of data to those pieces of data fall under, and who are the the tactical level stewards for that data so I think you can get some quick wins by just picking a slice of a slice of the organization, and figuring out how do they use, you know how do they use that data, how does that roll up to subject areas, and who do we go to and we have a question about that you can start to document who your operational and your tactical level are right away you can start doing it, as soon as this webinar ends if you wanted to. And Bob what advice would you give if you find resistance in your organization from the business perspective to change management when you are starting a data governance program deployment. Well, I would start with the premise of you know what we're already governing data. We're just not doing it very formally, and because we're not doing it formally we're not doing it efficiently we're not doing it effectively. So I would start there and say, you know what the messaging that we want to share with people is that this does not have to be difficult. I've talked about different approaches to data governance being the command and control, which is going to immediately feel like it's over and above what people are doing versus the kind of the traditional field of dreams approach, which is the if you build the program will gravitate toward it. If you build it they will come versus starting and looking for quick wins by formalizing things that already exist to a certain extent, or at least recognizing them and getting people to be held accountable based on their relationships to the data. That's the easiest way to get the quick win is to recognize things instead of just taking that top down approach. So if you're looking for quick wins I would start with that. Are you there Shannon. I'm talking to the mute button, you know, I'm good at that. I got a new mic so I'm still trying to figure out my rhythm here. So we are at present trying to establish roles for the governance of a 41 year old data set. How would you define the following terms data curator data custodian and chief data steward. I don't use those labels as the names of the roles but you know a 41 year old data set may or may not be documented. First of all a data set that's existed for 41 years is probably it's existed that long for a reason. And maybe it's because you've got decision makers for that data. You know, if the data sets is that old, then you know make certain that it's documented well that people who are using it understand it. I don't know if I would change the roles and responsibilities associated with that you have for that data set, but you might want to align them with the roles and responsibilities you define as part of your program. So a curator that might mean something to your organization data custodian chief data steward, those types of things may mean something to your organization if they do, by all means use those roles, instead of using the names that I've provided, but recognize who's already doing this stuff already and start by and I'd say with any data set of any age 41 years, you know, 25 years, you know, recognize who's using it, and those people are accountable for how they use it recognize who's defining the data. They're more responsible for putting definition to the data. I would just, you've got that data for a reason. I'd take advantage of that and say, who's doing what already, and then name the roles appropriately for your organization. All right, I'm going to try and slip in one more question here and if you have more questions for Bob keep them coming and we'll get them over to him and he will write up the answers to be included in the follow up email. So, what would your recommendation be as far as further defining data steward roles, definers producers, etc, when the organization is at large has been misusing data governance terminology and role definitions. They call them data stewards but that's the name that's being used in organizations, or being used for this application of discipline, you can call them data owners I mean that that's what a lot of organizations do already is they call them owners, and they own different levels of responsibility. You know, I would suggest take advantage of what's already there. And, you know, look to to make this as easy for your organization as possible. And when I say that, you know, we need to formalize this. How are you going to formalize it, you're going to formalize it by documenting what the roles are, you're going to formalize it by documenting what the processes are, and the people that are going to be engaged in different parts of the process. You're going to, you're going to formalize it by formalizing your communications around governance and recognizing that you're going to communicate differently with people at the executive level, then you're going to communicate with people at the operational level. So, you know, go look to formalize whatever you have already. It's just going to feel, it's going to feel less invasive to people, and they may be more willing to kind of sit forward in our chair and listen to what you say. And you know what, it's always a good thing when you're starting, not at zero. You're starting at, you know, some level of maturity between one and two, for example, instead of starting at one or below, because we already know who some of these people are. We're going to formalize them. It just makes sense to help organizations to get to where they want to be quicker. Well Bob thank you so much for another great presentation and thanks to all of our attendees who are so engaged in everything that we do again if you want to keep your questions coming in I'll get those questions over to Bob to be answered in the follow up email which I will send to all attend all of these trends by end of the Monday with links to the slides and links to the recording as well. Thank you everybody hope you all have a great day. Thanks Bob. Thank you Shannon thanks everybody.