 Hello and welcome. My name is Shannon Kemp. I am executive editor for Data Diversity. We would like to thank you for joining the current 2015 installment of the monthly Data Diversity Webinar Series, Real World Data Governance with Bob Siner. Today, Bob will be discussing data governance roles and responsibilities. Just a couple of points to get us started. Due to the large number of people that attend these sessions, you will be muted during the webinar. For questions, we'll be collecting them by the Q&A in the bottom right-hand corner of your screen. Or if you'd like to tweet, we encourage you to share highlights or questions via Twitter using hashtag RWDG, Real World Data Governance. As always, we will send a follow-up email within two business days containing links to the slides, the recording in this session, and any additional information requested throughout the webinar. Now, let me introduce to you our speaker for today, Bob Siner. Bob is the president and principal of KIK Consulting and Educational Services and the publisher of the data administration newsletter, TDAN.com. Bob has been a recipient of the Damon Professional Award for significant and demonstrable contributions to the data management industry. Bob specializes in non-invasive data governance, data stewardship, and metadata management solutions. And with that, I will give the floor to Bob to get today's webinar started. Hello and welcome. Thank you very much, Shannon. Thank you, everybody, for taking time out of your schedule to attend the webinar, this installment of the Real World Data Governance series. As Shannon mentioned, we'll be talking about data governance roles and responsibilities today. It's a subject that a lot of people ask questions about. A lot of people realize that the roles and responsibilities associated with the data governance program are kind of the backbone to the program itself, getting people involved, getting people active, getting people to be held accountable for how they manage the data. So I hope you're staying warm wherever you are. I know it's quite cold here where I am and you're going to only be getting colder tomorrow. So I hope you're staying warm. And as Shannon always says, settle back and hopefully you'll find a lot of information interesting in this webinar. Real quickly, before I get started, I want to talk real quickly about the book that I published recently, Non-Invasive Data Governance. There's some information about where you can find that book. Please visit kikconsulting.com if you're interested in more information about non-invasive data governance. And just to let you know of two events that I will be speaking at, diversity events. One is the biggest event of the year, or at least one of the biggest events of the year, Enterprise Data World 2015 in Washington, D.C. I will be speaking on progressive topics in data governance. And I will be covering big data and big data governance. I'll be addressing agile and data governance. And I'll also be talking about the internet of things and data governance. So it should be a quite fascinating session of certainly all new and all progressive topics in the subject of data governance. In June, I will be speaking at the Data Governance and Information Quality Conference, the DGIQ conference. And I'll be giving three presentations, getting started with governance, applying metadata requirements for governance, and also applying data governance to agile projects. So I hope that you will be able to attend some of these events and look forward to seeing you there. Also, just to let you know of the webinars that are coming up in March, April, May, and June, I'll be talking about data governance best practices next month with a special guest. We will be announcing that guest shortly. Data governance framework components in April, building your own data governance tools in May, and then the concept of everybody is a data steward and how to deal with that. And I'll talk a little bit about that today when we talk about the operational roles that are associated with the data governance program. So please register for some of these events. I look forward to having you at the webinars that are coming up in the next couple of months. Just real quickly to go over the abstract. These are the things that were in the description of the webinar. You know, talked about some of them already. Data governance roles and responsibilities lie at the heart of successful data governance programs. And so all activities tend to focus on the roles. I have talked in the past and I will talk in the future about something that I call an operating model of roles and responsibilities. And that's really going to be the basis of the presentation today. I'm going to go through the different types of roles, different levels of roles, talk about exactly what their responsibilities are, time commitments, and those types of things. So I hope to find a lot of information in this webinar to be helpful for you. And if you have any questions, as Shannon said, please insert the questions in the bottom right-hand corner under the Q&A. So this month, actually this session, I'm going to cover the executive, the strategic, tactical, and operational and support roles in the operational model. I'm going to talk about how to recognize who your stewards are and who the other people are that play the other roles in your program. I'm going to talk about how to apply roles consistently through all facets of your program and talk about how do we provide these people that we call stewards with incentive to get them actively involved in the program. So without further ado, what I'm going to start out with is tell you the definitions that I use for data governance. I know there's a lot of different definitions that are out there. I word my definition pretty strongly and the intent is to word it strongly so that people know that data governance is really all about the execution and enforcement of authority over the management of the data. We need to make certain that we enforce rules and that we enforce authority over the data, and that's how I came up with that definition. Data stewardship is very related to this presentation. We talk about the formalization of accountability. So if you've heard me speak before, you know I talk about non-invasive data governance and the idea that there are already people in the organization that are stewarding data and that have responsibility for data, and what we need to do is identify who those individuals are and formalize that level of accountability, and that makes it very easy instead of having to assign people as data stewards, we're going to identify people as stewards or as one of my clients mentioned years ago, we're going to recognize people as stewards. So recognize them has a positive connotation of the fact that they have a positive influence, they have an impact on the value of data throughout the organization. Last definition I'm going to share with you is the one of non-invasive data governance. We talk about taking existing processes and applying governance to it, applying formal accountability and behavior to people in the organization that have a relationship to the data. So we're going to apply governance to existing processes. We're going to assure that the definition of production and usage of data assures those things, regulatory compliance, security, privacy protection, and everything that we're looking for as benefits from our data governance program. So non-invasive describes that it's a non-threatening approach to putting a governance program in place and that the goal of the program is really to be transparent, supportive, and collaborative. So the first thing we're going to talk about when we're talking about being logical about roles and responsibilities is the fact that the data itself is not being governed. Some people have said that data governance is probably the wrong term to use. It's the people's behavior that is being governed so that when we have people that define data, we don't have people that are defining data for the tenth time when that data already exists in a format that can already be used. People that produce data understand their responsibility and their behavior associated with producing data and that people understand what their roles and responsibilities are. So I love the picture of this t-shirt here. It reminds me of Sheldon in the Big Bang Theory, but it says, I find your lack of logic disturbing. I think what we need to do is take a logical approach to how we identify the roles and responsibilities that are associated with our data governance program. And so with that, what I want to share with you is there are several different approaches that organizations use to governing data into putting roles and responsibilities into place. There's the non-invasive approach, which I'm going to talk about today, but then there's also the command and control approach where we assign people into the roles and we give people new responsibilities or even a more harsh approach, which I consider to be the two-by-four approach, where if you take a two-by-four and you smack people over the head and you tell them that data governance is not optional and that they need to make time, my preference is to stay with a non-invasive approach rather than clubbing people over the head and changing their job titles and making them feel like we're adding a significant amount of additional work to what they're doing. In my opinion, organizations are already governing data. They're doing it very informally, oftentimes very inefficiently, oftentimes very ineffectively, and the idea is that we are going to try to formalize that behavior. We're going to formalize people's roles and responsibilities when it comes to governing the data as an asset of the organization. As I mentioned before, I'm going to talk about what I call an operating model of roles and responsibilities, and it's a pyramid diagram and you may have seen things similar to it before, but it's broken into different levels. And typically in the diagram, there's four different levels, and I've seen organizations that have taken this model and divided it into additional sections, which only makes it more complex and difficult to explain to people. So the first thing we're going to do is we're going to talk about the levels. We're going to talk about the scope of data and the burning platforms that you may have in place already that will help you to focus where the data governance program will add value for your organization. I'm going to share with you the diagrams, the common data matrix and the pyramid of the operating model, and then we'll dive into depth of the information about the different roles that participate in the program, the responsibilities of the people in those roles, and then we'll talk about applying those roles to the processes that we may already have in place in our organization. Lastly, we're going to talk about the communication with the roles, how it's important to recognize that different roles, different levels of the operating model need to be communicated with in different ways. So that's the agenda for today. The first thing I wanted to talk about here was the roles, was the role levels. And in most organizations, they view things very similar to this fashion, where they've got an executive level of the organization, they've got a strategic level, a tactical level, an operational level, and then they need a support level. Somebody has to have responsibility for the program itself. So the executive level is basically your senior leadership, your enterprise leadership, your strategic level is the people that have responsibility for the management of not only data, but people and financial assets within each of the different business areas. So we've got a strategic level. We've got a tactical level, which I will emphasize repeatedly as being the most difficult hurdle to get over for most organizations where they want to break down the silos of looking at data specifically for each business area when we start to look at data across business areas and giving people responsibility to view that data and have accountability for that data across business areas. That is the most difficult challenges for some of the programs in place. So I'm going to focus a lot on the tactical level, what I've called a data domain steward or enterprise data steward. Some organizations call them subject matter experts. We'll focus quite a bit on the tactical level. The operational level is also very important. That's where the data stewards, the operational data stewards reside. And they're the per business area, they have responsibility to do their job within their part of the business. So they are very much operational. They're not viewing data necessarily as a cross business area asset. They're looking at it solely for the purposes of what's going on within their business area. And then there's the support level. Who's going to add sustenance and support the levels of accountability and who's going to facilitate and manage the program for the organization? So that's how I'm going to break it down. I'm going to talk about executive, strategic, tactical and operational, and then I'm going to wrap it up with talking about the support areas. Before I share the diagrams with you, the domains are where a lot of organizations start even when it comes to defining roles and responsibilities within their organization. First thing that they're looking for is the different burning platforms. What are the reasons why we want to implement governance across the business? Are we doing it to protect the data? Are we doing it to extract and share data to improve our ability to make decisions? Are we doing it to improve our insight? Well, the fact is a lot of organizations, when it comes to completing that tactical level of the operating model, I'm going to share with you in a minute that cross-business unit perspective, we need to have individuals that have subject matter expertise around certain subject areas of data. So a lot of organizations, when they start to fill in some of the diagrams I'm going to share with you, they focus on different subject areas of data. In fact, there are some organizations that have global customer data governance programs or supplier management data governance programs. The focus of their programs are not to cover the entire organization all at once, but rather to focus on specific subject areas of data within the organization. So in the next slide, I'm going to share with you a whole bunch of the different subject areas that a lot of people have gotten started with. So as I mentioned, several organizations have put data governance programs in place specifically to focus on their customer data or to focus on their supplier or product or material data. Even employee data and student data when it comes to universities and for-profit education organizations. One of the things that I suggest to most organizations when they're getting started with data governance is to document the different subject areas of data that have importance to the organization. And oftentimes that's a very finite list. A very endless list of subject areas, but at least highlight and identify the most important subject areas or domains of data for your organization and then recognize that we need to identify people in the organization that have some level of accountability for those subject areas and data. So again, the domains, if I would make one suggestion to you right out of the gate, it would be why don't you document what the different subject areas are that you care about in your organization and who the people are in the organization that are the decision makers or again the subject matter experts for those different subject areas. And I'll share with you in one second here how these apply to some of the tools that we're going to talk about throughout this webinar. The pyramid diagram that I mentioned earlier, some of you may have seen this before or you've seen things that are similar to this, but this is what I consider to be the operating model of roles and responsibilities in the organization. And what I'm going to spend the next 45 minutes talking about is I'm going to dissect each of these different layers and talk about what do we need to have in place when we're talking about the executive level or the strategic tactical or operational level. How much time commitment are we expecting from these folks and what's the need for the data governance team. If you look on the left-hand side, the supportive roles, the data governance team, the data governance chair, the organization, a couple of things that I want to share with you about this diagram. First of all, the amount of space in each of the different layers of the pyramid have a meaning here. In a lot of organizations, they try to push as much of the decision-making as they can down to the lowest part of the organization, down to the operational part of the organization. Let's see if I can get my pen working here. So I'm going to talk about the operational level. And if the majority of the decisions need to be made at that level, that's why we represent the operational level of this diagram with the amount of space that I share here. So that people understand that the idea is to push as much of the decision-making down to the operational level. When it's not a business-unit-specific issue, then along the right-hand side of the pyramid, we've got an escalation path. If it's not just a business area or business-unit-specific problem and it's now a cross-business-unit issue, this is where the roles and responsibilities associated with those domains of data come in. So I'll describe to you what are some of the traits that make up good data domain stewards or whatever you call these people in your organization. I'll also share with you the roles and responsibilities of the folks at the tactical level. If those data domain stewards or enterprise data stewards don't have the authority to be able to make decisions on the data for the organization, then we need to be able to continue to escalate that up along the left-hand side of the diagram to the strategic level. At the strategic level, most often organizations call those roles and responsibilities the data governance council or something that is similar to that. The data governance council is oftentimes identified by people at the executive level of the organization. At the senior leadership, things that you'll notice is that there's no space within that little bar that's sticking out, that little tower that's sticking out at the top of the pyramid, because we don't want to imply that the people at the executive level are going to be actively engaged, that they're going to be making decisions. Ultimately, the ultimate decision maker is at the strategic level. So we want to make certain that we can escalate issues from the operational level to the tactical level and then to the strategic level, to the issues up to the to the executive level of the organization. And then on the right-hand side, again, we've got the data governance partners, we've got the data governance team that act in supportive roles, and I'm going to share with you some roles and responsibilities around what those specific roles do and what activities and roles they play within the organization. So the first impression that people get when they see this diagram is a lot of different levels. And the truth is that some of these roles already exist within your organization. So that's why I just highlighted the things that I highlighted on the far right and the far left of this diagram, that you may already have people in your organization that have the responsibilities of the data governance team. If that's the case that I'm going to want to share with you some of the ideas that I have for what those teams' responsibilities are. The data governance partners, the regulatory and compliance project management, a lot of those already exist. So what we can do is we can kind of add that to the diagram so that people understand that the data governance team, the data governance partners are not necessarily new roles for the organization. Now if you look on the right side of the diagram, typically most organizations have a senior leadership team or a steering committee or a level of people at the executive level, so that already exists. And those operational data stewards, finding and producing and using data, they already exist. What we want to do is really, like I mentioned before, let's focus on the tactical layer and the strategic layer of the pyramid. Those are the most significant roles when it comes to putting a governance program into place. So there's a lot of information on this slide. What I'm going to do is share with you in the remaining time that we have the detailed description of what goes behind each of these different levels of roles associated with data governance. Now this is a diagram that I use quite a bit. It's called a common data matrix. And the interesting thing about this diagram, if I haven't stated it before, is that it's kind of color coordinated with the pyramid diagram. And you can see that all of the roles that are identified in the pyramid diagram, the colors of those roles are also identified in the common data matrix. And the common data matrix is a very simple tool, the two-dimensional spreadsheet that cross-references the different types of data that we have in our organization to the people in the organization that have responsibility for that data. So there's a lot of great data governance tools on the market. My suggestion is that this is a tool that we can develop and that we can maintain internally ourselves without applying a great amount of expense to it. We can design this tool. I'll be glad to share with you versions of the common data matrix. I get that request a lot from the webinars. But we need to put our arms around who does what with data in the organization, and then we need to apply the appropriate roles to governance for our organization. Just to step back one more quick second here with this diagram. My suggestion is not that you take your organization and try to plug it into this diagram and plug it into the executive, strategic, tactical, and operational levels. My suggestion is actually quite the reverse, is to take this diagram kind of overlay it over what already exists within your organization. Well, how do we do that? We capture the information that I've documented in the common data matrix. We know that for a specific subject matter of data that data resides in specific different systems, and there may be some subject matters of data as well, but these yellow roles that I had, the yellow roles from the operating model are the data domain stewards or the subdomain stewards. The peachish color roles are the operating roles or the people within the business areas that have accountability for data day in, day out. So this is just an easy way of being able to cross-reference for you what the specific roles are, what we need to have in place in order to make governance successful within our organization, and like I said before, I'll be glad to share that with you if you have an interest. So now what I'm planning to do is to start through the operating model of the responsibilities that are associated with those different layers. So let's start at the very top and let's talk about the executive level or the enterprise leadership, and that's typically made up of senior management or of a steering committee or people that are at the C level of the organization, and oftentimes that executive or leadership committee already exists within the organization. They do have one very important responsibility when it comes to data governance for people that will participate in the data governance council that is the tactical level that falls right underneath the executive level. So they identify the people that are part of their organization that participate on the governance council. They have no specific day-to-day, monthly, day-to-day or monthly governance activities that are their responsibility, except for that they need to be reported to by the data governance council the success of the governance program. So the executive layer, again, that's the reason why there's just a stick or a tower sticking out of the operating model, because these folks do not play an active day-to-day role in data governance. They're there to support and sponsor the activities of governance, but again, from a day-to-day perspective, these individuals don't have a lot of individual responsibility that takes place day-to-day in the data governance program. And in fact, that's the only level that I'm going to share with you that doesn't have some level of day-to-day responsibilities. So the next level down that I'm going to talk to is the strategic level, which is the business area leadership. And in a lot of organizations, they have a data governance council, that's what they're called, or a data governance committee. Oftentimes those individuals, as I mentioned before, are assigned or identified by the executive people in the organization or the data governance council. They're the ultimate decision makers, typically when we escalate issues from the operational to the tactical to the strategic level. So they're often aligned with or assigned by the executive level members. They have direct accountability to the executive level to report the status of governance and all the good things that it's doing for your organization. Oftentimes these individuals that participate on this data governance council at the strategic level, actually people at all levels of the organization are quite busy. They're not sitting around and waiting for you to give them responsibilities that are associated with governance. If somebody who participates on the council cannot participate in a meeting, then it's important that we have a stand-in or somebody that can fill in for that person and carry that same information back to their part of the organization. So the data governance council, that's where it resides in each of the columns. So it's at the top of the columns associated with the business perspective or the business areas or units in the organization. It's at the top of the IT part of the organization as well. The data governance council consists of strategic representatives of all of the business units and information technology and project management and risk management and information security. We need to have people in this council, again, the ultimate decision makers for data when it comes to the organization. So why do we need a data governance council? Well, we need them to coordinate across divisions. We need them to impress upon the organization that we need to cooperate across divisions. We need to utilize them to communicate across divisions, to have comprehensive risk management and to be consistent in the way that we apply governance across the organization. So I've seen organizations that have said with the pyramid diagram, maybe we can remove a layer. I would suggest that really operational, tactical, and strategic is the way that a lot of organizations look at the individuals and parts of the organization. So my suggestion is that we're not going to remove a layer, but we're going to always have a strategic level that has the ultimate responsibility for making decisions associated with the data. All right, so what does the data governance council do? Well, they've got a whole bunch of different responsibilities. Their first responsibility is to become educated in what we mean by data governance. How it's going to work within the organization, how the roles are going to be defined, how we need to understand from them what information they need from us in order to embrace data governance in the program that we're putting in place. Another role of the data governance council is to approve things that need to be escalated to their level for approval, whether that's a data policy, data role framework, like the operating model, the different methods and priorities and tools that we're going to use in our program. The data governance council is that strategic layer within the organization that things get escalated up to and where decisions are made, they also have the responsibility of pushing data governance back into their areas by actively promoting the good practices that we're defining as part of our governance program. Other things for the data governance council get involved in there. People that make decisions at a strategic level when issues get escalated from the operational to the tactical and then to the strategic layer of the organization. So they're, again, the ultimate decision makers when it comes to data, they meet regularly or they send that alternate that I spoke about. They identify and approve of the different roles associated with the program and they advise the person that kind of runs the council and reports to the executive layer onto the activities that need to be within the purview of data governance within the organization. So the data governance council, they're not involved actively day to day but they play a critical role within the program. So let's quickly talk about how much of a time commitment there is for people that are these council members within the organization. So again, what I suggest in organizations is that they hold monthly or bimonthly council meetings at least early on, the more often the better again, get up to speed in understanding what data governance is and how it's going to work for the organization. They consist of representatives of all divisions there. The meetings are scheduled by somebody who has responsibility for the council. There's an agenda that is facilitated by the people on the data governance team which I'm going to talk about a little bit. So this monthly meeting or bimonthly meeting is really 60 to 90 minutes a month. So we don't need their active involvement and we don't need them in meetings all the time through the program. These folks are very busy. They're at the strategic level of the organization. We're going to ask for 60 to 90 minutes a month. I've heard some people say that people at the strategic level need to dedicate 25% of their time to data governance. The fact is people at that level don't have that amount of time to dedicate to governance. So we need to make certain that we take the best advantage of their time that they do allow us to use the other months to talk about data governance and the program and the activities of the program. So how much of a time commitment? There's also time required for them to read and review and comment the things that we escalate to their level to approve like the policy and the mandates, the roles and responsibilities, all those things I mentioned earlier. And we're going to need maybe 60 to 90 minutes a month for that as well. Basically after the first several months of the program you may not have at the strategic level. So it may not always be 60 to 90 minutes a month, but if they can allocate time for the meetings and they can allocate time to review the things that we're going to share with them as part of the program, that's the time commitment that's usually required by the strategic level. Then there's also whenever there's an issue that gets escalated to the council, they need to be able to have the time commitment to be able to help to resolve those issues again at the strategic level of the organization. So we're not asking for active involvement, but we are asking for involvement of people at the strategic level. Now we're going to move down to the tactical level and that's where we start running into the issue of cross business area accountability. And there are primarily two roles that I talk about that fit that tactical level. One is the data domain steward, that's the subject matter of expert per data and I've seen that role called many different things in different organizations. I'll share with you the clean names that people give for that role. The enterprise data stewards because they are data stewards that are looking at the data from an enterprise perspective. There's the data custodians, I've heard them called that. I've heard them called subject matter experts. One of my clients said, well, we're really talking about subject area experts or subject matter experts when it comes to that role. And I said, yeah, that's pretty much all these new terms. Let's use the subject matter expert to describe the role of that tactical level of the data governance program of the operating model. And there's also a second role associated with that tactical level and that's of the data steward coordinators. And those are people that per business area have some responsibility for making certain that the stewards do what the stewards are supposed to do. So if we think about it, let's look at the domain stewards in terms of the common data matrix. They have the responsibility for the enterprise management of that specific domain of data. Typically they're identified by a position or maybe even a person who's a part of a single business unit who has that expertise and that knowledge to be that subject matter expert. However, when they're playing the role of the data domain steward or the enterprise data steward or the subject matter, their association to their business area really needs to be secondary. If their true purpose is to view data across the organization then the idea is that we would have individuals that can play that role while still participating from a different part of the organization if you notice in that common data matrix the domain stewards are to the left of the yellow line that I just drew. Those are not people that are associated with different business units at least in the context of the common data matrix. They have a responsibility to the data as it crosses the organization. So they may or may not be the authority to make decisions associated with that data where they're not the authorities, we need to be able to escalate it to the next level which is the council that I just spoke about but the data domain stewards play critical role, the tactical role of the emphasis of data governance within your program. They have these additional responsibilities for escalating issues to the strategic level, for documenting the rules associated with the data, making certain the rules are communicated to people across the organization, the data domain stewards or whatever you call these people in your organization play the most vital role for data governance within your organization. Let's talk real quickly about some of the traits of good data domain stewards. So just to share with you real quickly the vision of what the future of data as an asset looks like within the organization. They're always looking for ways to improve the status quo and the ability to motivate the organization. They set an example of data related behavior, their team players, their diplomatic, and then I had a client that added this last line for me and I see a lot of value in it. They're people that have a personal interest and intuitive ability in the communication skills to facilitate issue resolution to win-win wherever possible. So recognizing that we're trying to solve issues across business areas we need to make certain that we're doing it in a diplomatic way. Ultimately at some point decisions are going to be made and everybody might not be happy with those decisions but the domain stewards play a very tactical role in the bringing together of the different ideas and different thoughts as to how data needs to look from an enterprise perspective. So the data domain stewards not only are the most difficult role to fill but they're also the most critical role to the success of a data governance program in almost any approach to using data governance in an organization. I want to talk briefly about the data steward coordinators that sit on the tops of the columns and associated with the common data matrix. These are people that can help us to identify who the operational data stewards are for data within the organization. These are people that can help us to be the point person for communications with the different stewards within their part of the organization. Oftentimes these people have the responsibility of just really managing the activities of the stewards within their part of the organization. I've seen with a lot of organizations that the people that fill the role of the data steward coordinators are a lot of the people that are participating in the definition of the program. They're people that have invested interest in seeing governance become successful within the organization. So if there's one role that I've seen organizations eliminate it's been the steward coordinator and then oftentimes they end up adding back later after they find that they need somebody within the different business areas to make certain that number one we've documented who the appropriate stewards are and that we've engaged appropriately across the organization. So additional responsibilities for the steward coordinators is that they help us to identify the operational stewards. They work alongside the data domain stewards. They're really that critical person that connects the data domain stewards with the operational data stewards within the organization. So the last level at least within the pyramid itself that I want to discuss is the operational level and those are the data stewards themselves. So I've walked into a lot of organizations, a lot of sizable organizations where they've pointed it at people within a room and said these are our data stewards for the organization. This is our customer data steward, here's our product data steward, here's our supplier data steward and the one thing that I typically try to impress upon people is that there's more than one steward associated with different types of data within the organization. Certainly we need to have people within the organization that are decision makers associated with subject matters of data. That's the tactical level that's the domain steward of the subject matter expert that I just spoke about but there's people at the operational level of the organization that define and produce and use data as part of their daily job and in most organizations senior management, senior leadership will say that if people have a relationship to the data whether they define the data as part of their job or they produce or they use data as part of their job, there needs to be a level of formal accountability for how they define produce and use data. In fact I mentioned early in the session here that an upcoming webinar I believe it's June, we're going to talk about this idea that organization is a steward of data. That everybody that has a relationship to data is accountable for how they handle that relationship to the data. So I've seen organizations that have broken it out into people that have definition, responsibility, production, responsibility, user responsibility pretty much that includes anybody in the organization. So what we need to do is we need to help them to understand the impact that they have on the data in the organization. So we'll talk a little bit more about the role here in a minute. I've had some clients recently that have also used a role that they call deputy data stewards. So this is everybody in the organization that has to realize that we're going to manage data as a valued strategic asset of the organization. So we can consider the fact that everybody in the organization that has a relationship to data has a level of accountability that may make you feel like your program has just expanded 100 times. It's not true. We need to be able to communicate with those masses of people and let them understand that their relationship to the data has an impact on the organization and how we're going to hold them formally accountable, if you go back to the definition that I used for stewardship at the beginning of the session, hold them formally accountable for their relationship to the data, whether it's as a definer, producer, or a user. So that's the lowest level of the operating model. And so here's just kind of a tease when I come up in the webinar a little bit later this year is I put together some rules for becoming a data steward. So in the approach that I suggest, a steward can be absolutely anybody. And it really describes a relationship to the data and it's not a position. We don't need to give people the title of a data steward. They're a data steward based on their relationship to the data. We're not going to hire people to be data stewards. We're going to have people in the organization that we're going to formalize that data. But we're not going to necessarily give them the title of data steward. They don't have to be told how to do their job. One of the things that I say that gets a lot of pushback is that this idea of public or industry data steward certification is a load of bunk. And really what I think is that we can certify our stewards within our own organization, but to send them out to a public or an industry certification does not seem to be as valuable as trying to do that type of certification internally. People are educated on how to do their job. That implies a relationship to the data. We need to help them to understand how we're going to formally hold them accountable for that relationship to the data. There's more than one data steward for each type of data. Anybody, again, who defines, produces and uses data is a steward of the data. And we should focus on formalizing that accountability internally for data steward training. So in the common data matrix, I've highlighted where the operational data stewards fit in. They have responsibility for defining the data that's going to be used by the organization, producing the data that's going to be used by the organization, using the data as part of their job. Personally, everybody in the organization could be considered a steward of the data. And we need to have a way to help them to understand what their impact is on the rest of the organization to be a data steward in order to be a steward of the data within the organization. They participate in the creating, reviewing and approving of data definitions. They participate in the integrity and quality of data definition. I don't want to read through all of these different things that they have responsibility for, but basically, they have the responsibility for doing their job when it comes to data within the organization. The last two bullet points on this slide are extremely important. These people are the eyes and ears of the data in your organization. They also have a responsibility for communicating new and changed business requirements to people that can influence change. They also have a responsibility for communicating concerns and issues and problems with the data to those same people that can influence change. So these operational data stewards, and there may be a lot of them within the organization, they have a huge amount of responsibility when it comes to governance. And one of the things that we need to do is make certain that we have a level of communications with those individuals so we can help them to understand that they too play a role in the data governance program. All right, let's quickly jump over to the left-hand side of the diagram where we've got our two different support levels that we talk about. We've got a data governance planning team or a programming team, and we've got an area that I call data governance partners. We've seen models of late. The data governance partners, I always listed that as being IT. So we've got the data governance planning team and we've got IT. The fact is that data governance partners go way beyond IT. IT plays a role in the program, but so does risk management. So does the project management office. So do the agile teams and information security. And all those centers of excellence that we have within our organization, those different partners within the organization. But at the same time, this planning team or this program team is extremely vital to the success of the data governance program. In fact, I'll go as far as saying that without having somebody that has responsibility for the program, the program is going to die on the vine. It's not going to go anywhere. So obviously we need to have a high level of senior management support sponsorship and leadership and understanding of the program, but if we don't have somebody that has the responsibility for running the program, the program typically doesn't go anywhere. So we'll talk about the roles and responsibilities of the planning team or the program team. So I'll always use the acronym DGPT to represent this part of the operating model of roles and responsibilities. The truth is oftentimes it starts out as a planning team and then that planning team evolves into the program team long-term. It may be the same people, it may be some of the same people, but we need to have somebody that has the responsibility for governance within the organization. So they participate in the program development. They architect the solution and the framework. They assist in administering the program. They run the data governance council meetings that I spoke about earlier. These folks have a very important role in the data governance program as well. They're the ones that make the program work. Now it's very interesting how this diagram has come to be. Here's actually a different version of the typical pyramid diagram that I've shared in previous webinars. But on the left-hand side of the cube or the square that I just showed you, it shows you where the emphasis of the program is oftentimes during the project phase while we're defining the program and then how it evolves into the program phase. So during the project phase of defining what governance is, there's more of an emphasis on the executive and the strategic layer. Then getting the individuals and the tactical layering engaged and there's really less focus on the operational people. However, when we operationalize our program, the emphasis becomes more on the operational folks and then the tactical folks and then the strategic folks. So I had an organization that took the pyramid diagram and basically put another pyramid next to it, but it inverted and we came up with this diagram to demonstrate how the emphasis of the planning team and the different roles within the program change as the program evolves from a plan into an actually deployed and delivered program. So I don't know if I've shared that diagram before, but it really makes sense for a lot of organizations that early on when they're trying to sell the need for the program, they focus on the executive and strategic layers when it comes to the operationalizing and the tactical level within the organization. And the fact is that the planning team or program team does not exist on the common data matrix. They don't look for a place for them there, but they participate in the development and delivery of educational materials, awareness materials. They report results to the council who then reports the results to the senior leadership team. They participate in the development and the delivery of the policies and plans and procedures. They assist in defining those metrics for measuring the success of our program that are involved in supporting data quality issue analysis and remediation for data that's strategic by nature that gets escalated again to the strategic level of the roles and responsibilities, which is the data governance council. They conduct audits to ensure that the components are in place for continually improving the program. The data governance planning team does not online say that your program won't be successful unless you have somebody that has the responsibility for doing all of these things. So those people are the data governance team or the data governance planning team which involves into a program team. So let's spend a little bit of time talking about the data governance partners. Like I said in the past, there's always been information technology and in the common data matrix model that I have there, it's also represented as being that are in the project management office that are in IT, that are on the agile working teams that have a lot of understanding of the data, and we don't want to discount their knowledge. We want to get them involved. We want to understand who in those different partner areas have the knowledge about the different data and the different systems that exist within the organization. So again, they're focused on consistent data protection and classification requirements for securing the infrastructure for managing projects. These are folks that are already doing their daily jobs. Security, regulation and compliance project office, all of those individuals, they already have a role to play. They also can play a role in supporting the data governance initiative. And the data governance partners ensure that the policy procedures and metrics are in place. The strategic data is modeled that they provide technical support. When technical support is necessary, we don't want to eliminate the need for IT. We want to take advantage of the knowledge that IT has about the data. We want to take advantage of what the security people know about the data and the project management people think. So there's definitely a role for those individuals. However, data governance doesn't need to reside. Well, I guess that's actually a question. How should governance reside in an organization? I've had some people say that or a lot of people say that it has to reside in a business area. That's true for a lot of organizations, but I've seen data governance become successful when it's run out of IT as long as they understand that the stewards of the data are people that are in the business areas themselves. So real quickly in the few remaining minutes that I have, I want to talk about how do we cross, once we've identified these roles, once we've created an operating model to work for our organization, once we've documented and recorded the different people in the different roles associated with a common data matrix, what do we do next? Is that what the data governance program is all about or is there really an operationalizing factor to putting governance into place? Well, a lot of organizations put governance into place by applying governance to some of their existing processes within their organization. So actually I would say that people can apply these roles in a proactive way or in a reactive way. We can even build it into our system development methodologies and the processes that we have, or we can use it to resolve data issues within the organization. So proactively, we can apply the roles and actions to existing processes. One of my pips is people talk about data governance processes or the process of data governance. The fact is that governance needs to be applied to processes and not a single data governance process within an organization. So when we talk about being non-invasive in our approach to governance, we're going to take an existing process or procedure or policy that we follow and we're going to apply governance to it rather than calling it a data governance process. Let's call it the process that it is and let's not point at data governance as being the roadblock or the brick wall that's standing in the way of the way the process used to work. Let's make certain that we apply governance to the process rather than calling all the processes data governance processes. We would do these processes anyway with or without having data governance program in place. Reactively is applying roles and actions to existing reactive processes. I've spoken many times about data governance bill of rights, which is getting the right people involved at the right time using the right data, follow the right processes to solve the problem at the right time, at least most of the time. If we think of data governance as being just that, being the bill of rights, and the right people involved at the right time, we need to have a way to be able to cross-reference these roles and responsibilities I just talked to with the different actions and the different processes that take place in the organization. One way that I do this is to define the different processes that need to be governed. There are six different processes that organizations have considered or at least within this one organization have considered to govern. The first one is resolve or research information quality issues. Identify and monitor risk, monitor information quality, gain approval, validation, build the vocabulary. All of these are specific processes. The interesting thing about this specific tool is that if you clicked on one of these different repeatable actions today, here's the steps to follow this specific process. Here's the different roles that are associated with our program. We can put in these blocks who's responsible, who's accountable, who's consulted, and who's informed as part of those steps to apply governance to those specific processes. Another example of this is one that's used in a reactive sense, data issue resolution where we have the steps of defining the problem associated with the program. Again, we use the idea of RACI or RASCII, whatever you want to call it these days, to identify who's responsible, who's accountable, who's supportive, who's consulted, and who just needs to be informed along the way. Again, it's a matter of taking existing processes and applying governance to it rather than redefining the processes all new and calling them all data governance processes. One of the last things I'm going to talk about is the need to be able to communicate these different roles. Again, this diagram is color coded or color cross-referenced with both the common data matrix diagram and the pyramid, the operating model diagram, where we understand that the different things that we need to communicate down the left-hand side of this communication plan matrix, they need to be communicated across all of the different groups that we've identified as part of our program. If we say that group one is our executive leadership and group two is our data domain stewards and our group three is our data stewards, we can't communicate in the same way to group one as we communicate to group two as we communicate to group three and ultimately with everybody in the organization. So it's important to put together a communication plan that says when we're going to communicate the charter and the principles or the role-based activities or where governance documentation exists, you've got to make certain that we have an approach for communicating these things to different people in the organization and that we're not going to just use a one-size-fits-all when it comes to communicating about data governance within the organization. Last couple of slides I have are ways to encourage stewards to get involved. Well, we need to help the stewards to understand their value to the organization so that they buy in or they volunteer or they offer their time. There are organizations that have offered perks and rewards to people. There's a whole bunch of different ways to encourage data stewards to get involved and that's encouraging on a positive sense but then on the flip side of that there's also ways to force stewards to be involved. We're going to tell people that you will do this and that participation is not optional and that we're going to make it mandatory for them to participate in these activities and they develop point systems for being able to see how often people are participating in the program. The fact is that's a lot more invasive than taking the identify and recognize approach rather than assign people to roles. We want to take more of an encourage role and want to get stewards to understand that they should promote within the organization the idea of encouragement for getting stewards involved rather than forcing it down people's strengths. I've kind of got six minutes before the top of the hour here. These are the things that I covered, the different levels of roles and responsibilities, how we apply those roles, how we communicate with these roles and ways that we can provide incentive for people to get actively involved within our program. And so with that I'd like to turn it back over to Shannon and see if there's any questions in regard for this webinar. Always a lot of questions from our attendees which I love and of course one of the most popular questions are people asking if they'll get a copy of the slides and the recording of the presentation. I will be sending out a follow-up email by end of day Monday for this presentation with links to both of those. In addition of course I do have a copy of the matricy that Bob presented so I will get a copy of that out to everyone as well. So first question Bob, in organizations where you don't have that one person with the end-to-end subject area expertise to act the role of the enterprise data domain storage, how do you handle that? That's a great question and that is again one of the reasons why that's one of the most challenging aspects of the data governance program. In fact I had a client recently who actually found that there was nobody who had end-to-end knowledge about the customer within the organization and somebody stepped forward and said look I'll volunteer to facilitate in that role but ultimately I'm not a decision maker. So oftentimes to solve that problem with a person who knows the data from beginning to end it's going to take somebody from a data governance council to identify a person to participate in that role if there's not a single or at least several subject matter experts that you can point to. The fact is that it is a critical role. It is very difficult to fill and if you don't have somebody with the end-to-end knowledge you need to find somebody that will at least play the facilitator role and then decisions if they're just a facilitator then the buck won't stop with them as we're escalating issues. That's when the issues would automatically basically be taken to the council to make the decision at the strategic layer. That's a great question and that's a question that I get very often when it comes to that tactical level of the pyramid. That is a great question and the next question is the triple is often you don't find people with such profile, personnel interest diplomatic etc. That's kind of more of an extension and for the end to be least invasive, most win-win what about an approach by agile most equal and let the users determine what data is most appropriate? Well, and so it's good that if the users have a good sense of what data is going to be most appropriate then we can make decisions down to the operational level and yet it is an extension of the previous question. It really becomes almost more of a political role where the person that's playing the role of the data domain steward or the enterprise data steward or the subject matter expert needs to be able to take into account viewpoints from different parts of the organization and not be a my way or the highway type of person where they can understand the different viewpoints, they can consume those, they can then take that and put that in a form that they can bring it to a decision at a strategic level. It becomes that role again just becomes critical and we need to take politics into consideration. We need to take their position within the organization into consideration and first and foremost we need to take their knowledge about that specific subject matter into consideration when we're identifying those people. Is there additional training material that you recommend to use to orient or ramp up people to career and MDM or centric to governance? Actually there's a lot of universities that are now starting to adopt data as a focus or data as a profession as I tweeted about earlier this week. There are a lot of places, there's a lot of information available on the internet, there's dataversity which has white papers galore and places that you can go to learn more about the skills that are required for each of these positions. There's the data administration about what some of these people need to know in order to have an extensive career in MDM or in data warehousing or in big data or whatever it is. My suggestion is do some searches on the net, visit dataversity quite often, get the information that you need and if you ever have questions about what the roles would be feel free to reach out to myself or to get those questions answered. We do have more questions rolling out, we have time for today. Keep your questions coming because one of the great things about this particular webinar series is Bob will write up the answers for you and we'll get those out as well in the follow-up email which will contain links to the slides, links to the recording and the links to the matrix that Bob presented today and that email will go out by end of day Monday to everybody. Bob, thank you again so much for another great presentation. It's so important to set up the stewards and everybody else and responsibilities in governing the data and thanks as always to our attendees for all the great interaction and participation that you bring to the table. We just love it. Hope everyone has a great day. Thank you very much, stay warm and we'll see you next month. Bye.