 Hello and look, my name is Shannon Kemp and I'm the Executive Editor of Data Diversity. We'd like to thank you for joining the current 2015 installment of the Monthly Data Diversity Webinar Series, Real World Data Governance with Bob Siner. Today, Bob will be discussing build your own data governance tools. Just a couple of points to get us started. Due to the large number of people that attend these sessions, you will be muted during the webinar. For questions, we'll be collecting them via the Q&A in the bottom right-hand corner of your screen. Or if you'd like to tweet, we encourage you to share highlights or questions via Twitter using hashtag RWDG, Real World Data Governance. As always, we will send a follow-up email within two business days containing links to the slides, the recording of this session, and additional information requested throughout the webinar. Now let me introduce to you our speaker for today, Bob Siner. Bob is the President and Principal of KIK Consulting and Educational Services and the Publisher of the Data Administration Newsletter, TDAN.com. Bob has been a recipient of the Damon Professional Award for a significant and demonstrable contribution to the data management industry. Bob specializes in non-invasive data governance, data stewardship, and metadata management solutions. And with that, I will give the floor to Bob to get today's webinar started. Hello and welcome. Thank you very much, Shannon, and welcome everybody. Good afternoon. Good morning. Good evening, depending on where you are. Thank you very much for attending this installment of the Real World Data Governance hearing. And as Shannon mentioned, this one is called Build Your Own Data Governance Tools. One of the questions, I get asked a lot of questions about data governance, but one of the questions that I get asked so often or very often is, what are the appropriate tools for me to use to help to enable my data governance program to be more and more successful in my organization? And I will tell you, there's a lot of tools on the market. There's more tools every day that are introducing themselves as being data governance tools or being metadata tools. And it's very difficult in some organizations to get the funding in order to purchase a product. And a lot of these tools that are on the market will go a great way. We'll offer great things to your initiative. And I'm not going to tell you that you shouldn't look at the tools because there are some terrific tools out there. But a lot of organizations have been asking, are there things that we can get started doing prior to purchasing a tool? Things that we can do to help us to build our requirements as to what tools we are going to need. And over the years, I've been developing, I've been building my own data governance tools using the tools that are readily available to people within their organization. And I thought I made a chance to have a webinar on building your own data governance tools because if I can help you to get started and I can help you to build some of the things that are going to be necessary to move your program forward, that's certainly one of the goals of this webinar series. So thank you again for attending. I hope you'll find a lot of this information to be relevant and helpful to you. And I'm looking for feedback and comments from people all the time on whether or not these products, these tools, make sense for implementation in your organization. Before I get started, I wanted to share a couple of quick things with you. One is, as Shannon mentioned, this is a regular webinar series, and I wanted to put some information out there about the webinar that's going to take place in June, and this session is called Everybody is a Data Steward, Get Over It. And it's a really interesting session, and those stewardship webinars are very popular, and it's very much of a different take on things for organizations, a lot of organizations. Take a handful of people and say they're the data stewards. Think of the fact that everybody in the organization may be a data steward. That's going to add some complexity to our implementation. And some of the tools that I'm going to share with you in today's session will help you to record and know who the stewards are across the organization. So if you bear with me, I'm going to get to a point where I'm going to share with you a bunch of tools that you can create yourself. We'll talk about the steps that are necessary to create those tools, and then implement them within the organization. So I always love sharing this information, and hopefully you'll find a lot of valuable information in this webinar. Also, before I get started, I wanted to point out a couple of things as Shannon had mentioned. I focused on something that is called non-invasive data governance. It's just published a book back in September. So please, if you get a chance to take a look at the book, a lot of these tools are things I'm going to share with you in this webinar. Some more details of those tools are available through the book. Also, if you're interested in more information about non-invasive data governance, please go to the kik.com.com website. And also, as usual, I speak at a lot of events. I speak at a lot of data-versity events. I want to make you aware of an event that is actually just a few weeks away at this point in early June. The Data Governance Information Quality Conference on this slide here, you can see a couple of the presentations that I will be giving. I hope you will join us there. I hope you will join us also in future webinars. I also start out my sessions often by sharing with you the abstract that was used to promote this session. I just want to talk to a couple of points in there really quickly too. As I mentioned before, there are a lot of tools that are available to assist your organization. And the value from those tools is proven time and again from organizations that are using these tools to deliver successful data governance programs. But the truth is that oftentimes in order to even get to the point where we have the ability to start looking at tools, we need to define some really important requirements as to what are we looking for these tools to do, how are we looking for them to operate, what type of information will we capture in those tools. And before we even have the chance to be able to go outside and look at it and put out RFPs and evaluate tools and products, it's often good trust to be able to develop some of these things internally first and then make the case for why these tools that we would purchase would be better off than the ones that we're creating internally. So I'm going to share with you a bunch of them. I hope that, as I said before, I hope that a lot of them will be very valuable to you. So in this webinar, what we're going to do is we're going to talk about a couple of different things. We're going to talk about tools that are going to be able to help you formalize accountability for governing data for reporting critical metadata about your data governance program. And I've mentioned before that one of the five products of creating a data governance program is the metadata that comes from creating those programs. We're going to share with you some matrices and tools that talk about applying governance to existing or new processes. We're going to talk about providing necessary awareness, communication in the organization, and then also tools about building and improving data understanding. So without further ado, we're going to jump right into it. The first thing I do, again, also is I share a definition of data governance and non-invasive data governance. So when I talk about non-invasive data governance, one of my points is that there is typically governance taking place in your organization. It may be very informal. It may be very inefficient and ineffective. If you want to formalize these things, if you want to hold people formally accountable, number one, we've got to know who these folks are. We've got to know where they are in the organization. We've got to know what data they use. We've got to know when we want to get them engaged. All of these things are really necessary to be successful with data governance programs. So the definition that I use for non-invasive data governance is the practice of applying that formal accountability of behavior through roles and responsibilities that would be considered less threatening or less invasive, and I call it non-invasive, to the organization. And we're going to apply governance to existing processes or if we're creating new processes, we're going to apply governance to that or to those processes. The fact is a lot of organizations found or a lot of those organizations will focus on trying to formalize things that are already in place rather than trying to create all new roles and responsibilities for people. And we're shooting to assure that the definition of structure of usage of data assures those things, regulatory, compliance, security, privacy. Again, the goal of non-invasive data governance is to be transparent to the organization, to be supportive, and to be collaborative as well. So that's the definition that I use for data governance. There are a lot of definitions that are out there. The straight definition of data governance is that it's the execution and enforcement of authority over the management of data. And the fact is that at the end of the day, no matter how you define data governance, we need to be able to execute it in the force of authority. And some of these tools that I'm going to share with you today will take you a great distance towards being able to do those types of things in your organization. So what types of tools are we going to talk about? We're going to talk about tools that are associated with primarily these four things in the organization. We're going to focus on tools that focus on formalizing roles and responsibility, formalizing the accountability for data, formalizing processes and awareness. And the fact is that you're going to have to address all four of those things that you're putting a data governance program into place. So it makes sense to start with tools and templates and things like that that will help you to do all these things, to formalize roles, to formalize accountability, and so on. So you may as well find a way to formally record this information. And hopefully some of these tools, excuse me, will help you to do just that. So one of the first things that I want to share with you is this idea of having a data governance policy. So I don't necessarily call this a tool of data governance, but for a lot of organizations, they've come back to me and they've said, this is a tool. If we can use some core principles around data governance and we can share those with people in the organization, it does become a tool for greater success within the organization. And on this slide, down the middle of the slide, I highlight four important principles of data governance. First one is that data must be recognized as a value and strategic asset of the organization. In order to manage data as a value and strategic asset, we need that asset of the organization. We need to make certain that we have as much information as we can gather that's relevant to people within the organization. But we need to manage it. It's very difficult to manage any of the assets that you have if you don't have information about those assets. So the metadata about the data that we collected and that we share with people in the organization becomes a big part of governing data as a strategic value asset of the organization. The second principle is data must have clearly defined accountability. So we need to make certain that we know who in the organization has responsibility for defining data, for producing data, and for using data. Not only do we need to identify who those people are, but we need to record that information. We need to put it somewhere that we can use that information. So for example, if there's a change to a specific piece of data, if there's a change to a calculation for a primary or a key piece of information that we use, we need to know who, if we change that definition, is going to be impacted by that. So I'm going to share with you a tool that we can use to not only identify the people that define produce and use data across the organization, but we also want to make certain that we can help them to understand that just by the mere fact that they have that relationship with the data, there's a binder or a producer or a user that they understand what accountability comes with being a definer, producer or user of the data. And data must be managed to follow eternal and external rules and regulations. Organizations are not coming to us as saying the federal government and industry-specific organizations are not coming to us and presenting to us regulatory compliance and protection and security needs and saying, well, cover these if you want. They're coming to us and saying, we have to manage our data to follow both the internal and the external rules and regulations that are being shared with us. And then data quality must be defined and managed consistently across the lifecycle. And these tools that I'm going to share again will help you to be able to manage the data governance initiative that managed the data governance discipline effectively and consistently across the data lifecycle. So I've got a lot of information that I'm going to share with you. And this is like a larger view of the center section of that slide. If we can get our management to buy off on the fact that data governance or that data itself is a value in the strategic enterprise asset and we can get them to agree that we need to hold everybody who touches that data, whether it's, again, as a final producer or user, we need to hold them accountable for their relationship with the data. That, again, becomes one of the core principles and if we can get management to commit to that, that helps to take us a long way towards having a successful data governance initiative. Data must be managed to follow the rules. I spoke about that and there are lots of rules. I worked with an organization recently that was focusing on personal information, personal health information, the PII and PHI. And again, organizations are not coming to us and saying, follow these rules if you want. We need to record these rules. We need to communicate these rules with people across the organization and do that effectively. And then how to do it consistently across the organization that becomes a big piece of it as well. So again, I'm going to continue on here and I'm going to share with you tools that will help you to address each of these different areas. So the first tool that I want to share with you is the operating model of roles and responsibilities. And so I've shared this in the past and I've done webinars on the operating model of roles and responsibilities. These go out to the dataversity in search for those if you're interested in learning more about the roles and responsibilities I'm going to talk about here. We need to be able to formalize these roles. We need to be able to engage these people. We need to be able to communicate effectively with these people. So we want to make sure that whatever tools that we're putting in place are going to do those things. They're going to formalize roles. They're going to engage people and they can be used to communicate effectively. And the one thing that we really need to remember is that at least in most organizations, to every organization that I've ever worked with, there have been existing levels of governance already taking place in the organization. So by creating these templates and tools to be able to collect this information, it helps you to formalize the existing levels of governance. If you've got an information security program, if you've got a compliance program, regulatory compliance, if you've got security and privacy concerns, oftentimes in organizations they're already doing those things. And those are a certain level of governance. So in fact, I was just mentioning to somebody earlier this week that if you have those types of initiatives underway in your organization, and most organizations do, it's very easy then to be able to identify who's using what data. And we need to record that information. So again, if there's a change to some of the data in the organization, that we can identify all of those people with the organization that are being impacted and help them to understand what they're going to have on them and their position. If you're not adhesive in your approach, the operating model is in the form of a pyramid, which I'll share with you in a second, and there's arrows on it and things. I'm going to explain all of those things here just to let you know that there are easy ways to go about implementing roles and responsibilities around data governance in your organization. So since this is a build your own data governance tool webinar, let's walk through the steps that are necessary to create this operating model. And the first thing that I suggest to organizations is that they identify at what levels of the organization do we need to have governance in place. And in a lot of organizations, they're set up the way that is demonstrated to you on the screen in front of you right now. There's an executive level. There's a strategic level, a tactical and operational. We've got partners that do the business and we've got a team of people that have the responsibility to have governance in place. So if we understand that there's roles associated with each of these different bubbles in the middle of the block, the middle of the slide, then it helps us to say, okay, we need to define exactly what we expect out of executives. We need to define exactly what we expect out of the strategic layer, the tactical layer, and the operational layer. Now, some organizations have looked at the model I'm going to share and they said, well, you've got so many different layers. There are organizational levels that you're trying to address, but they think it becomes confusing or difficult to manage. I've seen organizations take the model I'm going to share and break it from three basic layers, those basic basic layers being operational, tactical, and strategic, and break it into 10 layers. And think about this. If you try to over define your roles and responsibilities associated with the data governance program, you're going to be spending a lot of time explaining to people what the difference is between one layer and another layer. So this session itself is not focused on the different roles and responsibilities of the operating model. It's more on helping you to build a tool that will help you to communicate to people in the organization what levels of the organization need to be engaged when it comes to data governance. So another aspect of the noninvasive data governance approach is that rather than assigning people into roles, because that's pretty invasive when somebody's already working 40 hours a week, 50 hours a week, 60 hours a week, you can come to them and say that we're going to also make you a data steward and you're going to have all these additional responsibilities, but then we really shouldn't be surprised when people push back because they're already busy. And if we go to them and say, we're going to give you more work to do, but we're not going to give you more time to do it, no wonder. I would push back as well. But what we're going to do, rather than assigning people as stewards, the term that I used for a long time was we're going to identify people into roles. And then I worked for a U.S. government organization that suggested to me that we use the term recognize people into roles. There's a positive connotation that comes with recognizing people for what they do, recognizing people for their relationship to the data, and then helping them to govern the data as a valued strategic asset for the organization. In the model, I'm going to emphasize the space in the chart. I'm going to talk about the colors that are associated with the escalation path and the communications path as well. But that's the first thing that you need to do is understand what parts of the organization, what levels of the organization need to be engaged. Well, typically the executive level is going to be engaged a lot less than people at the operational level. And in fact, oftentimes for organizations, they spend a lot of their time focusing on the tactical and the strategic layers of this operating model. So the first thing that we wanted to do is, again, identify with the different levels of the organization that we need to embrace as part of our governance program. And this pyramid diagram in front of you now is the operating model of roles and responsibilities. It's really funny, the reaction that I get from people when they see this model, the first thing that they say is, wow, that's really bureaucratic. You know, we need to build all these things that's going to be very difficult. That's why I added those things on the far outer peripherals of this model. For instance, you've already got senior leadership. You've not already got people in your organization that are defining, producing and using data as part of their job. That's not the operational level. They already exist. If we may already have subject matter experts around specific subject matters of data. So that's kind of the tactical layer where folks are subject matter experts for different domains, for different subject matters of data. I typically refer to those people as domain stewards. And then everybody seems to be talking about the data governance council or the data governance steering committee. We also need a strategic layer in the organization to resolve issues that could not be resolved at the tactical layer. So if you look very closely at this diagram, and as Shannon said, we'll be glad to send these to you after the webinar is over, if you want a larger version of it. But if you look within the space of the triangle itself, at the bottom layer, it says to the operational level that those roles are very business unit specific. And then the tactical levels, that's why we're trying to break through some of the silos that have been created in our organization. The tactical level is to cross business unit level. And then the strategic is the individuals that have been assigned at the highest level of the organization to make sure that we're, again, focusing on data as an enterprise asset. And the reason why I mentioned on the previous slide that the amount of space within each of those levels has a specific meaning to it is because in a lot of organizations, they want to push as much of the decision base down to the lowest part of the organization. So if it's an issue that needs to be resolved pertaining to each specific individual business unit, we want to be able to allow that decision to be made within that business unit. However, if it's going to touch on other parts of the organization, that's where the tactical level gets involved. That's where the cross business unit, the data bill gains towards enterprise data stewards get involved. And then at the top level there, it would get the pyramid itself as the council. And if you look along the right-hand side of the diagram, you'll see that there's an escalation or an approval path. So if we can't resolve things at the operational level, oftentimes they get escalated up to the tactical level if the people who are our data domain stewards or our enterprise data stewards don't have the authority to be able to make decisions, oftentimes then it's escalated up to that strategic level. And that's one of the responsibilities of the data governance council. If you notice at the very top part of this diagram, the senior leadership or the executive level, there is no space within that tower that is kicking out of the top of the diagram. That's because typically we don't escalate data issues. If you notice, the escalation path only goes as far as the data governance council because that group is typically the one that is empowered to solving issues that can't be solved at any other level of the organization. We don't take data issues at least typically. And again, depending on the size of your organization, we don't typically take data issues up to the executive level of the organization. If you look along the left-hand side of the diagram, there are two sidebars that I refer to. The sidebars, we've got the data governance team or those individuals in your organization that have responsibility for putting the program in place. But then there's also another sidebar, which is what I call our data governance partners. In years gone by, I have talked about the need to have these partners. And oftentimes it was IT that was one of the partners. But what I've found is that not only are the folks in IT partners, but also the folks in project management, the folks in regulatory and compliance are also partners of the data governance program. And if you notice, right next to those, you also have the word exist. So those folks, the regulatory and compliance, the project management in IT, they already exist within the organization. So if we could take this model and we could overlay it over existing roles and responsibilities in our organization, it becomes a lot more valuable than having to assign people into roles. This is a very easy visual to share with folks, and it really goes a great way towards helping them to understand what roles and responsibilities are going to be necessary when we're putting a governance program in place. And the arrows are important. The amount of space in each of the levels are important. Communications have to take place from the executive layer all the way down to the operational level. So again, this operating model is a tool that you can use, and my suggestion is don't try to plug your organization into this model. Overlay this model over your organization. Identify who's already stewarding data at the operational level. Who our subject matter experts are so that we can start filling in some of the blanks to assess who is already participating in roles similar to this and then help them to understand that we're recognizing them with their relationships with the data rather than attempting to hand down responsibilities that are brand new to them and brand new to the organization. So this operating model diagram becomes very important when you're finding the roles and responsibilities in your organization. One of the things that I also wanted to share is the colors that are associated with each of the different pieces within the operating model. I try to stay very consistent from one diagram to the next as to where am I demonstrating. The strategic level is necessary. The tactical level, the operating model, the operational level is available. You could follow the roles that are by color associated through each of the diagrams that I'm going to share with you. Each of the models are tools that I'm going to share with you in the balance of this presentation. So what should we include in the operating model? Who's going to participate in the program? How many people are going to participate? What they will do, how much time is expected? In a lot of organizations, the roles and responsibilities associated with data governance change when we get past the launch phase of the program and into the steady state phase of the program. So you might want to be able to depict that in your operating model of roles and responsibilities as well. And I wanted to share this diagram with you, which is both the regular pyramid that you see on the right side of this diagram, which is larger at the operational level and then smaller at the taxable and even smaller at the strategic level of the organization. That's during the program. That's during the steady state. But if we look at during the project phase where we're defining the program and we've got to get commitment and we've got to get dollars' sponsorship and support of the program itself, oftentimes during that phase of an initiative, the emphasis is on the project roles first. And then the tactical roles next. And then the last but not least, the operational. So the different organizations will go from the left side of the diagram, which is the project roles and responsibilities to the right side of the diagram. The same roles will apply, but the emphasis and the need to get those folks engaged will change over time. Where again, we're getting the executives in the strategic layer very heavily involved in defining the program early on. Later on, they have a role of breaking ties, of resolving issues that have been escalated up to them. So again, this diagram helps to understand that it helps you to demonstrate that the roles are going to change as your program progresses from just being a project to define the program to being an ongoing steady state type of data governance program. So that's a real simple set of things that you could, or a simple diagram, that you can use to define data governance and roles and responsibilities in your organization. I just want to share with you real quickly that a client of mine decided that they didn't like the three levels and they changed it to nine layers, a nine level. I mean, it's hard enough to try to describe to people what the difference between the operational and the tactical layer is, and the tactical and the strategic layer, but when you've got nine layers in your program, it becomes even more difficult to explain to people the difference between level nine and level eight, or level three and level four. You want to simplify. You want to keep it as simple as possible. However, you want to cover all of these aspects of the organization, operational, tactical, strategic, and executive, and then also the support layers as well. So I know I haven't spent a whole lot of time on the operating model, but I hope that gives you enough information to help you to build a model that will help you to embrace all the different levels of people in your organization and their responsibilities that go with being identified into the operational, tactical, or strategic level of the organization. So again, that was the operating model. That's the one that helps you to, again, define the roles and responsibilities. The second tool that I want to share with you is something that I call a common data matrix. And a common data matrix assists in those things that are listed on the screen in front of you. They assist in the inventorying of data, inventorying of data stores, the systems, the system or records. This tool helps you to identify and recognize and record who the stakeholders of the data are across the organization. And it really helps you to assist you in formalizing accountability for the management of data and information across the organization. So basically what you're creating with the common data matrix tool is a cross-reference of domains, subject areas, and potential stakeholders. So it's there to help you formally manage master data categories, identify strategic, tactical, and operational stakeholders, and formally identify and engage those people in the organization that have some skin in the game, so to speak. They have a vested interest in the success of your data governance program. And so what steps do we take in order to build this common data matrix? We start by defining subject areas. And I would venture to guess that even your organization could sit down for a couple minutes and brainstorm through what are the main subject areas, the sub-subject areas of data that you care about in your organization. So in this example here, there's customer data. There's product data, supplier, employee, material, finance. There's a lot of different subject areas of data in your organization. And not only that, there may be sub-subject areas as well. So under customer, you might have different, you might have customer demographics or customer transaction information. You may have sub-domains as well. The same thing may hold true for products, suppliers, and employees as well. So recognizing that we have these main buckets of data, so to speak, that there are also kind of sub-buckets that go inside those buckets. And it might be somebody different in your organization who could be the domain steward or the enterprise data steward or subject matter for customer data. There might be somebody different in your organization that is the decision maker for a sub-subject area. So we need to identify the subject areas. See if my pen works here. No, it doesn't. Okay, so sub-subject areas, sub-subject areas. We want to identify the knowledgeable people, where they reside in the organization. We want to identify the business system users, knowledgeable people in IT, and all the stakeholders of data in the organization. So the first step to building the common data matrix is to understand what subject areas of data governance is going to apply to. Then we want to identify what are the different parts of the organization that we want to apply data governance to. So you may have finance and operations and sales major. So these two steps are very easy. You can define your domain. You can define your parts of the organization. The question is, how do we make use of that information? So this diagram here basically shows the cross-reference of the subject areas down the left-hand side, the parts of the organization across the top, and then where the rows meet the columns, those are where our data stewards reside. Those are the people that, in other words, are being labeled as users of the data, but they might be definers of the data, producers of the data, and users of the data. So if we build what we need on the left and we build what we need on the top, eventually a common data matrix is going to look something like this. And I know this is difficult to read and I don't need to really to read the specific details in each of the areas. And if you're interested in a spreadsheet like this, we'll be glad to send that to you as well. So all we're doing in the common data matrix is cross-referencing the types of data that we have at the organization to the different parts of the organization. And again, as I mentioned earlier, the commonality of the colors from the operating model to the common data matrix becomes very important because if somebody sees themselves as being a domain steward or the taxable layer is yellow in the one diagram, they can then look at this diagram and see where they fit as well. So I'm going to break down this diagram for you here real quickly, that you've got people that are associated with domains of data. Those are the people that are on the far left side of the diagram. So you might have a domain steward or an enterprise data steward for customer data, but you might also have an enterprise data steward for each of the sub-subject areas under something like test customer data or finance data. If we work our way across the diagram, you'll notice that we recognize information technology. I get asked the question all the time, where should governance reside in technology or in the business areas? And my answer to that question is yes. We've got to take advantage of all the knowledge in the organization from IT, all the knowledge from business, and in this version of the common data matrix, you can see that not only do I define the different subject areas and domains of data, but I also identify what system do that data reside in, who the data subject matter experts are and who the system subject matter experts are from IT, but then also within the corporate units and the business units where the rows meet the columns, that's where your stewards reside. And I also have a great column associated with each of the corporate units and business units as well, because a lot of organizations have shadow IT organization. The areas that play the role of IT within a specific business unit, we cannot discount the knowledge that they have about that data as well. So the common data matrix is a tool to help you to put your arms around who does what with what data across the organization. So there's a change to a piece of data within one of those domains or subdomains down the left-hand side. We take all the guesswork out of identifying who across the organization are the definers, producers, and users of that data. Here's another example of a common data matrix. I actually used this within a university environment, so they called it a university data matrix. Again, the concept is the same. Down the left-hand side, we have the different subject areas of data across the top. We have the different parts of the organization, the different organizational units, and this one is the red, yellow, and green. It's like a spotlight. We want to be able to highlight who uses restricted data, who uses open data, who uses sensitive data in the organization. So if a square has just the red in it, then they're just users of sensitive data in that specific subject area. Again, there's a lot of variations on the common data matrix. The fact is that it can be used. It can be shaped to fit your organization and how you use these needs for this type of information. When I mentioned earlier that data is a byproduct, that a data is a byproduct in the organization of a data governance program, it's true. It's the people aspect of the data and who does what with the data across the organization. The fact is, in organizations, they may be created common data matrix for the organization, but if you've got subsidiaries or other parts of the organization, you may have multiple common data matrices for your organization, and then there's also a need for a master version of a common data matrix so that we can then communicate effectively with those people in the organization that are going to be impacted by changes for the data in the organization. The next tool I want to discuss is workflow templates. And those workflow templates are used to assist in formalizing processes and workflows across the organization. They cross the reference again. It's another matrix. So you're going to see a couple different matrices here that I'm going to share with you next. People tell me that if you're helped, you only do things in forms of a pyramid or a triangle, and the matrices I've got, my pyramid, I've shared it with you already. And then there's also these templates, these matrices that will help you as well. What we're really trying to accomplish for the workflow template is we define the steps of a process. We define different roles in the organization that need to be involved in the steps of the process. And again, we're going to cross-reference the steps with those governance roles. We're going to formally identify who's going to be accountable, who's going to be... If any of you may be familiar with RACI or RACI, the Responsible Accountable Consulted has formed some organizations that have added support of the piece to that as well. But we may use that acronym, the RACI acronym, to help us to identify in any given step what role has which level of responsibility. Are they responsible or are they accountable? We just need to consult with them or they need to be informed of the decisions that are made. So we're cross-referencing methodologies, risk management activities, any activity can be cross-referenced with the different roles and responsibilities defined for your program. And you can specify the outcomes and the deliverables and the file sets, the timeline. I want to share with you a couple versions of that. But before I do that, I want to share with you the steps that you're going to take to create a workflow template in your organization. So let's use as an example the steps of a common system development lifecycle methodology where the steps are to plan, design, develop, test, and implement, and maintain. So first thing I say is don't call it a data governance process because then people are going to point at data governance and say that's the reason we're doing these things. We don't really want to do that. Let's just call it the process that it is and let's apply governance to it. So the steps already exist. If we can apply the appropriate roles and responsibilities, it again gives a great way towards formalizing who does what and when within a specific process in your organization. And again, using the RACI or the RACTI, that acronym that also helps us to then be very clear as to who's responsible, who's accountable, who's consolidated and informed. So the first thing we do is we define the steps of the process. We may already have those steps defined for us. The next thing that we want to do is we want to kind of go back to that operating model of roles and responsibilities and understand what the different roles that we have. We have the team, we have the council, we have the stewards, we have the partners. We have a bunch of different roles in our organization. All we really need to do is then cross-reference the steps of the methodology or the steps of the process with the different roles that we have within the organization and then be very clear as to what we expect from those roles within these specific steps of the process. So I'm going to share a couple different versions of that with you. Here's the whole concept is if we can develop the steps down the left-hand side and we know the roles across the top, then we can define what are the specific tasks that take place during each of those different steps in this example of the methodology. So again, we're cross-referencing the steps with the different roles that we've defined as part of our program. This is impossible to read. I know, but again, the idea is not for you to look into the details of this, of the diagram. Now the left-hand side, there's a master data development lifecycle methodology. There's the steps of the methodology across the top of the different roles associated with the program. We can be very specific as to what we expect from people during those steps, what we expect from the people in those roles during those specific steps of the process that's being governed. And there's a bunch of those as well. Here's an example of a spreadsheet that was developed for one client. But if you look on the left-hand side of the screen here, you'll see that there's six primary processes that they wanted to govern as part of their data governance initiative. And they was resolver research information quality issues and identify and monitor risk and monitor information quality and lifecycle, again, different processes that need to be governed as part of our governance initiative. In this interesting spreadsheet, you have the ability to click on one of those or click on any of those different processes. And when you click on those, you'll see the second spreadsheet, the piece that appears on the right-hand side of the diagram, which again details the steps that are necessary to complete that specific process. And it also defines the different roles of the organization, the roles of the data governance initiative across the top. And again, organizations use things like race to be able to depict who has responsibility, who has accountability, who do we consult with, who are we going to inform, and who's going to be supportive in our venture here to apply governance to processes within the organization. Here's another example. Again, just trying to cross-reference the steps of a process with the different roles. If you're interested, it'll be glad to send you a version that you can blow up as large as you want to help you to read it. But again, I'm not talking to the details in these diagrams because the details of the process may be specific to your organization. But again, the idea of building your own data governance tools or what are necessary to put these workflow templates or the governance activity matrices into place. And again, these are examples. In this one here, they also specify how much time is going to be expected and how long that's going to need to take place. So you can't just like with a common data matrix that you can fill it in in a way that makes sense to your organization. The same thing holds true for the workflow templates. Define them in a way that's going to work for your organization. Start with the left side, which these are the steps to the process, and follow through to the right to the top, which is these are the different roles that we've defined as part of our program. And then you can be very specific or as specific as you want. What role does that specifically or what are the tasks that that specific role plays in that specific step of the workflow? So I call this the workflow templates or the governance activity matrices. So far we've talked about the common data matrix. We've talked about the operating model of roles and responsibilities, which are really a basis of putting a governance program into place. So I want to share with you this next diagram, and I'll share it with you in a second. It actually uses the same color scheme that we talked about earlier to be able to identify. If I see myself here in this role as part of our program, here's where I see myself in the process. And here's the specific things that are required from me when I'm engaged in that step of the process. There's actually really two ways to apply governance into processes in your organization. One is to do it proactively. Building the processes that are proactively taking place in your organization so that we govern the data upfront. And then there's the reactive processes, the processes that we use to resolve issues. So here are the issue resolution templates. They have just been formalized in the process. They're cross-referenced. They do all the things the other diagram shared. But again, this is now specific to issue resolution. And so we might have steps in our data quality methodology similar to the one that you see in front of you here. And then what we're really trying to do here is cross-reference the methodology with the resources. So basically who does what and when, and again, we can extend that to include how much time is necessary, what the deliverables are going to be out of that step. You can customize the activity matrix to work for you within your organization. Here's another diagram. Here's the one that I expected on an earlier slide, the issue resolution process, where on the left-hand side of the diagram of the template, we have the different steps that are necessary to resolve data issues. Across the top, we have the different roles and responsibilities of our governance program. Again, color coordinated with the operating model and with the common data matrix. So again, if you see yourself on the operating model somewhere, you see yourself in the common data matrix somewhere, you can also jump very quickly to what your responsibility is going to be around data governance for this specific process that we're governing. And in this example here, it's issue resolution that's being focused on. And you can apply this to any different process that you have within your organization. It's, again, a simple two-dimensional matrix that cross-references the steps of the methodology with the roles and responsibilities that you've defined. Again, taking advantage of things like Gracie or Rasky to make very clear who's responsible, who needs to be consulted, and who is going to be informed. The last tool that I want to share with you is one that I call a communication matrix. I told you I had a pyramid and I had a bunch of matrices that I want to share with you. Communication and awareness seem to be one of the most important aspects of a successful data governance program. So there's a couple things that we need to do if we're going to create a tool ourselves, create this communication matrix around data governance, and I'll share those steps with you in a second, but what's the purpose of the communication matrix tool is to assist in formalizing communication and awareness, to cross-reference what content needs to be created as part of our communications plan and who exactly needs to see that different type of content that we're providing. And informally identify the communications and awareness checklist of what types of materials do we need to provide, identify the audience, the content that's going to go to the audience, the specific message that's going to be applied during that communications, what media we're going to use for, what timing, all that information can be included within this communication matrix. And so the message and the delivery may be different depending on your audience. We're going to communicate differently with the executive layer than we're going to communicate with people at the operational layer. We're going to communicate differently with the council than we communicate with the day-to-day data stewards or our partners. So we want to make sure that we can identify what needs to be communicated to who and how that communication takes place. That sounds like a plan to me. We need to have a communications plan. Oftentimes I refer to this tool as the communication plan matrix. And there's a couple of steps to create that. What information do we need to communicate? There's three different phases actually of communications that take place in a lot of organizations. There's the orientation to the program. There's the getting people on board and understanding what their specific role is. And then there's on-going communications. Several clients that I've worked with have assigned communication specialists to their initiatives just because they understand that communications is such a key part of delivering a successful data governance program. So consider taking advantage of communication specialists that you have within your organization and then plan effectively with them as to what communications needs to take place, what the form of it's going to be, how often we're going to be doing that communications, and what tools are we going to be able to use or are available to us to provide that communication to the organization. So the first step of creating your communication matrix is defining what is it that we need to communicate. So we need to communicate information about the program, information about the council, what their specific role is. And I'm reading down basically the bubbles in the middle of the diagram. You know, role-based activities is one of the most important things that we need to communicate during an effective governance program. What types of things are going to trigger governance into effect? What types of documentation is available? What metrics and measurements are we putting in place? So the first thing we need to do around the communications plan is to find what needs to be communicated. And you'll notice that we need to do the same thing as we did with the governance activity matrix is we need to identify, again, using the roles that we've defined in our operating model is to find, you know, we've got team members, we've got the council, we've got the stewards, we've got the partners, and we're going to cross-reference the things that we're going to communicate with the different roles, and the abbreviation for communications, by the way, is CX. So that's where the CX is being on this diagram. But if we're going to communicate about the program to the team, and we're going to communicate about the program to the council, the things that we're going to communicate are going to be different, depending on the audience for this information that we are going to share. So, again, a very simple cross-reference of the picture we're going to communicate to the different roles that we have within our data governance program. This diagram right here depicts exactly what I just said. We've got the different types of communication listed down the left-hand side of the diagram. We've got the different roles and responsibilities of a governance program across the top. And, again, using that color coordination that I mentioned earlier, we want to be able to say, we're going to communicate this to this audience in this specific way using these tools. This is the timing of it. Again, it's just a way of putting our arms around what we need to communicate to different people within the organization. We need to have a plan for how we're communicating about governance in our organization. So, we're getting towards the end of the hour here. These are the four tools that I communicated with you earlier throughout this session. We've got the operating model on the upper left-hand side. We've got the common data matrix on the upper right-hand side. We've got the activity matrix on the lower left and the communication span on the right. And you can see, by having color coordination between these different things, there's a very effective way of creating these tools internally and not going out and purchasing these tools yet because there's going to be value to these tools. But we can help to define what our requirements are going to be by initially just collecting this type of information and then defining tools that will make it easier for us to take advantage of each of these different types of templates and tools that we will use in our organization. So, I know I spent a very little bit of time on each of these. I could have spent probably a whole hour talking about each of these. I hope that those have been helpful to you. The tools internally developed are used to do these things to formalize roles and responsibilities, formalize accountability and processes and awareness. Use these tools as a component of your program in order to make it successful. Formalize how this metadata is reported and made available. And really, the tools of your program become the face of your data governance program to people without the organization. So, we talked about these things. We talked about all of the different aspects of governance that we can build tools ourselves to collect it, to record it, to follow. With that, I'd like to turn it back to Shannon to see if there's any questions regarding what we've talked about here today. Hi, Bob. And of course, there's a lot of questions coming in as always. I love that we, our audience, is always engaged in everything that we do. You know, of course, one of the most popular questions that we always get are people inquiring about the slides and the recording. So, as I was reminded, Monday is a holiday. So, I will be getting the follow-up and a date Tuesday with links to the slides and the recording. And of course, now for this particular webinar, everyone's asking how they can get the larger copy of the matrices and the tools that you've been demonstrating throughout this webinar. And I will send links to those as well so everyone will have a copy of those in the follow-up email. And if you don't get one of those and if there's something that I'm missing in that email, this thing, Bob, or myself, and we won't be sure to get you a copy of anything that you need. So, a couple of great questions coming in here, Bob. Just in general, are data stewards business people or technical systems people? Very good question. Are they business people or technical people? And the answer to that question is typically yes. They can be both. But oftentimes in organizations, they consider the data stewards to be business people and the data subject matter and technical subject matter efforts to be IP people. So, in general, I would answer that question, that data stewards are most often going to be business people. There will be some people that will argue with me and say that all of them have to be business people. But the fact is that if we're looking for people in our organization who have knowledge about the data and have some accountability for the data, the data stewards can actually be mostly in business, but there could also be the role of the data steward played in IT as well. I would. I've heard a lot of that as well, Bob, that it's all of the above. Now, the next question is, why doesn't the team extend to the executive level? Well, and that's probably one of the pitfalls. That's a great question, great observation. You know, it's true that the data governance team has to support everybody, and I'm not telling you to use the templates that I provided exactly the way that they are. In fact, in most organizations, the team does also support the executive layer. If it's not the governance council that communicates with the executive layer, in that case, you wouldn't really need to extend the data governance team up to that layer, feel free to manipulate these diagrams, how you see fit for your organization. That's a great question, because very often the data governance team does support the executive level as well, and in that case, I would suggest that in your diagram that you would depict that in the diagram, show that they're not only supporting the operational, tactical, and strategic, but the executive layer as well. It's a very good observation. All right, and Bob, the next question is actually a couple questions from one of the audience members. Why doesn't T, or excuse me, how can this be compressed for a smaller company and its project equal launch and program equal study state? Well, and so I mentioned earlier that that operating model can be made bigger, because I shared with you the fact that an organization broken into nine or 10 layers, I've seen organizations try to condense it down into two or three layers. The truth is, and the reason why I have the four different thick layers is that a lot of organizations, no matter what the size of the organization is, look at things operationally, tactically, strategically, and in an executive view as well. So that's the reason why I have those four layers. I have seen organizations kind of combine the bottom two layers I've seen organizations combine the upper two layers. A lot of my clients actually don't even have the executive layer on their operating model because, again, it just adds another layer of complexity that has to be discussed. So you can condense it down into something smaller for a smaller organization by combining the tactical and the operational, by compacting and connecting the strategic and the executive. Again, it's just a model to be used for your organization. The idea would not be to make it much bigger and make it more complex. Keep it simple. Keep it set that it's something that's easy for people to understand. Again, the operational, tactical, strategic, and executive are the ways a lot of organizations look at themselves. That's why I included those four. But yes, it can't be cut down if necessary. And I love this next question, Bob. It's great to put all these matrices in place, but how do you keep them current? I mean, do you identify stakeholders by name or role, or how do you account for an organization that has frequent change? Well, and that's another great question. So the fact is that somebody has to have the responsibility for keeping it up to date. Somebody needs to have responsibility for viewing change within the organization so that we could make certain that the common data matrix doesn't become a snapshot of a point in time. So typically it's the data governance team that has responsibility for keeping these things up to date. Usually the things that are going to change, the thing that's going to change the most is going to be the common data matrix as people move in and out of the organization or they change roles. You know, typically the activity matrices, the communication matrix, the operating model aren't going to change that much, but I would definitely suggest putting a change manager across such a place to keep your common data matrix to keep it current. And oftentimes that requires that somebody from the organization makes you aware that there's been a change that somebody's moved or somebody's entered in so that they could be allocated in that diagram as well. All right, and I think we have time for one more question. In addition to the valuable tools you introduced today, any recommendation on locating a simple metadata management tool? We would like to find one that serves a business-enabled accessible repository as well as for technical metadata. It's very interesting you asked that question because presently I'm assisting a client to define a data governance and a metadata tool that work together. I'm not going to mention any specific tools by name because we try to stay as tool agnostic as possible in these sessions. But there are a lot of tools. If you go to the Dataversity event pages for the different events that they do and you look at the companies that are sponsoring those events, those are the ones that I typically would start with first when I'm defining what tools are out there on the market to be used. I definitely agree that we need to govern the data and people's responsibilities through tools and we also need to collect metadata through those tools. That's a great place to start because the companies that want to be at these events and want to be in front of these audiences are usually the strongest players in the field. Also, you could use the Gartner, Magic Quadrant, the Forester Wave to help you to identify which ones that those industry analyst groups believe are the strongest tools in those markets. Bob, thank you for another fantastic presentation and thanks to our attendees as always for being so engaged and asking so many questions. I'm afraid that's all we have time for today but one of the great things about this particular webinar series is any questions we didn't have time to get to today. Bob will write up the answers to all the questions that were presented today and so we will also get those out in the follow-up email that will go out by end of day Tuesday. And again, the follow-up email will contain links to the slides, links to the recording, as well as links to the tools that Bob has presented today in this particular webinar. So thank you, everybody, and I hope everyone has a great day. Bob, thanks so much. Thank you, Shannon. Thank you, everybody. Hope to see you again. Take care.