 My name is Monica. I'm with a digital team at Data Diversity. I'm stepping in today for Shannon Kemp, our Chief Digital Manager. 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 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. If you would like to chat with us or with each other, we certainly encourage you to do so. Just click the chat icon in the bottom middle of your screen for that feature. For questions, we'll be collecting them via the Q&A in the bottom right hand corner of your screen. If you'd like to tweet, we encourage you to share highlights or questions via Twitter using hashtag RWDG. And if you'd like to engage more with Bob and continue the conversation after the webinar, you can go to Data Diversity, the Data Diversity community at community.dataversity.net. As always, we will send a follow-up email within two business days containing links to the slides, the recordings of this session, and additional information requested throughout the webinar. Now let me introduce you to our speaker of the series, Bob Siner. Bob is the President and Principal of KIK Consulting and Educational Services and the publisher of the Data Administration newsletter, TDAN.com. Bob has been a recipient of the DEMA Professional Award for Significance and Demonstratable Contributions to the Data Management Industry. Bob specializes in Non-Invasive Data Governance, Data Stewardship, and the Metadata Management Solutions. And with that, I will give you the floor to Bob to get today's webinar started. Hello and welcome. Hi, Monica. Thank you. Thank you for filling in for Shannon. Good to have you here. Good to have everybody here. I appreciate you're taking the time out of your busy schedule to join us today. As Monica said, we're going to talk about building your own data governance tools today. So I've often shared a lot of the tools that I use to assist my clients and to assist organizations to implement governance programs through the webinars and presentations that I give at Data Diversity. And today I'm going to highlight some additional tools, things that you may not have seen before and hope that they will be something that will be of interest to you. Monica, I'm having trouble finding the spot to now change the slides. It's disappeared from my screen. So hover over the middle and on the left you should see a small... No, it's not there anymore. It's not there. Oh, dear. So I might need to ask you, can you possibly change the slides? I can do that. So let's go to the next slide. Sorry, you know. More than happy to help. It should work the same, but for some reason it's not changing for me. So, okay, let's go to the second slide. Are you showing the second slide? I am. I'm not seeing it. Oh, dear. I'm on slide number two. Okay, I'm still seeing slide number one. Hold on. Let me see. Now am I changing them? Ah, there you go. Okay, it reappeared. Okay, let's go to slide two. Thank you, everybody, for your patience as we're getting started today. You know, typically before I get started, I like to talk about a lot of the things that I'm involved with in the data management and data governance industry. As you know, the real world data governance series has been going on for several years. Actually, we just re-up for 2020. So a lot of interesting subjects on the calendar for the coming year. So you'll be finding out more about that soon. Also, I talk a lot about non-invasive data governance. And there is the book called non-invasive data governance that's available wherever your best books are sold. I speak at a lot of data diversity events. I was at the data architecture summit this week. I'll be at Data Governance Vision in Washington, D.C. in December. And also speaking at the Enterprise Data World Conference in San Diego, I've just learned that there's going to be an Enterprise Data Governance online event in January. And I'll be speaking at that as well. If you're interested in learning more about non-invasive data governance or non-invasive metadata governance, please go to the Data Diversity Training Center at the URL that I've provided there. Monica mentioned the Data Administration Newsletter. That goes out every other week. And a new issue of that was just published yesterday. And last but not least, KIK Consulting and Educational Services. KIK stands for Knowledge as King. So I focus on helping to transfer best practice knowledge to my clients about data governance and specifically non-invasive data governance. So here's the things that I'm going to talk about today. I'm going to spend a bunch of time up front in the webinar describing to you a bunch of tools that you might want to consider building yourself. Now, these are tools that are internally developed. You define your requirements yourself. I'm going to help you to talk about how to customize those tools to address the specific needs within your organization. We'll talk about how the development of internally developed tools could lead to tool acquisition when the time is right. And knowing when that is, when that time is right to start thinking about acquiring tools. And then we'll talk about integrating the do-it-yourself tools, the tools we're going to talk about today, with the tools that you already have in your environment or the tools that you're acquiring as part of your data management and data governance practices. So I want to start this webinar where I kind of ended the last webinar that I did last month. And so I focused on the data governance framework last month. And I just want to use that as a way to provide context to the tools and things that I am, that I'm going to provide to you today. So last month we talked about the framework. And actually there's a company overseas that is focusing on developing a digital twin for the non-invasive data governance framework that would actually provide links to tools and things that you could use for each of the components of a successful governance program. This framework, I'm finding it to be used increasingly by organizations that are trying to communicate what their focus is. But I want to really use that to align my thinking along with tools and things that I'm going to share with you. So I'm really using the framework as the basis for this webinar. And if you can see now, this is the framework that I dissected in great detail in last month's webinar. But I don't want to focus on the framework as much as the different pieces and parts of the framework. So if you remember, if you were here, if you were on the webinar across the top, those are the critical components that every organization that's implementing data governance should be thinking about. And that's obviously the data, you know, the roles and responsibilities, the processes, the communications metrics and tools. But we also got to look at these things from different perspectives in the organization, that being executive, strategic, practical, all the way down to support. And the framework that I spoke about last time really focused on data by level. Then we looked at roles by level and processes and so on until we basically covered the whole framework. So that's actually a tool that you can use and you could fill in with your important components and your levels. But I'm going to guess that your components and levels look somewhat similar to the ones that I'm sharing in this model. So the reason that I'm showing you this, and so this is where we're going to be focusing on, you know, what are the tools that you can build that focus on these different things that are the core components to your program. So just to kind of give you a little word in advance, I'm doing a companion book to the noninvasive data governance book where I'm going to talk all about these tools and other tools. And I just so happen to break these tools down along the components line in the framework that I spoke about before. So if you actually look at it, the core components that you have in the noninvasive data governance framework are actually the same as the tools that I have started to put together and utilize for my organizations that I've been working with. And then what I really want to do is focus on the ones that are in red. So I've picked a tool out of the data category and the roles and process and communication category to talk to you in this webinar. If I had more time, I'd love to go through all of these things with you, but we're going to address some of these that are most requested and are most used and that potentially add the most value to your organization. So I'm going to focus on the framework. If we just talked about the framework, I'll come back to that probably once during the webinar to show you how the things that I'm providing to you align with the framework. We're going to talk about the operating model of roles and responsibilities. And you may not have seen an inverted version of the operating model. It's actually very interesting. And I found that a lot of organizations have decided that they want to define what the project of data governance looks like versus the program once we start to operationalize and roll out the program. I'm going to go into some detail on the common data matrix on something that I call process bubble flow. And it's another way to be able to depict your racing matrix where you're identifying steps of a process and the people that have responsibility, accountability they're consulted with that are informed. I'm going to share with you a communication plan matrix because we all know that communications plays a big role in the implementation of a governance program. I'm going to share with you a rubric opportunity evaluation tool. And lastly, for those organizations that are actually getting to the point where they're looking at what are the most appropriate tools for the organization. I'm going to provide for you a tool evaluation tool. Sounds a little bit repetitive, but we need to make certain that we have a structured way of looking at the different vendors that are in the market that we are looking at and coming to a conclusion as to which is going to be the best tools that we can acquire that might be able to do some of the things that the tools that you build yourself can't do and that will fit nicely into our environment. So let's jump into these things and let's talk about them. If you're interested in learning a lot about the operating model, there's actually, we've done webinars, real world data governance webinars that have focused on the roles and responsibilities associated with data governance. So you've seen them a lot. There's also articles on TDAN that talk about a complete set of roles and responsibilities, but if this model is not something that's familiar to you, let me take a couple of seconds here to describe to you what it's really laying out. So most organizations are set up in ways that are at least similar to this. They've got an executive level. They've got a strategic level, tactical individuals in the organization and operational individuals as well within the organization. Then they also have a support level of the organization. So down the right, I'm basically laying out that there's an executive steering committee that we need to kind of guide the ship. I always talk about best practices in terms of the very first best practice being that senior leadership, however that's defined in your organization, support, sponsor and understand what the heck it is we're doing with data governance or our program's going to be at risk at some time. So we've got to acknowledge an executive level. A lot of organizations have committees or groups that are called a data governance council at a strategic level. And if you look along the right side of the pyramid, you see an escalation arrow that stops with the data governance council. Typically we don't take issues to the to the executive level of the organization. So typically at the strategic level, those folks are the or the buck stops, you know, it gets to them, they need to make a decision. We don't typically and then escalate it up to a higher level. But below them, there are the subject matter experts and the people that are recognized as the quote unquote owners of the data, the subject matter experts, the data domain stewards, you may have referred, you may have heard me refer to them as the people that have some level of authority or authority or accountability for data that falls under a specific subject area or functional area of the organization. And then at the operational level, those people are the data stewards. We talk a lot about data stewards. Well, I've been known to say that everybody in the organization is a data steward, because if they have some relationship to the data and they're being held formally accountable for that relationship, then they don't really have an opportunity to opt out as being a data steward. You know, they basically have to protect the data, the way the data needs to be protected. They have to produce it the way that it needs to be produced, but all of these things, you know, are very important. And so we need to at least be able to recognize who the people are in the organization that are defining, producing and using the data. That's the next tool I'm going to show you when I talk about the common data matrix, it gives you a formal way of being able to record who does what with data across the organization. Along the left hand side of this diagram, you see the support level. And that includes the data governance administrator or the data governance office or manager. The second best practice I typically talk about is that your program is really going to be at risk immediately if there isn't somebody that has that responsibility for guiding the ship, the ship being the data governance program. So we have to acknowledge that there's a data governance administrator or an office, and there's data governance partners. There's people within your organization that are already governing data as part of their normal function. So IT might be an example of that IT security, project management, risk and compliance, all of those things, they're already governing. They may not call it governance, but there's certainly partners to a successful data governance initiative. And then typically where the rubber hits the road for an organization is where we start to define the working teams. It's one thing to have a target state as to what you want to be able to accomplish, but you don't really get the ball rolling until you activate these working teams. So I consider this a tool of data governance because you really need a way to start to record and communicate to people what role they play in the operationalizing or the communication in regards to the data governance program. So I've shared this model many times before. Like I said, there's a lot of information out there on it, but what I wanted to share with you was an inverted version of the operating model. So you may not have seen this before, but if you look across the bottom, we've got a timeline. So basically starting from the far left and moving to the far right, when we're in the project phase of a data governance initiative, that is defining what the program is going to look like, but not actually operationalizing the program. The emphasis is typically different. We're not necessarily emphasizing the operationalizing the operational level as we do in the, when we start to roll out the program. So really the emphasis is oftentimes to get the strategic level and actually to get the executive level on board to understand that this is something that we need to focus on. And oftentimes you're going to be getting your artillery to go to your senior leadership from your tactical level from the people that are looking at the data and saying, you know what, we are siloed in our approach. We've got the same data in multiple places and we need to kind of pull it together and standardize on the data. So as you can see, the emphasis basically during the project is more at the strategic level and then a little bit less at the tactical level and much less at the operational level. However, as time moves forward and we start to roll out the program, the emphasis switches. I really emphasize the people that are doing this stuff, the people that are defining, producing and using data as part of their job. We make most of the decisions per division or per part of the organization at the operational level. And if we can't solve the problem there and it just so happens to cross over business functions or across divisions, it gets escalated up to the tactical level and then to the strategic level, as I had shown in the pyramid diagram on the previous page. I haven't shared this much, but I actually think it becomes a very powerful tool for describing where the emphasis needs to be as you're focusing on your program. So now I'm going to try to use some of these doohickeys on the left to draw a circle or to draw some lines. But if you look at this period, almost a straight line, where the two different, the inverted pyramid and the regular bottom up pyramid are shown, you can see that there's actually a period where we're actually kind of doing both. And I would say that the period of time that falls between those two lines that I drew is the pilot project. We need to, now we've emphasized and we've convinced leadership we need to do this, but we need to demonstrate that it's active. So we've got to start activating it so that we continue to set the need for the program. So you can almost consider that piece between the two lines as being, you know, that's the pilot period. And then you start to operationalize the program and you'll see where the emphasis needs to be as you operationalize your program. So that's an additional tool. It's basically just taking the operating model tool and inverting it. It's a way to describe where your emphasis needs to be when it needs to be that. So now let's talk about a data tool, the common data matrix. And as Monica said, we'll be taking questions at the end or you can submit questions throughout and we'll address them at the end of the webinar if you have questions about some of these tools. But the common data matrix is probably the tool that is requested most often from me. It is a tool to help us to identify, you know, how data is used, where data is used, who's using that data. I actually have started thinking about calling it an inventory and accountability matrix. I think I'll stick with the name common data matrix because that's what people are used to. But this is a really important tool. At some point in time, you're going to want to know all the information in the tool. So let me blow it up a little bit for you to provide a bigger version. And you can see that down the left-hand side of the common data matrix, we have information about a specific domain or subject area, whether that's customer or product or vendor or employee or whatever it is, you know, we define certain domains or subject matters of data. And oftentimes when it comes to the most knowledgeable person or even the authority for that subject matter of data, it might be a sub-subject matter or a sub-domain that they have responsibility for. So if you look at this, I have a yellow block which coincides in the color key as part of the common data matrix as being the data domain or sub-domain stewards, basically the middle tier of the pyramid diagram that I showed, and that's one thing I should add. The color coordination is consistent throughout the tools. So if you're in the peach area and you're an operational data steward, you can see where you come into play in all of the different tools. But getting back to the domains, we need to recognize who the subject matter experts are for the different types of data, and potentially there's more than one. And that's one of the reasons why we end up having siloed data is that we have different people defining basically the same data in different ways. But we need to know who those owners are, who those domain stewards are. And so this is a way of being able to record who those people are. Now oftentimes I get a question as to what's the right appropriate level of granularity to build this tool. And I suggest it's really up to the organization. You can do it by domain. You can do it by sub-domains within the domains. But you can also do it by critical data elements. So in this example that I'm showing you, and I don't think I've shared examples like this before, you can start to define what the different critical data elements are that make up that sub-domain of data. And then as you work your way across the diagram, you can document where those things are stored, where people are presently accessing the information, and who the IT and business resources in IT are that have knowledge about that data. Again, continuing to work across the common data matrix, you could go business area by business area. And each business area may be broken into different functional areas. For example, in finance, you may have several. You may have an accounts payable group, accounts receivable. You might have payroll. Some of those things might exist within your finance department. And I'm just throwing names out there. But you know what I mean? You might have a division that's broken up into several divisions. And I'm not sure if you have something that would be considered shadow IT in your organization. But certainly business areas are known to develop their own technical know-how and even potentially have their own IT area. We need to know if this data is being stored somewhere that might not be in one of these systems that we recognize, or who in that group in that business area has real specific knowledge about that specific data within that specific system. So the common data matrix and a lot of people, like I said, request access to a tool like this. The nice thing is that Dataversity provides this information. So when they do the follow-up email, there will be links to the common data matrix, links to the other tools and templates and things that I'm talking about. So the common data matrix, if you're thinking about that data column, you really need to know what data is important to who. You need to know where that data resides, who has responsibility for that data. And certainly a tool, a purchase tool could help you to do that. But if you don't have funding to do that, you want to start to set up a structure where you can really inventory the data that's most important to you in the organization and what parts of the organization are using that data, where they're getting that data from. All those pieces of information are absolutely critical to the success of a program, whether you store it in a common data matrix or you store it some other way. This seems to be a very valuable tool. And the thing is we can build it ourselves. And we'll talk a little bit about how do we customize that in a couple of minutes as I get through the rest of the tools. So basically just kind of going back to the framework for a couple of minutes here, I took the first two columns, the data column and the roles column, and I started to identify some tools that align with that. The common data matrix, and you can see it as the parts that are highlighted in red, that there is basically, we're using the same construct that we have for the operating model, the same roles and responsibilities, the same colors, and then even in the inverted model so that we can basically continue to focus on the executive, the strategic tactical operational and support perspectives for each of these tools. So that's why I wanted to talk about the framework at the beginning, because it gives us kind of something to link back to as we're starting to put our programs together. So now let's talk about the process column of the framework. And I'm not going to keep bringing the framework back to you, but you know what I mean, we're kind of working our way across the components of the framework and addressing them with different tools. Most of you are probably familiar with racy matrices. Again, we're cross-referencing the steps of a process with the roles in the organization and you can see on the right that the colors of the columns basically align with the common data matrix in the operating model that I shared earlier with you. And the racy matrix becomes really important because we need to be able to demonstrate that we're formalizing how we're doing things. So maybe formalizing how people request for access to data. We're formalizing the improvement of critical data elements in our organization to help to support certain functions of the organization. So the racy matrix is probably something that you're already familiar with. I'll share with you a blown-up version of that in a minute here, but I wanted to focus a little bit on the item on the left, which is very similar to the racy matrix, but maybe you can say it's I don't know if I would say it's dummy down, but it's simplified so that people can understand it. And basically the same steps that you would include on the right-hand side, you'd include on the left-hand side, but visually you can look at the process bubble flow and what I'm going to do is blow that up for you and see what what I'm talking about here. You could see that data governance council is involved in all of those steps that fall under the data governance council. The business unit working teams, remember the teams that I talked about to operationalize governance, you could see exactly when they get involved. Now it shouldn't be a surprise to you that the data governance administrator is basically involved in all of the steps. So typically that's the way it's going to be reflected, but you can hand somebody a bubble flow diagram and have them very simply recognize where they're going to need to be involved in the processes associated with governing data. Here's a blown-up version of the the racy matrix. Again, we just use the acronyms R, A, C and I and some organizations have included the letter S for supportive, so it's gone from Racy to Rasky, but the same content, the same context is aligned with any acronym that you use to describe whether somebody's responsible, accountable, consulted. Again, that's something that you could develop, but again what you're doing now is you're taking the steps of a process, you're cross-referencing them to the different roles that you've defined as part of your program and being very specific as to who's responsible, accountable, consulted, and who's informed throughout the process. Let's talk about the communication column. There's the communication plan matrix and I'm going to provide a blown-up version of that for you to see as well. Typically when I talk about communications, I break communications into three categories. There's orientation communications that's made available to everybody. There's onboarding communication, as we're getting people active in the program, they need to know what their responsibilities are. And then the third piece is the ongoing communications. And so one thing that most organizations recognize is that you can't communicate with all of the different audiences associated with your data governance program in exactly the same way. The people at the executive level and at the strategic level of your organization, you're going to need to be more succinct with them. You're not going to have as much time. They're looking at things more broadly and less deep. But we need to make certain that we're communicating the right message to those people. So laying out a plan for communications that addresses all the different audiences that you've now defined as part of your data governance program is going to be critical to your success. So building out a tool like this, it's not necessarily something that you're going to hand to the data stewards or the domain stewards or even the data governance council but it is going to be the plan that the data governance administrator and the data governance office is going to be following to complete the appropriate communications for the organization. So communication plan matrix, again very simple to put together. Now a lot of people ask, well what am I going to put into each of these squares that we have here? So we're going to talk about how we're going to communicate this specific subject to that specific audience and in that block or in a supporting document we can provide information about how often the communication takes place, what's the tool that's going to be used, what's the core message that's going to be provided, what's the cadence of the communications, all of that stuff basically makes up the plan when it comes to communications around data governance for your organization. The rubric opportunity evaluation tool is a new tool. I don't think I've shared this before. Something I'm working on with a with a recent client and it's a way for them as they set up their program and they're taking in different opportunities to evaluate that opportunity and to prioritize the opportunity. So let me blow that one up for you a little bit so you can see one category and basically has a benefit category, has a description of what the evaluation criteria is. You're supposed to rank the opportunity from a level of 1 to 10 for how it aligns with the corporate strategy and assign it a number, then that number is a certain percentage of the total number that you have and then you can evaluate it with a certain weight and give it a score and you can then start seeing well which opportunities are actually assigning more with the corporate vision than the others and find a way to actually identify and evaluate the opportunities as they're coming into your organization. The last tool that I want to walk through is the tool evaluation tool you know the repetitive tool and what you do with the tool evaluation tool if you get to that point where you're evaluating different products to bring into your organization you're going to define your requirements those requirements are down the left you're going to weight those requirements on a scale of 1 to 100 you're going to identify what 100 is what percentage of the total weight that you're giving given all the different requirements for that category and 100 happened to be 0.13 or say 13% of the total of 760 you know multiplying that times how they're being evaluated here on the right side of the matrix gives you a score and you can have a way of physically going and identifying which tools are most aligned with the requirements that you have in the organization. The ones that show up in green potentially could be the ones that are hitting 3 out of 3 they're right at the top and I'm going to blow this one up for you a little bit too. The ones that are red may say that this vendor when they responded to our process didn't even address resource requirements or something like that so you can highlight who is exceeding expectations who's not even coming close to addressing expectations and come out with scores that you can use to evaluate what the appropriate tool is in your environment. I could talk about these tools for the whole webinar but I need to move on to the next subject which is now that we have these tools now how can we go about using them to be used within our organization. So one of the first things that I suggest is define what your domains of data are what buckets of data are you caring about customer how do we break down customer how do we break down product so we need to know what the domains are and when we go to the common data matrix we're going to start to define that from the left to the right of that tool and then the parts of the organization you know a way to be able to document what parts of the organization are we focusing on are we focusing on North America are we focusing on US are we focusing on global Europe what what parts of the organization do we need to get involved and you might want to consider them as well as you're building out your common data matrix you know what are your roles that are associated with data governance your roles might not align with the operating model that I provided and so you want to make basically customize the tools to use the roles that you're defining within your organization and also the processes may differ from organization to organization these are all things that can be customized within the tool even the purpose of your data governance program and what I wanted to do was share with you you know some examples of some domains you've got the customer product parts employee you know and there's a lot of different domains students spatial data there's a lot of different types of data or categories of data so one of the things that we should be doing is at least brainstorming on defining like what are all the buckets of data that we have in our organization and then use that definition or if you have a taxonomy or a data model even better but use those things to define how you're using the products that I shared with you in this example most specifically the data tool is the common data matrix and you could use these things to define where the data resides who uses who defines produces and uses the data that specific data from that specific resource across the organization you can as I said before you can customize the parts of the organization whether it's locations or countries whether it's a company or a subsidiary of a company or there could be multiple initiatives going on within the same company again these are all things that can be customized in your organization as we start to put these tools together so typically your tool isn't going to look exactly like my tool it's going to be customized for what you need in your organization I have a client recently that took the common data matrix and aligned it to their business capabilities and that was where they started to figure out well what data is filling what business capability and they took the common data matrix and made it their own and that's what I'm suggesting that you do take these tools customize them and make them the way that they need to be for your organization but there's also some issues around the organization some organizations kind of take a centralized approach where there's a central group that has responsibility for data governance other organizations take more of a federated approach where there might be a guiding set of people in the organization that are not necessarily handing down law to other parts of the organization but they're stating here's a set of minimal standards that you need to follow in giving those parts of the organization those federated parts of the organization more autonomy in defining how they're going to go about aligning to what the central office is stating you know consistent or distributed international or regional again these are all different things that you can consider when you're customizing these tools for your organization you have roles and responsibilities we talked about before you might have a steering committee or something like that insert the name of what you call it take data governance council out and call it your advisory group or whatever you want to call it you know your data owners again I hate the word data owner because of what it implies I had a client say well aren't these people at the tactical level really are subject matter experts for specific subjects of data their response was well why don't we just call them that why don't we call them subject matter experts and to me I think that made perfect sense so they inserted subject matter expert at the tactical line the data stewards anybody that supports the organization again as you're color coding these tools that you're developing they're going to be focused on these lines basically you're going to be able to recognize the strategic tactical operational and support in almost all the tools that I'm providing to you the processes that you're governing those might be also different so you want to take a look at for the racy matrix for the bubble matrix to include or to focus on those processes that you are planning on governing basically any process is a form of governance but it doesn't really become data we start to apply the appropriate roles and responsibilities to those different actions so the processes that you might be governing might include data quality data protection understanding certification all these things basically any process in your organization that has to do with data definition data production and data usage is again a way for you to customize these tools to make most sense and to be most beneficial to your organization if you're focusing on improving critical data elements around let's say a loyalty program for a supermarket chain you can certainly have that as a category of data and you can certainly focus your governance program on the processes that are associated with that so again take a look at what you're doing data governance for and make certain that you're aligning the processes that you're governing with that purpose and here are just some examples of purposes that I've seen organizations use they want to improve data quality or to improve data protection all these things are things that are examples of processes that you could govern using a racy matrix using the operating model using the common data common data matrix as a tool to help you to provide for provide you with the knowledge as to who the appropriate people are that need to be convened into the working team and who need to be engaged at appropriate steps in the process so the purpose of the process or a purpose of your program may also be a way to for you to be able to customize the tools that you are using. Alright let's spend a couple minutes talking about internally developed tools and how they lead to tool acquisition and so what is it about these internally developed tools that lead you to acquiring tools well first of all as you're developing these tools internally within your organization you're really defining your requirements as to what you'd like a tool to do and you'll find that sometimes the tools do exactly what you want them to do based on the tools that you've developed internally but sometimes you'll have some requirements that you never really even thought of that you know that you need to have addressed for the tools that you're acquiring so one of the things that it does in helping you to kind of lead you to tool acquisition is to define your requirements for what you need the tool to do another thing that these tools will help you with is to recognize who's going to use the tool that's really important we don't want to get tools that nobody is going to use but if you find people are accessing your common data matrix or they're focusing on the communication plan you can look to see do we have tools that are going to suffice for these stakeholders and these people within our organization so it helps you not only to define your requirements but also to recognize who in the organization is potentially going to use these tools because that ultimately is the goal is to get the tool into the hands of the end users that are going to get the most value from it it's going to help you to quantify the impact of the capability of tools if you can demonstrate that the common data matrix has helped you to formulate working teams a lot quicker than the best guess approach because you're recognizing who is doing what with that data across the organization you can start to quantify the impact that's being provided by the common data matrix well you want to make sure that you can quantify that same impact from the tools that you're looking to acquire it helps you to shape the need for metadata dissemination now who needs to get this metadata when do they need to get it it helps you to define the usability considerations people start telling you I like I like this aspect of what you develop but you know if you can provide a web front end to it or something that I could access through my iPad that would make it really helpful or very extendable for me and for my part of the organization so it'll help you to define usability considerations and most importantly may help you to find out what you don't want in a tool go to a vendor and a vendor decides to sell you everything in the kitchen sink and you don't necessarily need that so it really helps you to define what also you don't want out of a tool so what is the connection between these internally developed tools and the purchase tools will they both require somebody to manage them you can use the internally developed tools to prove that there is a need if all of a sudden people are accessing your common data matrix because they feel that it has information that is sorely needed as they're creating working groups and teams or even focusing on impact analysis if I make this change to this data who in the organization is going to be impacted by that now when people start to depend on that and you perhaps would take that away from them they'll start to holler they'll say you know what we still need that functionality so you can use the internally developed tools to prove that people are going to use these things within your organization and before you go out and spending what can be lots of money to acquire a tool and to acquire licenses to use those tools in the long line of things that you're doing but you want to use these tools to provide insight into what the advanced tools that you're going to create are going to need to look like what capabilities are they going to need to have you can use the tools to understand how people want to access the metadata like I said before if they say if you developed a web front end to this or you provided a mobile device front end to this this would be really valuable to me so you can use the tools to understand how people want to access the metadata you can use the tools to understand the metadata that's going to help to improve your data governance so by developing internal tools you're serving a need you're actually serving many needs you're serving the present day needs because the beauty of an internally developed tool is that you have control over that the advanced thought towards internally developed tools is that it's doing all these other things as well all the things that I shared with you on the last couple slides helps you to understand what users what they need when they're going to access it all of those types of things need to be considerations when we're going out and we're acquiring a tool and putting good money towards it but you also need to know that even utilizing internally developed tools also require resources they require resources to create the tools to maintain the tools to keep that information up to date for example if you created a common data matrix and you recognize who used what data across the organization and that changes and you're not having a change management process in place to keep the tool up to date the tool starts to add less and less value over time because it's not accurate there's a new group that uses this data there's a new system that's been developed and it's being used by part of the organization we need to have change management processes associated with not only the internally developed tools but then also the tools that we acquire and so the one thing to keep in mind is that it takes resources it's going to take at least a resource to manage an enterprise data governance tool for your organization and at least most of their time if not all of their time may be focused on that that's one thing that organizations need to think about by developing tools is what tools are going to require resources how many resources are we going to need how long are we going to need them is that going to change over time and those types of things so a lot of things to think about a lot of things that you can demonstrate with your internally developed tools before you actually get to the point where you go out and acquire tools so let's spend a little bit of time talking about knowing when it's the right time to acquire a tool well we need to know when will it be time to advance from the internally developed tools to the acquired tools and I'm not sure it's always an advancement that's why I have the sick there it may find that some of the internally developed tools suffice for an organization your size you don't need to necessarily go out and acquire a bigger tool but what are some of the things that we need to be concerned about with the tools that we're developing ourselves well the first one is capacity how much information can we store in the tool the common data matrix is a great tool if you're looking to document inventory and accountability but at some point if you list every single domain in every part of the organization the common data matrix becomes somewhat unwieldy it's very difficult to use a common data matrix to represent the entire organization some have tried, some have been successful some have failed it just becomes too big so the capacity of some of these tools can grow to the point where you know what we really need to look at tools that are available outside the organization as a way to be able to address this issue access might be time you have additional folks may not be all of a sudden it might be overtime you have additional folks who want to access those tools the functionality of the tool, the management of the tool all these things when we recognize that something's taking too much cost to own this type of tool we need to find a way to streamline that process when is it time to advance perhaps budget becomes available you've been budgeting for a data governance or a metadata or a data modeling tool for years and it's been declined year after year but all of a sudden we have budget to be able to do these types of things that might be a time to start thinking about what other tools we can look at outside the organization so all of these things might in some way shape or form lead you to the point where you feel like the internally developed tools aren't cutting it for you and that another tool on the market might do a better job of addressing your needs and concerns so which are the internally developed tools that might need that might meet the limits at some point the common data matrix as I said before at some point it might get really large and very difficult the data dictionary and the business glossary a lot of organizations start with that they may have multiple data dictionaries or business glossaries but if you're looking to centralize on a single data dictionary or business glossary you might reach the limits of whatever tool you're using whether it's a spreadsheet or SharePoint or OneNote or one of those types of things to develop it might reach its limits the data documentation or the data movement documentation tools again as you start to put more data movement processes on the tools they may max out you may find you know what we really need to go out and acquire a data movement tool an ETL tool or something like that that's going to benefit our environment but you can start by documenting that stuff internally but at some point you're going to need a time to be able to expand that tool and what are some of the tools that I talked about here that might not meet any limits and that you might be able to use and not have to acquire a tool to address it well the operating model it's not going to grow and grow it's not going to be adding new types of your organization most organizations are set up as being executive, strategic, tactical operational and support so that's the way that I've defined the model you know if there is a new group or as the organization changes yes there may be need for changes to the operating model but it's not going to reach its limits it's really a model of the roles for your data governance program so that one I would say you're never going to grow out of an operating model same thing holds true for the process models the process tools, the bubble flow and the races you're not going to get to a point where those simple tools are going to outgrow your organization or the need for those tools do so you might have ways there are products that will help you with your process flows you know you may not need to address that in your organization depending on the size and the breadth of your data governance program so all these tools listed here are the ones that most likely at some time will not really reach their limits and these are things that you can use and leverage on an ongoing basis within your organization so the last subject that I want to talk to you about today and I know I've been going quickly through a lot of these slides I hope it's been helpful to you and I'm going to take a look at some of the tools that I'm going to talk about today these do it yourself tools with the acquired tools so the first thing we should think about is looking for how these internally developed tools complement the other tools actually don't just look at the acquired tools look at other tools in your landscape if you're doing data modeling and you're putting cheeseburger definitions in your data models what is a cheeseburger definition what's the definition of a customer number it's a number for a customer it doesn't tell you a whole lot but if you're doing data modeling and you're putting ineffective definitions there but you're recording good definitions in your data dictionary you might want to look for a way to be able to leverage the best of both of those worlds so don't just look to your new tools but look to be able to complement and integrate the things that you're collecting with the tools in your environment if you may not remember but kind of going back to the tool make the tool evaluation tool that was one of the things that we need to know is we need to know how easy is it for us to get metadata into these tools and how easy is it for us to get metadata out of these tools you want to look at how your tools may be serving the same functions as tools that you could acquire where do they serve separate or complementary difference what's the cost of these tools you know can metadata be integrated or passed from one tool to another maybe a critical requirement as you're addressing the need for tools beyond the tools that you're just creating within your organization and another consideration is what will take to train people on another product so they've already been trained on certain products you've got a new one that you want them to learn that it takes time it takes somebody has to have the responsibility for defining how we're going to train people and keeping them up to date if we expect them to use the tools for the long haul focus on the metadata that will improve the effectiveness of the three actions that I talk most about when it comes to data you can define data you can produce data you can use data you can do two of the above you can do all three of the above if that is part of your job data definition production or usage and you're going to be held formally accountable for that relationship to the data meaning that if you're a data user you need to understand the rules associated with using the data and follow those rules or you're producing data we want to make certain that whatever actions we're taking whatever tools we're providing are enhancing our capability to govern data definition production and data usage another item one of the last items here is the total cost of ownership to add new tools the total cost of ownership or the TCO as people refer to it is not necessarily the cost of the tool itself is not the total cost as you can see in the diagram I'm sharing here as an example there's a product cost there's a resource cost maintenance cost so make certain that you're looking at everything that's going to be required when you acquire a tool certainly make certain that there's a person that has responsibility for knowing that tool inside out and supporting that tool in your organization but the total cost of ownership may point you back to using the internally developed tools so I know I went through a lot of stuff quickly and I'm going to turn it back over to Monica here in a second these are the things that we talked about today easy to build data governance tools talked about how you might look for things in your organization to customize those tools the internally developed tools and what can we get from those other than just the tools themselves how does that lead us to acquiring tools knowing when it's the right time and starting to integrate the things that we're developing with tools that are in our environment and with that I will turn it over to Monica see if we have any questions today all right thanks we have a ton of questions Bob so I want to take a question first we'll probably won't be able to get to all of them so what forum you go to the dataversed community what forum can questions be asked for you? What I'll do is I'm going to start a separate conversation specifically focused on building building data governance tools or building your own data governance tools so look for a forum on that I have not created that yet I think in the future I may create that before but if you give me a couple minutes after the webinar I'll be glad to go out and create that group otherwise just reach out to me directly if you have questions or you want to talk to me about the tools and the questions that you have but go ahead so you're saying go to the data governance forum and you're going to create a thread within that forum to ask questions perfect okay so here's my first question in reference to the digital twins cited at the beginning of the presentation what organization or what is the subject of the twin? The subject of the twin is the data governance framework itself so for the executives so let's just take an example of a column and as an example of a row so let's say that we have for under the under the role column from the executive perspective so that block we have information about what you need to develop the executive role for your data governance program are there any tools or things that you can use to do it so the model itself the twin itself is going to be of the framework if we can get this going and get this out there but certainly let me know if there's interest in the digital twin because I think that's the direction a lot of organizations are going. What is the data DME on the common matrix? What is the data DME? Well it's typically it's a subject matter expert focus specifically on data and database design so I usually have like a business SME and I have a technical SME if I had it as DDME or however I had it it's really the data subject matter expert in IT that we're focused that knows say if you're going to ask questions about a specific type of data who am I going to go to in IT to talk about problems I'm having with that data it gets very specific about that. I've had lots of questions about getting examples of these tools that you're showing is there how can people have access to examples or the common data matrix? One of the wonderful things that data diversity does and they certainly do a lot of wonderful things is provide that follow-up email that you talked about Monica at the beginning of the webinar that has links to the tools has links to a PDF that has copies of a bunch of these different tools and so that's where I would suggest you go to first. I don't have examples of client filled out versions please reach out to me and let me know and we'll see what we can figure out for you but that's a good thing that data diversity does is and I'll provide that link within the forum as well as to where you can go to get to these tools. Okay so we did have a question about the presentation shown here we will post this presentation and the slides within two days on dataversed.net and my last quick question Bob is when is your new book coming out? Yeah see that's the risk when you start talking about things like that I'm hoping that it's going to come out soon I'm actually going to be working with my daughter who is an excellent writer to work on that and it's going to focus on the tools and templates the goal is to have it completed by the end of the year so I would hopefully look for some time in the first quarter of next year. Okay great well it looks like that's all the time we have today I want to thank Bob for the great presentation and just a reminder we will post the webinar and slides within two days on dataversed.net Shannon will send up a follow-up email with all the links and the requested information so thank you again for attending today's webinars and I hope you have a great day. Monica can I mention one more thing keep the questions coming because dataversed provides me with the questions and as I can get to them I'll address your questions if we didn't address them here or come meet me in the community in the next couple of minutes so thank you everybody thank you Monica great job. Okay thank you and have a good day everybody. Take care everybody bye.