 Hello and welcome, my name is Shannon Kemp and I'm the Chief Digital Manager of Data Diversity. We'd like to thank you for joining the current installment of the Monthly David Diversity Webinar Series, Real-World Data Governance with Bob Siner. Today, Bob will discuss an operating model of data governance roles, 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. Just click the chat icon in the upper right-hand corner for that feature. For questions, we will be collecting them by the Q&A in the bottom right-hand corner of your screen. Or if you'd like to tweet, we encourage you to share highlights or questions via Twitter using hashtag RWDG. 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 Damer 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 us started. Hello and welcome. Thank you very much, Shannon. Thank you, everybody. Good morning. Good afternoon. Good evening. Or even happy tomorrow if you're in a part of the world where it's already Friday the 19th of May. Thank you for once again joining us in the Real World Data Governance webinar series, as Shannon mentioned. Today we're going to talk about an operating model of data governance roles. And this seems to be a subject that we always seem to come back to once every couple of years. Talk about one of the most important aspects of putting a data governance program together. One of the questions that I get most often is what do the roles and responsibilities look like as we're setting up a program within our organization? So I'm looking forward to sharing a lot of information with you about how to go about setting up an appropriate set of roles and responsibilities by using an operating model that I have shared before and talked quite a bit about. So before we get started, I'd like to share just a couple of things that are coming up. First thing I'd like to do is to talk about the upcoming webinar. So next month in June, we'll be talking about comparing approaches to data governance. It's a abbreviated version of a session that I gave at the Enterprise Data World event earlier this year. In July, we'll be talking about is a data governance charter necessary. That's a very timely topic. In fact, a client that I'm working with right now is struggling over whether or not a data governance charter is going to be necessary for their organization. So I hope that you will come back and join us in June and July and other webinars that we're holding in this series. So also I wanted to tell you quickly about the noninvasive data governance book that was published back in 2014. If you're interested in learning more about noninvasive data governance, please go and check that out on Amazon or your local bookseller. Also real quickly, I'll be speaking at an upcoming dataversity event in June, the Data Governance and Information Quality Conference. I'll be giving two sessions, a tutorial and a regular session. Also, through the Dataversity Training Center, there's an online learning plan, noninvasive data governance. That's available, seven online courses with a chance to be evaluated at the end of each of the sections of that course. And last but not least, Shannon mentioned the Data Administration Newsletter, the online publication. That is in its 20th year of publication, believe it or not. But if you're a reader, that's great. I'm glad to have you there. If not, I hope you'll take a chance to go check out the Data Administration Newsletter, tdan.com, to learn more about the data management industry and hear from people that are writing some great topics associated with data administration. So what are we going to talk about today? Like I said, the operating model of data governance role seems to be one of the most popular topics of this webinar series and one of the most popular topics that people ask about when it comes to putting a data governance program together. In fact, the roles and responsibilities that we define for our program are often the foundation of a successful data governance program. Oftentimes, when organizations are developing operating models, they look at it from all different perspectives of the organization. And that includes from the executive perspective, the strategic, the tactical, the operational, and also the support perspective. There's different levels of an operating model. But I'm going to go into a fairly deep amount of detail during this hour. So during this webinar, I'm going to talk about a couple different things. First thing I'm going to do is share with you the operating model as a pyramid diagram and an easy way to be able to represent how the different roles in the data governance program should be set up. We'll talk about five distinct levels of responsibility. And I just mentioned those as being the executive level, the strategic, the tactical, operational, and then those parts of the organization that support your data governance initiatives. I'm also going to talk about a couple different approaches, actually three different approaches to stewardship and how we identify and how we work with the stewards within our organization. And I'm really going to focus primarily on the operating model and talk about the details at each of the different levels that I just mentioned. But at the end of the session, I'm going to also talk about who is expected to participate at each of these different levels and what will be the ask of these people. That's one question that I get all the time as we're setting up roles and responsibilities. We need to be able to be very clear to people as to what we're asking them to do as they are being asked to participate and get involved in data governance. But with each webinar, I like to get started by kind of laying the groundwork for data governance. Let's start with a definition of data governance. So you may have yours, I have mine. There's a lot of different definitions that are floating around the industry. But I like this definition and this is one that I've used repeatedly over the years. I say that data governance is the execution and enforcement of authority over the management of data and data-related resources. And I choose this definition because I like the definition to have some teeth behind it. I like people to cringe a little bit when they hear the definition because the truth is at the end of the day, no matter what we do to set up our data governance program, no matter how we set up the roles and responsibilities, the fact is that we need to execute and enforce authority over the management of data in order to be successful within our organizations. The definition that I use for data stewardship is specifically relevant for today's webinar, where data stewardship is the formalization of accountability over the management of data and data-related resources. And what I mean by that is that there's already people within the organization that have some level of responsibility around the data. In fact, anybody, and I'll talk about this a little bit later as well, anybody in the organization that has a relationship to the data, whether they're a person that's defining data as part of their job, as parts of big projects, or they're producing data as part of their job, or most people in the organization are users of data. Well, if you have a relationship to data, then the non-invasive data governance approach talks about making certain that people understand that there's a level of accountability that's associated with each of these different relationships that people have to data. So if you define data, you have responsibility to make sure that that data, that the data that you're defining doesn't exist somewhere else before you define it. Again, if you're producing the data, you have some level of responsibility around understanding the impact of the data that you're producing to the organization. And certainly the no-brainer of it all is that if you're a user of the data, we can pretty much be assured that our senior leadership within our organization is going to want to make sure that people are using the data appropriately, that they're protecting sensitive data when data needs to be protected, that they're securing data that needs to be secured. So if you're a definer or a producer or a user of data within your organization, and that sometimes can account for almost anybody in the organization, there is a responsibility that you have. There's an accountability that you have for that relationship. And when I talk about stewardship, I talk about how do we formalize that accountability for the data in the organization. Real quickly, non-invasive data governance is basically the practice of applying that formal accountability and behavior through this set of roles and responsibilities that I'm going to share with you today. And to be non-invasive in our approach to data governance, typically organizations focus on applying governance to process rather than redefining all their processes as data governance processes. And we do this to assure that the definition, production, and usage of data assures all the things that we're looking for out of our data governance program, like regulatory compliance, security, privacy protection, whatever it is, it's the focus of your program. So basically in a nutshell, non-invasive really describes how governance is applied to the organization, with the goal being to be transparent, supportive, and collaborative. So I'm going to share with you the pyramid diagram here in a minute of different roles and responsibilities. But before I do that, I wanted to share just a couple things that go into making up the operating model of roles and responsibilities. We're going to talk at good detail about each of the different levels associated with the operating model. We're going to talk about different domains and subject matters that are important to your organization and identifying the people in the organization that are the subject matter experts for that data and giving them an appropriate role in the data governance program. I'm going to share with you a couple different diagrams, one being the pyramid diagram and another being something that I call a common data matrix that helps to really pull it all together so you can see who has responsibility for what across the organization. I'm also then going to go into a good level of detail about the different roles and the different responsibilities that are associated with each of those different roles. So I talked about the five different levels of roles that typically take place in a data governance program. In fact, some organizations have cut it down to four roles they've gotten rid of or they've combined different levels. Well, typically I like to talk about these five levels. I talk about the executive level of the organization, the steering committee, the C-level positions within the organization. We know that they're not going to have a whole lot of time for data governance or to participate in data governance, but they do play a role. So we're going to want to talk a little bit about that. We'll also spend some time talking about the strategic level. A lot of organizations have a committee or a council that they call the data governance council or something similar to that. And I'm going to talk about what are the responsibilities typically for the data governance council and what can we expect of them, what the time commitment from the council is. In fact, a lot of organizations that are successful with their data governance programs have strength in the strategic level at the council level where they support sponsor and understand the activities of the program, but they also get engaged in helping to resolve issues that get escalated to the strategic level. The tactical level of roles and responsibilities is perhaps one of the most important in this set of five levels of responsibility. The tactical level is where we go from looking at data from an organizational or from a siloed business unit by business unit asset, and we start looking at data across business units, across the enterprise. And that's a big step for a lot of organizations to take because oftentimes it's not obvious who that person is or who those people are that will have the responsibility for making decisions associated with the data for the entire organization. So I'll talk a little bit in detail as to the tactical level and why it's so important to the data governance program, but also that it seems to be the most difficult level for us to fill as we're building out our roles and responsibilities associated with our program. We'll talk about the operational level and we'll talk about the support levels as well. So typically, and you might have seen this in other diagrams or in diagrams from other organizations, a lot of organizations set it up this way. They have executive strategic tactical operational and support and therefore it may kind of make sense to define an operating model that's going to fit into the way that the organization is already structured. I talked a little bit about domains but let's spend a little bit more time because it's important for us as we look at data across the organization to identify what the domains are, what the subject areas of data that are most important to our organization. So it's not difficult to define the domains. In fact, you could probably right now in a couple of minutes on a scratch piece of paper write down what are some of the most important subject matters that your organization cares about. What's difficult about the domains is identifying those people in the organization that have a level of responsibility or even have a level of authority associated with each of those different domains so that when we have issues that start to cross business areas, that we can point to these domain experts, these subject matter experts and get them involved in resolving issues that cross different business units in the organization. So some of the examples that I share here with you of data subject areas are customer. That's one that a lot of organizations focus on very early in their data governance program. Supplier, product, material, finance, employee. Again, if you took a couple of minutes to scratch out what some of the domains are that are important to your organization, the next step you might want to do as you're starting to define your operating model of roles and responsibilities is to identify the people in the organization that might be considered the subject matter experts. And I'll share quite a bit about the data domain stewards. In fact, I'm going to share with you information about what are some of the common traits that would make up a good data domain steward or that tactical level of the operating model. So here I'm sharing with you the pyramid diagram and you may have seen it in prior webinars but I'm going to spend a whole bunch of time going through each of these different levels and as you can see at the top level of the pyramid is the executive level and that's typically made up of senior leadership and at the strategic level that's where a lot of organizations have their data governance counsel. The tactical level seems to be one of the most difficult for us to fill in the organization. Again, finding those subject matter experts across the organization. The operational, well that's typically anybody in the organization as I mentioned before who defines and produces and uses data as part of their job. So and on the left-hand side of the pyramid you'll see two sidebars. One is for the data governance team or data governance office or whatever you call those groups of people or that individual basically that has the responsibility for defining the data governance program and then there's all the other parts of the organization the partners, the people that data governance partner with to make sure that data governance operates the way that they're looking for it to operate. So there's some of those support levels could be the information technology area could be the information security, project management there's a whole bunch of different parts of the organization that could be considered partners with the data governance team to make certain that as we're delivering our program we're delivering those things that we are setting out to achieve. So for example, if we're focusing on protecting sensitive data then we wanna make sure that we get the privacy people and the information security people involved. They'll partner with the data governance program to deliver a successful program focused on those things that are most important to our organizations. So the first impression that a lot of people have when they see this diagram is that it's very bureaucratic that there's too many levels that we need to remove some levels we need to make this easier for people to understand. In fact, I may have mentioned before that I've had clients that have taken this diagram of three levels and broke it into nine different levels and they spend a lot of time trying to explain the difference between the levels. My suggestion is to take a look at the way the organization is set up take a look at it from the executive perspective strategic tactical and operational and set up the program that way. In fact, when people look at this and they think that it's very bureaucratic and they think that it's gonna be brand new to the organization that's why I added those things on the outside parts of the diagram where it says that some of these things already exist in the organization. In fact, you probably already have senior leadership. You probably already have people in the organization that are defining producing and using data as part of their job at the operational level. So they already exist. You could basically put a check mark there next to those and say, well, you know what? These things already exist in our organization. We really don't have to set up anything new in order to accomplish data governance when it comes to the executive level and the operational level. But when it comes to the strategic level and the tactical level, perhaps there's already people within your organization that make up a council or a board or some type of group of people that are decision makers within the organization. And that would typically be the data governance council. There may also be subject matter experts for different types of subjects of data. They may not recognize themselves as subject matter experts. They may not have the authority to make decisions for the different data subjects across the organization. But we want to look to see if we can find out who those people are first and we want to leverage them. So again, the executive and the operational level, they tend to already exist within the organization. The council, there may be something that looks like that that we can leverage. The subject matter experts will take a look at who do you go to when you have questions about certain types of data or when you have issues that need to be resolved around certain subject matters of data. On the left-hand side, there's the data governance team and the data governance partners that make up the support level of the operating model. And the fact is that potentially those people that are on this webinar today are the people that have responsibility for data governance within your organization. So I'd say the data governance team or at least those individuals that have been given that responsibility, they already exist. Well, IT and project management and information security, they already exist. So the truth is if you look at this model and you think that it's gonna be very bureaucratic and it's gonna be very difficult to fill, the fact is that most of these things are already taking place in your organization. And if we're gonna follow a non-invasive approach to data governance, then we're gonna work to make sure that we leverage those roles and responsibilities as best we can and make it so data governance is not a scary proposition to the organization. A couple other things to share with you about this diagram. If you look along the right-hand side of the pyramid diagram, you'll see two arrows. The first arrow is the escalation or the approval path. And oftentimes in organizations, when issues start within a business area, they get escalated if it ends up covering more than one business area up to the tactical level of the organization to make decisions or those people that have responsibility for data across business areas rather than just specifically within one business area. And then the escalation arrow extends up into the data governance council as well. And the reason why the arrow doesn't extend all the way into the executive level is that typically in our organizations, we don't take data issues to the executive level. So the escalation would be start with the business unit specific issues and if it becomes a cross business unit issue, then it gets escalated up to the data domain stewards. And if the data domain stewards have the authority to be able to make the decisions, then the buck stops there basically. But in a lot of organizations, in order to get a decision at a strategic level, it requires that the issues get escalated up to the strategic part of the organization. Also, the amount of space within each of the layers, the pyramid means something too. The bottom level, the operational level, most organizations that I've come in contact with have wanted to try to push the decision-making down as far into the organization as they can. So since there's the greatest amount of space in the operational level, that's representing that we want to decide most of our issues or the majority of our issues that are just business units specific within those business units. But then issues that can't be resolved that way, they need to be resolved at the tactical level, which is lesser space. And even the strategic level, the data governance council is even less space within the pyramid part, within the triangle part of the pyramid. And in some organizations, in fact, they'll say that if you escalate more than five to 10% of your decisions to the strategic council, to the data governance council, there's a serious shortcoming within the tactical level. So when we're identifying who our data domain or subject matter experts are, we want to make sure that we're naming them appropriately and that we're giving them the level of responsibility that's necessary to resolve issues for the specific subject area that they have knowledge. The last thing about this diagram is that my suggestion is that you don't try to plug your organization into this model. In fact, I would suggest exactly the opposite. I would suggest that you take this model and you overlay it over what already exists within your organization. So you look to see who are the operational people that are defining, producing and using data. Then we look to identify who are those people that we go to resolve issues around specific subject matters of data. Then we look to see if there's a council that already exists or there's a group that looks like or sounds like a data governance council, as I'm gonna describe it here in a minute. So again, instead of trying to plug your organization into this model, my suggestion is that you take this model and you overlay it over what already exists within your organization. Now this presentation is not really about this diagram, but this diagram does a lot to help people to understand where the roles and responsibilities come into play. So if we take a look at the previous diagram and in this diagram, we see that there's color coordination between these two diagrams. This is something that I call the common data matrix. And in most organizations that are implementing governance, it is very important that they inventory what data in what systems is being used or defined or produced by what people across the organization. And this common data matrix is a very simple way of being able to go about recording that information. Down the left hand side, we have information about the different subject matters of data. Across the top, what we have is the different parts of the organization, basically the organizational model of what the organization looks like. And what I suggest is that when you're getting started with your data governance program that you record information about, let's say for example, we've got customer data and we've got a subset of customer data which is demographic data. And that data can exist in the ERP system and the data warehouse and the MDM solution. And there can be people in different business areas that are using that data within those different systems. Well, this is all metadata that's very important to the operation of a data governance program. And as Shannon will tell you, we're very glad to share this model, this matrix with you after the webinar today. If this is not something that you've seen before, I can tell you this, that most organizations as they're getting started do need to inventory who does what with the data across the organization. So we're not really gonna spend time talking about the common data matrix, but as I go through the different roles and responsibilities, take a look at where they fit within the common data matrix. So real quickly, let's talk about the enterprise level, the executive level of the data governance operating model. So it's typically senior management made up of C-level individuals or something similar. There may already be steering committees that exist that you can take advantage of. Typically, they have no specific day-to-day responsibility when it comes to data governance, but it's very important that they support sponsor and understand the activities of data governance within the organization. In fact, I often share that as the very first best practice that I use is that senior leadership must support sponsor and understand data governance in order for it to be successful within your organization. There's not a whole lot to be said about the executive level because we're not really asking them to do a heck of a lot. And in fact, we're really not asking for a whole lot of their time at all. We just want to make sure that they understand what the heck it is that we're doing when it comes to data governance. But the next level down, the strategic level, the data governance council is extremely important when it comes to developing your data governance program. And let me tell you why. If the people at the tactical level, the subject matter experts and the domain experts don't have the authority to be able to make decisions, it's important to have a body within the organization that we can go to and bring all the information to and ask them to make decisions associated with the data and the different projects that are taking place within the organization. Now, oftentimes the executive level people will be the ones that will identify or assign people to be on the data governance council. And typically the data governance council has direct accountability to the executive level. And oftentimes those individuals that are responsible for representing their part of the organization on the data governance council, there's typically somebody that can stand in for them if they can't participate in some of the data governance meetings or data governance council meetings that are taking place. So the data governance council typically consists of strategic representatives of business divisions, Crosby organization and your information technology part of your organization as well. So the question becomes, why do we need a data governance council? Well, the fact is that we need a data governance council for several reasons. One is that we need to have coordination of data governance activities across the different divisions or across the different business units of the organization and that's represented on the council. We need cooperation across these divisions. We need communications. We need comprehensive risk management. We need to be consistent in the way we apply governance across the organization. So it's important to, at the strategic level of the organization, have a body that we can go to, have a group that we can go to, to resolve issues that cannot be resolved at lower parts of the organization. So what do we typically ask a data governance council to do? Well, there's several things that we ask them to do. The first one is we ask them to become educated in what data governance means, how it can and how it's gonna work within the organization. We ask the people at the data governance council level to approve things that need to be approved, things like data governance policy, maybe even your set of roles and responsibilities in your operating model needs to be approved at the strategic level of the organization in order for you to move forward. Another thing that we ask the data governance council to members to do is to push data governance into their areas by actively promoting different things and different practices that we are engaged with as part of our data governance program. We ask the data governance council typically to make decisions at a strategic level and do that in a timely manner, given the appropriate knowledge to make those decisions. Typically the data governance council meets regularly or they send their alternative or alternate for their part of the organization. They stay up to date on the information on the status of activities of the data governance program. So either they attend the regular meetings, whether it's once a month, once every other month, once a quarter, however they're set up within your organization. But if they're unable to attend, we wanna make certain that they take the time to read the minutes and stay informed of the different activities that are going on within the data governance program. We ask them to identify and approve potentially those pivotal data governance roles, including the domain stewards, the subject matter experts, or the authorities for different subjects of data across the organization. And we ask the council members also to advise a council owner or a person that has responsibility for running the council to advise them on what are some of the things that we as an organization need to focus on when we are delivering data governance. One question that I get very often is, how much of a time commitment is there for our council members? And typically, and I've heard people say that they should have, I've heard some people say that they're expected to spend 20 or 25% of their time on data governance. Well, the truth is that that's not the impression, that it's not the focus that I have. The data governance council, typically we're asking them to meet for 60 to 90 minutes once a month or once a quarter, however it is set up in your organization. We're not asking for them to be dedicated to data governance. And in fact, at one conference, somebody came running out of a session and said that person told me that the data governance council needs to apply 20% of their time to data governance. Well, the fact is that if you introduce it that way within your organization, when people stop laughing at you and telling you that it's gonna be impossible for those people to spend that amount of time on the program, then you should tell them, well, what we really meant is that we really need them to be there to resolve issues that get escalated to their level and to attend a meeting once a month or a quarter, or again, however you have it set up. They need to have time commitments available to read, review, and comment, recommend, and approve different things that we talked about, like the data governance policy or data policies in general, the operating model of roles and responsibilities. So typically, not only do they need to have that time to attend the meetings once a month or once a quarter, but they also need to have time to review issues that are escalated to their area in a timely manner. Typically, as I mentioned before, only 5% to 10% of the issues would get escalated to a data governance council, and if you're taking all your issues to the data governance council, there's a serious shortcoming in your tactical level of your subject matter experts. So typically, when they hold these meetings once a month, issues aren't resolved at the meetings. Those meetings are set aside for status and updates of the program activities. Typically, the resolving of issues takes place outside of the meetings, and again, we say that we don't wanna have too many of our issues go to the data governance council. Only those issues that require the strategic perspective and the strategic decision-making, those are the issues that get escalated up to the data governance council. Now let's talk about the tactical level, the data domain stewards, as I've called them. In fact, I was working with the client recently that said, well, aren't these people really the subject matter experts for the data? And I said, yeah, that's typically what they are. And they said, well, why don't we just call them that? Why do we have to call them domain stewards? Well, the fact is you don't have to call them anything that I'm suggesting here. If they're subject matter experts in your organization, use that name, but these are the people that have some level of knowledge and responsibility for data across the organization. Now another role that takes place at the tactical level is that of the data steward coordinator, and I'm gonna talk a little bit more about that in a minute, but these are people within the business areas that have responsibility for doing exactly what the name suggests, coordinating the activities of stewards in their business area. Let's talk about some of the responsibilities of the data domain stewards. So typically they're responsible for the enterprise management of a domain of data. And that means that they're not just responsible for that information within their business unit, but they have responsibility for that data across business areas. They're typically identified by position or by person as part of a single business unit, but when they're acting in the role of the domain steward, they need to put their affiliation to their business unit secondary, because when they're playing the role of the domain steward, they have the responsibility for making decisions or at least facilitating towards decisions for data across the organization. And if they come in with just their organization's interest in mind, it becomes very recognizable very quickly that they're not necessarily looking out for the best interests of the organization. They're looking out for their own business unit's best interests. So they're typically an involved facilitator in cross business unit resolution. Sometimes they're the decision maker, sometimes they're not the decision maker. When they're not the decision maker, it becomes important to be able to escalate that up to a group of people that would be the data governance council that we just talked about. So what are some more of the responsibilities of the domain stewards? They're responsible for escalating well-documented issues to the strategic level. They're responsible for documenting data classification rules and compliance rules. They're responsible for making certain that the rules are communicated to all of the stakeholders of that data across the organization, or they might delegate the responsibility of doing that. Oftentimes, these data domain stewards are responsible for participating in working groups or tactical steward teams, as I call them, where they work with other stewards, other domain stewards and steward coordinators to help to resolve issues associated with their domain of data. As I mentioned before, I wanted to share with you a few traits that I have found to be useful when it takes, when you're taking a look at what are typically good traits of a data domain steward. So typically, they would have a vision of what the future of data as an asset looks like for the organization. They're looking for ways to improve on the status quo, their ability, they have the ability to motivate the organization, set examples of data-related behavior, but I want to really point at the last bullet point, because that actually came from a client of mine who sums it up pretty well when they said that the data domain stewards, the subject matter experts, need to have the personal interest, the intuitive ability and the communication skills to achieve a win-win when we're resolving issues associated with data that crosses over business areas. The data steward coordinators, as you can see where I'm circling them on the common data matrix, they sit within the business areas and they have a responsibility to act as that point communication person for sharing information with the different stewards that were identifying within their business areas. They act as the point communication person to document and communicate issues. They act as that point person, oftentimes in completing the information that's important to fill out a common data matrix. So the data steward coordinators, those aren't full-time jobs. Sometimes in organizations, those are even administrative types roles, but they help us to identify who was in their part of the organization to find, produce and use the different types of data that we care about as we're putting together our data governance program. Oftentimes the data steward coordinators identify the operational data stewards within the organization. They work alongside the domain stewards to resolve issues. Oftentimes these people at the data steward coordinator level don't have any level of responsibility other than making sure that the stewards are active within their part of the organization and they're engaged and they're communicated with appropriately. Quickly let's talk about the operational roles within the common data, within the pyramid diagram of the roles and responsibilities. So basically as I said before, the operational data stewards could be anybody in the organization that has a relationship to the data, whether they're defining or producing or using data as part of their job. The steward coordinators help us to identify who those people are within their part of the organization and we don't necessarily need to go out and tag each of them and tell them that they're data stewards but we do need to know who is defining, who is producing and who is using the different types of data in the different systems across the organization. So I've shared in a prior webinar my rules for becoming a data steward. So basically I said if you have a relationship to the data then you need to be held formally accountable for whatever that relationship is. So basically a data steward can be anybody within the organization and being a data steward really describes a relationship to the data. It's not really a specific role itself but if you have a relationship to the data you have accountability for stewarding the data based on the definition, production, usage whatever the activity that is that you're taking with the data. A data steward is not hired to be a data steward. A data steward does not even need to have the title of data steward and oftentimes they don't need to be told how to do their job except for when it comes to if they're not following the rules associated with defining, producing and using the data. Some organizations talk about public or industry data steward certification. Well, the way I put it is that that's a load of bunk. You basically don't need to tell the data stewards what to do in their job but you do need to help them to understand where their levels of accountability exist based on their relationship to the data. And oftentimes and in fact in all organizations that I've seen there's more than one data steward for each type of data and data steward training needs to focus on the formalization of the accountability for the data across the organization. So what are some of the additional responsibilities in the operational data stewards? Well, typically the operational data stewards could be broken down into three different levels. The data definers, the data producers and the data users. So if there's some way that you would want to denote that within the common data matrix as we're identifying who does what with data across the organization and those people that have responsibility for defining data have different levels of accountability than those people that are using the data or should I say they're accountable for different things in the organization. So that's something to consider. We may want to break down our operational data stewards into three different levels, which would be data definers, data producers and data users and even detail what their specific responsibilities are again based on that relationship to the data. I'm not going to read through a list of all these responsibilities because there's so many of them but other responsibilities of the operational data stewards are to participate in creating, reviewing and approving definitions, participate in integrity and quality of definitions. They have a lot of different responsibilities but what I want to point out is the last two in this list of bullet points here. The operational data stewards have responsibility for communicating new or changed business requirements to individuals who might be impacted or who can influence change for that data across the organization. Now oftentimes they also have the responsibility for communicating concerns, issues and problems with the data to people in the organization that can influence some level of change to that data. Let's spend a couple of minutes talking about the support levels. Typically there's a data governance planning team or program team where you might have both or your team might consist of just one person. Now there's also data governance partners as I mentioned earlier, the information technology part of the organization, risk management, PMO, your agile teams. There's a lot of different parts of the organization that can be considered partners of the data governance program and it's very important for us as part of our operating model roles and responsibilities to identify who those people are and engage with them as part of our program. Now I had a client recently where I used the operating model, the pyramid diagram that you see there but they also wanted to be able to reflect what it looks like during the project phase, during the definition phase of our data governance program and then once it becomes rolled out as a program, what it looks like. So I've taken an inverted pyramid diagram and put it next to the regular pyramid diagram that you see as the operating model, say that over time as we move from the left to the right in that diagram basically the emphasis changes from the executive and the strategic level to the operational level and that data governance planning team or program team oftentimes there's a group of individuals that have responsibility for planning and defining the program and that evolves into a working team as the program gets rolled out to the organization. They participate in program development, they architect the solution, they facilitate the data governance council meetings, there's a lot of responsibilities for the data governance planning team and the interesting thing is that they're not represented on the common data matrix. So oftentimes as we're filling out that inventory of who does what across the organization, we don't have to necessarily put in that diagram in the common data matrix who those people are that have responsibility for facilitating the program. Oftentimes this group is responsible for the development of the education materials, the awareness materials and oftentimes they also have the responsibility for mentoring different people across the organization. They have the responsibility for reporting the results to the data governance council. They participate in the delivery of the policies and the standards and the guidelines. You know, oftentimes they have the responsibility for defining the metrics and the measurements. How are we gonna measure the success of our data governance program? Oftentimes that responsibility will sit in the hands of the data governance planning team and then the project team. Well, what are some of the responsibilities of the data governance partners? Again, the other sidebar to the left of the pyramid diagram. Well, their focus is on consistent protection and classification of data. They're responsible for the technical handling of the data. Typically those different parts of the organization. For example, the PMO has responsibility for project management and may have the responsibility for basically integrating data governance into the project methodology within the organization. The information security people, they have a lot of information about who has access to what data across the organization. Well, we wanna partner with the information security people, with the privacy people, compliance people and make sure that we're working together as a team to deliver successful governance across the organization. They have the responsibility for ensuring that the policies and procedures are in place and that they're being followed for making sure that strategic data is modeled and named appropriately. Basically, they have the responsibility to do what their groups are set out to do, but they do that in partnership with the data governance program team to deliver successful data protection, to deliver successful projects and project management. So we're not necessarily gonna tell the data governance partners what they need to do in order to operate, but we are gonna work with them to gain knowledge from what they already know about who does what with the data. And in fact, oftentimes, they can be very supportive in fulfilling out the common data matrix as I shared with you earlier. I think I have too many slides for the slide deck, but I'm gonna go through the rest of them as well as I can. There's basically three different approaches that organizations can take to stewardship within their organization. And I've talked about these before. There's a command and control approach. There's a traditional approach and there's a non-invasive approach. And basically, when it comes to stewardship, the difference between these approaches is that in the command and control approach, we assign people within the organization to be data stewards. In the traditional approach, we're basically identifying people in the organization that are gonna play the different roles associated with our data governance program. And in the non-invasive approach, we're gonna recognize people based on their relationship to the data and give them the appropriate role that they need to fulfill when it comes to implementing governance in our organization. So real quickly, the command and control approach, we assign people to be stewards. Typically, people are assigned as being data owners. There's gonna be a select number of people within the organization that are the data owners and they're told that they're going to do this. They don't have an option. We're talking about command and control, top-down, iron, fist, however you wanna look at this in your organization. The command and control approach of assigning people to be data stewards is typically the most invasive approach to data stewardship that we could select versus the traditional approach where we identify people in the organization to be stewards. And typical stewards, again, are identified as data owners and it's still just a select number of people who are stewards within the organization. And people are told, you know, you really need to do this. It's a less invasive approach to governance, but it's still somewhat invasive because it may be responsibilities that these people don't already have when it comes to implementing governance within the program, within your organization. So the approach that I suggest to organizations is that they take a non-invasive approach where they recognize people to be data stewards. So typically, the data stewards are recognized, as I mentioned earlier in the webinar, based on their relationship to the data as the finers, producers, and users of data and their accountability is formalized, again, based on that relationship. And in this model, basically anybody in the organization that has a relationship to data could be a data steward. So I've said before, and I'll probably say it again, that everybody in the organization is a data steward. So you have complete organizational coverage when it comes to once you've now recognized who's defining, who's producing, and who's using what data across the organization. And in fact, to stay non-invasive, the idea is that you're already doing this, so we're really not giving you something that's over and above your existing responsibilities. And this is the least invasive approach to stewardship. In fact, this is the non-invasive approach. So basically, real quickly, I shared with you what the operating model is, and I walked through each of the different levels, and now let's spend a moment here to talk about who is expected to participate at each of these different levels in this operating model of roles and responsibilities. At the executive level, it's typically the enterprise leadership that is participating in that role. So we're not giving them anything new, but we want them to support, sponsor, and understand the activities of data governance. At the strategic level, typically it's business area leadership that's involved at that strategic level when we're identifying the appropriate people to participate on our data governance council. At the tactical level, it's the subject matter experts and those domain leaders or functional leaders, the people that have the knowledge to be able to make decisions associated with the data that crosses over business areas. At the operational level, as I mentioned before, that could be business area staff or anybody in the organization who defines, produces, or uses data as part of their job. The people who are expected to participate at the support level are people that are already part of supportive staff for the organization. Oftentimes it's gonna be those groups that I mentioned, it's gonna be your information security, your IT, your project management, and it could be mostly groups that come from the shared services parts of your organization, or those parts of the organization that are basically providing services across the organization. And last but not least, let's talk about what will be the ask of these people. So as I had mentioned earlier, at the executive level, they have extremely limited involvement. Oftentimes we're not asking them to engage and we may meet with them or we may not meet with them. It may be the responsibility of the data governance council to report to the executive level what's going on within data governance and what the status of different data governance activities are. At the strategic level, we're looking for limited active involvement, but meaning that we're not going to engage them all the time, but when an issue gets to the point where it needs to be escalated to have a strategic decision made, we're asking them to have limited involvement. We're gonna ask for maybe a couple hours of their time over a period of a month, but we're gonna ask for active involvement, meaning that when an issue gets escalated to that level, we're asking them to be involved in making the decision that's gonna resolve the issue for the organization. At the tactical level, those are people that are very actively involved. Those are the data domain stewards, the data steward coordinators are actively involved and it's gonna just be part of their regular job, but typically they're going to be engaged in those working groups associated with things like data standardization, data protection across the organization. At the operational level, these are people that are daily defining, producing and using the data as part of their job and the responsibility of the data governance program is to help them to understand how their relationship to the data needs to be governed. At the support level, basically we're asking for their supportive involvement. We're not necessarily gonna be asking for a whole bunch more of their time, but we're gonna ask them to participate when we need them to do the things that we're trying to accomplish with our data governance program. So, basically in this webinar, I shared information about several things. I shared with you an operating model as a pyramid diagram. We talked about the five distinct different levels of responsibility from the executive, strategic, tactical, operational and support levels. We talked about three different approaches to stewardship being the command and control, the traditional and the non-invasive approach. We spent a little bit of time talking about who's gonna be asked to expect it to participate at each of these levels, and then we spent some time talking about what's gonna be the ask of these people, how much time do we expect from them as we're rolling out our data governance program. And so I know I went through a lot of information very quickly in this hour that we have together. At this point, I'd like to turn it over to Shannon and see, Shannon, do we have any questions today? We have a lot of great questions coming in already and just to answer some of the most popular questions we receive, just a reminder, I will send a follow-up email by end of day Monday with links to the slides, links to the recording of the session and anything else requested throughout the webinar, and including, Bob always answers questions in written form which will be included in the follow-up if we don't have a chance to get to all the great questions coming in already. So just to kick us off, so Bob, let me move back up the line here. I was looking at some more questions. What's an example of division focus versus enterprise focus emphasis on a domain steward may make? Well, a division focus is a person that has responsibility for making decisions for the data specifically within their division. When we talk about the domain stewards or people that are looking at domains or subject areas of data using the model I shared with you today, these are people that have responsibility not just within their business area, but have responsibility across business areas. In fact, I've seen some organizations that have defined policy that say who the people are in the organization that will have responsibility for making decisions for data across the organization. So again, the big difference between divisional and kind of the enterprise view is that a domain steward can't really just exist within a division and have responsibility within their division unless you're just setting up your program for your division rather than as an enterprise program. But typically again, a domain steward should have enterprise view of data rather than just a divisional view of data. Sure, and do you have a bad practice example? Do I have a bad practice example? Yes, I do. In fact, an organization I worked with recently had set up subject matter experts in each division for the same type of data. And what that did was that didn't resolve anything. It did not have a role associated with the program that was responsible for making decisions that were going to impact the entire organization. And the bad practice was that what it really did by defining domain stewards within divisions rather than as an enterprise view, it actually caused more problems in resolving issues because those people thought that they were the people that knew or were responsible for driving towards solutions within their division. So my suggestion is at that tactical level, it really needs to be across business divisions. So along those same lines, so then who in would call them on the bad practice? Say that one more time, I'm sorry. Who would call them out on the bad practice? Well, you know what, oftentimes it comes when you're defining your roles and responsibilities for your organization. If you define your roles and responsibilities the way that I've defined them here in this webinar, that tactical level, by definition, if you look in the pyramid diagram, it says these are cross-business division people. There are people that have responsibility for data across business divisions. So I would say it's the responsibility of the people that are defining the program to make certain that they've defined roles that are looking at data that are gonna break down the silos and operate across business divisions. So moving on to a different topic here. What would you estimate for a timeline for initial setup of a data governance program for multi-facility entity? Wow, timeline. Well, you know, oftentimes that really depends on the number of people and the levels of people in your organization that you're gonna involve in the definition of the program. I would say that a lot of programs can define the operating models over a matter of a couple weeks, actually, but in order to start operating and delivering that and executing with the model, obviously it takes more time. So I would say that in order to stand up a data governance program, or at least to define the operating model, you could do that in a relatively short period of time. And as you're doing it, my suggestion is start to engage some of the people at these different levels so you can make certain that the operating model is doing for your organization what you set out for it to do. All right, so what role does the data governance office play? Is it a support role? Well, data governance office, yeah, I call it a support role because, again, it's kind of a shared services across the organization, but it has the responsibility, as I define in the slides, for defining the program, for defining the operating model, maybe for producing an inventory of the data across the organization and who does what with that data. So typically the data governance office, and I'm finding more and more organizations these days are using that name, data governance office, rather than data governance team, the data governance office is supportive to the entire organization as the people that are facilitating and managing the data governance program. So what is the difference between identifying and recognizing people for the data governance roles? Well, you know what, just look at the use of the terms. So when you identify somebody into a role, that's nice. They're not necessarily given their responsibility, but recognizing people has a positive connotation that goes along with it. So basically, if you go into meetings with people when you say, you know, we recognize that you do these things. You know, people like to be recognized for the things that they do. So there's not a whole lot of difference between identifying and recognizing, except for the terms that you use to acknowledge who the data stewards are in your organization. And I've found that by using the fact that you recognize people, that there's a positive connotation that comes along with it. And typically when you recognize people based on their relationship to the data, the fact is that basically everybody in the organization can be a steward of the data based on their relationship to the data. Well, I'm afraid we are out of time that brings us right to the top of the hour. So keep those questions coming in. There's a lot of great questions out there still. And like I said, mentioned that Bob will write up the answers to the questions we have yet to get to. And we'll include that in the follow-up email that will go out by end of day Monday with links to the slides and links to the recording of the session as well. So Bob, thank you for another fabulous presentation. Great as always, another hot topic for everybody. And thanks to our attendees for being so engaged in everything we do and asking all these great questions. We really appreciate it. And we hope everyone will have a great day and hope to see you next month in the next webinar. Thank you very much, Shannon. Thanks, Bob.