 And here we go. Hello and welcome. My name is Shannon Kemp and I'm the Chief Digital Manager of DataVercity. We'd like to thank you for joining this DataVercity webinar, Enhanced Communication and Productivity with the Universal Business Glossary, sponsored today by Sandhill. Just a couple of points to get us started. Due to the large number of people that attend these sessions, you will be muted during the webinar. For questions, we 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 DataVercity. And 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 bottom middle of your screen for that feature. And if you'd like to continue the conversation after the webinar, you can continue the networking at community.datavercity.net. As always, we will send a follow-up email within two business days, containing links to the slides, to the recording of the session, and any additional information requested throughout the webinar. Now, let me introduce to you our speakers for today, Jeffrey Giles, Lynn Silverstone and Robert Lutton. Jeffrey Giles is a principal architect at Sandhill Consultants. He has over 15 years experience in information technology and is a recognized data management professional. Information management experience includes customizing enterprise architecture frameworks, creating model-driven solution architecture for business intelligence projects. Modeling experience includes modeling and analysis of business process workflow, modeling data at the conceptual, logical and physical levels, and UML application modeling. Lynn is an author, consultant and speaker with over 30 years of experience integrating organizations information systems and people. He has a thought leader in data modeling, data management and the human dynamics of integrating information and is well known for his universal data models. Reusable models that help to develop higher quality data models in less time. Robert leads Sandhill Consultants and is responsible for creating an organization that delivers technology, service, products and training in the areas of enterprise data governance, business, glossary, data catalog, data architecture and data modeling. Sandhill's vision is to develop market and deliver innovative solutions of exceptional value in the areas of enterprise modeling, universal data modeling, universal business glossary and data catalog space. Sandhill Consultants is a certified CMMI DMM partner and is focused on enhancing data as an asset via practices and technology to maximize investment in data management. And with that, I will give the floor to Robert to kick off today's webinar. Hello and welcome. Thank you, Shannon and welcome everyone to our webcast. When we started to put this webcast together, Len, Jeff and I came up and wanted to identify and perhaps even clarify our intentions for this webcast. First, we discussed we wanted to offer you the listener real value in the upcoming presentation. We hope to help you and your organization in creating and or updating your business glossary quickly and easily. Second, our intent is to change and improve how the industry creates business glossaries in general. And third, we're looking for your engagement during this webcast and welcome your feedback about our concept. One of the things we do is that in this presentation, when we talk about business glossaries, one of the things we talked about was engaging our audience in a very simple and effective way. And what we have done is we have created a couple of slides, two engagement questions right off the bat that we would like to get your simple selection. You can do one, two, or three in the chat window that Shannon talked about at the beginning of the call here. So for our first engagement question, we would like to right off the bat ask, is your organization currently developing a business glossary? Again, in the chat window you can just type in one, two, or three. We won't call for that, we'll just see that coming in and you'll see our engagement style throughout the presentation because we're looking for your engagement. We want to make it as simple and quick as possible. So following this here engagement, we have another question we'd like to just ask. The second question, the second engagement question, is your organization using templates to jumpstart your business glossary efforts? You'll again notice that we've increased the content, the count here to be four and five, so that way we know exactly what you're saying. And at any time you can go back and just review those questions and type in one, two, three, four, five, you'll actually see as we get further questions through idea interaction that they'll all be numbered so we can keep track of them. So we all know that having a business glossary should be mandatory. In today's interactive presentation we'll be talking about how you can save time and money by jumpstarting your business glossary program. We'll be starting off with the land, we'll be talking about how to jumpstart development of a business glossary and how to develop an effective process for developing business glossary using templates that save time and of course money. Jeff Charles will then follow up with exploring the universal business glossary, leveraging technology solutions by reviewing an easy to navigate structure, naming of business terms and consistency of definitions. So with that, Len, I'd like to pass it over to you. Thank you, Robert. Well, welcome to this webinar and thank you all for checking in with these questions just to engage you. What I'd like to talk about is what I think is one of the greatest issues in developing a business glossary and that's how do we do it efficiently and effectively? I have witnessed many business glossary efforts flounder and many times it just takes too long to get to a common vocabulary. And then I have also seen examples of organizations really flourish. One example that comes to mind is a company, one of our clients actually last year that said, okay, they recognize this problem about business glossary and about the need for a common vocabulary and they recognized it not only in terms of the lack of productivity in business operations but across systems where they were using the same term that meant different things or different terms that actually meant the same thing and it caused patches in their systems interfaces. It caused confusion and they recognized wow, we really need to invest in this. So what they did is they decided, okay, let's invest and they basically invested two months to say let's take a team and see what we can get done in two months. And in these two months, we had a very focused effort and they were actually able to jumpstart an initial business glossary effort and get 800 terms out there as a first cut on these terms. Now you say, wow, 800 terms, how could they do that? Well, one of the key things is that they were used. So we helped them reuse a number of terms and taxonomies and subject data areas and they could not have come anywhere near this without the idea of reusing. I noticed in the question, it looked like the first question a lot of you are developing a business glossary and then in the second question, I noticed well, many of you are not actually using templates or reusable definitions or taxonomies and this is really the main thing I want to talk to you about, the importance, the unbelievable importance in reuse. So now before we start, I want to distinguish between a business glossary, a data dictionary and a catalog because there's a lot of confusion in the industry about this. As a matter of fact, there's a whole bunch of different definitions on each of these terms in the industry. So if you look on the web, you'll see a whole bunch of terms. So let's define our own terms. We're talking about a business glossary here. So one of the definitions I liked that came from the office of the National Coordinator for Health Information Technology was a compendium of business terms and definitions that have been approved by stakeholders and are maintained and governed. So if you look at the business glossary here, this is business terms and definitions. We simplified that definition and said it's a collection of business glossary terms, definitions, and other information that provide an authoritative source that works across business operations. So basically this is in terms of business and is used to get a common vocabulary across the business. As opposed to a data dictionary, a glossary is not a data dictionary. A data dictionary, if you look at the Techopea definition, a data dictionary is a file or set of files that contains a databases metadata and it goes on to give a technical definition. Now, we've also simplified that and said, okay, so really what this is is a technology language focused and is regarding the descriptions and technical details about data storage and movement. So basically in a data catalog and in a business, you're going to get things like terms and definitions and you might also have policies and rules, but in a technology, you're going to get things like technical specifications, technical names, the systems, the lineage of it. And a catalog is simply a directory or the access. I like one of the data versity definitions from Sokolovsky and Mahajan where they said it's a business-oriented directories that help users find the data that they need quickly. We've simplified that and said it's a directory to find data and metadata. So basically this is the directory, this is business-focused language and this is technical-focused language. So why do we need a glossary? Well, the biggest reason is that this will help us communicate. Now communication is like the glue that holds business together. One of the greatest examples, I think, of common vocabulary, which, by the way, is this huge issue in our industry, common vocabulary, I think is Starbucks, where Starbucks has created a whole language around coffee. I mean, it's amazing the productivity that they gain across the worldwide operations by standardizing language and it creates this extremely efficient business process. So for instance, when you order a cup of coffee, there are 10 things that you're ordering and it actually starts out with, like do you want it hot or cold and then there's the size of the caffeine levels. So however the customer communicates, they communicate however they want, but they translate it into a universal language and this universal language across Starbucks aids in the communication, in the simplification and in the control of their operations. Another example is one of our clients, a distributor, where they were able to take many of the models that we offered with universal constructs and create standard APIs and standard micro-services and everyone was able to follow this very standard, if you will, universal language across their organization and this not only simplified how they developed applications but it simplified how they communicated with each other and the interfaces between them. So it's huge in terms of productivity. So now the challenges, this maze, does anybody feel like this maze out there? I know I viewed a number of business glossary efforts and a lot of times people are saying, wow, where to start? There's so many terms. In some glossary efforts, there's hundreds of terms. In some of them, there are thousands of terms. One of the participants in one of my business glossary classes said they had 6,000 terms and how do you do this effectively across so many terms taking so much time and ensure the quality of the terms? Well, the only answer that I could come up with is to say let's reuse, let's not invent the wheel. It's a tremendous amount of work to develop all these terms. Now, when I say reuse, I'm suggesting, hey, there's many places to reuse from. I'm going to share some of our reusable constructs with you but what I highly suggest is get a hold of as many reusable constructs as you can and see what fits, see what you can apply to help save time and save effort. In today's day and age, we must not start from a blank piece of paper. So there's three ways we can reuse. One is in setting up the domains, the groups of data items where we're going to manage and govern our data from the domain. We can use reusable models. A second is the taxonomy, the breakdown within a domain of okay, there's customers, then there's end user customers and shipment customers and build to customers, maybe installation customers. What's the breakdown of all these different terms within a domain in like a hierarchical structure? So we can look at that instead of trying to develop on our own. There's often a reluctance to doing this with a not invented here syndrome. No, no, we have a unique, we have a unique set of terms, we have a unique definitions and after doing this for the last number of decades, what I found out is businesses are actually very unique. However, much of the data you're working with, there's a tremendous amount of commonality among the types of data you're working with. And then thirdly, the terms. So the terms and definitions, you can get many examples of terms. We offer thousands of terms in our repository, but there's many other sources and many other ways you can get reusable terms to jumpstart your business glossary effort. One of the universal constructs that we're talking, in other words, generally applicable. By the way, people get the wrong impression around universal. They say, oh, universal, that means you're trying to fit a square peg into a round hole and it's force fitting. It's nothing of the sort. Universal just means generally applicable or holistic. So we're saying, hey, there's generally applicable stuff, like how many of you have various types of parties or associates or actors, for instance, customers, partners, employees, different people and organizations within your organization. When I do this live, everybody will raise your hand, unless of course I ask how many people do not want to raise your hand and then maybe somebody will raise their hand. But everybody has a party. Everybody has parties or associates or actors or roles of people and organizations. In any organization, everyone has some type of offering. So it might be parts or it might be products or might be services or it might be some type of financial offering or some type of logistics offering, but you're offering something. Otherwise you wouldn't be an organization if you weren't offering something. And then there's an agreement that happens between these roles and between these products. So we've organized many data governance efforts with a business officer to say, look, let's look at all the information about your associates or parties. Now, by the way, in a lot of data governance efforts, we may not use party. We say, no, there's a customer domain. There's a partner domain. There's an employee domain. There's a supplier domain or some cases will say, you know what, these are all associates or these are all roles. And there's a lot of commonality. And then there's the products and then there's the orders, the commitment or the agreements or the contracts. So a lot of times we'll customize this to say, hey, what's the terminology that best fits you. And this is where you do things before the agreement, like for instance, quotes or RFPs or requests for proposals or proposals themselves and the things previous to the order, including all the agreements. Now, what happens in business universally is you have parties and then you have product offerings. And then you have contracts and then you have to deliver on the contract. So you make some agreement and you deliver. And generally these are delivered via work efforts or you can go on projects or activities or tasks, but things that are being done when we track time. This is where you often get into performance management types things or shipments. You're moving things, you're delivering things. You're delivering a product from point A to point B. So this is delivery section. So it only makes sense. You have contracts and then you deliver. And then the fun part you get paid. So it's like, okay, great. Let's ask for a payment. That's the definition of an invoice. And let's receive payment for it. And then you have financial and accounting and then it and HR. So if we start with these type of ideas and often the first several hours that we spend with clients will say, okay, let's use the same types of concepts, but in your business vernacular and change them around. And often we'll make changes to this. So the idea of universal doesn't mean a take this exactly as it is. You want to customize and reuse. So for example, in different industries, this is how it might look. You have different parties and insurance, the agents and the agencies you have offerings and the contract that you establish as a policy. And then when you deliver on that policy, that's the claims process and it might also include shipment of documents in professional services. Your offering services to the offering changes. And then the contract are the professional engagements that you have in healthcare. You have healthcare offerings and then appointments. So you schedule time with doctors or at hospitals or emergency rooms. And then there's the delivery of that healthcare. And then there's also claims information and invoicing and payment in this area. So basically this type of model universally applies to many industries. We look at some more details like in financial services and banking. You might have a client or a partner domain and then financial products or investments or checking accounts or saving accounts. And then there's an account and account transactions. Now these are the high level views so that you could assign data stewards to a domain and you can manage all the different data items in a reasonable way. Now some of our clients add subject data areas like there might add domains like there might be a geographic domain. There might be a contact information domain, or you might choose to include those within my client and partner. So basically you're going to customize these, but why not start with these template type models? And I'm only showing them for a few of the industries that we support, just as examples. Here in a manufacturing domain, you're going to have customers and partners and orders. And you might call these agreements or so on professional services. We've already talked about engagements and clients and partners. So the first thing is establish these common domains and establish and use models that you can reuse and customize. So it's really two things. One is reuse. And then the second is don't just force fit and reuse it, customize it. And this can help save in my experience with all these different reusable models that we're going to show. This can save months of time or thousands of hours of time. Now, again, only in the interest of engaging when we do this live, I like to do interactive exercises. So just in the interest of engaging in your organization, just to get a better idea, what domains are of greatest interest? Now there are common domains and there's industry domains. So like for instance, how many people are focused on customer area or product area? And again, just enter the number in. We see, oh, someone customer, someone product, someone financial services, someone healthcare, someone others, someone many domains. Good. Thank you for your participation. Really, really appreciate it. This just helps with interactive communication. After all, this whole seminar is on communication. So thank you for your input. Really appreciate it. So a number of you in finance, a number of you in insurance it looks like, a number of you in other industries. Feel free to put in whatever industry you're in. I might be able to bring up examples in those other industries if you like. Only if you like. Great. Thank you. So now one of the things that I've seen. Oh, thank you. A number of different industries. I read we have models for that construction, telecom with models for that utilities. Great. Great. So, aside from the domains, one of the things I've really seen business glossary efforts. Flounder with is setting up a structure. And often in, often in business glossary efforts, they say, oh, you know what, let's not get into data modeling. That's too technical. But we've actually found that we've been doing these universal data models and these universal data models actually inform the business glossary effort. So we've been developing these, these universal data models for decades. And what we do is we use these universal data models to inform a hierarchical structure. So it's not a data model. It's a very, very simple structure to say, oh, look, there's people in the organization. Here's the various common roles. And common across all industries, you have all different, you have the type of name and the name component, like it's the first name, second name, a third name, first names, middle names, last names, suffixes, nicknames, maiden names, and so on. With definitions of each of these things. So this is a very, very, very small portion of a hierarchy of different types of ways to do common things. Or there might be common reference terms, like time or units of measure. There might be under product, you might set it up as services, goods or solutions, which by the way, this is again, a reusable construct. Some people say, no, no, no, the top one is an item and then you have products and services and solutions. Or some people say you have products and services and items and solutions. In any event, you can use the key meaning behind this. So let's not get caught up too much in semantics. There are certain universal constructs saying there's hard tangible things. You could call them goods, you could call them items. There are things that are not tangible like services. And there's things like a combination that you call a solution. So we can use these. Now what I find it's really fascinating is that in many organizations with some of the most brilliant minds in these customers that we've dealt with, they actually have missed some of these constructs and they've developed glossaries and models over a couple of years. And then I will come in sometimes to QA it and they'll have missed some of these key concepts. And then they've already socialized the model. So it's kind of hard to change it later. So what I'm suggesting is as soon as you can get a hold of all these concepts just as a QA point or as a jump start. Now in financial services, again, you could also say, wow, what are the people roles? There's retail investments, financial advisors, of course many others. There's organizational roles like financial institutions. And by the way, some will change this and say, no, no, no, we want banks specifically. That would actually be a sub hierarchy of financial institution. And there's institutional investments and contrabrokers and clearing agents. So what we've done is put together this taxonomy that is we're just trying to be of use to say, wow, let's not reinvent the wheel over and over and over again. You can use some of these structures. So enough on the structures and the taxonomy. Let's talk about definitions on definitions. Biggest thing if there's nothing else you remember from this presentation, don't start a definition from scratch. Don't do what this guy is doing and say, okay, let's define anything a bend customer product, you know, in different industries, I've actually seen this over and over and over again in manufacturing operations. I've seen a big discussion between parts and products and the distinction between them. And then look at sample definitions of parts and products. Reuse them and don't necessarily take it verbatim, but see what you can find from reuse in financial services. I've been to several different financial services organizations and it seems like every financial services organization I deal with, they have this debate about count versus portfolio and the distinction. So you can reuse definitions and say, okay, what is the distinction between an account and a portfolio? Like, for instance, in manufacturing on part or on product. We define a part as a component that's used to make a product. This represents the type of actual item that exists as opposed to the marketing offering. The marketing offering, by the way, is the product. So you can reuse these and then products are good services or solutions, combining goods and services. That's what a solution is. That is was or will be offered for sale by the enterprise. So one of the things that you're buying in standards organizations, and we've looked, by the way, in a lot of standards organizations, and we've looked at a lot of online definitions. But one of the key things is you want definitions that are actually suited and tailored to a business glossary. So one of the key things before you start a definition is to create a set of definitions guidelines. This is really, really, really important. And I've seen many glossary efforts that have not done this. Now, you can find actually business definition guidelines in different places on the web, like for instance, the ISO slash IC 11179 standard. If you look in section four, it has some guidelines for creating definitions. Now, by the way, those guidelines are tailored to database definition guidelines. So they're good as a start. But I would take it a step further. So like, for instance, what we've done is defined 16 different guidelines, specifically for use in for a business glossary. And by the way, we're taking some of the standards from 11179. But kind of re-archestrating them a little bit, staying in the spirit of that. So for instance, like one of the guidelines in 11179 is be singular in your definition. And what we've found is useful as one of the 16 is saying, hey, when you describe when you describe something, start the sentence with an instance of this thing is and then start your definition. So for instance, a product. An instance of a product is a good service of solution that is, was, or will be offered for sale by the enterprise. What this helps is a lot of times we found mistakes and definitions to say, well, a product, that's the listing of all the things that you offer. No, a product is not the listing. That's your product catalog. And if you always describe an instance of thing that's useful. Another guideline that 11179 kind of sort of talks about is, is, you know, it said, it should be very, very descriptive, which implies that you shouldn't have commentary or opinion. And, and one of our guidelines, we said, you know what, this is, this is really about not having commentary or opinion. And by the way, thanks for, thanks for checking in with your comments about NISO and CZ 39.19 great. If anybody has any other suggestions about other taxonomies, other sources, I'm a big believer in, in getting whatever resources that you can that will help. So what we've done is we've taken 16 different guidelines and said, let's take this repository that we've been building for 30 years and take all these data models and what the last number of years we've been converting them to business glossaries and hierarchies and business terms. So for instance, like the definitions that we used on subtypes and our data models, well, these aren't subtypes, they're types of things. So we're changing around terms, so they're business oriented, which by the way, that's one of the key guidelines that you want to use standard business terminology, like 111.79 says don't use acronyms and that's really part of using standard business terminology unless you define those acronyms or abbreviations. Okay, so let's look at an example. Here's one term out of like thousands that we've defined for customer. Now, one of our other guidelines is keep it very, very short as possible but complete and accurate. So one of the things that people miss sometimes is what a customer is, a role played by a person or organization that has purchased and shipped or used products from our enterprise. By the way, you'll notice in some of these definitions, like when I talked about a good or service, we're including tents in the definition. So very, very, that's one of the 16 guidelines. And we're also including all the different ways that someone could act, all the different subterms and make sure that we're inclusive of all the subterms in our overall definition. Without repeating definitions. So basically underneath the customer, there's going to be subterms, which is going to be shipped to customer and bill to customer and user customer that we're going to define this further more. Another very important guideline is don't use, and I credit Bob Siner with this, is don't use cheeseburger definitions. Don't say a cheeseburger is a burger with cheese. So don't use the term in the definition itself, except when you're defining subterms, because if you're defining a subterm, you want to link it. So for instance, a ship to customer, you can say a ship to customer is a type of customer because you want to link it to the customer definition. Now, I want to share with you a process that we use in our course. We go over this in much greater detail, but a process that we use to say, hey, how do you use, how do you reuse models? One is just think about the points that you want to create. So for instance, in customer, you might say, well, our customers, both people and organizations, is it people that have bought from us many years ago? One of the various points, then the possibilities and possibilities like you might use stuff from Miriam Webster. You might use stuff from our repository of models. You might use stuff from, if you're in retail from the arts data model, you might use stuff from Salesforce. You know, you might use stuff from SAP, where SAP has a whole bunch of definitions, customers in different contexts. So then these are all the possibilities you can use. And then you pick out key phrases. And then what you're going to want to do is pick which one of those is most applicable to what you want to do and then propose a solution. So in the longer course, we go through each one of these steps and show how to actually go through this process. But here I'm just going to show you the possible results. So this is actually based upon the universal business glossary definition to say, you know what, we really like distinguishing to say, a customer really is a role. And it's played by a personal organization. And we're using many of the guidelines. We're saying, hey, this might have purchased and shipped or used products. And then we might modify the definition and say customers also include resellers of our products, which basically came out in the possibilities that we distinguish. So what we can do is same thing under product. We can say, okay, here's a sample definition of good service or solution that is, will be offered for sales. Now, by the way, often we have this as the definition and this is the description. Products include both tangible goods, which are called goods and non-tangible offerings, which are called services. And then we give different examples. And it's debatable if you want to put examples in the business glossary term or if you want to put them in a separate place in the business glossary. So you want to establish your standards for that. Now, the key thing is, is that we did a study at one client where we said, hey, what's the average amount of time that takes to do a definition? And at this particular client, we said, okay, the average amount of time is four hours to do a definition. Now, some of these definitions we did very, very quickly and other definitions took us months, very like products or customers or invoices to products. Do customers include prospects or do they not include prospects? If somebody bought something 20 years ago, are they still a customer? If somebody's just about to buy something, are they still a customer? But the average amount of time is four hours. And we actually did some studies saying if you use a reusable model, on the average, you're going to save about 50% of the time, which makes sense. So most glossaries are many, many hundreds of terms or very often thousands. So basically, if you reuse, you're going to save tremendous amount of hours and you're going to be able to think of things that you never thought of before. So in summary, the only thing I like to remember is don't start from scratch, don't reinvent the wheel. And then one more engaging question. So what do you think is most critical to your organization regarding definitions? Developing solid, meaningful definitions. And by the way, we didn't get into this whole idea of linguistics, which again, we cover in our course. Jump-starting definitions, saving time and money, common understanding of terms or organizing terms with a taxonomy or some other thing. So many of you are saying common understanding, yes, yes, yes. Develop solid, meaningful. Some of you are giving multiple answers. Good, good. And by the way, these reusable terms can have a tremendous effect on common understanding. Well, with that, I'm going to hand it over to Jeff and talk about some of the technical aspects of glossaries. Thanks, Len. So hopefully from Len's presentation, you've been able to glean just exactly how much time and effort goes into building a business glossary from scratch. And by leveraging the common domains can really speed things up. So what we have is what's called the universal business glossary where we've taken this idea of a general business concept such as products and work effort and things like that and abstracted them into industry representation. So products might become parts in manufacturing. It could become policies, various other things in various other industries. So those concepts have been pushed into an actual vertical or an industry. So what I'm going to talk about in the next few slides is how the alignment of business and technology come together with building a data catalog. So what I'd like to do is just start off with a very simple architectural overview. Hang on a sec here. Will I advance my slides? Oh, I guess I'm going to have to click. Here we go. So data catalog architecture. If we look at this simple diagram here, if you read it from the left-hand side, you've got your, let's call it content, your raw information. That can be a universal business glossary or it could be an Excel spreadsheet or some other textual information. You push that stuff into the data catalog in some sort of a glossary manager concept. So that populates that part of the glossary. On the other side is the actual technical metadata. Now the technical metadata can come from a lot of different places. It can come from reverse engineering a database through ODBC or JDBC. It could come from connecting to an ETL engine and pulling information out that way. It could also come from a data model. Again, this is mostly just metadata that goes into a metadata manager function. The business glossary itself and the metadata from the technical specifications need to be associated. So sometimes this is done in various products through things like machine learning. Sometimes they use some pattern matching, such as if the names match, then it will make a connection there. Sometimes you just actually have to do a manual synchronization or a manual link. So let's take a look at these two concepts of a business glossary and metadata from a technical perspective. So if we look at this, context is everything when it comes to metadata. So IT professional versus the business person, they have different perspectives on how they look at this metadata. So on the left-hand side of this diagram here, this is where the technologist more or less lives. What they're interested in knowing is information about the system and what database did it come from? Did it come from an ERP system or CRM system? Which one of these systems is actually the system of record? Technical specifications. This is your data dictionary type stuff. What's the data type? Its length? Its precision? Is there a code set? Have allowable values? Does it have standards? Things like HIPAA, et cetera. And then the technical name, because the technology world tends to use shorthand when they start naming things due to database limitations or technical limitations, they might abbreviate purchase order as PO or they may spell it out as sales order or ORD. So these technical shorthand ideas don't lend themselves to the business people because on the right-hand side, the business people are interested in knowing, when it comes to an order, what's the policy around orders? What are the business rules? What is the regulatory rule around, let's say, security? Governance, those types of things. An order can be different types. You can have a sales order, a purchase order, a work order. So there are really subtypes of this concept of an order. And then an order, of course, could be related to other larger concepts of a contract or an agreement. So if we think about it, an agreement is kind of a contract. That contract is kind of manifested as an order because the order is how we actually complete it. So this is from a business perspective what they're looking at. So we have almost like two halves of the brain hemisphere here. So let's take a look now at some management ideas here. When you're building your data catalog, you want to understand the business meaning. That's what the business glossary is all about. It's about understanding the business meaning. It's also understanding the policies and the rules, term governance when we create terms, how do we manage those terms, and then connections between, let's say, the other concepts of a data dictionary, system level type stuff. So these connections are what make the data cataloging software very prevalent today. So what we'll do is take a look at a concept of a business term. Now these screenshots come from Irwin's, I think it's their data integration or data intelligence suite, but the same concepts apply in various other cataloging technologies out there too. So if we look at this thing and we look at product, which Len mentioned, we can see that on the left-hand side we have the term, then we also have its definition. We also have this idea of a workflow status. So at what level is this? Is it safe to use? Is this something that I can actually depend on? So you can see what level it's at. You can also see who is the steward, the person that's actually in charge of managing this thing. And then there's this idea of a catalog hierarchy or sometimes people refer to this as being a taxonomy. And we can see that it's in general business through to products and services and the various categories that things might belong in. Now the whole idea about a hierarchy or a taxonomy is the ability to drill down, to get to the thing you're looking for quickly. So if you take an example of, let's say, like Google Maps, right? You're looking at the entire United States. Then you can look at, let's say, the eastern half of the United States. Then you can look at New England. Then you can look at Massachusetts. Then you can look at Boston. Then you can look at Lansdown Street. So you can begin to drill down and that's kind of what your taxonomy or hierarchy allows you to do is to get to the thing you're looking for much, much quicker. And then you can look around your terms is a very useful thing. But let's drill into this concept of a product or this product definition in a little bit more detail. And as Len mentioned, when you're creating a definition, that definition should be devoid of any extraneous details. So you don't want to see information about, let's say, policy in here. You don't want to see any information about technical specification. You don't want to know who's using it or why they're using it or any kind of process stuff. It's a simply saying that this is the definition that best describes what this thing is. If I want to know what the allowable values are and things like that, I might set up a business rule and I would associate a definition to a business rule that says these are the allowable values for this particular definition. I probably wouldn't start to combine them together. However, it is useful to have additional descriptions that add a little bit more augmentation to this idea of this base definition. So there's descriptive field where you can put in more detail that you wouldn't normally put in a definition. So the way that I look at it is the definition is the short version and a description is the long version. That's what I ever wanted to know about this particular piece of information. Now, when I mentioned this whole idea of taxonomy and hierarchy, that's where I can say this idea of a product might actually have subclassifications to it. So if you're a data modeler, you could recognize this as saying, oh, that's a subtype of a product and you'd be pretty much correct. In the lower left-hand corner, you can see that I have good service and solution. These are all subclassifications or subcategories to something that's called a product. So these business terms are also associated with that higher level business term. And in this particular piece of software, they classify things as upstream and downstream. So if I wanted to say that a product could be related to a much, much broader category, I could go upstream of product and see how all of that stuff begins to fit together. Now, one of the things that's missing from this is, of course, the technology side, the whole idea that I have a data dictionary and how did that begin to fit into this as well? So when I start looking at that, now I'm associating technical metadata with this idea of a product. So I could say that we have an application and that application has information and data about it. So if we read this from the left to the right, there's a particular column in a database that's called Product Code. There's a table called Product 2 and the Salesforce or S-Force application. And then it's inside of a system called CRM. So this in itself is also a hierarchy where CRM's system is the big container. Salesforce application is the specific application around customer resource management and the product table and the product code has information about that particular piece of information that I might want to run a report on. Now, what if I want to see it laid out in one view? Then that's where this idea of lineage comes from. So you'll hear a lot of data cataloging companies talk about this idea of lineage. So lineage is just simply saying that we have this idea of a product which you can see over on the right hand side with that little red book that has a steward assigned to it. So if we look at this, there are associated business terms that are tied to it. So we've got used by and then here's general business, products and services, product category, good service solution. So this all comes from what Len was talking about with that whole idea of domains and subdomains within this idea. But then below that is the associated technical metadata which says there's a CRM system which may have one or more applications that's tied back to a particular table that's associated with a particular column. So if I'm looking at this, I'm looking at both hemispheres of the brain, that is, the technology side that tells me where is it located so I can retrieve it, and the business side which is, well, what does that mean? So what does it mean in this context, right? So below that is the associated general business rules and policies that might be associated with the concept of a product which might tell me things like allowable values. Is this a secure term where it needs to be secured in a particular database? All of those kinds of things that are associated with that. Now one of the unique things about being able to build out some of these taxonomies and to break them into the various vertical industries is the idea that I could actually look across different taxonomies and see an organization role in healthcare versus an organizational role in let's say insurance where I have insurance, somebody called a claimant and then in the healthcare I've got somebody called a patient, right? So they have a relationship and that the claimant and the patient might be the same person but they're just looking at it from totally different contexts. So with this metadata information context is important when we start looking at these ideas. So the other part of this is the governance of things. So you need to establish some kind of a workflow and Len mentioned this. If I were to take and start a business glossary or a data catalog effort but I didn't control let's say how terms were created, how they were approved approved, how updates were handled, how deletions were handled we'd end up with a big jumble of lots of terms in various structures that nobody could ever follow or understand and then they wouldn't really trust the catalog very much and so all the money spent on the catalog software would sort of not return the value you hoped it would but that's mostly because of the governance and the management of the terms and the dictionary that you're using inside of the product. So having a good governance program is essential to making sure that your business glossary program and your data dictionary programs actually have life beyond let's say six months to two years. Governance is really what is a primary success factor here. So I'm just going to close this out with another one of the engaging questions we've been asking. So essentially here I'm asking how are you planning on technically storing your business glossary? So there's lots of different levels people are at. So sometimes when you're just starting out you'll just say an Excel spreadsheet seems to work out pretty good for us or well we also have SharePoint and it has a glossary thing. So let's use that. Maybe we already bought Filibera or Elation or Irwin's DI suite. Are you building the catalog based on jump-started definitions or do you have another approach? And with that what I'm going to do is I'm going to send it back to Robert for final remarks. Thanks Jeff. Thanks Len. While people are just putting their final engaging questions we really do appreciate all the feedback and all the chat we've been watching and chat windows there. We want to just come back to the key point that we've talked about throughout this presentation on how organizations can save time and money by using the template approach with the universal business glossary. It is our hope that viewers can see how easily it is to manage a business glossary and hope that by leveraging the universal business glossary they can see how it can provide an initial jump-start that can greatly reduce the time spent in creating and developing the business glossary. We've also shown that you need a vital technology to manage the business glossary. So again we'd like to thank you for the interaction today. It's been great to see all the chats and the feedback. What we'd like to do is put a couple of options out there for you to engage us. For example, if you would like and Len touched upon it but we couldn't go into detail but if you would like to obtain the 16 definition guidelines we've got that in the bullet point. We'd be happy to email that out. Please go ahead and email me on the email you see on the screen. Or if you're interested in engaging with us by giving us a term, one term that you would like to help define we can show you how we can increase the quality while saving time. And of course if you'd like to jump right in and inquire about the universal business glossary or the workshop that we offer you can go ahead and reach back out to me to schedule a call or of course visit our website at Santel Consultants. So with that I'd like to maybe ask a few minutes to hand it back over to Shannon to see if we'd like to open up for any kind of questions. Shannon. Thank you all for this great presentation and thanks to our attendees for being engaged with the webinar. If you have questions I'm afraid we don't have a lot of time for questions but feel free to submit them in the bottom right hand corner in the Q&A portion of your screen. And just a reminder I will send a follow-up email to everybody by end of day Thursday with links to the slides and links to the recording and I will be sure to include all the contact information so you can include contact Robert and team with your questions and feedback as well. And I don't see any actually additional questions coming in right now for you all but if you have questions feel free to type them in and I'll make sure and get it over to everybody. Robert, Jeff and Lynn thank you so much for this fabulous presentation it's been very good very informative. We appreciate the feedback that we've received through the chat box like nice to see a lot of Canadians on there interacting and a lot of the folks in the US we will obviously I think Shani you're going to be setting up a follow-up communication that will have our contact details and we certainly look forward to hearing with folks. Lynn did you have something to say? Yeah I was noticing a lot of the chats and by the way thank you everybody for making sure you're active and putting in a number of you have put in chats about how do you actually measure it and really look at the return on investment and I have some ideas on that we only have about a minute left but if you want let us know about that some of them involve setting up a test that we can share some information about how you can do that and really show executives return on investments in the stuff. So anyway thank you everybody for your time. And just Shani just while we remain the last few seconds I've just got emails coming in for people asking for the 16 guideline bullet points but yes we will send them out to you I've got your email many thanks indeed for that Shani thanks. Yeah absolutely thank you guys and again great presentation and again just a reminder to everybody I will send a follow-up email by Ender Day Thursday with all the information. Thanks everybody hope you all have a great day. Thanks Shani, bye everyone. Thanks Len, thanks Jeff, bye.