 Hello and welcome. My name is Shannon Kemp 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 discuss data governance roles and responsibilities sponsored today by data.world. 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 and to note Zoom defaults the chat to send to just the panelists, but you may absolutely switch that to network with everyone. For questions, we will be collecting them via 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 the chat and the Q&A panels, you may click those icons in the bottom middle of your screen to activate 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 any additional information requested throughout the webinar. Now let me turn it over to Tim for a brief word from our sponsor data.world. Tim, hello and welcome. Hello, hello, Shannon. Thank you so much. Love the opportunity to work with the folks over at Data Diversity. It's always so much fun. And Bob is awesome. He is such a great speaker and an expert around governance. So this is going to be such a great webinar for folks to consume some great content here. So thanks for having us and the opportunity to sponsor. A quick introduction about Data.World and to kind of kick off our webinar today. I just wanted to say I'm Tim Gasper, VP of product over at Data.World. Also the co-host of catalog and cocktails. If you enjoy these kinds of webinars and love learning about data, catalog and cocktails is on all your favorite social platforms, as well as broadcasted live on places like Facebook and LinkedIn. It's an honest, no BS, non-salesy conversation about enterprise data and we drink cocktails while we talk about data. So it's a ton of fun. Check it out. And today just really quickly as we kick things off, I wanted to introduce who Data.World is and talk a little bit about why this idea of agile governance, non-invasive governance is so important that Bob pushes on and really advocates around, first of all, Data.World is different. We are the enterprise data catalog for the modern data stack, but we are relentlessly focused on adoption. We believe that there's such a big issue and challenge around data enablement around data literacy and governance and cataloging are key areas where you can really make a difference in that area. Data.World was born on the cloud. It is focused on how can we really easily integrate with your environment and create that discovery. We believe in a Facebook and Amazon-like experience, consumer-grade experiences around collaboration and really around being open and flexible, no black boxes, interoperability with the rest of your stack. And something that's really important in the governance world right now that folks like Bob are doing such an amazing job really bringing to light is around the changing sort of wins in the world of governance. Governance is now becoming much more about data discoverability than just data protection. While application silos continue to pose governance challenges, taking an inclusive and agile approach can make a huge, huge difference. Governance needs to be a benefit, not a burden. And I know many of you in your organizations are focused on turning governance not just into a defensive sort of activity, but actually going on offense and helping the company create more value from data and actually taking friction away. And finally, business users don't want to have to install a bunch of software, and that's where we see that cloud and software as a service is making a big difference in the world of governance. There's a huge movement towards not barriers, but accelerators, right? And so at Data.World, one of the concepts that we're so excited about is this idea around agile data governance, where you can take as Bob really advocates a non-invasive approach to governance, take an iterative approach to governance, really focus on the collaboration of people across your company and focus on use cases, because ultimately you don't want to boil the ocean, you don't want to just take a platform approach. You want to solve problems, you want to help various parts of the business to find the data that they need and put it to work. And if you can take a faster approach, then what you can do is you can take your data producers and your data consumers, take out some of the middle men or the more complicated processes and really focus on this flywheel, right? You need to be able to curate audit, govern and document, and you need to do it as fast as possible, iterate your way towards more value and better governance within the organization. There's a lot of different people involved in governance, right, from the program team and the actual governance team that are working on it, to data engineers, to the data stewards, whether you've got full-time stewards or more like most companies, you've got folks that are just wearing that hat, right? Data analysts and decision makers that are all part of that cycle and they all have an important role to play in governance and making it more iterative and more agile. And importantly is think about how you can build your data front office. If you're trying to empower use of data, if you're trying to make data governance work better in your organization, think about how you can create a layer where folks can find what they need, where it interoperates with the rest of your data ops ecosystem. So if you're using other lineage or quality or policy type tools that those things can work together. Ultimately, you want to understand your data supply chain and provide a more self-service experience around AI, machine learning and analytics for the rest of the organization. So, agile data governance is the way to go. And Bob is an excellent expert to talk about all the things that you should be doing around governance and key roles and responsibilities today. So I'll pass the baton back over to you, Shannon, to get things kicked off. And thank you so much. Always a joy to have you presenting with us and data.world sponsoring. If you have questions for Tim, he's going to be joining us in the Q&A at the end here. So if you have questions for him about data.world or data governance, feel free to submit them in the Q&A panel. I'm going to 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 specializes in non-invasive data governance, data stewardship and metadata management solutions. And with that, I'll give the floor to Bob for his presentation. Hello and welcome. Thank you very much, Shannon. Thank you, Tim, for that great presentation. I really liked a lot of the things that you spoke about. My slides seem to be changing on their own today. So let's try not to let that happen. Thanks again, Tim. That was a great presentation. I really like the concept of agile data governance, the iterative approach. I just had conversations with clients this morning. I'm not going to be able to flip a switch and have governance come on for the entire organization. So why don't we learn from what we're doing and doing an iterative more of an agile type of fashion. You also alluded, Tim, to the people that need to be involved. And that's specifically what I want to talk about today is the specific roles and responsibilities that are necessary to stand up a formal data governance. To Tim, you talked about stewards and engineers and a bunch of other rules, the people that run the program and those types of things. I want to provide to you a model today that you can perhaps use within your organization that details each of the different roles and responsibilities. And we'd love to hear questions on the subject as to, you know, whether or not these are things that are working in your organization or if you have questions about how to get some of those things working. So now I'm going to change my slides. Okay, things are moving weird here. Okay, so before I get started real quickly, just wanted to introduce myself. I've been doing this webinar series, excuse me, for many years always on the third Thursday of the month. That is today. Next month we'll be talking about the role of metadata in the data governance program. I'll also be speaking at Dataversities DGI Q event that's going to be taking place in June in San Diego. I talk a lot about non invasive data governance and Tim referred to it and it's always seems to come up in conversation as to how you can be non invasive in the way that you're implementing your governance program. So there's a book about it if you want to learn more about it. In fact, the book has now been translated into Dutch Italian German and French so if you're interested in receiving a book of that in that translation please look for it. I also provide some non invasive data governance classes and metadata governance classes through the Dataversity Training Center, published the TDAN or the data administration newsletter publication and I've been doing that for 25 years. Also have the KIK consulting and educational services is my consulting and education business and on the side is if all those things weren't enough to keep somebody busy. I'm also an adjunct faculty member at Carnegie Mellon University here in Pittsburgh, Pennsylvania, which is where I am from. So what are we going to talk about today we're going to talk specifically about the backbone of a successful data governance program. We're going to talk about roles and responsibilities that go into communications they go into task planning, they go into accountability and ownership for the data roles and responsibilities play a critical part in a are a critical component of a successful data governance program. So I'm going to talk about five different levels of data governance roles. I'm going to share with you an operating model that I've used a lot in the webinars and I use a lot with clients and talk about how you can basically take that operating model and customize it to meet the requirements from your organization so instead of plugging into my model, I always suggest take my model and be less invasive about it take the model and overlay it over your organization. We'll talk about setting appropriate expectations for each of the roles, and then we'll spend a little bit of time talking about how to operationalize the roles and demonstrate value to the organization. So, real quickly to get started I just want to share with you some definitions, and then I actually want to share with you my data governance framework and talk to you about how that relates to the operating model of roles and responsibilities that I'm going to share with you. Real quickly, my definitions of data governance and data stewardship are as follows day I say that data governance is the execution and enforcement of authority, even though I say that we are going to do it in a non invasive manner. At the end of the day we need to follow the rules that we're setting up we need to formalize accountability for what people are doing with data as they define produce and use data. So that kind of leads into my data stewardship or definition, and then a data steward and we'll talk more about who the data stewards are, and where they fit into this model. As I go throughout the webinar today but it is a person that has a relationship to the data that's actually being held formally accountable for what they do with the data, whether that's defining data, producing data or using data. I've been known to say that everybody is a data steward and that organizations should get over it. You know what if people have relationships to the data, and they're being held accountable for those relationships. Basically they're a steward it's not something that somebody can opt into or opt out of. So, it's interesting that I've had several clients recently that have taken my operating model that I'm going to share with you the pyramid diagram that you may have seen before about roles and responsibilities, and they refer to it as their framework. So, I don't use that term to describe my operating model, and I want to share with you what just real quickly, before we jump into the levels of the model. This is what it came to be and the framework that is used basically to build out the model, and the framework basically includes things like the core components of data governance and one of those core components is the roles and responsibilities associated with your program. It goes through the organizational levels, and then it cross references those, you may have seen this diagram before. It's what I refer to as my data governance framework. And like I said I have those six core components across the top of the screen, and then down the left hand side, I have the five different levels that basically, at least from my experience represent all the people within the organization that we need to engage in data governance. And so, what I want to do is I want to first of all highlight what I had up in the upper left hand corner of the framework, just to share with you again the components and the levels that we want to talk about. But actually when I first delivered this framework, I didn't have a data column. So the data column has been added in the last several years, but I really think we need to look at data in terms of what the executives care about. We need to look at the role of each of those levels in the organization we need to look at the processes that mean something to each of those different parts of the organization. So, as I start to lead into talking about the five different levels of roles and responsibilities. Let's focus on the executive strategic tactical operational and support levels of the organization. It's nice to have an empty framework, and it's nice to fill in the framework I also want to provide to you an example of the framework filled in. And I want to specifically focus on the roles column. And you can see at the role in the roles column there's a level at it intersects the executive level the strategic and so on all the way down. We need to make certain that we know who the people are at the executive level that need to support sponsor and understand data governance in order for us to be successful in order for us to decrease the risk to the organization. Many organizations have data governance councils at the strategic level have data owners or domain stewards or subject matter experts at the tactical level at the operational level there's everybody in the organization that has a relationship to the data. If they're going to be called a data steward or if they are going to be recognized as stewarding data as part of their job, and then there's the support functions. So, I wanted to share this with you, before I got into my operating model of roles and responsibilities, because roles is only one component of a successful program, while you've got processes communications metrics tools and those types of things. So we're going to focus on the roles and responsibilities and those five levels right now. So, first of all, what are the levels that, and you know what I would suggest that if these levels are different for your organization you make them what you need to make them for your organization. If you're trying a power company on the west coast to here in the US, tell me, you know what we use different terminology we actually flip the operational and the tactical level. So they had the operational level up as the cross business function perspective, and the tactical as being very business unit function perspective. These are the five levels and typically they represent the majority if not really everybody in your organization. And so again make them your own as you're building out your operating model but these are the standard five that I use. And so what are we going to call the different people at each of these different levels and we'll go through this in a little bit more detail when we go through the operating model in detail, but at the executive level. Oftentimes there's already a group of people a steering committee. You have a group of executives that meet regularly or meet, at least on a scheduled basis. And we don't need to create a new executive level but we can take advantage of the steering committee or an advisory committee at the executive level. At the strategic level, like I said, many organizations have data governance councils data strategy committees, advisory groups, or if you don't have one of those. We'll talk about in detail what that role needs to what the role is that that group needs to play within the organization, and then there's the tactical level. Those are the subject matter experts those are the people that have accountability for data across business So not just specifically within their business unit, but people who are looking at the data across the organization. And at the operational level, we've got those people that are defining producing and using data as part of their job. And then there are some support level functions that are required to implement a data governance program. So there's the administration of the program itself. There's also the working teams of pulling together people to resolve issues. There's also the different partners that there are within the organization. So, you know, you might want to think about the different roles that are necessary to move your program forward. And I wanted to share with you, at least quickly here, who the people are that typically participate at these levels. So for the executive level, it's people at the top of the organization. And that's pretty well understood of its C level or executive board members, it really depends on your organization, but there should be some type of executive levels. Recognition of the program and understanding of the program in order for you to guarantee success moving forward at their strategic level. There's a committee, you know, you want to build a committee that would be the council or the advisory group at the tactical level. Immediately you might want to point to who are the people who really have the answers about the data or know the most about the data as the subject matter experts. Those are the people that are going to participate at your tactical level, the operational level as I've stated several times here can be basically anybody in the organization, people that define producing use data as part of your job, or part of their job. And at the support level again the program leadership, you know the existing functions and the teams that are going to be brought together to resolve issues or to address opportunities in your organization. So, what are some of the things that we need to define for people when we are slotting them into a role or recognizing them into a role is how much of their time is going to be required. And if they're actually part of a group, how often is that group going to meet, or is it just an individual function, rather than a group function, who are you going to report to data wise and who's going to coordinate this ever moving forward. So, when you get to the point where you are going to onboard people to each of these different roles, you're going to need to provide to them detailed responsibilities, including things that are specific to the role details of their involvement in working teams details of the documentation that might might be expected from them, or that they're going to get engaged with as you're activating your program, and then validating the detailed responsibilities with people that are in the roles. So, let's talk about this model a lot so this is where I really want to focus a bunch of the presentation today is on the pyramid diagram. So, and again, like I said, I have some clients that actually refer to this as being their data governance framework. I actually consider the idea that a framework is going to include more than the roles and responsibilities. So, I draw this model this way for a purpose. The first response that people have typically when the seat they see this model is they think that it's very overwhelming. They think that it's very bureaucratic boy do we have to plug into that and in fact like I mentioned before. The idea is to take the model, take the roles and responsibilities that we're going to define here and overlay them over what already exists within your organization. So, you'll find that there are some ways that you can build this model that decrease some of the fear factor of, wow, do we need all these different roles and responsibilities when we're delivering the program. So I wanted to blow it up for you because people always tell me that often, at least oftentimes tell me that the diagrams are not big enough for you to read so hopefully this is big enough for you to read. Recognize that there are people at the executive level that participate as the steering committee. There's people that are going to look at data as as an enterprise asset, and that are going to make up a strategic level where your data governance council, and we're going to go through in detail, what each of these roles do. There's the domain stewards, there's the people that coordinate the activities of the data stewards. I consider those roles to be included at the tactical level. The data stewards at the bottom, I want to explain to you why it's drawn this way to, and I'll do that in a second, and then down the left hand side there's all the support levels. There's the administration of the program itself. There's people who are governing whose functions are already governing like it and project management and legal and audit and all those groups. There's a lot of partners of data governance because they're doing governance work it may not be data governance work, but they're all project management, your pms are are governing your projects, people in it are governing the information technology assets of the organization, and so on so again this is the model. I want to dissect it for you I want to go through each of the levels and share with you examples of what typical role, the responsibilities would be at each of those roles. So, I'm going to talk a little bit about how you can customize this model to match your organization. And the first thing I want to point out is that the amount of space in each of those rows, lead from the bottom to the top of the of the pyramid diagram, they represent something. In most organizations they want to push as much of the decision making as they can, down to the individual business units of the organization. So if you think of that orange area within the operating model is larger than the tactical the yellow area, which is larger than the pink area at the top. So there's a decreasing number of issues that are going to be resolved at each of those levels. So therefore it makes sense to kind of build it as being a pyramid. You may ask the question why is there then a tower that sticking out at the top of the pyramid diagram, because again that represents the executive level. But the fact is if you look at the right hand side of the pyramid diagram. There's an escalation arrow where we take issues that go from an operational or just individual business unit focus to cross business unit from focus to enterprise focus. We don't typically escalate data issues up to the executive level of the organization. That's why you're going to build some strength in your data governance office. And again, you know, you typically aren't going to take data issues all the way up to your executive level of the organization so the space in each of the levels means something. There's oftentimes consistency in color as well because I share other models in different webinars and presentations that I've given for data versity, where the models are consistent across across model in the use of colors. If you remember back and I'm not going to go back and show you the framework diagram again, but the operational level was consistent with this color, the tactical the strategic, the executive and even the supporting groups. So, again, you want to customize the model to represent your organization and perhaps the percentage of the decisions that are being made at each of those areas. And also the lines actually the way this model is constructed the sections kind of just resting up against another section actually mean something, because oftentimes if you look at the model we see the data governance team. They're touching every part of the organ part of this model, they're going to be engaged with everybody. Typically the data governance partners are going to be engaged with the data governance team, the working teams are going to be made up of the individual and operational groups. So again there's more meaning to the model. I didn't actually intend that initially, but somebody pointed it out to me and said, you know what if we could really describe in detail, how these groups work together. That would be a very powerful thing. And so the last thing I want to share with you just about how the model is designed itself is that these groups are not all new to the organization. These functions already exist. IT and project management and IT security and privacy they're already governing those partners, you might want to leverage those. You might already have somebody who's responsible for your data governance program so the data governance office or the administrator, they exist, you may have a steering committee that you can leverage, and the council might be new. So if you want to highlight in your model, those things that already exist within your organization. And again this really highlights the noninvasive aspect of governance is that if we can take people from the roles that they're playing and plug them into the model for data governance without really adding a lot to what they do. It's going to be less threatening to them it's going to be the path of least resistance and greatest success for your governance program. Again, you know, the use language call these things that things that make sense to your organization. So let's go through each of these different differing levels of the five levels that I shared with you. And let's start with the steering committee so what does the steering committee do. To be honest with you when it comes to data governance to steering committee doesn't do a whole lot day to day that I mean they don't do really much anything at all day to day, they're active. They understand data governance they're there to support and sponsor data governance, they're people at the highest level of the organization, but they don't have any specific responsibility to data governance except to be reported to what are the what's the progress of the program. Their real job is to get to the point where they can support sponsor and most importantly understand data governance. Understand what data governance is what it means to your organization, what it's going to take to be successful, including resources and those types of things. The data governance council, you know, and the things that are happening within data governance, typically they appear as a line item on a steering committee meeting on a steering committee meetings agenda. So we'll get a few minutes to talk about data governance but honestly, the people at the data governance steering committee level. They're understanding of data governance only goes so deep. They're looking at so many things across such a broad part of the organization that their knowledge and their involvement in data governance doesn't need to be active day to day but they need to support sponsor and understand what you're doing with data governance. And that's what you want to describe you probably already have a steering committee get your data governance program as a line item on that steering committee meeting, and you've satisfied the top part of the the operating model. The data governance council is the next level down and oftentimes the steering committee people will have the responsibility of defining who's going to be on the data governance council. It's a strategic group where when we escalate issues, it goes to them and it stops there, because that's where the decision is being made. So it is important, especially if people at your tactical level don't have the authority to be able to make decisions. It's important to have a group to be able to escalate issues to. People don't just agree to to to knock heads together disagree and go in their own merry way. Now we need to resolve issues so we need to have a council, and what is the responsibility of the council. Well it's to become educated in what data governance means. And I'm just going to read for you here, how it can and how it can work for the organization, how it will work for the organization. So they need to approve things that are brought to them because this group is going to meet fairly regularly they're going to meet monthly or quarterly or bimonthly, however you want to structure it for your organization, but they're going to be active in the fact that we're going to ask them to review and approve data policy, maybe our data governance role framework or operating model or our methods or those types of things. These folks to help us to push data governance into their areas by doing things that will actively promote data governance activities within their part of the organization. One of the really important responsibilities of a data governance council is to make decisions at the strategic level in a timely manner. Oftentimes, since the data governance council meets once a month or meets, you know, once a quarter, we can't and let's say it's on the second Wednesday of the month. But what if an issue comes up on the second Thursday of the month. We're not going to wait three months for the next group to next meeting to try to pull people together and make a decision so we need to have a way to be able to work with the council virtually, not necessarily always in the meetings themselves. So the people on the council should attend, or they should send alternates, they should stay aware of the things that are happening in the data governance program. They're not running the program but they are there that they're that strategic body that's helping to helping data governance to do the things that are expected from them. They identify and approve the roles and responsibilities. Oftentimes there may be a council owner or somebody who's administrative person perhaps would be responsible for scheduling meetings. But data governance council is extremely important because otherwise, unless you can push all of your decision making down to the tactical level, you're going to need somebody to break ties to make decisions to review things and relate to people at the executive level. So let's talk about the data domain stewards here for a couple of minutes, and this is a very critical role. In fact, when your organization talks about breaking down silos of data. You need people. Excuse me, you need people in the organization to view data across business areas. We've got people that are viewing the data pertaining to their specific business area. Well, and I refer to them as data domains or data subject matters across organizations. I've always referred to them as data domain stewards, until a client of mine said well. So what you call them data domain stewards but they're really data subject matter experts right. And I said yeah I guess you could consider that to be the case. They said okay that's what we're going to call them. I'm not stuck to any of these names of what I'm calling the roles, but they, they refer to them as the data subject matter experts. And this is some of their responsibility so they're responsible for an enterprise management of a domain or a subject area of data across business units, oftentimes they're identified by a position, or maybe we always go to marry. They're really concerned about this specific data, maybe she would be the subject matter expert, until we find that she's not the appropriate person and it might be somebody else. When they're acting in the role of the domain steward whatever affiliation they have to their existing business unit basically become secondary. They're really playing the role of looking at that data across the organization, rather than specifically within a business unit. As an involved facilitator and bringing people together, the definition the production and the usage of that specific subject area of data across the organization. Sometimes the people as the data domain stewards are the in a position of authority to be able to make decisions. If they're not in a role of authority, you're going to need your counsel, because you're going to need to be able to escalate it to somebody who will ultimately make the decision. There are no responsibilities for the data domain stewards are responsible for escalating issues to the strategic level, they're responsible for documenting. If not themselves they may delegate it to other people but document how their specific data is classified document the compliance rules the business rules for their domain. They're making certain that these rules are not only documented, but they're being communicated to people across the organization. If the person at that tactical level doesn't have the time to do that, it's important that they would have be able to delegate these responsibilities, because again, we're not looking at data in a siloed fashion. We're looking at data to help us to improve our analytical capabilities across the organization. So we don't want people to have five versions of what a of what a faculty member is as an example. So we've got the data. So what are some of the traits of the data domain stewards, and to be honest with you the data domain steward is the most difficult role out of this operating model to fill. Or it may be the easiest, you know, if you have a person that you already go to that maybe it's the easiest, but to determine who the people are that have responsibility for data across business areas is not an easy task. So what are some of the traits that make up a good person to be a data domain steward, they have a vision with the future of data as an asset for your organization. What that looks like, they're looking for ways to improve the status quo. They have the ability to motivate the organization again I don't want to read all of these, these traits but I really find that people that are successful in the role of the data domain steward, do have these traits. The important bullet might be this bottom bullet that they have the personal interest, the intuitive ability, communication skills to facilitate, you know, when you get together to resolve issues to a win win, because there will be differences of opinion. When it comes to data and even how that data is defined how it's produced, how it can be used across the organization. The data domain steward that central piece that yellow piece of the pyramid is the most critical, probably the most critical role, I could probably say each of the roles are very critical I said the council role was very critical, but these the people who start to look at data, instead of business unit by business unit but look at it across business unit are extremely important. Okay let's talk about the data stewards of course they're important to and as I've been known to say everybody in the organization that defines and or produces and or uses data as part of their job. And that could be pretty much anybody or everybody in the organization, if they're being held accountable for how they define produce and use data, their data stewards. So there is the potential you should at least consider the fact that there's not just the five data stewards that we've recognized as part of our program. In fact, we need to have entire coverage of the organization. So we should at least consider the fact that everybody in the organization is a data steward. And that means they participated in creating reviewing data definitions. They participate in all these ways they produce they create the update they delete they retire data, you could just say they do their job. Basically data stewards are people that do their job, and who have an impact on the data in the organization. They're people that were identified document issues they share knowledge with other stewards they communicate their requirements to people that need to know how the data needs to be set out and need they communicate their concerns their issues and their problems data stewards are your eyes and ears of data across the organization, you're going to have more data stewards, then you're going to have anything else, as far as a role and responsibility. Do you need to name, do you need to title them data steward. No, do they need to understand or recognize that as part of their responsibility. They're taking care of data to the organization. Yes, we don't have to call them data stewards. But if you're a person that uses sensitive information, and you're being held accountable for how you're protecting that data. You're a steward you can't say no I'm not. It's part of what you do. So they are defining the data that's going to be used by the organization they're producing the data, they're using the data. It's possible for the integrity of the usage. Like I said the data stewards are that bottom section of the pyramid diagram. So we've worked through from the executive level which is hopefully an existing group to a council that may already exist or you might need to create new the subject matter experts or the domain stewards, and then the stewards, everybody within that triangle part of the diagram. Those are business people. So all of your stewards now you might have technical data stewards, people in it that have responsibility for data that is specifically associated with it. They could be stewards to but they're not going to be stewards of the same data they're not necessarily going to be stewards of the business data it. It's not necessarily the earth shattering to you but it doesn't own the data. I know a lot of your business folks think that it owns the data know the business does, we need to engage them appropriately. Okay, let's quickly go down the left hand side of the of the diagram. I think this one's pretty easy to go through. You need to have somebody that has the responsibility for running your program. Data governance manager data governance lead administrator manager whatever you want to call that person. Somebody needs to have the responsibility for running the program. Some organizations build out data governance offices if they have multiple resources that are working together. Some organizations are planning to build out data governance offices, but we need to at least acknowledge the fact that there is somebody that is responsible for administering the program. That would be your data I like the name data governance administrator, because it does represent what that person does. So, oftentimes a group and I can name several clients right now that have planning teams data governance planning teams of people that are pulled together to define the team. They eventually may evolve into what becomes a program team. They're still kind of advising on how the program is being built. They're not necessarily the administrators of the program. So the administrator needs to participate in all of the program development activities they need to architect what your solution looks like that framework that I shared with you earlier. Even the operating model that's still on the screen. They're the ones that are going to be defining these things and have the responsibility for sharing these things out to the organization. They really assist in administering the program, or they are the administrators of the program. And oftentimes, I mentioned the data governance council and that they meet they can meet fairly regularly, monthly quarterly or sometimes we're in between, typically, oftentimes those meetings are facilitated by your data governance administrator or your lead or your manager. They participate in all of these things as well and again don't want to read them all to you I hope that this slide deck will be a good resource for you to go back to to understand what are some of the things that a data governance administrator would do. They report to the council they assist in defining the quality metrics, they may be the person that drives the data catalog effort the metadata management effort within your organization. I'll start with you that as the as a best practice, I'd say that the very first best practice that I have is that senior leadership, however that's defined, they support sponsor and understand data governance because without that, you're going to be at risk. The second best practice often focuses on this data governance administration role. We need somebody to run the program. If there's not going to be the program's not going to run itself. It is a best practice that you would have somebody in your organization that has the responsibility for all these things when it comes to running your program because like I said before, the program is not going to run it so. And so now let's work our way down the left hand side so you know you need somebody who's the chief of data governance, you need to take advantage of your data governance partners. There are also tools that I provide of groups that are already governing but not necessarily governing data can be your security group, your HR group is governing your employees your legal audit communications project management. There's a lot of different functions within your organization that are already governing something and that have a vested interest in making certain that data governance is successful. So work with them as your partners to find them as your partners. Don't give them a new role. They've already got a role you're not trying to do what they do, and hopefully for your sake, they're not trying to do what you do. But you're all governing so I actually had a group recently, then instead of calling a data governance planning team, they called it a governance planning team, and they had individuals from each of the partners that were part of that governance planning team. And I'll give you some additional examples of what the partners do. Again, don't want to read through these but you know you've got it you've got data modelers these folks are focusing on the data, they're there to help you. If you can build working relationships with them the partners become an integral part of a successful data governance. Oftentimes there's battles as to what what is the boundaries of one group versus another group. It's fairly defined as part of your roles and responsibilities what do your data governance partners do versus what does your data governance team or your data governance office do provide technical support provide technical support for data governance and data cleansing. So you can define what it is that your partners do and just include them in your operating model of roles and responsibilities, because they're already governing. They should be able to be a big advocate of a successful data governance program. So the last thing that I want to talk to you in the, in the few minutes that I have remaining is to kind of emphasize I very rarely if ever show a picture of the cover of my book, this late into the webinar. I want to highlight kind of the subtitle which is that if you're taking a non invasive approach where you're identifying, or should I say recognizing people into roles, rather than assigning them into roles. That is really the path of least resistance and greatest success. I know that in all the organizations that I work with people are busy people have day jobs. If you are going to assign them to be a data steward, it is immediately going to feel like it's over and above what they're presently doing, when in fact you may not intend that with what you're with what the way that you're going about associating them with a role. So instead of assigning people. Let's recognize them for what they do. Let's just emphasize that you're being non invasive in your approach. You've already got people that are doing some of these things at least. Let's formalize who they are let's work with them let's onboard them, help them to understand the role that they play. Let's ask them if the role that we've defined associated with data governance matches what they do. And if it doesn't, you know, maybe there's things that we can learn from what they do that we built into our operating model. So highlight the roles that resemble being something new in the organization if you've got a council, you've got to call that out, introduce the operating model to people generally in the organization during your onboarding while you're bringing them in to their specific role within the program. And really most importantly is get people in the organization to recognize themselves into roles, rather than having to be identified or being assigned into roles. If somebody comes to you it says I use sensitive information. You know we need to protect this information, they're steward work with them and understand that. As I mentioned earlier in the session, instead of, I know my model my pyramid diagram is kind of busy, and it can be very overwhelming at first glance, but instead of trying to plug into what I have in the model. Consider taking the model and overlaying it over your existing organization, start to recognize people into roles, rather than assigning people into roles. So, at the executive level expand the responsibilities of an existing committee at the strategic level, make certain that you have people who represent each of your business functions. The tactical level, recognize people that we already go to, who may be the subject matter experts are the owners of the data. I won't even talk about the operational level because potentially could be everybody in your organization, and then on the support level understand recognize that there's already groups that are governing within your organization so you want to activate these roles. Oftentimes organizations do that through opportunity focused working groups. I used to refer to them as issue focused or issue resolution groups. They're not only going to get together to solve problems. They're going to get together to address better ways of doing things so there may be an opportunity without it being an issue. Oftentimes, we look to get our program operationalized or activated through the use of the data catalog, getting people associated with data definition, where in the data catalog, the stuff that Tim talked about earlier you use that as your resource for where you're going to collect your information about data definition, about data production, and about data usage, and you're going to apply governance and I'm finding this to be very helpful at many organizations. Look at existing projects. Look to who they're recognizing and who they're engaging as the people in the know about the data and formalize their responsibility when it comes to data governance. So the last thing I really want to share with you are it's really all about communications and communicating the operating model to your organization. I always break it down into what I refer to as the three O's of data governance communications, and that is orientation on boarding and ongoing communication to just make certain that as you're developing out your communication and this would potentially be the role of your data governance administrator, working with a partner, who is your data, who is your communication specialist or your change management people. We're going to make certain that as part of our roles and responsibilities as part of our communication plan, we're going to tailor things specifically to the different levels of the audiences that I just spoke about. The executives don't get communicated with the same way at the same way as the operational people. The council and the executive level the strategic and executive they may be more similar but make certain that you're tailoring your message to the part of the organization. What things do we typically include in orientation communication that is introduction to the program why it's important to have a program the level of the program. You notice roles and responsibilities aren't defined here in the orientation because you're going to you're not getting into the how yet when you're orienting people to the ideas of data governance. So then when we get to the onboarding piece the second oh, it's, you know how are people recognized into the roles what what it is expected of them, what is their role based activity. What's job aids are available to them how can we make this interesting or fun across the organization by gamifying it. You know the ongoing communication could be role based success program status program activities and those types of things. So communicate communicate communicate and then when you're done communicating communicate some more people need to understand what role they play in your overall program. I hope that the model that I just shared with you was helpful to you. I really believe that if you don't if you're not scared at first view of it, and you consider it as something that should be overlaid over your existing organization. It's a lot less threatening it's a lot less bureaucratic than, then you might have first considered. So I talked about those five levels. I shared with you my operating model. I talked to you about ways that you can customize through color through the amount of space in each of the sections in the way that you name your levels, ways to customize the models to match your organization, setting appropriate role expectations, and then how to take that model and start to operationalize it across the organization. And with that, I will kick it back to Shannon to see do we have any questions for Tim and I today. So many questions so many great questions, and just answer the most commonly asked questions. Just a reminder I will send a follow up email and I think I said Thursday earlier but today's Thursday so I was going to follow people at end of day Monday with links to the slides links to the recording to everybody so you don't have it in your inbox by the Tuesday morning or you know Tuesday morning Pacific time anyway. And also we had a couple questions about receiving a certificate of attendance so you can email info at data versity net, if you'd like a certificate of attendance for attending today. So diving in here to these hot questions. So this came in early so what is interactive approach mean. What does interactive approach, or was that the iterative approach. Well thank you. Thank you. Yes, I'm reading that incorrectly. Do you want to hit it first. Yeah sure I could I could jump in first and then Bob if you want to add to it so I think I may have first brought up the iterative approach when talking about agile data governance and I think, especially what means in that context is, is making sure that you're not boiling the ocean right I think a lot of companies or folks approach governance and they're like whoa, there's so much to do so much that we need to accomplish, and, and they really try to do too as much as it wants. And an iterative approach can really mean like look at what is really important that you need to do like what is that sort of we call it like the use case backlog, and what you're trying to do from a governance perspective and really tackle the biggest issue first, get the right people together and think about like what's the fastest meaningful increment of value that we can achieve right almost like a minimum viable product approach. And that's what we mean by iterative here is like getting to value quickly, getting that out there, whether it's a policy, whether it's, you know, getting your committee together whatever that might be and then, and then getting to the next increment and getting to the next increment so that's kind of iterative there. Bob anything that you would kind of add or taking another direction there. Yes, certainly you're not going to govern all of your data in your organization at once you're not going to flip a switch and have it come on, you're going to need to I hate the expression of ET elephant one bite at a time, right. You're the nice thing about it is that you know I think what Tim what you were talking about I consider those initial those use cases, oftentimes to be very critical data element focused. So in fact I'm working with several clients that they're they're they're iterative because they're starting with a very finite set of data that they're considering to be their critical data elements, but they're building a process. While they're focusing on governing those specific pieces of data that they can use for another set of data, and then another set of data, and you know what it's going to be better the second time, and it was the first time, because you've now been through this process of vetting the process. You know the third time it should be better than the second. So I agree with the idea of being iterative is don't try to do it all at once, learn from what you're doing, and that will really help your program to be more successful. I love it. So, um, why only financial companies have been able to do and and data governance and not other industries. I don't know who asked that question but the, that's not true anymore. I, at least I firmly believe that that's not true anymore financial organizations were the ones that embraced data governance first. You know the whole concept of of Sarbanes oxley that was really what when we think back to the, the infancy the beginning of data governance, a lot of it was focused on Sarbanes oxley. And now, you know, privacy of data, analytics of data is no longer just a financial industry thing anymore. So I can, if this person wants to reach out to me and they're looking for examples of other organizations in other industries that have had beginning to success, while not beginning to end because a program goes on forever, but they've had beginning and sustainable success in their program please reach out to me. I don't know Tim have you experienced it's all finance. I totally agree with you I think I think it's much broader than finance now and agree that I think finance kind of was at the on the earlier edge of all of this kind of it kind of speaks to the power of regulation to really drive action. So that's obviously a key driver there but I think, in addition to regulations being important to a really broad variety of companies now even if regular regulation isn't driving your governance motivation as much. You know self service analytics AI data literacy there's so much going on now that like it's it's really impossible not for you know for, for, for, you know any company of any significant scalar size size to sort of avoid governance and and many are doing a very good job of it now. Yep, I agree. Love it so Bob back to your framework slide is the data column the domains. No, that's not what they're they're meant to be the data column. Again, kind of partnered up with each of the different levels as you go down and intersects each of the rows. It is, you know, typically it would be what is the data that is most important to the executive level. What is the data that is most important at the strategic level at the tactical the operational and even at the support level. It is not domains oftentimes the business domains or the subject areas are going to be that tactical level. Again, as I talked about how you got your counsel, and then you've got your stewards at the bottom, you know the council at the top of the triangle, but that middle you know those are the people, you know, those are the people that we really want to focus the most. Perfect so how is non invasive data governance different than the invasive counterpart any examples. Well I'll just simply use the word assign versus the word recognize. Because in a in a in a more invasive approach people are assigned to be data stewards, instead of being recognized to be data stewards, instead of in a not in a more command and control approach, they're told you will do this, instead of starting with a premise of, you know, you're already doing this in a more command and control approach, you're going to redefine all of your processes, but in a less invasive approach, you're going to apply governance to your processes. So it is literally less threatening to the organization, because you know what you already have processes, you have people that are doing things with data. You have a lot of these things that that can be leveraged as a starting point. So that's why I say it's the path of least resistance and greatest success, because we're going to take advantage of what is already there. If you work for a company right now, and your company's been around for five years 10 years, 50 years, 100 years, you were doing something right. People had accountability for data. It just wasn't formal. Being non invasive is just formalizing that accountability that you would hope would have existed all along. That's what non invasive is. Can we want to add anything to that? No, I honestly, I think that's perfect. I mean, we're huge fans of the non invasive approach over at data.world and we feel like it really is the best way to not boil the ocean and be iterative. So nothing, nothing really to add there other than an endorsement. Good. Thank you. Well, I'm going to try and slip. I don't know if we can slip. We were just that realm was right to the top of the hour here. So I'm afraid that's all the time we have but you can keep your questions coming because I will get those over to Bob and we'll get those answers to you after more is in the follow up email, which will go into the end of day Monday with links to the slides recording and anything else and I threw in the chat to some people had some questions about where to buy your book and you can learn all about non invasive data governance. So it's in the chat there and I'll make sure that's also included in the follow up email as well. Tim, thank you so much again for joining us and for data.world for helping to make these webinars happen. Appreciate it as always. Absolutely. Thanks so much Shannon and thank you Bob. Thank you. Thank you everybody. I hope you all have a great day. Take care everybody.