 Hello and welcome. My name is Shannon Kemp and I'm the Executive Editor of Data Diversity. We would like to thank you for joining the current installment of the Monthly Data Diversity Webinar Series, Real World Data Governance with Bob Siner. Today, Bob will discuss data steward definition and other 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 for that feature. For questions, we will be clicking them by the Q&A in the bottom right-hand corner of your screen. Or if you'd like to chat, we encourage you to share our highlights or questions by Twitter using hashtag RWDG, Real World Data Governance. 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. Bob has been a recipient of the DMA 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. How's that for speaking fast? And with that, I'll get the floor to Bob to get us started. For attending the webinar today. And I apologize for the technical difficulties we've been having, but that's not anything that's really under my control. But again, good to have you here. One of my favorite subjects for this webinar series. So I always like talking about data stewards, talking about how you define data stewards, talking about other roles associated with your data governance program. You know, Shannon, we've been doing this webinar series for five years, and we've had very few technical difficulties. So you got to figure that day was going to come sometime. So we are there today, and this is what we're going to talk about today, data steward definition and other data governance roles. Next slide, please. All right, now if I can do it on my computer. All right, just real quickly, before we get started, give you some heads up about upcoming webinars in the series. In August, we'll be talking about mastering and master data governance. In September, we'll be talking about successful data governance models and frameworks. And as always, they are on the third Thursday of every month, assuming that the creek don't rise and we have internet connection. Next slide, please. Now a couple other quick reminders. The book that I talk about or the approach that I talk about a lot in regards to data governance is non-invasive data governance, the path of least resistance and greatest success. You can find that at all best booksellers, Techniques Publishing is my publisher, Amazon.com. To remind you as well, KIK Consulting is the home for non-invasive governance. And to give a quick reminder that I will be speaking at the DataVersity event, DataVersity with DevTech International, the Data Governance Financial Services Conference that is taking place in Jersey City in September of this year. So that's coming up real soon. Hope to see you there. Next slide, please. Last thing before we get into the subject at hand today, want to remind you about the Data Administration newsletter. If you haven't seen the Data Administration newsletter, the question is, wherever you've been, it's been out there almost 20 years. I am now a partner of DataVersity on the publication as well, and the July issue is now available. A couple things I wanted to point out real quickly on the newsletter is one, there's a column that I wrote for this month's issue called Everybody is a Data Steward, Get Over It. And if you recall, and if you've been a participant on these webinars in the past, we had a webinar by that name a couple of years ago, and it was very well received. But it's interesting, I've got a very interesting perspective on Data Stewards and Data Stewardship. I'm going to share that with you today. The other thing that I wanted to point out to you on the publication is that we're celebrating our first year of the partnership between DataVersity and the Data Administration newsletter. And then there's a quick survey out there if you feel so inclined, please go out and tell us what you think about the updated publication and the updated content, what type of content you would like to see moving forward. All right, next slide please. The agenda that we used for today's webinar talks a lot about how the Data Steward is extremely critical to the success of the Data Governance Program. In fact, there are some organizations that call it Data Stewardship rather than Data Governance, but there are definitions for each of the two of those. But one thing is for certain that the role of the Data Steward is pivotal in the success, successful implementation of a Data Governance Program. Several different approaches that organizations can use to identify and recognize and assign people to be Data Stewards. So we're going to talk about those today as well. We're going to talk about all the different roles that are associated with Data Governance and give you some considerations for how the roles might look within your organization. Next, please. So the Data Governance roles we're going to talk about specifically the operational Data Steward roles, the definers, producers, and users of data in your organization. We'll talk about the tactical, strategic executive, and all the supporting types of roles within this hour. We will get to all of those different types of roles. But we're going to talk specifically about Data Stewards and some alternative approaches to how we can identify who the stewards of data in our organization are. Next, please. We typically start out with my webinars. I talk about the definitions that I use for Data Governance and for Data Stewardship. And so the definition that I use for Data Governance is that Data Governance is the execution and enforcement of authority over the management of data and data-related assets. And the Data Stewardship is the formalization of accountability over those same assets. So people say that the definition that I use, the execution and enforcement of authority, is worded quite strongly. And the truth is that if your program is going to be successful, you have to have a solid definition of Data Governance that has teeth behind it. I'm not telling you to necessarily use those words, but truly by the end of the day, when we're managing data within our organization, what we are trying to achieve is execution and enforcement of authority over the definition of the data, the production and the use of the data. So I'll talk quite a bit about those three aspects of being a Data Steward in this webinar. Real quickly, non-invasive Data Governance is, as you see in front of you, the practice of applying this formal accountability and behavior through the set of roles and responsibilities that I'm going to share with you today, and applying Governance to process rather than calling things Data Governance process. A really non-invasive Data Governance describes the approach to how Data Governance is going to be applied in your organization. Next, please. So let's talk about Data Stewards for a few minutes here. In my opinion, from my experience, I have seen there being several different approaches to how we identify or assign people, how we figure out who in the organization are the stewards of the data. And so the four that I'm going to talk about here briefly and then kind of go into this aspect of, potentially, everybody in the organization is a Data Steward. If they have a relationship to the data, we need to hold people accountable for that relationship to the data. But the four approaches that we're going to go through quickly are we can assign people to be Data Stewards, or we can actually, as I've seen with several organizations, we can hire people to be Data Stewards. Certainly, we can identify people in the organization that are stewards of data, but the one that I tend to point to the most is using the word recognizing people as Data Stewards. To recognize somebody for something has a positive connotation to it. If you assign something immediately, it feels as though it is over and above the work that you're presently doing. Next slide, please. And I got to remember to keep telling you to do that, Shannon. So let's talk about these four approaches to Data Stewardship real quickly. When we talk about assigning people to be Data Stewards, the first thing I know when I was in the corporate world, when I would be assigned to do something, or even with my children, my young adults in school, when they get assigned to do something, it's typically over and above what they're presently doing. So I really shy away from using the term assign when we're talking about figuring out who the stewards of the data are in the organization. And when we assign people to become Data Stewards, the first thing that they typically ask is, well, how much time is it going to take? What activity am I not going to focus on in order to be a Data Steward? It certainly feels invasive to people when you assign them to be Data Stewards. So I try to be as non-invasive as possible. And this is really approach that's kind of like a 2x4 approach. I know that in old slides I used to have two feet by four feet. That's a big piece of wood to hit somebody over the head with. But a 2x4, if you hit people over the head and assign them to be Data Stewards and tell them that they will do this and that they will make time, what do you expect their reaction to be? So I suggest let's not use the word assign people to be Data Stewards. Same thing holds true for higher people to be Data Stewards. You know, I've seen organizations that have had full-time equivalents for Data Steward roles and they're bringing people in from the outside because their management says that we don't have the people that we have within our organization. They don't have time for this. And so I really, again, shy away from the idea of hiring people to be Data Stewards because as you see, as I go into my definition of what a Data Steward is a little bit deeper, you'll see that people are Data Stewards, they have accountability for what they do with the data no matter whether or not you give them the formal title of Data Steward. So we certainly don't need to hire people to be Data Stewards. Next slide, please. Identify people as Data Stewards and that's a term that I used for a long time in these webinars and in my data governance practice is that we identified people as Data Stewards. So basically people are Stewards of data based on whatever existing responsibilities they have. So if they define data as part of their job, they have a responsibility, those people that are defining data to look to see if that data already exists in the organization and to not redefine the same data the 20th time but to utilize the data that's pointed to as being the system of record or that data that's the golden record of the data. So what we want people to do, even those people that are defining data as part of their job, let's build into the practice of them defining data that the first thing that they should do is go out and look to see what data already exists before they define another version. The term that I use most often to associate people with being Data Stewards is the term recognize. And as I mentioned before, recognizing somebody for something has a positive connotation that comes along with it. Basically, it's very similar to identifying people as Data Stewards. People's Steward Accountabilities are formally based on their relationship to data. As I've said before, if you define data, you have a responsibility for making sure that data doesn't already exist. If you're producing data, you have the responsibility for making sure that you understand how that data is going to be used in the organization. So if you're a producer of data, you have people formally accountable for how they're producing data. And the last but not least is the usage of data. And basically, if somebody uses data in their job, then they have a responsibility for knowing and understanding the rules associated with using that data. So honestly, from my experience, I've seen that almost everybody in the organization either defines, produces, or uses data. In fact, in most organizations, people do more than one of those things. They define and they use data, they produce and use data, whatever it is. So in my opinion, basically, everybody in the organization that has a relationship to the data needs to be held formally accountable for that relationship, for how they handle the data in relationship to that association to the data. So basically, what I'm saying is everybody is a Data Steward. If you remember what I mentioned in the webinar here, the column in the TDAN publication is everybody is a Data Steward. Get over it. If people think that that's going to make their program much more complex, the fact is that we just don't want a handful of people or a subset of the population in our organization protecting the data. Basically, anybody that has access to PII data, personally identifiable information or personal health information or even intellectual property, would understand the handling rules associated with the data that they use. So basically, everybody in the organization is a Data Steward. Next slide, please. Maybe you buy into the idea that everybody's a Data Steward. Bob. Maybe you don't. Yep. I think he missed the next slide. Which can you confirm which slide you're on, please? Okay, perfect. Thank you. We are doing the best we can to stay in sync and I think we're doing an okay job so far. So I want to share with you some hints as to how you're going to recognize people as Data Stewards. So basically, I'm going to share 10 things that you can possibly work on to determine who the everybody is in your organization that are Stewards of the data. So what I suggest, and I'm going to go through these real quickly, is per the source of the data, let's identify who the people are that make decisions associated with data that's in a specific source. Or even within a subject area, a lot of times I talk about a tactical level of Data Steward that I call a Data Domain Steward or Subject Matter Expert. So make a list of the different subject areas of data in your organization and then identify the people that most people go to to get decisions associated with that data. Maybe they're the ultimate decision maker, maybe they're not, but potentially those people would be the tactical Stewards associated with that subject area of data. You can do the same thing per system of data. Identify who the people are from IT or in the business areas that make decisions associated with the system of data. And basically as a practice within the organization, it should help these people to be accountable for the data that they know and that they work with. And that would mean accountable for not only the definition of the data, but the production and the usage of that data as well. Next slide. 12, please. One other thing that we need to do is we need to identify if there is a real need to look at data from an enterprise perspective. And in most organizations, they will say that there is that need. We don't want to stay siloed, which is the way a lot of organizations are presently. They want to view the data as something that's cross-business function, cross-organization rather than siloed within the business units. And the truth is if you know people in your organization that already have accountability for specific types of data, then those people should be the people that you recognize as being that tactical level of data steward. Now, one of the things that I hear from organizations is that nobody is accountable. Well, that typically wouldn't be true in most organizations. If you've built a data warehouse or if you've built a master data management solution or you do any data integration at all, somebody in the organization typically has some level of accountability for defining the data that's going to go into the data warehouse or going into the master data solution. Somebody has the responsibility for producing that data. Somebody has the responsibility for defining producing and for using that data in the data warehouse or the MDM solution. So the truth is it's very easy to kind of shy away from the term that nobody is accountable because typically in order for organizations to be successful in the investments that they make in the information technology part of the organization, somebody is accountable. And one of the things that we need to do is identify who those people are and we need to record information about who they are. So certainly if your management is thinking that nobody is accountable, what we need to do is use some concrete examples to demonstrate who is accountable for the data or at least who we go to when we have a question about the data. And then identify how decisions are being made, how they need to be made. You know, potentially these people that have a relationship to the data, those people are the data stewards of the data in your organization. Next slide, please. So when you look at the industry, the data management industry in general and you look for an industry standard definition for what a data steward is, I'm not certain that there is a single definition. I mean, you can go to the dictionary. You can go to freedictionary.com as I do quite a bit to get a very high level definition. And typically the definition of a steward is somebody that takes care of something or somebody else. And you can look it up. That's the definition. I've looked it up several times to make sure that that's still the definition that they're using. And really that's what we're trying to do is we're trying to identify the people in the organization that are taking care of the data as part of their everyday job. So the question becomes, should there be an industry standard? Whose responsibility would it be to come up with an industry definition of what a data steward is? Truly the definition of a data steward, whether you're taking an invasive approach or a non-invasive approach or a 2x4 or a command and control approach, the definition or the way that we define the data steward in the organization is truly specific to the organization. So let's talk a little bit about what are some of the things that we should consider when we're addressing how we approach identifying or recognizing people as data stewards. So the very first thing I want to do here is give you a definition of how I view a data steward. Slide 14, please. So who is a data steward? Basically, in the organization, so that's what I say, everybody's a data steward, get over it, but a steward can be anybody in the organization, whether they're business or technical driven, that defines, produces or uses data as part of their job. If we are going to hold them formally accountable for what they do with the data. So let me read that again real quickly here. A data steward can be anybody in the organization that does any of those things, defines, produces or uses data if you are going to hold them formally accountable for their relationship to the data. If they define, make sure they look for data first. If they produce, make sure they understand what they're producing. If they're using data, make sure that they understand the rules. So a data steward, basically the second definition that I have on slide 14 is a data steward is a person that defines, produces or uses data as part of their job and has a defined level of accountability for assuring quality in what they do with that data, defining, producing and using that data. So the truth is that that opens your program up to a lot more, or at least potentially a lot more people in your organization. Just to share with you a real quick anecdote with a client that I'm working with now that they're focusing on protecting personal information as really the end result, the goal for their data governance program. And they realize that everybody in the organization that uses that personally identifiable information needs to understand the rules associated with how they can share the data, how they can print the data, how they can ship it within branches of the organization. But basically they agreed that anybody who used the data needed to be held formally accountable for how they use the data. So to think about that, is that true in your organization? Are people that use PII data accountable and do we need to educate them? And I'm talking about educating them more than just a simple class or an orientation to the data when they join the company. We need to raise the level of awareness of people in the organization as to what their responsibility is based on their relationship to the data. And the usage of the data, the data usage relationship, is the easiest one to point at. If you use the data, you've got to protect it so we're going to give you the rules and we're going to hold you formally accountable for how you use PII data as an example. All right, next slide. Slide 15. A couple of other things that we need to focus on is when we're selecting data stewards is, you know, a lot of people think, well, who do the data stewards report to in the organization or what types of qualifications or what should we pay somebody who is the data steward? Well, you may or may not like what I'm saying on this slide here, but the truth is that the data stewards report to whoever they report to. You know, we don't need to have all the stewards in the organization to report up to the same part of the organization. Basically, a data steward doesn't even need to be called a data steward. If they have a relationship to the data, we need to help them to understand what impact their relationship to the data has on the rest of the organization. It really doesn't matter who they report to. We need to educate the masses. The qualifications or skills that are needed by a person, we don't necessarily need to look at those either because a person is going to be in the role that they are in in your organization based on their ability to be able to carry out that role. But in their carrying out that role, in their doing their basic daily job, they have a relationship to the data. And we need to, again, educate them on that relationship to the data and the importance of that relationship to the data. So we don't necessarily need to focus on what are the qualifications or skills needed by a person who's going to be a data steward. And again, that might not be the way that you typically look at things, but if you believe the idea that everybody's a data steward, qualifications or skills don't necessarily matter. Following the rules, the handling rules with the data and following process that is being governed is what really needs to be done. We don't really need to worry about qualifications or skills, and we really don't have to worry about their salary range. Basically, data stewards make what data stewards make. And they oftentimes, and in fact in most organizations, and in fact in every organization that I've ever worked with, stewards don't get paid extra for stewarding the data as part of their job. It's just part of what they do. They either define or produce or use or multiple of those the data as part of their everyday position. Next slide, please. Slide 16. So these people need to be held formally accountable for following the rules associated with their relationship to the data. So if they define the data and they're looking at new data versus existing data, they should understand and at least be engaged with the logical and physical data modelers in the organization. They should recognize that somewhere in the organization is the go-to place for that data, at least in most organizations. So we need to help them to recognize that there may already be a system of record for the data that they're defining and help them to understand that there is a business glossary or data dictionaries or metadata that is available to help them to research what data is already available in the organization. If they're a producer of data and part of their job, whether they are a key punch entry person or a person that works at a cash register in a store, I share often an example of a store where I go to often and that I was shopping around the Christmas holiday and this store usually would ask me my zip code. And I noticed that the person who was working in the cash register entered in the zip code of the store, not only for me but for the person before me, the person after me, that person is a producer of the data. So I'm a self-professed data geek. So I had to ask them, why don't you ask me what my zip code is if you're going to enter something in? And his response was that my supervisor told me that that wasn't important. Well, the fact is all the data that was reported back to that company's headquarters had all the people, well, if all of the people running the cash registers were following the same rule, every person that shopped in that store came from the same zip code of the store. No, those people that produced the data need to be held formally accountable for how they produced the data and for understanding what they do around how they produced the data. So that can be data that comes from the inside, whether it's something that they're entering or from one source to another within an organization. It certainly makes sense to have people follow data production rules for data that they're bringing from the outside. Are we balancing those records? Are we checking to make sure that the data is valid? Are we looking for missing data? Certainly the people that are producing data or responsible for producing data from the outside need to follow the rules associated with bringing data into the organization. And I already talked quickly about the usage rules. I mean, there's business rules for how data can be used. There's classification and protection rules around the data. That's a big hot topic around data governance is protecting the data that needs to be protected and classifying that data as such that we define handling rules associated with the classification of the data. Certainly the usage rules include compliance and regulatory rules as well. So you can see from this slide that if somebody defines data as part of their job or they produce data as part of their job or even if they just use data as part of their job, they are a steward of data. They need to understand how their relationship to the data impacts the organization and potentially puts the organization at risk as well. Next slide, 17. So years ago, I wrote an article in the TDN publication called Signers Rules for Becoming a Data Steward. And I actually wrote those to be somewhat controversial. The problem was that everybody that read the article came back to me and said, you know what, I agree with you. These are things that we need to do in order to fully implement stewardship, the stewarding aspect of data governance across the organization. So the first rule is, as I've said many times, a data steward can be anybody as long as they have that relationship to the data. Being a steward describes a relationship to the data. A steward is not hired to be a steward. They don't even need to be called data steward. You know, a data steward typically doesn't have to be told how to do their job as long as they understand the handling rules associated with the processes that are in place for managing that data. So we don't necessarily need to tell a data steward how to do their job. Public or industry organizations that are certifying data stewards. So I am nothing against these organizations, but the way I think is that public or industry data steward certification is a load of bunk. If you're going to certify your steward internally within your organization, I'm all for that, but sending them outside to teach them how to do their job, to teach them about their relationship to the data, is not necessary in a lot of organizations. Another thing in the designer's rules for becoming a data steward is there's more than one data steward for each type of data, and the data steward training should be focused on formalizing accountability rather than handing the accountability to somebody as something that's brand new to them. Next slide, please. So the rules for becoming a data steward, the ones that I just shared with you on the prior slide, you may agree with all of them, you may agree with none of them. In fact, I've had people tell me that if everybody is a data steward, it's a nobody or a nothing approach, and you got to laugh at that a little bit. It's actually the other side. It's the do everybody approach. Everybody in the organization that defines, produces, and uses data needs to be held formally accountable for that relationship to the data. I know I said that many times, but it's really very much worth repeating that people in organizations need to understand that their relationship to the data is extremely important to the value and the quality of that data in the organization. So if everybody's a data steward, what incentive is there for people to become a data steward? So that's not a question that I've had many times before, but really that whole idea of incentive to become a data steward, the question that I got, that question, was based on the article that's in this month's issue of TDAN. Basically, I'm telling people to get over the fact that everybody is a data steward. And they were asking the question of, how do you distribute the carrots to the people? And the fact is that if your senior leadership supports sponsor and even most importantly, understand what data governance is and how you're implementing it, there's really no need for carrots. There's no need for incentive. And in fact, people in the organization that are stewards of the data, that use data that's sensitive, should not be given the opportunity to opt out. So the fact is that this relationship, this idea of incentive to be a data steward, you want them to be incentive to participate in projects, even to define data, they need to be involved in those conversations. If they use the data, they have to protect the data. They can't say, no, I'm not going to protect the data. So it really kind of even eliminates the need for that incentive. There's really no need for carrots, but it's really based on getting senior leadership to support sponsor and most importantly, understand what we're doing with data governance. We're basically helping everybody understand what their role is associated with the data. So basically, the levels of data steward are based on people's relationship to the data. Next slide. We're on slide 20 now. So let's talk about different types of stewards within the organization. I've talked a little bit about the fact they're definers, producers, and users of data. We know that. I've even challenged people on these webinars and in person to come up with another role that people have with data. They either define the data or produce it or use it or do multiple of those things. I'm not sure that there's a fourth category there. So the operational data stewards, the people that day to day are doing their jobs, they're defining producing and using data as part of their job. And I call those folks operational data stewards. The job of the data governance program is to educate them and make them aware of the importance of their relationship to the data and help them to improve on that relationship to the data and improve the quality and value of data across the organization. So there's operational data stewards, but then there's also tactical data stewards. And these are a role that I call data domain stewards. A domain being a subject area of data. People that have certain levels of accountability or knowledge about, we know that we go to Wendy because Wendy knows everything about customer data. Or we know we go to Bob because Bob knows everything about product data. So domain stewards may already exist in your organization. They may be held accountable for making decisions. They may not. In the cases of where a domain steward is not the go-to person, does not make the final decision, that's why we have data governance councils in place. So we can escalate issues that cannot be resolved at the tactical layer, and we can resolve them by escalating them up to the strategic layer, which would be the data governance council, which I'll talk a little bit more about in a second here. So these data domain stewards, they're enterprise data stewards. I've heard them called that. I've heard them called subject matter experts. There's also a role for people to coordinate the activities of stewards. You know, one of the things that I try to stay away from is the term ownership, because the organization owns the data, and not necessarily any individual. But there are some organizations that may call these tactical data stewards information owners. Next slide, please. So if you have participated in these webinars before, you may be familiar with the pyramid diagram that I'm sharing with you on the screen now. I'd love to be able to point at certain things, but due to technical problems right now, I can't point at them and have you see them. But I'm going to talk through this relatively quickly. In the red area, in the red square on page 21, those are the two levels of stewards that we're talking about. We're talking about operational stewards at the lowest part of the pyramid, and then the tactical stewards, which are at the central part of this pyramid. The tactical level of responsibility is the most difficult piece to fill in most organizations. Those people that have responsibility for breaking down silos are typically tactical level stewards. They're data domain stewards. They have knowledge about a subject area. And again, now if you look on the far right of the pyramid, there is an arrow that goes from bottom to top. And so if we can't resolve something at the operational level, we escalate it to the tactical level. It's the people at the tactical level at those domain stewards don't have the authority to make decisions. We escalate it up to the strategic level, which is the Data Governance Council. So the first thing that I really want to get across is that in your organization, because that's for the fact that almost everybody can be an operational steward, that this other level of stewards are extremely important. The tactical level of these data domain stewards become critical in solving data problems across the organization. So let's go to the next slide, please. Slide 22, recognizing different types of stewards. So the operational data stewards, they basically work in a business or technical unit. They have hands-on knowledge of the data that they use and that's used in their part of the organization, basically just through their job. And through their job, they define produce and use data that's associated with whatever their function is in the organization. So what we need to do with all of these operational data stewards is raise their level of awareness and raise their understanding of the impacts that they have on the usage of data in the organization and the ability to be able to make decisions from quality data within the organization. So let's not talk about the everybody that's a data steward for a minute. Let's kind of jump into the next slide, slide 23, which is let's talk about the data domain stewards. And those are the people that are at the tactical level of that pyramid that I just shared with you. So yes, they work in a specific business unit or a technical unit of the organization. They have hands-on expertise of the data, but these people are potentially recognized as the go-to people for these different subjects of data. They're potentially recognized as the subject matter experts. In some organizations, a couple of different universities that I did work with, they had defined in their data policy people that were data trustees, people that had responsibility for certain subject areas of data. So for example, the registrar was responsible for student data. The VP of HR was responsible for HR data, but in the policy, it defined these people as data trustees. In that organization, in order to be non-invasive, we didn't call them data domain stewards at the tactical level. They were basically the trustees of the data in the organization. They were the ones that were looking at data as a cross-organizational asset. These people have the responsibility for facilitating resolution of issues pertaining to the domain that they are associated with. And as I mentioned a little bit ago, they may or may not have the decision-making authority for that domain of data. If they don't have decision-making authority, that's where the data governance council comes into play. And typically issues that can't be resolved at the tactical level get escalated to the strategic level, which is where the data governance council resides, at least in my operating model of roles and responsibilities. Data steward coordinators are also at the tactical level, but they don't play the same role as the data domain stewards. Typically, the data steward coordinators are people that work within a business unit, but they know who the people are in the organization, in their part of the organization that are stewards of the data. And they play a role in helping to communicate effectively with people in their part of the organization. So they're kind of like the point person for discussion around data issues associated with the different data that's used in that function or that part of the organization. So this next slide, let's go to slide 25, is what I call the common data matrix. And I've shared this in several other webinars in the past, and it's a tool that's quite handy for most organizations. Down the left-hand side of that matrix is where we identify people that are the domain stewards, the subject matter experts, the data trustees of the different subject matters of data. But across the rest of the common data matrix, we're identifying people in IT and in different business units that also are definers, producers, and users of a specific subject area of data within a certain system in the organization. So again, based on their relationship to the data, they need to be held formally accountable for that relationship. So the common data matrix, and it's something that we share at the end of all the webinars, so certainly there will be a link to a common data matrix coming from this webinar. But it is an instrumental tool in understanding who in the organization does what with data and helping you to identify the everybody in your organization that we need to communicate with and raise their level of awareness. So in this version of the common data matrix, let's move to slide 26, I highlight for you in green on the left-hand side, that's where the data domain stewards reside in the common data matrix. And in the red box that goes across, that's where the operational data stewards are. Except for maybe information technology, they may have a different perspective on the data, but if we eliminate the use of the data subject matter experts and the system subject matter experts from IT, we're making a big mistake. They may not have the same steward level responsibilities as those people within the business units, but they have some level of accountability for their relationship to the data as well. And if they are users of the data, then we need, again, to educate them as well on why the way that they produce the data or the way that they use the data is important to the organization. So next slide, please. I just superimposed the operating model, the pyramid diagram over the common data matrix, and the reason I did that is because I like to kind of color coordinate the two. So where you see the pinkish color in the operating model, you can see that where those people are in the common data matrix, the tactical level rules are in yellow, and they're in yellow on the common data matrix. The operational stewards are also displayed also in the common data matrix. So it's really a good idea for us to inventory what data we use or is being used by what people across the organization and then either at least identify who the domain stewards are, but let's certainly identify who the people are that day-to-day have the responsibility of defining, producing, and using the data. Next slide, please. Slide 28, the responsibilities of the operational data stewards. So I shared some with you about the tactical level. These people are the ones that define the data that's going to be used by their organization or produce the data or use the data, and all of those people are responsible for the integrity of data usage across the organization. Slide 29, please. So what additional responsibilities of everybody or additional responsibilities of the operational data stewards? Well, first of all, they're responsible for following the rules associated with the data that they define, produce, or use. That's assuming that you have rules associated with defining, producing, and using data. And if you don't, that's another good place to start your data governance program is to produce those rules that need to be followed, because once you've done your inventory, we will then have something to educate the people on what are the rules that they need to follow. And the truth is, at the end of the day, at the end of the year, if we don't even use the term data governance to describe people's involvement, that's even all the better. We don't need to point at data governance and say data governance is the reason why we're doing these things. Again, when it comes to data usage, the rules are pretty much self-explanatory. You protect certain data certain ways, and you're going to do it as part of your job and you're going to be held accountable for that. So if you're producing, creating, updating, deleting, archiving data that needs to be managed in the organization, you are an operational data steward. We may not call you an operational data steward. Somebody may not go over to you and tap you on the shoulder and say, hey, you're a data steward, but because of your relationship to the data, we as the data governance practitioners are going to make darn certain that you understand the rules associated with whatever your relationship to the data is. So they're responsible for the integrity and the quality of the data that's created and updated in their part of the organization. They support and share knowledge with other data stewards. These last two bullets on this slide are extremely important. They have the responsibility of communicating new or changed business requirements and communicating concerns and issues and problems with the data to people that can influence change over the data in the organization. So the day-to-day data stewards, we need to educate them on what their responsibility is. We need to educate them on their relationship to the data and what that means and what they must do to help formally accountable. But these are some additional responsibilities of everybody in the organization, basically the operational data stewards in the organization. And pardon me, I'm calling from my personal line and somebody's beeping in. That may be the noise you hear. The last slide that I have on the responsibilities of the operational data stewards is basically one that I really like to take away from this webinar. A operational data steward is responsible for doing what is expected of them in their job while being found formally accountable for how they do it when it comes to the data. So basically it's, again, taking everybody in the organization and educating them on their relationship to the data, why it's important, how it's important, how we're going to help them formally accountable. So it basically begs the question of, well, what does it mean to hold somebody formally accountable and that really becomes the job of the data governance program, is we need to find a way to educate them to raise their level of awareness and make sure that they understand what their responsibilities are based on their relationship to the data. Slide 31, please. Responsibilities of the data domain steward is they're responsible for the enterprise management of a domain of data. Typically they're identified by a position, but oftentimes in organizations that have certain types of cultures, it may not necessarily be a position, but it may be a person that we go to. And so it may not necessarily be a position. It's a person that we go to who is a part of a single business unit or a function, but when they're playing the role of the data domain steward, their affiliation to their business unit basically becomes secondary because they're looking at the data across business units and that's at that tactical level that I said was the most difficult to fill in organizations. So they may or may not be the authority. It really depends on their position within the organization. They have the responsibility for escalating issues to the strategic level. I mentioned that before, documenting the classification rules, the compliance rules, or making certain that they are documented so that they can be shared. They also make certain that the rules are communicated to all of the people in the organization that are going to be impacted. They may do that or they may delegate that as well. But once we've documented the rules associated with definition, production, and usage of data, and oftentimes it's the data domain stewards that are involved in documenting those rules, we need to make people in the organization aware of those rules and how they're going to be held accountable for following the rules. These people also participate in tactical work groups with other domain stewards and other people in the organization, and typically those are for finite periods of time to address specific issues. Fine, please. So what are the responsibilities? We're on slide 33. We're getting to the end of the presentation. The responsibilities of the data steward coordinators are such that they really act as the point communication persons for distributing rules, act as the point communication person for their business units. They basically act as the point communication in the common data matrix as we are getting the data stewards of the organization to be held formally accountable for their relationship to the data. Slide 34, additional responsibilities of the data steward coordinator. They may be participating early in the program to help you to identify and fill in the information that's on the common data matrix. So identify operational data stewards per their domain. Typically they are part of the organization, part of their business unit. Oftentimes they work with the domain stewards, and they're not necessarily in a position of responsibility where they're making decisions, but they are vital to the fact that we coordinate the activities of the data stewards in the organization. Next slide, 35. So there's a couple pieces of the operating model diagram that I did not talk about yet, and those are highlighted within the red squares. The data governance team, the data governance partners. Now these are people that typically already exist within an organization. And when we look on the right-hand side, the senior leadership team at the executive level or the data governance council, since we're really talking about data steward roles and data steward definition, I wanted to share with you an idea that we need to have people at the strategic and the executive level supporting our programs. We need to have people at the support level who are facilitating the program, and then there's the role of the data governance partners. And those could be people from regulatory compliance from project management, from information security, information technology. They basically are putting governance, aspects of governance in place. We need to work with them hand-in-hand and become partners of theirs if we are going to implement governance successfully across the organization. So one more picture of the operating model kind of transformed into a cube, almost a cube I guess, but the usage of the cube to define the operating model basically has the element of time added to it. Let's go to the next slide so we can look at this a little bit bigger. In the early phases of the program, during the project phase, the emphasis is on the executive and strategic layer, but the de-emphasis or the lack of emphasis is on the operational level. Well, when we get into the program part of implementing data governance, it's exactly the opposite. The operational side is where the focus is, everybody's a data steward, and we only utilize the executive or strategic piece of the organization to resolve issues that have been escalated to that area. So let's move on to slide 38, just a repeat of the common data matrix. It's something that's very important for you to catalog and inventory the data that is important to your organization and to help you to identify who the everybody's are in your organization that are stewards of data. And Bob, I just want to give a note on time. I know we started late, but we have been recording now for 50 minutes, so I just want to make sure we... I appreciate people staying on the line and hanging in there as we started late, and we will keep it going a little bit so we can get to a bit of a Q&A. So, thanks. I went through some of those slides quickly, but thank you for that. So the last thing that I really want to talk about is something that could make or break your data governance program in regards to your data stewards. Get leadership to concur. Get them to agree that everybody in the organization that uses data is accountable for how they use the data. And it's interesting because senior leadership to a person oftentimes thinks that this is already given in the organization. Data governance is not optional. We don't need to care it. We don't need the incentive. The data must be protected. So we are going to educate you, and we are going to hold you accountable for how you use data. That's pretty much a no-brainer for most organizations. They're not going to say just a handful of people are data stewards. Everybody is a data steward. Slide 40, please. Get leadership to concur that everybody who produces data must be held accountable. So the quality of the data for understanding the impact of the data, for gathering all the data that's necessary to make the appropriate decisions in an organization. So again, if we can get leadership to concur, that people who produce data have a level of accountability, too. That's a darn good thing for your program. Get leadership to agree that people that have the responsibility for these major projects, these major investments, that they should look to see what data already exists before they define new data. So we need to get senior leadership to concur that everybody who defines data must be held accountable for following procedures, for putting together sound business definitions rather than cheeseburger definitions, cheeseburger with cheese. Patient account is the account of a patient. We need to have sound business definitions. And also, we need to make certain that people who are defining the data are responsible and accountable for recording the metadata about the data. So in this webinar that we've had all sorts of technical difficulties, we discussed several things. We discussed the approach to defining stewards and stewardship, how to select stewardship. Identify, there's the assign, there's the recognize, there's the hire. Different ways, different approaches for selecting stewards. Different levels of stewards. We talked about operational and tactical stewards. I shared with you an operating model of data governance roles that can basically be molded to fit any culture in any organization. And we talked about why the approach to defining data governance this way can basically make or break your data governance program. So before we turn it over to Shannon here real quickly for the Q&A, I appreciate you're staying on the line with us. Just a quick reminder of the August webinar, which is going to be mastering and master data governance. And I look forward to having you there. So with that, I'd like to turn it back over to Shannon for the Q&A. Thanks, Bob. We've just got five minutes left in the hour. And again, I apologize for the technical difficulties. Bob lost his internet connection completely and I was trying to keep up on the slide changes along with answering questions from the attendees. So, but let's jump into the Q&A. And just a reminder, I will send a follow-up email within two business days with links to the slides, links to the recording of the session and anything else requested throughout the webinar. So what is the company's decision process is via committee? Would it be a steward committee? If the process is by... I guess it would be a committee of stewards. Call it a steward committee. Typically, the people that you're going to pull into a room to make a decision by group. And I've seen a lot of organizations that are consensus-driven organizations. Typically, those people are going to have some level of responsibility for the data. So I guess, yes, you could call it a data steward committee, but basically, it's... if there is such a thing, it's a task with the responsibility of making the decision. All right. And have you ever run into a place where too many people consider themselves accountable? However, view the data in different ways. How do you deal with weeding out who's ultimately actually accountable? Okay, so I'm guessing that we're talking about the tactical level with people that have responsibility or accountability for a specific subject area of data and not just accountable for doing their job associated with the data. And so typically in an organization where there would be more than one person that has the accountability to make the decision, if they cannot come to an agreement, that is where the Data Governance Council comes into play. If you recall in the pyramid diagram, there's an escalation area along the right-hand side so that if we can't resolve it from those multiple people who have different views, we can't just agree to disagree and go on our merry way. We need to have an escalation path. And that escalation path is typically to the Data Governance Council, which they have brought all the information from all the different people that are having the hard time making decisions and it's ultimately their responsibility for making that decision. Perfect. I think we've got time for one more question here. So where do ETL developers fit into this? I'm sorry. Say that one more time. Where do ETL developers fit into this? That's a great question. ETL developers, in my opinion, have some level of responsibility for data production. So they're taking data from disparate sources often and moving that data into a consolidated, singular view of the data. And so because of that, there are some decisions that need to be made during the ETL process. So really what they're doing is they're producing new data from old data, and it becomes their responsibility. So I would put the ETL developers in the Data Definer role, which is an operational data steward, and give them the responsibility for making certain that they're producing the data properly and that they're documenting how the data is being produced. But certainly the ETL developers belong in an operational role as operational data stewards, as data definers. Alrighty. Well, I'm afraid that is all the time we have for today. Bob, thank you so much for working around the loss of your internet connection. I think we managed to keep up fairly well in between. And thanks to all of our attendees for being so patient with the technical issues technology. It's so great when it works and such a challenge when it doesn't. And so as a reminder, I will be getting out of links to the recording, links to the slides of this webinar by end of day Monday and of course links to the matrices that Bob was displaying as well. So you can have all of those, and I'll be sending that to all residents. Bob, thank you so much. I hope you get your internet working up and working again and appreciate the time and thanks to all of our attendees. Hope everyone has a great day. Thank you very much. Take care, everybody.