 Hello and welcome, my name is Shannon Kemp and I'm the Chief Digital Manager of DataVercity. We'd like to thank you for doing the current installment of the Monthly DataVercity Webinar Series, Real World Data Governance with Bob Sinner. Today, Bob will be joined by special guest, Lil Freiman, to discuss metadata governance for vocabularies, dictionaries, and data. Just a couple of points to get us started. Due to the large number of people that attend these sessions, he will be muted during the webinar. If you'd like to chat with us or with each other, we certainly encourage you to do so. Just click the chat icon in the upper right-hand corner for that feature. For questions, we'll be collecting them via the Q&A in the bottom right-hand corner of your screen. Or if you'd like to tweet, we encourage you to share highlights or questions by Twitter using hashtag RWDG. As always, we will send a follow-up email within two business days, containing links to the slides, the recording of the session, and additional information requested throughout the webinar. Now let me introduce to you our speaker for today, Bob Sinner. 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 Daimeth Professional Award for significant and demonstrable contributions to the data management industry. Bob specializes in non-invasive data governance, data stewardship, and metadata management solutions. And with that, I will go to the floor to Bob to introduce today's guest speaker and to get today's webinar started. Hello and welcome. Hi, thank you very much, everybody, for taking time out of your busy schedule to attend the webinar. And I'm very fortunate today to have a special guest, which I'll introduce in a minute. But as Shannon mentioned, this is a very important topic for a lot of organizations. There's a lot of organizations that are focusing on metadata, focusing on the governance of the metadata, and specifically for three different levels that I'm going to kind of introduce and then ask Lowell to provide his opinion on and his perspective and his experience on. So I'm going to talk a little bit about business vocabularies and business glossaries. We're going to talk about dictionaries, and we're going to talk about the data, the metadata for the data itself. So we're going to go into a lot of detail on some of those things. We have several topics that we're going to address today. I'll go over those in a minute. Before we get started, I just want to remind you of a few things that are going on in the data governance industry. All things that I've been involved in recently, and a lot of them are working with my partners at Data Diversity. First of all, the Real World Data Governance series takes place on the Thursday of every month. And I'm glad to have you back next month. We'll be talking about using data governance to achieve data quality. If you're not familiar with the book Non-Invasive Data Governance, then you should be, and you should go check it out and see how data governance can be non-invasive. I'll be speaking at a couple of events. The first one is the granddaddy of them all, the big data event, or should I say the biggest data management event in the industry, the enterprise data world event in San Diego. And I'll be speaking on using and building maturity models for data governance in San Diego as well in June. I'll also be speaking at the Data Governance and Information Quality Conference, speaking about how to save a failing program. And there is a non-invasive data governance learning plan that's available through Data Diversity, and everybody should be aware that the month of March is Data Education Month at Data Diversity. So if you're looking for ways to save money and get some good data management education, please follow data, you know, hashtag dataEDU to learn more about things that are available through Data Education Month at Data Diversity. As Shannon mentioned, the Data Administration newsletter is available twice a month on the first and third Wednesdays of the month, and please subscribe if you're looking for information about what is published on a monthly or bimonthly basis. Last but not least, KIK Consulting and Educational Services is the home for non-invasive governance. So if you're non-invasive data governance, so if you get a chance, please stop by the website and let me know what your thoughts are on non-invasive data governance. I am honored, and it is my privilege to have with me a friend of mine, been a friend of mine for many years, Lowell Freiman. He is a practice principal and capability manager at Calibra and their customer success team. He's co-authored a couple of different books. Business metadata is one, and the data and analytics playbook is another. Lowell has held positions within DAMA and DAMA International, and the way that I know Lowell the best right now is that he provides a quarterly column to the Data Administration newsletter on business glossaries and metadata. So when I was looking to determine who was the best person to have as my guest for the subject of metadata governance for vocabularies, dictionaries, and data, I couldn't think of anybody better to have than Lowell. Lowell, can you say hello and... Sure, the sound works, right? Thank you very much for that introduction, Rob. I am very pleased to be here, and I really hope we'll enlighten and inform the large audience that you have. That's great, and this is a very important subject. As you know, as we've talked about, it is something that a lot of organizations are looking at or will be looking at at some point in the future. So the things that we're going to talk about today and the questions that I'm going to pose to you, Lowell, so you can provide your experience are focused on these five things. We're going to talk about, first of all, the differences between vocabularies and dictionaries and data and the metadata that's there to support each of those three levels. We'll talk about the metadata that populates each of these data stores. We want to talk about metadata governance specifically in this webinar. So we're going to talk about some of the roles and responsibilities that might be necessary if you are going to begin to govern your metadata. We're going to talk about applying governance to metadata processes, and last, we're going to talk about some requirements for tools that are associated with governing metadata within your environment. There are five topics, like I said, that we're going to talk about today. We're going to spend approximately five to ten minutes on each of these. The first one that I want to talk to Lowell about is about the value add from vocabularies, dictionaries, and data. And I thought that I would start out real quickly with a description from my perspective as to what the difference is between a vocabularie, a dictionary, and the data. Typically, if you've seen my webinars on metadata management, typically I break it down into these three levels. The first one is the top level is the business glossary and the business semantics. These are terms that are associated with your business and providing good descriptions for those terms so that people in the organization are speaking the same language. Typically, when organizations start with business glossaries, they're not necessarily, at least at the beginning, associated with the data dictionaries, and the data dictionaries from my experience are resources, metadata resources that are associated with a specific application or a specific use of the data. So you might create a data dictionary that defines all the data within your data warehouse within a specific application or ERP package within a data lake. So data dictionary is the next level down from the business terminology, and it describes the data that resides in the system but more from a business perspective of the data in the systems. And the third level of metadata is the physical level of metadata, and that's basically in the olden days they would call a metadata repository. I hear the term data catalog being used. It's really the technical metadata that's associated with the data in your systems. So we're talking about more physical names, physical attributes of the different types of data that you have in your system. So really, Lola, my first question for you is are you lined up with me? Are you aligned with my thinking as far as the three different resources associated with metadata in the organization from the glossary, the dictionary, and the data itself? Absolutely. Actually, the challenge is, though, is semantics, right? Which is the big challenge we're trying to solve with the business side of business glossary. But very often the metadata repository data catalog is called the data dictionary in some technologies. So, you know, we introduce our own confusion on terminology. But I think you clearly describe it. Thank you. Okay. And you know what? I think you're right. I mean, one of the things that we as data practitioners are trying to do is to clear up some of that confusion. So I like to be consistent in the way that I talk about it. You know, typically, again, terminology and semantics at the highest level and then information about data in a specific system within a dictionary and then the physical metadata itself. And so, you know, maybe from your perspective and from your experience, you can provide a description of each of the three different levels and, you know, what are the relationships between them? You know, is it better at certain times to focus on one versus the other? You know, all the questions that I have on the screen right here. Can you kind of, can you answer those in relationship to those three metadata resources we just talked about? Yeah, let me do that without writing the book here. By all means. So, you know, business philosophy, primary purpose and primary content is all about the business side. Not the business metadata. What is the business term? How do we define that? What's the value set for it? For example, you can put in. And there's a few other things we'll get into later. Now, the data dictionary is what we've all known, loved and hated about our applications because they do describe most often just the physical environment and if they really talk about, you know, anything at a business level, they're talking about it from the terms of how the application uses the data, not how the business views the data, shall we say. So, it's very an application, a technology-centric view of our data in that application. And the data catalog is very much, then, a meta-data level view. It's got a lot about the technology which it might import, generally, from the data dictionary. But the catalog, generally, is more enterprise level, robust above an individual application. So, you may have one data catalog and many data dictionaries and hopefully have one business glossary that includes the enterprise level as well. The relationship between them very much is over time, you know, as your data governance matures. And let's say, you know, very often get into it. Data governance and meta-data governance often begins at the data dictionary level, gets imported into a data catalog, and then we build a relationship to the business glossary so we have a relationship between business terminology, actual data in applications, and a good understanding of the technical meta-data and framework around that. So, the three are important to have relationships. So, we can quickly... Go ahead. So, when organizations are focusing on building glossaries and dictionaries and catalogs, just kind of going with that terminology for the time being. I mean, does it make sense to do all of these things together, or is it appropriate to start at one and kind of work your way into the other? What has your experience been in organizations that have tried to implement these meta-data resources? Do they do them all at once, or is there a reason that an organization should focus on one versus another? You know, you have excellent questions, Rob. Thank you. Yeah. I would suggest, and the reason the shameless plug on my data and analytics playbook, we take a business playbook view of implementations, which is really nothing. It's more agile. You do these together with a finite scope, and very often it's somewhat a governance beginning with the data dictionary, because we all know the data we use, and we're concerned about governing that critical data. So, from that standpoint, we build these together, shall we say, along a finite scope of some critical data elements, rather than just, you know, let's build a data dictionary for all our applications or data catalog for the enterprise, or business glossary for the enterprise. That's almost a never-ending project, because your business terminology will always enhance and change. So, if I answered your question, it's really to build these together with a finite scope of some number of critical data elements, and I've often find that, you know, you try for 15 and end up with 75, and you do that in two or three months' duration. Yeah, you know what? And recently I've had the opportunity to work with organizations that were setting up these different levels of metadata. And oftentimes, from my perspective, I've found that a lot of individuals, a lot of organizations, should I say, have a specific group of people focusing on business terminology. For example, in the health insurance field, going through provider handbooks and employee handbooks and subscriber handbooks and things like that, and just pulling out the business glossary terms, basically the language that we speak, and then drawing the linkage from those to the data in the applications, the data in the systems. So, thank you for answering that question. There is a lot of business value, and a lot of organizations don't necessarily start out doing them all at one time. They may focus on the data dictionary first. That seems to be the traditional metadata resource that a lot of organizations are working on. Now, I told you before the webinar that I wanted to spend time specifically focusing on metadata governance and the governance of the metadata itself. So, you know, I'd like to hear from your experience how metadata governance is different from the traditional ways of implementing data governance within the organizations, and maybe you can share with us some examples of some of the organizations that you've worked with, maybe not specifics, but how they have set about to govern their metadata. Yes. Very much the organizations that I advise is around being their practical, being very focused on delivering value quickly, and also using non-invasive resources. Thank you for that concept. So, we definitely find that people are focused very much about the data dictionary. Certainly, you know, it becomes a question of what data do we have and how do we have it. And the metadata itself is, oh, gee, I've described it to somewhere about 70 to 100 different attributes of metadata attributes you can build between your glossary and your data dictionary effectively about the data. The metadata governance, though, certainly focuses on more so on the technical aspects of ingestion and usage of the metadata. You might consider it or sometimes back office activities rather than front office, take a governance activity with data stewards. It's more of activities or technical stewards and different technical stewards. It's also associated with the data dictionary and the processes to ingest metadata from those data dictionaries or data catalogs. Typically, when I talk about data governance, I define data governance as it's the execution and enforcement of authority over the management of data. Could we use that same definition and say it's the execution and enforcement of authority and management of metadata? Yes, we could. Okay, so I typically break it into three different functions. The definition of the metadata. Somebody in the organization needs to define what metadata is going to be important. You mentioned 70 or 80 or 90 attributes that could be either shared or could be used within each of those metadata resources. Somebody has to select what the metadata is and has to define what that metadata is for the organization in order for the organizations to really successfully govern the metadata. Somebody has to have the responsibility of producing that metadata and making certain that the metadata adds the terminology and adds the things change in the descriptions of the data or the valid values of the data that somebody has that responsibility around producing the metadata. Then the third action is that people can use the metadata and there has to be governance around how people can use it, who can have access to what metadata. So I typically break it down into defining producing and using the data, using the metadata. And can you say how would it be different around metadata than it would be around data? I think you mentioned back office, front office, that a lot of times you're going to get the business people involved in the data governance. But are you thinking that the metadata governance is more a function of the people that are physically defining the data? Yes, I do. I often call them the technical stewards, right? Because they have to manage technology and the concepts around the technology. But there's somewhat, to a certain extent, a little overlap as there always is in things. There aren't black and white clean lines. For example, the metadata might not have a code set in it per stay, but it's got a data type, a data length, a precision. That technical definition. Is it a key or not a key? Is it primary key, foreign key? Those sorts of things are in the metadata themselves. And it doesn't address the data, nor would our data governance really be concerned with that because it's certainly more technical in nature. And there aren't fine lines. Some people would consider a code set, like a set of country codes, to be metadata. I certainly don't. The definition of the columns and the length of the columns and precision, et cetera, I do. That's technical data and needs to be governed as such. And just like we would govern the data. Okay, so to me, it seems that we're defining different things. We're defining the metadata versus defining the data. And as an example, again, recently with an organization that I worked with, they made certain that once they published their data dictionary for their data warehouse, that if anybody wanted to change anything within the descriptions of the data in the data warehouse, it had to go through a governance process, meaning that a request had to be made to change the metadata associated with the data in the data dictionary that represented the data in the data warehouse. So that's one of the forms of metadata governance, is making certain that you just don't have it as a free-for-all and that people can re-describe your metadata or re-describe even the metadata that is being recorded in these data sources. Now, I agree with you with what you said about the code values. Some organizations do consider that to be metadata because it's data about the data. But in reality, it's really data, the information about the code values, how it's described, how it's defined, what it is categorizing and those types of things would be the metadata. So there is a clear distinction oftentimes between what's considered business data that needs to be defined and the metadata that needs to be defined. Now, let's move on to a little bit more of a focus on the governance of the metadata itself. I think you called them technical data stewards or the people that might have responsibility for the metadata that's going into either the glossary of the dictionary or the data catalog. In your experience, how are the metadata governance roles different than data governance roles? Do organizations go to the same lengths to define the roles associated with metadata as they do for their data governance roles? And should they? I mean, do you think it's important that clear distinction of roles and responsibilities should be defined around metadata the same way that they're defined around the data itself? Excellent question. And since many things are not like default, preference is that from my view, of course there should be to answer your question. Yes, there should be roles around that. But very often organizations really don't. They use or reuse the technical data stewards from data governance to also govern the metadata. And that sometimes can certainly overwhelm the individuals in those roles. And data governance will take precedence over metadata governance just about every time. Now, what am I concerned about with metadata governance? Data governance is very much like we might be with data governance, that it's defined properly, that we understand how to use it, when to use it, why we should use it, all of the six operatives around the metadata itself. But also that we have good metrics and processes around not just definition and usage, but the actual technology processes to ingest metadata into the data governance platform, for example, to ensure that the latest metadata is available to all our governance resources. And then we have some measurements of quality around it. I've been involved with a few new customers. I'm sure you have that their governance programs are not as effective because they haven't managed the metadata governance side. Did your import of metadata from your data warehouse application actually run last night? Do your stewards have the latest information to work with? And I've seen programs having challenges because they forgot to put metrics and governance around the metadata program that feeds the data governance program with this technical dictionary and catalog information. Yeah, I think that's a real important point is that, you know, and from my experience I've seen the same thing as well, which is that data dictionaries, the things that describe the data in the applications are originated when these data stores are being created, but there's not necessarily any ongoing process for keeping that information up to date. And, you know, metadata becomes such a valuable resource to the organization that in order for you to continue to get the value out of it, it's important to have processes and procedures around how you define your metadata, how you produce your metadata, and how you use your metadata. You know, one of the things that I would really love to hear from you is, you know, and I think that you've kind of answered this, but I'd like to maybe have you elaborate a little bit more, is who's responsible for the governance of the metadata? Is it really the technical data stewards? Do we need to involve the business community? You know, basically who has the responsibility for owning the processes that are associated with the metadata? Is that a technical role as well, or does the business get involved in that? One, it should primarily be a technical role. If you wanted to use the term ownership, ownership should be certainly, it's a technical ownership in a way. A technical stewardship. Now, does the business get involved? Great question. I'd like to have them involved. Because, you know, many times they know better because of their usage of data and data governance. They end up knowing better about the metadata itself than the technical people. You know, and you're absolutely right. You know, it often, particularly data dictionaries, they get defined when you first implement the application and they never have smelt change management, issue management, new releases. Those things just don't happen because the application environment doesn't have the, let's say doesn't have the resources or they don't actually worry about it, right? So things don't get implemented. And we often see that as, you know, a challenge that smells like it's a data quality problem when in fact it may not necessarily be a quality problem in the data. It may be a quality problem of the metadata. And we, you know, we don't keep that up. We don't understand it. We can't communicate any changes that may have happened around the metadata through data governance or business people. And so I know this will be a question that'll be near and dear to you, especially in your present role, is how can the tool, how can a data governance tool or a metadata tool assist with providing the appropriate levels of governance around the metadata? A couple of ways. One is certainly recognition of, you know, less ingestion and maintainability, which we often call quality of the metadata by itself. But also in bringing in or visualizing the data lineage and traceability of the metadata to the data governance team. So technically we have to have this traceability, by all means, from data dictionary or application application ETL process to ETL process till we visualize data. The data governance team needs to know all of that, excuse me, lineage and traceability to even assess, at one point, quality of data. And where does it come from? What's the right source and authoritative source that should be used because of differences in the metadata and the quality of the metadata? I typically look for the data governance tools to kind of formalize those processes. And once we've defined the roles of who should be involved, helping to make sure that the processes flow effectively, that the metadata is being collected. Let's spend a little bit of time talking also about applying governance to your metadata processes. So I had already mentioned kind of the definition process, the production process, and the usage process. Can we differentiate between the metadata processes and the data processes, or do they become one and the same as part of any major data initiative? I think I'm going to lean towards the... they get blended in. You know, particularly if the strong data governance team, a lot of the metadata governance gets blended into, again, probably the same resources, by all means, being the technical stewards, to identify if the metadata is correct as we have documented in the data governance program. And have we kept it up to date? What's the level of quality in it? So those same resources can help us with metadata governance. And we can call it... many people call it under the program of data governance. Okay. And so since a lot of organizations and a lot of the people that are participating in this call are most likely looking at or have already started to implement data lakes. You know, the one thing that I joked about in a webinar two months ago about data lakes, or at least in part about data lakes, is that they become data swamps. They become places for people to dump data where there is a lack of metadata. In fact, I had a conversation this morning with a client that is putting a lot of data into their data lake, but that data is not necessarily understood. So is there a way that you've seen that organizations have been successful in kind of synchronizing their metadata processes with their data processes? Have you seen data lakes to go oftentimes undocumented? And what would your suggestion be to kind of incorporate the metadata processes with the data processes associated with the data lake? Yeah, I think you opened Pandora's sponsor. It is for a lot of organizations. Yeah, exactly. Let me explain a little more. I think we are at our infancy of maturity around data lakes, and property data lakes by all means. And, you know, Shaman, us, the technology side of the house, we've initially seen it as a cost reduction dumping ground by everywhere, not my problem anymore. Report writer, it's now your problem. So, you know, ignore my discussion here a minute, but to answer the question, yes, there is a vast void that is not totally understood that our data lakes, depending on the technology you have, can have absolutely no metadata. It's just zeros and ones on the distributed hardware platform, right? Now there are some that do, but a pure Hadoop platform has no metadata, has no security, et cetera. Some of the newer ones, which is why they're coming out, right? Cloudera, I believe some others do have metadata. You can look at Gluc or Spark. Those technologies have some metadata. So I ingest my metadata in a data lake environment with my data governance. I ingest spark or glue, actually, to help me build the data catalog for data governance usage. Okay, so for those people that are on the call today that are creating these data lakes, ultimately who should have the responsibility to make sure that the data that goes into the data lake, again, and if you're using it as a sandbox to kind of throw all your data in and to work from it that way, that's okay, but we've proven over the years that data that is better understood, that organizations get better value out of that data. So if the data is going into the data swamp unfiltered without the metadata being defined with it, who's accountable for it should organizations kind of stop what they're doing and start to focus on putting solid definition to the data in the data lake, or do you think it's better served just as being that sandbox or that dumping ground? In a way, that's an organizational decision, but I've seen most considering it as a dumping ground and they need to reconsider that, you know, there's a difference between the sandbox, as you said, that's great data scientists. Tell me what's valuable data in there and then we can begin worrying about creating good governance in the lake to have a good lake. By all means. But you know, you can't stop to train in a way. Once organizations have decided they're going to use a lake and that technology, they're going to use it. You don't want to stop it, but you have to get the mindset changed a little bit. You have to have governance, because what you have is not a data lake. It's a swamp until you clean that up. And then you have a lake, right? So the architectures today that are more prevailing are basically calling a lake instance, a raw lake, and then another instance where you have applied data governance and integration processes around it and that's more of a lake than a swamp. And organizations are also building data lakes similar to data works. So they are specific to a certain business unit or technical implementation. So you may have multiple instances of data in the data lake platforms from raw governed and self-service environment similar to what we ended up with after 20 years of working with data warehouses. You know, I've actually found that oftentimes the level of metadata governance is directly related to the level of data governance. If the data governance office or the data governance team is looking for ways to be able to add value to the organization, as one example with an organization, they're putting a policy in place so that any tables that are added to the data lake have at least a bare minimum amount of metadata being recorded about it. So I think oftentimes the ability to be able to govern the data in the data lake oftentimes kind of comes back and is a reflection of the data governance program itself and how they figure, you know, where are they going to get involved, where are they going to be able to add value for the organization. So the last topic that I wanted to address with you all, before we turn it back over to Shannon to see if there's questions for today, for either of us, is really more associated with the requirements for the tools that are associated with governing metadata. And so I know that you work for a software vendor now and that you've had experience of working with a lot of the products that are on the market. You know, typically from organizations that are defining their metadata requirements, who are the people that are involved? Is it typically all technical people? Is it technical people and business people? Is it strictly business people? What has been your experience in the who in the organization that are defining the metadata requirements for the organization? Yeah, yeah, again, another wonderful question. It may, in terms of the metadata requirements and who's defining those, it's heavily flavored on the, or influenced by the technology side of the house. But you need business, for lack of another term, let me just call them business stewards, data stewards, business people that understand the data and how it needs to be defined and what's valuable to get out of it. So I've often added, on the teams doing the requirements, the business analysts, BI program managers, because they heavily understand the metadata requirements. They need for usage and what governance would be necessary around that. But again, that's still a little heavily influenced by the technology side of the house. I do like to get business people on it. Again, particularly business intelligence and even data scientists that I've been able to grab for those organizations that have them. All right, and so if we break it down and we've broken it down logically into those three classifications, three categories, the glossaries, the dictionaries, the metadata repository or the technical metadata, is it possible, and have you seen it possible to collect all of that information into a single tool or are there tools that are better for glossaries versus dictionaries? Are there tools that are better from the technical data perspective? Are you seeing that there are tools out there in the market that can actually be used to govern all three different levels of metadata? The answer is yes. There are tools that are valuable and can manage all three levels very effectively. There's a handful of those. There are still the, shall we say, older metadata repository tools that do a wonderful job on the data dictionary and technical metadata itself, but have very limited business glossary availability or usage, mostly because those tools are, in a way, designed for developers and not for business people to use in business people, just glass over and throw it out. So those tools that find the middle ground between the business data and the technical metadata and have effective interfaces for usage, particularly by business people, are those we find that are most popular these days for it. Since you work for one of the largest vendors in this specific market, maybe you can share with us before we turn it back over to Shannon. What's the future hold for data governance and metadata tools? Are they going to become more integrated or are they going to become more separated? What are some of the things that you see coming in the future? So what does the future hold for these types of tools? I think the future is making that differentiation between business glossary's data dictionary, metadata repositories, completely transparent to the end user consumer. They're going to need to handle all three. For example, when you bring data in to your data lake, that catalog, bringing it into a catalog effectively, there will be AI functions that will recommend to you the business term and definition associated with that data that you don't even know exist. There will be a lot of AI that will be able to infer the business concepts along with the data concepts from even patterns in the metadata. That's coming along and getting pretty close today. This year may be the year of AI here. So we'll see more of that in these tools by all means. So again, the connection between the business concepts and business metadata and the technical metadata will be improved to be seamless by all means. I think that's real important. I think that's something that I was a metadata repository administrator many, many years ago. We always seem to struggle with that issue of bringing together the business meaning with the data meaning. For those of you that are in the webinar, if you go back to previous real-world data governance webinar where I talked about those three tiers of metadata and the relationship between those things, I think there's a lot of information there to support what Lowell was saying, is that that needs to be the future, is that we need to be able to seamlessly be able to collect information about the data and about the metadata so that we can use this as one of the most valuable tools for getting the most value out of our data in our organization. Thanks, Lowell, for answering all the questions. I know through a lot of questions at you in a relatively short period of time, what I'd like to do is, well, first of all, if there's anything else I wanted to say about the future of governance and metadata tools, that would be great. But without that, I'd like to kind of turn it back over to Shannon and see, Shannon, it looks like we've got a bunch of questions today. A lot of questions, Lowell. Thank you so much for a great presentation. But yes, a lot of questions which started pouring in right away, actually. And some of it you addressed already, but to answer the most commonly asked questions, just a reminder, I will send a follow-up email by end of day Monday for this webinar with links to the slides and links to the recording of the session. And then again, some of these you've addressed already, but let's see, I want to ask them anyway, just to kind of do a little bit deeper dive. For this first one, we actually get this question a lot. Our team has some understanding of the importance of our data dictionary as a resource, but it hasn't really helped to perfect it. Any advice for getting more buy-in? So, Lowell, you want to address that first? Yes, yes, yes, yes. More buy-in. The quicker you can get it in front of consumers, report developers, those people that have to produce business value and they can understand the value of that data dictionary and what you put in front of them in order to be able to find, understand, and then trust the data that they're trying to use. The faster you can do that, the better. They are your champions. So effectively use them. And so what I've found often is that if you get the people in the business side to participate in the building of the dictionary, and they participate in providing the definitions that they, you know, kind of, one of the things that I found successful was kind of going to the business community and asking them, well, what information would you want to have about this data in an ideal world so that you could get the most value out of the data? So I think if we address that going in and going into the creation of the dictionary, we're going to almost automatically receive more buy-in because of their participation in the effort. Have you seen that as well, or do you see data dictionaries being created by, you know, technical stewards and then being turned over to the business stewards, which I would think would be more problematic? You're absolutely right. We've seen more failures happen than when you're not engaging the business at the beginning. So engage early and often, I think is what you said and what I reiterated. Yeah, early often and as many times as possible. Yep. Next. So wouldn't a data dictionary be the same as a data catalog? I differentiated it in the webinar was that the catalog was more of the technical metadata. It may be, and this comes back to the semantics that Lowell mentioned early on in the webinar, is let's get our terminology straight. Let's use a consistent set of terminology. So, you know, in some organizations, and I think Lowell you alluded to that, that the data catalogs were the data dictionaries. In my, the way that I set up this webinar was more that the data catalogs were more physical data. Is that the way that you see it, or are they kind of one in the same? No, that's the way I see it, the way you describe it, Rob. In my company's products, the data catalog is a physical connection to a database, and it just shows columns, you know, of a database table schema. Okay, so Shannon, I think the answer is that there are different things, maybe, depending on the organization. Well, this is perfect. I kind of leased to the next question, you know, does it ever make sense to combine the three metadata resources? I believe that there is, to make it seamless to consumers of the data, and, you know, the value coming out of data governance. Sorry, my cuckoo here. And so I think that, you know, as a resource that it makes sense to bring them together, but the act of governing the metadata might be different for the business semantic level that it is for the data dictionary level than it is for the technical metadata. So I think in a perfect world, you're going to have linkages between the three. People are going to want to provide the business with the ability to look up what data is associated with a specific subject matter within the organization. So we need to start with the subject matter being well-defined in the glossary, and then it doesn't happen itself. We need to have people that have the responsibility for linking the semantic metadata to the dictionary metadata, and then also providing linkage to the physical data itself. So, you know, sometimes it can be the same tool, but again, the processes of capturing the metadata, of defining, producing, and using the metadata may be different depending on the aspect of the tool that the organization is using. Absolutely, Ron. Yes. All righty. Could you explain what content should data dictionary include? I'll take the first crack at it. Yes. Data dictionary often includes, again, it's sort of an application view of the data that the application uses and maintains. So it's, you know, a lot about why we have it, what its usage may be, what some of the values sets in it may be, what each column is physically in terms of data type and length. And that's primarily what it has. It's, again, the application view. You know, it is the application view. And so I think that, you know, to make a short list of things that should be included in the data dictionary, we would want to include the business name for the data, the business name for the data element, or something like that, not necessarily with the abbreviations, but fully spelled out, because oftentimes the abbreviations are more cryptic, but it would also include a business description. And what I mean by business description is, it's kind of the, and I've joked about this before, where I call them cheeseburger definitions. So I even had a meeting earlier this week where we were reviewing a data dictionary for a data lake, and the definitions were the same as the name of the field. So, you know, it typically would have a business name for the data itself. It would have a business description. It would have the attributes of the data itself, whether it's character or numeric, how many positions it is, what some of the valid values would be. I mean, typically that would be, in my opinion, a kind of on the short list of things that would be provided as part of the data dictionary. Do you have an example of each metadata item that would be helpful? I mean, so from a business glossary perspective, again, we're talking strictly semantics. So let's use an example in the healthcare industry that a provider or a subscriber is a business term that is being used and has a business meaning. So you would have in your business glossary all of the business terms that are associated with a provider. But then again, the provider might be found in many different applications, in the data warehouse, in the data lake, in the different systems, the operational systems that you're running. So, you know, you would have information about the data that resides in that application, you know, just like a dictionary, for example, would be all the words in the English language. Well, this would be all the elements that would make up a specific system. And then the technical metadata is really something that you can get from your database catalog. You can get, I know I'm dating myself here, but from copy books and copy libraries in old mainframe systems, which basically say this is what the data is. That's in this table. This is how many positions it is. It may give you values and things like that. But, you know, all three of those things are important. You know, the most difficult aspect of it tends to be linking them together. Would you agree? Absolutely. Yes, that is the most difficult. And so, yeah, it takes time and it takes effort to capture each of these things individually. And those were some examples of how organizations collect that information or how that information is different. It really, within the tools, or where I think the tools add a lot of value, is where you can link things together so that people can navigate through the concepts and the subjects of the data and actually dig their way down into the data. The next step that I'd like to see is that organizations actually would have the ability to get to the data itself in the databases and not just the data about the data. But I think that, you know, some tools have the ability to do that and I think it's forthcoming in some other tools as well. You're correct again, Bob, but my arm is... You know, my company, Technology, can do that when it comes to the data lakeside because you need to do it to understand what's in there. But, you know, we have a business glossary and a data dictionary and a data catalog, and all of that is really housed in this same database. It's just a different view of that glossary and technical metadata. All right, Bob and Lole, that does bring us to the top of the hour here. Bob, thank you for another fantastic presentation and Lole, thank you for being a guest with us today. Always great to have you on. And thanks to our attendees for being so engaged in everything we do. Unfortunately, that is all the time we have for it, but I will get those additional questions we didn't get to over to Bob and we'll get those submitted and get answers for you in the follow-up email. That will go out by end of day Monday with links to the slides, the recording, as well. Thank you all for attending today and I hope you have a great day. Thank you. Thanks, Shannon. Thanks, Lole. Thanks, everybody.