 Hello and welcome, my name is Shannon Kemp and I'm the Chief Digital Manager of Data Diversity. We'd like to thank you for joining the current installment of the Monthly Data Diversity Webinar Series, Real World Data Governance with Bob Siner. Today Bob will discuss data governance and three levels of metadata sponsored today by Irwin. Just a couple of points to get us started, due to the large number of people that attend these sessions, you will be muted during the webinar. If you'd like to chat with us or with each other, we certainly encourage you to do so. Click the chat icon in the bottom middle of your screen for that feature. For questions, we will be collecting them by the Q&A in the bottom right-hand corner of your screen, or if you'd like to tweet, we encourage you to share highlights or questions via Twitter using hashtag RWDG, Real World Data Governance. As always, we will send a follow-up email within two business days, ending links to the slides, the recording of the session, and additional information requested throughout the webinar. Now let me turn it over to Danny Sanwell for a word from our sponsor for today, Irwin. Danny, hello and welcome. Thank you, Shannon, and welcome everybody. Thanks for attending what I think is going to be an excellent informative webinar. Just a quick word about Irwin, to get us started. For those of you that have not, aren't aware of Irwin or have not been following the journey, we were divested in 2016 from CA Technologies and became a standalone company building on our long pedigree of leading the data modeling industry and market with our Irwin Data Modeler product. From there, we've grown in leaps and bounds through internal development and innovation, as well as a couple of very strategic acquisitions, so that we can now bring to you what we refer to as the Irwin Edge platform or the Enterprise Data Governance Experience platform. And what we've really done is built a collaborative role-based platform that brings together some capabilities around data stewardship and governance, all the things that you would expect to see there, things like business glossaries, policy, business rules, ownership stewardship capabilities, underpinned by a data preparation and automation capability that really allows you to take a business and metadata-driven approach to governing the entire life cycle of data from its inception to consumption for all the many purposes we might do in the business. And then, of course, modeling and metadata enterprise modeling that gives you the views and the details that you need into the business, how it works, the capabilities, their motivations and strategies, as well as how data is structured to meet specific business use cases, and then a very well-connected metadata management capability underneath that. And when we talk about metadata being very germane to today's topic, we have a catalog that really allows you to get your arms around and fully understand all of your data at rest, all of the data stores, data models, places where data is managed and made available, as well as data motion, how data moves through the organization from its different points for different purposes for the business, really harmonizing data management and data governance, making sure that they have clear visibility and control over their aspects and responsibilities as it pertains to enterprise data. And as we say, we are the most connected platform, you know, looking at this list, you know, and it's a brief list, it's not an exhaustive list of what we'll connect to and automate so that you can understand exactly what you have in terms of a data management infrastructure, both data stores as well as data movement, automate all those processes so that's always up-to-date, accurate, and in the long term, sustainable. At the end of the day, our goal is to get all of the stakeholders that are in the data value chain working together with all of the people that support them in the work that they do to make sure that data truly becomes a valuable asset with a minimum of risk to the organization. With that, I think I will now let's get to the meat of the presentation and turn it over to Rob. Thanks, Danny, and thanks to Irwin for sponsoring and helping to make everything happen. It's always great to have you on. And you can, Dana will be joining us in the Q&A section at the end if you have questions for him there as well. And let me introduce to you our main speaker for today, Bob Siner. Bob is the president and principal of KIK Consulting and Education Services and the publisher of the data administration newsletter, tdan.com. Bob has been the recipient of the Dana Professional Award for its significant and demonstrable contributions to the data management industry. Bob specializes in non-invasive data governance, data stewardship, and metadata management solutions. And with that, I will give the floor to Bob to get today's webinar started. Hello and welcome. Hi, Shannon. Hi, everybody. Hi, Danny. Good to have you on board for the webinar today. Really love the subject. I know a very popular subject with a lot of the webinars that we've been seeing these days are a lot of the things that just lie at the core of what Danny just shared as the EDGE platform. I like the enterprise data governance experience. And if you notice, right in the middle of that platform was the data governance and some of the aspects of metadata that I'm going to talk about today. In fact, I wanted to point one thing out, just even in the title of the webinar, it's not data governance and the three levels of metadata because those of us that are familiar with the metadata management space understand that there's a lot of different types of metadata that we can manage. But the things that were really called out in the EDGE platform were the glossary, the dictionary, the usage of the data, and the catalog. So today, we're really going to talk about metadata that has to do with those things that Danny shared in the platform, improving the understanding and the use of data. So those are the three levels of metadata that I am going to focus on today. Let me see. I'm having trouble going to the next slide. Wait a minute. I'd like to just kind of run through some of the things that I'm working on in the industry. And as you can see, I'm pretty heavily invested in the data management and data governance and metadata space. My next webinar will be on December 20th, always the third Thursday of the month. And I'll be talking about how to govern your master data in that webinar. I refer often to the non-invasive data governance book. I just want to point out that there is a book that's available through your favorite bookseller called Non-Invasive Data Governance. And there's also an online learning plan available through Data Diversity that's called Non-Invasive Data Governance as well. I'll be speaking at a couple of the events that are listed here that are coming up. I'll be speaking just in a couple weeks at the Data Governance Winner Conference in Delray Beach. They just announced the agenda for the Enterprise Data Governance Online virtual conference that's going to take place in January. I'm going to be speaking, I'm actually anchoring that event. And then I'll be speaking at Enterprise Data World in Boston in March as well. A couple other things there is, if you're not familiar with the data administration newsletter, tdan.com, please go visit it. It comes out with new content twice a month and it is produced by Data Diversity and I am the publisher of that publication. And last but not least, there's KIK Consulting and Educational Services. That's where you can go to get more information about non-invasive data governance. So today, one of the things that we're going to talk about in the webinar, we're going to talk about specifically those three levels of metadata that I mentioned earlier and how they're different from each other, how they need to be linked together, all of those types of things. We're going to talk about different sources for the metadata that should reside at each of those three levels. We're going to talk about linking together the levels because that's really where a lot of people get a lot of value is that when you have metadata that helps them to dig into or dive into additional information that you have about your data. It's really important to link your metadata together. We'll talk about processes to govern all levels of metadata and then we're going to talk about institutionalizing policy just to make certain that all of the metadata at all three of these levels is coming across to people at a high level. But before I get started, I'd like to share just real quickly my definitions and I'm going to get to my definition of metadata here in a minute. I usually share these definitions just to kind of get people on the same page as to what I mean by data governance and data stewardship. Data governance to me is the execution and enforcement of authority over the management of data while data stewardship is really the formalizing of accountability. So there's people in the organization that have relationships to data and we need to recognize what those relationships are and then help to formalize what their responsibilities and what their accountabilities are based on their relationship to the data. So I talk a lot about data definers, producers, and users. And actually the different roles that you take, the different relationships that you have to data really help to indicate what type of accountability you'll need to have. So that's what I refer to as data stewardship, non-invasive data governance. It really talks about the way that we're applying governance to the organization. It's applying formal roles and responsibilities. Applying governance to process rather than really focusing on carrying everything down and rebuilding it as data governance. I can assure you that there's a lot of governance likely taking place within your organization. And if we can look for that and you can look to formalize that, that's really what non-invasive data governance is all about. It's looking to take the levels of accountability and responsibility in the organization. It's formalizing that with the people that have the relationships to data. So it's really non-invasive is how we apply governance across the organization. I shared those with you only to get to these definitions, the definitions of metadata. And the one definition that everybody in the data space seems to know for metadata is that it's data about data. But I like to take it a little bit further than that. I actually state that it's data recorded in IT tools that improves business and technical understanding of those three actions. The definition of production and usage of data that I just mentioned. So let me break that down a little bit further for you. So metadata is actually data. And that data needs to be governed. And that's another topic for another day when we focus about metadata governance. In fact, I'm going to be speaking about that at the Enterprise Data Governance online event in January. So if you're interested in more information, please attend that session. But it really is data. And it doesn't really become useful to you until you record it somewhere. Until you record it in a tool like Erwin, in your data dictionary, in your business glossary, until you record your data models. It doesn't really become metadata or really become useful to the business until it's recorded somewhere. And it used to be, I know when I got started in the industry, people always thought of metadata as being a technical resource when truly it has become an enterprise business resource. And how are people supposed to get the most value out of the data? How are they supposed to protect the data? How are they supposed to improve the quality of the data unless you have documentation about that data? So we're really looking to focus on improving people's understanding of the data through the metadata. And again, it focuses on the definition, production, and usage of data, which I consider to really be the three primary activities that you can take with data. And most all other activities kind of fall under one of those, definition, production, or usage. So let's jump right into what are the three levels that we're going to talk about today. And some of you may have seen things that are similar to this diagram. But as I mentioned, going back to the Edge platform, the stuff that was right in the middle was really the understanding of the data. And I break it into three levels. I break it into the vocabulary level, the dictionary level, and then the data level. So oftentimes, the vocabulary level is considered to be the business glossary by a lot of people. And I'll go into that in a little bit more detail as we go through the session today. But I consider the vocabulary level to be the semantic level. It's really made up of terminology and the business language that's used by your organization. And then there's the dictionary level right in the middle of the three levels. And that is where you have the business metadata. You really are explaining what the data looks like and how the data can be used within specific applications and systems. So oftentimes, organizations have data dictionaries for applications or for data sources or for the data warehouse or the business intelligence environment. But the data dictionary level is where we start to relate the business aspects to the data itself. So oftentimes, organizations call that the data dictionary. And in fact, I think every organization I've ever worked with calls it a data dictionary. They don't necessarily have them in place. They really need a good place to be able to store that information. But the dictionary level is the middle of the three levels. And then the bottom level is the data itself. And so I've worked with organizations and I've worked for organizations that have said, well, we don't really have any metadata. Well, the truth is that you do because in your database catalog, whether you're using Oracle or SQL Server or DB2 or whatever is your database management system of choice, there is a catalog that has a lot of information about it for managing your database environment. And that's really the technical aspect of your metadata. It really tells you what systems you have, what databases you have. It really gets down to the technical aspects of the data. So those are the three main levels that I'm talking about today. And like I said before, they're really focused on improving people's understanding and use of data across the organization. So let's walk through each of those levels real quickly here. When we talk about the semantic layer, we're really talking about the vocabulary. And as I mentioned before, it's the business language we use. And there's only a limited amount of metadata that we typically collect at the glossary level. And some of those things that you need to collect at the glossary level are listed here. If you have any ideas of other things that need to be collected in a glossary, please share them in the chat. I think it would be a great place for people to share what types of information they store within their business glossary if they have a business glossary. So there's a lot of different things that you can collect, but these are the ones that I find to be most consistent. The business terminology, the definition of what that term means, what domain or subject area that that thing falls in, who the people are in the organization that have responsibility for that thing. And I'm calling it things because it's not really data yet. We're again, we're talking at the semantic level, the business terms used. I don't typically use the term ownership. So that's why I have sick after in that bullet point. But the people that you need to know who the people are that has responsibility for all of the information associated with a specific object or something within your organization. So again, the vocabulary level, the semantic level is up top. It's not even really related to the data yet. It starts to really focus on what are the things that we care about most within our business. At the middle layer, as I said, it was the data dictionary level and oftentimes, at least the way that I've seen it, the data dictionaries exist for the data that exists in your data warehouse or in your business intelligence or your analytical platform. And there's a specific, there's a lot of different types of metadata that we can collect about the data dictionary as well. Oftentimes, it's what is a specific piece of data called, so the data element name, the definition of that data, what subject area or domain it's associated to, who is the person in the organization that is the go-to person and when it comes to decision-making associated with that data domain. Also things like timestamps and when the data dictionaries were updated. And there are some simple things that organizations can collect and include in their data dictionary. Again, if you're collecting things that are in addition to that, please share that with other people who are viewing the chat session right now. But we wanna be very particular and we wanna have reason why we're collecting the metadata we're collecting when it comes to each of these layers. And that particularly holds true with the data dictionary. I've seen data dictionaries that just have way too much information in it. It's good if people are using that information, but until you have requirements for people to use that information, you might be making your data dictionary environment just a little bit more complex than you need to. I wanna talk about the technical metadata, the third level down basically in that graphic that I shared with you. It's really the metadata that has the information about the database names, the table names, the column names, the view names. Again, all of the technical information about your data. So we think about it, we think about it. We go from business terminology down to specific data within specific systems or applications. And then we go down to the data itself. So just to share real quickly with you the diagram again, the three levels of metadata that I'm focusing on today are the vocabulary dictionary and the technical metadata about the data itself. Simple diagram. And if that's what all that was involved in capturing and managing the metadata associated with data understanding, that would be one thing. But the truth is that this diagram actually takes the last diagram and expands on it a little bit. And it says, okay, now we've got relationships between the things that we're collecting in these three levels of metadata. You know, we've got the business terms and the business terms are associated with the dictionary, which are associated with the data, but it even goes further than that. If you look at the data dictionary level, you know, there's some organizations that document things that I call critical data elements, CDEs or standard data elements. This is what we want the data to look like moving forward. It might not be what the data looks like now. That's when we do our data quality checks to see how our data compares to the standardized data. But you've got the business terms and that business term may point to the standards that are associated with defining the data associated with that business term. But then, you know, you might not have all your systems that are focusing on using the standard name so there might be system names that are also there. So we've got to relate to the data standards to what we're actually calling these things. You may want to call them aliases or something else, but what are we calling these things in the systems that we're using in our organization? I don't know how many of your organizations have the problem where the data can be given different names but it means the same thing. Or it's actually called the same thing but it means something different. And we need to be able to, if we're really going to get people to understand the data, we really need to clear up, provide some clarity to that. What is, what are we calling things and how do they relate to the standards for the data that we're defining in our organization? And then the standard names may also point at some business systems or the system data names may point at business systems as well. And there's relationships between the standard names and the system names so you can see that it's not as simple as just the previous diagram that I showed you that defines the three levels. There's relationships between the different levels of the metadata. So again, this isn't a very complex diagram but what is showing you more in kind of a conceptual manner that you could have business terms that say, well, give me all the information that we want to know about students if you're a higher learning organization or about patients if you're in the healthcare field or customers or whatever it is, you might have a business term that then points to, well, these are all the pieces of data that we have about that object, about that thing that we're defining in the business term. So this diagram actually takes the last diagram and takes it a little bit forward and says, okay, we need to collect all these relationships and that's what takes time. It may be easier, should I say, to get the information into your tool, into a tool like Irwin, but to make those connections, some of the tools have the smarts to help you to do that but typically that becomes a manual effort that really requires some attention to, okay, this is the term, these are the data names that we use, this is how it's represented in the system, making all those connections is somewhat of a manual effort and it requires knowledge of the systems and how they link together as well. So those relationships become very busy or become very important as a part of managing these three levels of metadata. So as I mentioned before, there's relationships between vocabulary and vocabulary, meaning that you might have a term for something that has to do with a student that is still just a term, it's not related to data, but you might relate it to the term student. So it's truly a business term to business term relationship. Then you also might take the vocabulary and connect it to things in your data dictionary and I showed you that before in the previous diagram which is the term connected to the standard business system data element name or the name that's used either the standard or the one that's actually used in your applications. So there's these types of relationships, there's relationships between the dictionary and the dictionary saying, okay, well what other data do we have about this thing in this application or in this system? We know that we need to not only collect those objects themselves at the glossary dictionary and data level but we also need to be able to relate them together and it makes sense to define requirements as to how you're going to use that information before you start taking the time to start linking all these things together. You wanna ask people, how are you going to navigate? What are you going to look for? Where are you gonna start? What is the ultimate outcome of what you're looking for? So once you understand those business requirements for metadata from your business community, you can identify what are the relationships that are important to us to manage. So again, as I showed you in the previous time, the diagram, it goes more than just the three levels, there's the relationships between the three levels which really help people to dig into the data, navigate into the data and find the information that they're looking for to do their job. So let's talk about some of the sources of the metadata at each of these levels. So I talked first about the semantic tier, the vocabulary level, the business terminology, wanting to know what subject that data is associated with and as I mentioned before, it's not data focused and I'll share with you where you can go to get some of the information about those things that are business terms or the language that you use within your organization. I just worked with a client recently that actually took a team of people and said we need to define a business glossary. Here's where you should go to get that information. I'll share that with you in one second here. And here it is. So what are some of the sources of the business terms within the organization? They could be in corporate documents like policies and guidelines and communications. They could be in handbooks that you have that you're providing to the customer or employee handbooks. You can find business terminology that's used within the organization, within these documents, within the catalogs, within the contracts that you have, either internally or externally to your organization. But if you give people the responsibility for scouring through these documents and finding the business terms that we use most often, that might be a very good place to start in building out a list of the business terms that are associated with your business. So again, the corporate documents, the handbooks, the catalogs, as I mentioned before, and I'm gonna share with you a case study from that organization, release a couple slides of one later in the webinar. But that's what they did. They got a group of people internally, gave them a certain amount of time to go look through these things and identify those things that were business terms that were most important to the business. So as I said before, we're focusing on things that are important for the business, and we might wanna come up with a name for what we're gonna call these things. And I love the three bear analogy right here, where we could call them objects, but that might be too general, because an object could mean a lot of things to a lot of people. Yeah, related. So I think that the term is the right things to use for organizations when you're defining your business glossary. And really, they become some of the most basic components of your business. So again, if you look through those things that I mentioned on a previous slide, there's some of the basic components that you use to operate your business. So that's a great place to go in order to get the terminology that you need to fill a business glossary. And here's some examples of some of those things within a healthcare provider, within a financial institution, within a retail organization. We just need to identify those things that are most important to the business, those terms that we use most often so we can get people using the same language. And I've been with organizations where they've had these things called customers, obviously. And customer means something different to each person in different organization. A customer could be somebody that we communicate with or somebody that comes into our location or somebody who makes a purchase actually has a purchase transaction with us. So there's a lot of different things that can be used or a lot of different definitions that could be given to just these handfuls of terms that I'm providing on the screen right now. Think about it in greater detail as to what are all the business terms that really make sense that we're consistent about within the organization. This is just an example of several. So there's not a lot of metadata that needs to be collected about the terms. As I said before, there's oftentimes the term name, the definition, the subject area, the business area, how it can and can't be used. Those would be some of the pieces of metadata that you would wanna collect at the semantic tier at the business glossary level. The business tier level, which again, as I mentioned before, is often referred to as a data dictionary, we're now talking about the business data elements and they can be associated back to the terms as I mentioned in those links that if somebody wants to know what's all the data that we have in the data warehouse about a healthcare provider, then you can start with the term and you can really dig down to see, well, what are we calling all these things that are associated with the business term of the provider within our organization? Typically, as I showed in that one diagram at the business tier level, there's oftentimes two categories of these data elements and as mentioned, one was the standard data element. This is what we want to get to. This is the one that we want to be shared and to cut off the bleeding moving forward. New systems should use standard elements and standard names. There's a much better chance that the data, if you follow the standards, is going to be a higher quality than if you look at the systems that have been developed over the years and you're now associating the system elements to the standard names, well, they can be called something completely different. They can have different values. In some ways, they can have just slightly different meanings. We need to know at the business tier level information about both the standard elements and the system elements. So that's why there's basically two things that we're looking at that level within the organization. And so what are some of the things that we need to know about the business data elements within our data dictionary? And those are things that I'm sure you're familiar with. The data element name, the definition, what size does it allow, nulls, those types of things, the acceptable values for the data, the relationship between that data and other data in the organization. The business rules associated with how you can use that data and the classification with that data is sensitive if it's classified or if it's sensitive or if it's public in nature. We might want people to know that specific pieces of data hold specific classifications which lead us to managing and handling the data in a specific way. And then down at the physical level, that technical level down at the bottom already being collected within your DBMS, within your database system. Even back in the days of COBOL and mainframes, the copy libraries or the copy books had information about the technical data, or technical information about the data down at the file level, at the record level. And so that's where a lot of the physical data can be found that will be used to feed into your technical tier. Robert, are you there? We lost your sound. We lost your sound, Bob. Looks like his audio just dropped. We'll get Bob going here in a second. Sorry about that, guys. Tech is great when it works. Danny, you want to sing us a tune while we're paused? I don't think that's going to help the situation. I don't think that's going to help the situation. Oh, it's here. We can get Bob connected again. So what I was talking about was what are some of the metadata processes that need to be done? And the case study that I'm going to share with you is the change management associated with the metadata. So if you're taking the time to build out a business glossary or data dictionary, you don't want people to be able to change it very simply. You want them to go through a process to control how change is taking place within these metadata resources. The metadata development request, so people want more information collected they want to select critical data elements that are going to be patient of the critical data processes that we need to put in place in order to make certain that the metadata that's associated with the data usage is well documented and recorded within an organization. And we want to make sure that we have the processes in place in order to manage that. So what I want to share with you is this case study, which came from an organization that I worked with not too long ago where once they had built their glossary, once they had built their dictionary, once they had started creating the linkages between the business terminology and the data in their data resources, they wanted to make certain that they had solid processes in place for people to go and request changes to the metadata that they had about the data. So what we're going to change with the business term means we want to make sure we go through a process and we just can't let anybody in the organization change the business term. Same thing with the data dictionary definitions. We don't want, once we've had them approved, we don't want to necessarily make them available to everybody to change, so there has to be a governed process in order to make changes to the metadata. So this is a high level diagram and I just want to walk through some of the pieces of it real quickly, so you'll see the bigger diagram while it's in smaller form in the upper left hand corner of the slide and I've highlighted or circled the piece that I'm focusing on on the screen. So this is where somebody's making a request and there's a standardized request form and process that people go through to make changes to it so they take that vocabulary add change request and they submit it to whoever the person is in the organization that's been designated as being the person that has the responsibility to kind of govern and manage the change to these metadata resources. Data governance manager, it's going to go two different ways. So the first way that I'm focusing on here is that once it's been decided that this needs to change and that there's going to be changes required and there may be technical changes that are required, that's when the data governance manager or whoever it is that takes the request passes it on to some working team or a resource manager that's actually going to complete the request and then get back to the folks who tell them that their request has been approved and here's the changes that have taken place. But then there's the other direction from the data governance manager which is often to take it to a group in this organization, it was called their data governance steering committee to get them to review it, compare it to what it is already within the vocabulary or the business glossary and they come to a decision as to whether a change can be taking place or not and that decision point comes back to the data manager who if it's approved then goes to the resource manager and such that we just talked about on the previous slide. And the ultimate on the far right hand side of that graphic that I used for the case study is the data governance metadata platform or your data dictionary or your business glossary data catalog any resource that you use to manage the information about the data within your organization. So meanwhile, should I say while all of those activities are taking place over here, try to point at it here over here, we wanna make sure that the end result is that the information gets cataloged somewhere. As I said earlier when I defined metadata it doesn't really become metadata until you get to a point where it's now being used, recorded and used by people across the organization. The main diagram, that's the complete diagram and we broke it down into different components but you need to have a formal process in place if you already have a process in place apply governance to it. That's more non-invasive than invasive but you really need to decide that you're gonna make sure that this information that you've now taken resource time to collect that it's going to be used it's going to be maintained properly throughout the organization. And here's an example I mentioned real briefly the critical data element process. So here's what another organization did as they were starting to identify what were the critical pieces of data and I know this is really complex and I'll share this with Shannon so she can share it with the group or share something like it. It's a typical racy chart with the different colors of the different columns being associated with the different roles and responsibilities that you've had associated with your program. So now let's talk about what resources are required and typically, first thing I like to do is take a look at what resources are gonna be required for data governance before we ever get into the aspect of metadata governance. So people talk about the need for senior leadership sponsorship where I say they're not only their sponsorship they're supporting their sponsorship in their understanding. There's a need for a role of a data governance manager data governance council stewards working teams all these different roles are typically associated with data governance. Now let's look at those roles as they associate with metadata governance. Well you might not need senior leadership or sponsorship around your metadata if they've decided that it's important enough that you have a metadata management program you may not need to engage them that much. You might not even need to engage your data governance council that much but they have a similar set of roles associated with metadata governance as you would have associated with data governance because metadata is just a different type of data. And just like master data is it's still data but people call it master data governance. We're gonna talk about that next month so please tune in for that. The resource expectations to assure quality metadata at the senior leadership level while we need their support sponsorship and understanding typically there's very little time commitment that they can provide or that they're really necessary when it comes to assuring quality metadata typically they lead the approval by committee. So when somebody decides that they wanna change a business term you might take it you may not take it all the way up to your senior leadership you might take it to your council but you need to have somebody who's going to take a look at it before that change is being approved. And so the truth is that typically in organizations that their business glossary efforts barely ever even tend to get off the ground unless there's a high level of understanding by your senior leadership to approve and to improve the business and understanding of data across the organization. So when senior leadership decides that improving business understanding of data is important you're gonna focus your glossary on the things that are where they're applying their resources where they are putting money into other initiatives like business intelligence, analytics, master data, big data and those types of things. So if they recognize that we're putting a lot of money into these resources into these types of activities we need to make certain that the data is well understood once it gets into the hands of the people that are going to use the data. The data governance manager typically they manage the business glossary process where they facilitate the resources in the organization that I mentioned earlier in the quick case study. And they had a person that was basically on top of the people who were, or should I say they were constantly in communication with the people that were being tasked with collecting the business terms and the data dictionary for the organization. Who has the responsibility of doing that? And oftentimes it's the data governance manager. They develop and gain approval of the glossary and the policy. They facilitate change management. As I mentioned before, they were smack dab in the middle of the process that I shared with you. And they're one of their responsibilities is to report the results of the improvement of the collection and the use of this metadata to management. Let them know that the time and effort that's taking place has been worthwhile in what they're collecting. The data governance council, well sometimes you might involve them in approving things to be changed in the vocabulary and the dictionary. And oftentimes they just have limited involvement as well. If you have a monthly or a quarterly data governance council meeting, you might take a part of that meeting and you might use it to say, okay, these are the requests that came in. Do we want to move forward? Do we want to investigate them further? That's how you would get your data governance council involved in assuring the quality of the metadata. The data stewards, now they're invested, they have invested interest in all three of those tiers in the semantic level, in the business level, and in the technical level. And oftentimes they're the ones that provide the business definitions at the dictionary level. They're involved in the validation process before these things are approved and put out there for general consumption. And oftentimes these people at the data steward level, the people that define, produce, and use data as part of their job, they're the biggest users of the business glossary and of the data dictionary as well. The working teams, as I mentioned, with that one organization, they created a working team of critical resources to go out and investigate what the different terms were that were being used within the organization. So not only that, once they had completed the terminology, the business glossary, their next step was to focus the same way on the data dictionary. And with this organization, they were focusing on a data dictionary associated with all the data within their data warehouse. So with the working teams oftentimes, again, depending on how quickly this needs to be done, there could be significant time commitment. They need to be involved in researching the different business glossary terms and then be involved as well in reviewing the change requests that are coming in to change things that you've collected. And there's less of a time commitment. Once the glossary is developed, certainly it's going to be front-ended with work associated with building these metadata resources to be used across the organization. And what's the role of IT? Last but not least, or I think they're last, they're the ones that oftentimes are, people come to them and ask them to change. Can you add this column to this table? Well, no, no, you can't add this column to this table unless you go through a governed process to say that we need this piece of data. How are we going to use this piece of data? They're the ones that make changes to the physical databases, to the logical data models within tools like Irwin. And there's oftentimes a time commitment required to make these physical changes. And they may be involved in the validation and they follow the standards for data and database design. So information technology is heavily invested in assuring the quality of metadata through the organization. Well, okay, so last but not least, there's the requesters. They're the people that can be basically anybody within the organization who at least thinks that there needs to be a change to some of the metadata being collected about the terminology, about the dictionary, and then about the technical aspects of the data itself. So there's a lot of different roles that need to be involved. We want to be very clear about what we're going to ask the people in those roles to do during the process. So in this webinar, basically I discussed these things. I talked first about the three levels of metadata and how simple it was to have just those three levels. And we talked about how they were the same, how they were different. But then we also looked at, well, what do we really want to do with that information? Do we want to connect the dots and give people the ability to navigate? So we talked about the sources of the metadata. We talked about linking together the different pieces of the three levels. We talked about processes to govern the metadata. And then we talked about, you know, institutionizing this within your organization, getting people involved to assure quality metadata at all levels of the organization. And with that, I want to turn it back over to Shannon. Before I do that, real quickly, just to remind you, the webinar next month will take place on December 20th, the third Thursday of the month, right before Christmas. And we'll be talking about how to govern your master data. And with that, now I would like to turn it over to Shannon to see if we have any questions today. Bob, thank you so much for another great presentation. So, you know, actually the first question in here, which came in, it's for you, Danny. Does Edge integrate with mainframe technologies? And does it integrate with WebSphere, IAB and MQ? The question is for Danny. Oh, and I got you muted, Danny. Okay, I'm sorry. Does Edge integrate with mainframe technologies, JCL, Natural, et cetera? And does it integrate with WebSphere and IAB and MQ? Yes, yes on all counts. So, we have connectors to mainframe all the way to the latest and greatest in big data and everything in between. So, and you know, with our interfaces, you know, once you define them as a metadata source, you can automate the process, put that under lifecycle control and really have that sniffing and scanning for change data in the background while you enrich the metadata in the catalog. So, going into the topic here, you know, what's the best place to start gathering terms is it project documents and internal corporate webpages? So, you know, I shared a few different examples of places where people go to get that information and it can be documentation, it can be the handbooks, it can be documents that are customer facing within your organization because if they're gonna use certain terms or if you're gonna try to get them to use certain terms, you wanna also be using that terminology within your organization. So, yes, the places that you mentioned were great places to go to find the business terms, but typically you need to have the resources to do that and then pick the best resources that you can find within your organization and see where they take you as far as what terminology is defined for the business. And Danny, feel free to jump in anytime on any of these questions. Just jumping down here, is it fair to say that the semantic here is often represented in a conceptual data model? Would it be better to represent that or would you recommend a logical model? You know what, I'll let Danny address that first if you'd like. Sure, sure. Well, you know, I think that the model itself is a good representation, conceptual or logical, I think you'll get some disagreement with different practitioners. I think importantly though, the process of modeling and the interface that you have with your customers out there as you go through the modeling process is a great way to source that stuff. I think ultimately it all needs to go and be depicted inside this combination of the three tiers of metadata between the glossary, the dictionary, and the catalog. So it really depends on how your modeling process is configured in your organization, but either of those I think are appropriate and then again, utilizing them as the source to start filling out the different metadata devices that you have in your organization. And you know what, I also find it as being a great communication tool for people that aren't really as dug deep into the metadata as we may be, where we can say these are the things that we're trying to collect. If you know the diagrams that I shared, they weren't really conceptual models. They weren't really logical models. They were some hybrid, somewhere in between. Basically it's that these are some of the things that we know we need to manage and this is how they're related to other things. So I think when you're starting with business terminology, you certainly could start with a conceptual model, but when you get down into the definition for the data for the system, specifically as Danny had mentioned, having logical models and having a governed process for modeling your data makes a lot of sense and therefore if you have that in place, the quality of the metadata at that level becomes a lot higher. It's no, you don't have the cheeseburger definitions that I've spoken about before where the definition of a burger, of a cheeseburger is a burger with cheese or the definition of a patient account is an account for a patient. Now if you have good modeling processes, you're gonna have better definitions than cheeseburger definitions and that's gonna improve the value of all of this metadata. Yeah, absolutely, a lot of organizations we deal with score their data models as part of the process and that scoring will really pay off as you start extending and expanding it out into a more formalized governance operating framework. Yep, yep. You know, we get this next question quite a bit. Actually, you know, what percentage of organizations would you say recognize the value of investing in governance and metadata management? What percentage? More than the auditors or the examiners have something to do with that where they say, hey, your data is not documented, your processes aren't documented so you need to do that. I'm finding that more and more within organizations that are being told that they really need to do this to show that their information technology environment is well in place. As far as percentages go, I would say at least half of the organizations are looking at some form of governance to play in place. I don't know, Danny, what's your experience? It's funny, we did some research at the beginning of this year, you know, looking at sort of large to very large companies who had, you know, over a thousand respondents. So I wouldn't call it scientific, but it's not a bad wet finger in the air. And the response directly to that question, 98% of the organizations thought that data governance was important and something that they had to undertake a little less than half of them had made any progress in that domain. So it was a very interesting and telling answer, I think, in terms of just the challenges of all the pieces that you need to put together, how you get started and things like that. But I thought that was a pretty interesting number. Those are great numbers. Yeah, and you know, typically, the question that comes in right after that is, you know, what is the elevator pitch? What do you tell those who haven't invested in it yet? How, what kind of value it's gonna add? Well, I'll be glad to share mine first is, you know, I actually would start the elevator pitch with, you know what, we're already doing this. We're already governing our data, but we're doing it very informally. We're doing it very inefficiently, which leads to very ineffective use of the data. And so if we can put some formalization around some of the things that we're doing, granted, there's gonna be a need for changes. But if we can take that approach, and that's kind of what I call non-invasive, is say, you know what, we're already doing this, but we can do it better. Let's focus on doing what Danny talked about, improving the processes associated with data modeling so that we have, or grading our models to make sure that we have high quality definitions within our data models. So it's, I find that there's certain things that organizations could use, but I like that pitch. I like to say, you know what, we're doing this already. We don't need to reshuffle the deck. We just need to get our cards in order. Yeah, and if I can add to that, Rob, because I think that the non-invasive piece will absolutely resonate with any senior management where this doesn't look like some sort of coup or 100 years war that they're starting to get engaged in. When I talk about data governance, it's very simple to me. You have a strategic asset that most organizations are still not managing as a strategic asset. And in order to get the return on that asset, you need to reduce the risks and increase the trust and impact of that or trust in that data across your organization to really get the return on investment or the return on opportunity that that data represents. Getting there doesn't require boiling the ocean. As Rob said, a lot of this is going on. It's about trying to find a way to capture that those tribal processes, tribal knowledge and institutionalize it and everything that is good about data standardized and then reuse that to get success, iterative success over time. And you know what, I had a chief financial officer ask me recently, how many stewards are we going to need and how long are we going to need them for? And to me, I thought that was a funny question. I knew the guy quite well, I kind of looked at him and since they were focusing on data quality, I asked him, how long do you wanna have quality data for? He said, well, we always wanna have quality data. And then he looked at me kind of funny and said, okay, I get your point that this is really a program. It's not a project that has a beginning, a middle and an end. It's a program that's going to be in place for how long you wanna protect your data, how long you wanna improve the data. And you made a good point. You said, talk about the value, the return on investment. Oftentimes, since organizations are investing more heavily in technology and in data analytic platforms and things like that, big data solutions, they're already putting a lot of investment in those things. And I usually say, well, let's look for what investment, what the return is that we're getting on those items, rather than the return on investment that we're just specifically getting from data governance. And if we can then partner up with these activities, we have a much better chance of demonstrating to our leadership that this is very valuable to the organization, maybe we can get that number up from a little bit less than half of the organization who started to embrace this to a number quite a bit higher than that. Well, so what is an average timeline to develop a glossary like this? It feels like a massive undertaking. It's viewed as a massive undertaking. I mean, if you sell it to your organization as a massive undertaking, that's what they're going to think. But if you can get a group of people who have an interest in improving the understanding of the data and they can allocate a certain amount of time per day, per week over a period of time to investigating these resources that we spoke about earlier to pull out your business terminology, it doesn't have to be that daunting of a task. If we do it in a structured way, if we have a plan and we don't tell people that it's going to be extremely time consuming and just use their time the best way we can, you can limit that. You can do it over a course of a month, over a course of a couple months, again, depending on the amount of resources and the amount of time that they have to spend on this. Yeah, we've found similar results. People that are trying to boil the ocean and creating a glossary as a task onto itself generally get bogged down in the sort of never ending, is it done yet? Is it done yet? A lot of our customers are leveraging our integrated enterprise architecture to really drill down into the goals, priorities and motivations of the business, find that sweet spot, and then leveraging, as Rob said, lots of great documentation that's out there that you can grab, but also looking at what's going on in data management today and what have they done, specifically those logical conceptual models to start pulling out a specific domain or subject area and really using that as the foundation to start refining that on. Also, there's the old amazing spreadsheets that are all across the enterprise and getting hold of them as best you can and pulling them into a platform where you can start to categorize can definitely accelerate the process. Yep, and like I said, like you said, don't boil the ocean. I mean, you might wanna start specifically focused on a subject area or a domain and get a process working so that you don't have to redefine the process for the next set of information that you're documenting. So I'd say start small, start incremental, demonstrate value, and then move on to the next. Yeah, and set expectations, give them roadmaps so that they can really see where you're gonna be and how it's gonna grow. Absolutely. Do you have any suggestions on how to avoid having terms to find the terms themselves? Is that similar to the customer talk? Get yourself some good analysts and put some good tools in their hands to help them through that process of really drilling down into what's important to the business when it comes to that terminology, that data. And use the synonym function within your word processing tool. I don't know if they call it word processing. See, we don't have to use the same terms, but we can get them point across using other terms. So yeah, I just hate using the terms that we're defining within the term itself. Sometimes you can't avoid it, but try to stay away from it as a best practice. Well, I'm afraid that does bring us to the top of the hour. There's a lot of great questions left. And if you do have additional questions, go ahead and type them in the Q&A. I will get those questions over to Bob who will include them in the follow-up email that will go out by end of day Monday for this presentation to all registrants with links to the slides and the recording as well. Again, thank you both for these great presentations today. Thanks to Irwin for sponsoring and thanks to all of our attendees for being so engaged in everything. We do love all the questions that have come in and all the engagements are out. Thanks, everybody. I hope you all have a great day. Thanks, Bob. Thanks, Danny. Thank you. Thank you. Bye.