 Hello and welcome. My name is Shannon Kemp and I am the Executive Editor of DataVercity. We would like to thank you for joining the current installment of the Monthly DataVercity Webinar Series, Real World Data Governance with Bob Siner. Today, Bob will be joining by well-known data modeling expert, David Hay, to discuss data modeling as data governance. 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 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 our highlights or questions via Twitter using hashtag RWDG, Real World Data Governance. As always, we will send a follow-up email within two business days containing links to the slides, the recording of the session, and additional information requested throughout the webinar. Now I'm going to do two for our speakers for today, Bob Siner and David Hay. David is the President of Essential Strategies and the author of several industry-leading books on data modeling and data model patterns. Essential Strategies is a consulting firm specializing in helping companies use information architecture to enable them to take advantage of the latest technologies, plan their information systems, analyze requirements, and make systems a reality. Bob is the President and Principal of KIK Consulting and Education Services and the publisher of the data administration newsletter, TDAN.com. Bob has been the recipient of the Dameron 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 give the floor to Bob to get to today's webinar started. Hello and welcome. Thank you very much, Shannon. Thank you, everybody, for taking time out of your schedule to attend the webinar. And a special thank you to all my special guests for today, David Hay. David will give him a second to introduce himself a little bit further in a second here. But again, just wanted to thank all of you for taking your time out of your schedule to attend the Real World Data Governance Series. Before I get started, there's a couple things that I want to talk about, and then we'll jump into the content for the webinar. Today I want to offer a reminder of the upcoming episodes of the Real World Data Governance Series in October. We'll be talking about governing metadata, vocabularies, dictionaries, and data. In November, we're going to talk about another popular subject, agile data governance, and how to apply governance to agile efforts. And in December, we're going to be talking about data governance and the Internet of Things. So the Internet of Things is, again, another hot topic. And we want to talk about data governance as it relates to interconnectivity between devices and people and the Internet. So as you know, the Real World Data Governance webinars are the third Thursday of every month, and you can register through TDAM, KIK Consulting, or Dataversity. A couple other quick reminders, as Shannon had mentioned, the data administration newsletter is back to being live, and I'm partnering with Dataversity. Please, if you haven't had a chance yet to go take a look at the new TDAM.com, please go ahead and take a look at that. There's a lot of articles, a lot of blogs and columns, as well, from individuals like Mr. Hay and others who want to share information about their data practitioners and their practices. Also, to let you know about the KIK Consulting site, please go and look at it if you're interested in more information about non-invasive data governance. Quick plug for the book, A Non-Invasive Data Governance Available Through Amazon and Techniques, and also wanted to make a quick mention of some Dataversity events that I will be speaking at in the near future. In a couple of weeks, the Data Governance Finance Conference will take place in Jersey City, and I will be doing a tutorial, considerations for starting or enhancing a financial data governance program, and then in November, the Enterprise Dataversity event will be talking about a strategic data framework based on governance best practices. So I hope you'll get an opportunity to attend these wonderful events and introduce yourself if you are at those events. So without further ado, I want to introduce my special guest, as Shannon had mentioned, Dave Hay. Dave is the President of Essential Strategies International, and as you can see, most of the information on this slide, the things that Shannon already shared with you. He's authored several books. He's an expert in producing conceptual and semantic and architectural data models. And Dave, please take a second and tell us what more we need to know about you before we get started today. I think you've done very well. I'm not on that slide. I don't know whether anybody else is. I'm still on your title slide. Does anybody else have that problem? I think that right now the slide that is showing is of you as a special guest. So please tell us a little bit about yourself. All right. Yes, as you'll find, you'll discover as we go further, my undergraduate degree was actually in philosophy. And when I encountered data models sometime later in my career, I discovered, ah, this is what I want to do for a living. And so I discovered that if you get at the fundamental nature of a business, you've actually captured the fundamental nature of many businesses. And so I've been promoting that for some time. My company is now 22 years old, Essential Strategies International, dealing with many different businesses and many different industries. And I have great fun going into a company which I don't really know anything about, except what the public would know. And thanks to the modeling techniques, you know, within days or weeks or months, I know as much about the company as anybody works there, which is great fun. Anyway. I know you're truly a data guy inside out, just like myself. And I'm very pleased and honored to have you attending and participating in the webinar today. The other modeling ideal that you should notice in the lower corner is origami. Yes, in the picture of the origami, Dave is an origami specialist. That is a picture actually off of my bookshelf. At home of an elephant, an origami elephant. So to get started today, I want to share with you the abstract that we have used to introduce this webinar. Data modeling is certainly considered a staple in the world of data management. The skill of the modeler and their knowledge of the business obviously plays an important role in successful enterprise information management in the organization. As we take a look a little bit deeper into data modeling, we find that data modeling requires formal accountability. It requires attention to detail and attention to metadata. And it also requires getting the business heavily involved in defining data requirements for the organization. And all three of these things, formal accountability, as I've mentioned many times before in previous webinars, attention to metadata and getting the business heavily involved are certainly traits of solid data governance programs. So we're going to talk about data modeling. Is it data governance? Is it a piece of data governance? Is one encompassing the other or is it the other way around? We hope to provide some interesting information about that subject in the webinar today. So these are the subjects that we're going to talk about here real quickly. We're going to talk about data modeling as an art or data modeling as a science. We're going to spend a little bit of time talking about the role of the data modeler in a data governance program the data modeler skills to be viewed as potentially being governance skills for those individuals that have full fledged or are starting their governance programs. We're going to talk about data modeling and data governance best practices. And then we're going to wrap up by talking about the data model itself and leveraging the model as an artifact for our data governance programs. So without further ado, what I want to do is I want to jump into real quickly a couple definitions and then have Dave share a couple definitions with us as well. But I'd like to start with a definition of the data governance is and data stewardship is. Data governance is the execution and enforcement of authority over the management of data. So no matter how you define data governance and there's a lot of different definitions of data governance out there, at the end of the day the idea with a solid data governance program is to execute and enforce authority over the management of that data and that can be data definition, data production or data usage. Stewardship on the other hand is the formalization of accountability is getting the people in the organization both on the business and on the technology side to understand that they play a role in the quality and the strength of the use of data within your organization. So governance is execution and enforcement. Stewardship is the formalization of accountability. And with that I'm going to ask Dave, how do you define data modeling and how does the data modeling definition that you use relate to my definitions of data governance and data stewardship? It's the data modeling is the creation of graphic representations of the structure of an organization's information and data. And the whole point of the action of data governance is it involves looking at the organization as represented in its data. And if that representation is sort of messy or confusing it makes it tough. And it also is the source of errors if the data is not represented cleanly. And so data modeling is the attempt to come up with not just graphic representations but clean and understandable graphic representations of the structure of an organization's information. Okay, and just real quickly, non-invasive data governance that Shannon alluded to earlier is really the practice of applying this formal accountability through a non-invasive framework of roles and responsibilities. There have been other webinars that have specifically focused on non-invasive data governance. But today we're here really to talk more in terms of data modeling in terms of data governance or data governance in terms of data modeling. Mr. Hay, you shared with me a couple of definitions that you provide for business oriented models and technology oriented models. Could you spend a few minutes? That's in the next couple of slides. Okay, right. I'm sorry, I'm not saying the slides that you are. I'm moving on my own. Okay, yes. The basic problem with definitions is data architects, we go into a company and we basically are accusing our clients of really messing up the definitions in their company because different parts of the company have different definitions for the same thing or the different things, terms are used for the same things and so on. But as data modelers, we're just as bad. And so things like logical data models, physical data models and conceptual data models, we tend to be rather careless on the definitions. So for today's purposes, I'd like to nail down those definitions, at least my version of them and my apologies to those I'm stepping on toes for. But these seem to be the ones that work. First of all, the business-oriented models as opposed to the technical models are of three kinds. The first is a management overview, which is a kind of a sketch discussed with top management, presenting a limited number of key concepts. There might be a dozen boxes at most on the diagram with not very informative many-to-many relationships among them. This is more or less correspond to John Zachman's Row 1. Row 2, which I'm calling the semantic model, is the representation of the language of the business. This is the specific terms, jargon, all this sort of thing, but the definitions. This is an issue because each department tends to use language differently and in homing in on the semantic model, we have to now come to terms with that. If it's done as an entity-relationship model, it tends to be very large, the wallpaper version, because everybody gets represented what we call divergent. This corresponds to John Zachman's Row 2. The third one is the essential model, which is the representation of the underlying structure of the organization's data. This is what I've evolved based on my experience with patterns, and that is that if you get at, what are the fundamental things of significance to the business? If you do this in one business, you discover that they're pretty similar to the things of significance in others. Not equal, of course, but if you have in your pocket a set of patterns, it makes the whole thing a lot easier. Now, note that I'm calling all of these conceptual models. This has to do with the fact that to Steve Holberman, his conceptual model is what I'm referring to as the management overview. If you deducted John Zachman, his conceptual model is what I'm calling here the semantic model, and I prefer to call it the essential model while I'm perfectly happy to refer to it for the whole thing. The point being that it's about the business. We are nowhere here modeling anything technological. Okay, next slide. The technology-specific models, I've hung on the name logical model as a representation that reflects the constraints of a particular data management technology. First and foremost, everybody's experiences with relational tables and columns, highlighted by the notion of primary keys and foreign keys. But object-oriented classes are also in this category. XML schema classes are in this category. The point is that this is a representation of the business, but with a very strong flavor of the data management technology involved. Now, from here you go to the physical model, which, from my point of view, is simply the bits and bytes on the machine. This is the vendor's idea of table spaces and partitions. The same relational model may be invoked in four or five databases worldwide. And so how this is implemented physically is a whole separate category in itself. So anyway, that's the sense of things. If you're interested in these definitions more fully, if you go to YouTube and look up kinds of data models, there's a half-hour presentation on these definitions. I believe we can send a link to that YouTube video that you had sent to me to the people who are attending the webinar today and they can take a look at exactly what you're talking about. Really, what we want to talk about is data modeling, data governance. Are they equal or is one a part of the other? And oftentimes I have people that kind of ask me, well, what do you mean? How can data modeling be data governance? And oftentimes data modeling is a component of data governance. So to answer the question, is data modeling data governance? To answer the question, yes. Well, certainly data models, as you've alluded to with the different types of conceptual and technical models or technology-based models, they certainly are the things that are being governed as we're designing the data for our organization. So in a sense, getting the appropriate business people involved in the definitions of the data within the different types of data models, data modeling is data governance or at least an aspect of data governance from that perspective. And also, as you alluded to, requires business stakeholder involvement. And it's really, typically, data modeling is part of an overall data management plan. But then there's those people that say that data modeling is not data governance. And so, like Dave, if you could share with us, what are your thoughts? Do you think that data modeling is governance and component of governance? It's related. It's related. Now, data modeling itself is about the quality of the data definitions. And data governance, in general, is about the quality of the data that are recorded. It's the data that business are using that is what data governance is about. And data modeling provides the buckets, if you will, of the places to store that. The discipline of data modeling is different from the discipline involved in governance. Data modeling is an intellectual discipline to try to represent things, you know, on paper in a coherent way. Data governance is about getting various people to do things in a coherent way. And for that reason, a brilliant, wonderful data model does not necessarily result in well-governed data. I am with you. In fact, what you had talked about earlier is getting the business stakeholders involved. In previous webinars, I've talked about something that I call a cheeseburger definition. The definition of a cheeseburger is a burger with cheese. The definition of a patient account is an account for a patient. How much is a wonderful thing? Yeah, they definitely don't get to the essence of truly what the data is. So in a nutshell, is data modeling data governance or is it a piece of it? What are your thoughts on that? Well, I would say they are related things. They're related, but they're not the same thing. Okay, very good. So you wanted to talk a little bit more about the different kinds of models that we have. Are any of the different types of conceptual models, or getting to the technology models, the logical and the physical, are any of those models governed, or do they need to be governed more heavily than other types of models? Yes and no. Starting with management overview, this is part of your conversation with top management. And the difficulties in conversations with top management is that they don't really necessarily understand what we're talking about and the conceptual structure of the underlying data. They see data sort of on the surface. And if we can be successful in helping them understand better what's going on here, then they're in a much better position to say, yes, I want data governance to happen, and I want these things to happen. The semantic model is all about getting your glossary sorted out and getting your definition sorted out, and you made a very good point about how most definitions are simply wrong. And this is going to be very much relevant to the governance process, because if you say this report has bad data, well, the reason it's bad is it wasn't understood properly back at the source. And the definitions of Corbett is provided it. We're not quite the same as your definitions as the user. And that is a big issue in the governing of the organization. The essential model is what finally gives people an overview of, okay, what are all of these things and how are they related to each other? And that ideally will provide a good basis for the governance effort. Now, if you go to the next slide, the technology-specific slides, here the decisions that go into the screens, well, the data entry screens will have a big effect on the quality of the data entered. If it's well-designed, then it's fairly easy to put the right things in. If it's badly designed, it's very difficult to get the right things in. The deal here is that if you've got a really, really good model, it doesn't guarantee a good structure, a good design. But if you've got a terrible model, it pretty much guarantees you'll have a bad screen design. Physical model, not so much involved in governance. Okay, so I've talked about governance. I've kind of defined governance in the past as getting the right person involved at the right time for the right reason to make the right decision. I basically have called it a bill of rights. I would think that in terms of logical modeling, I could agree with you that at the physical level, how the data needs to be represented in the physical data store may not necessarily be as important as making certain that we have found business definitions in the logical model. And I'm going to go back a little bit. The definition is back here for some handy models, yes. Yes, so like I said, I wanted to go back a slide here real quickly. Even in terms of how we describe things simply to management in the management overview, is there governance required to make certain that we're presenting the right thing, that we're consistent with the definitions that we use across the business-oriented models and then also across the... I would turn it around. We get them to make sure we understand what it is the business is trying to accomplish. And then we say, all right, and here is how proper use of the data will allow you to accomplish that. And these are the data governance implications of what you're telling us. And that happens in the discussion with management when they were looking right here at the basic concepts that are involved, and it's strictly at the level of basic concepts. Then the details of the semantic model or level down in business that actually gets at, okay, how do you do things? But again, the governance is very much a part of that discussion. Would you say that having a governance program in place that does not involve your data modeling team is a mistake? Yes. And why would you say that? If data governance is one of taking a look at the consumers of the data and the producers of the data and making sure that they are saying the same things and that they mean the same thing, then you really need to understand the model, the underlying structure of the data that's being discussed. And so data modeling almost becomes an opportunity for you to be able to demonstrate back to the business that you have a complete understanding of what it is that they're looking for and what they're trying to accomplish. Well, exactly. What I like to do is have feedback sessions and I make sure that people in different departments are in the feedback session. And I'll make one of the assertions on the model that this particular thing has... My great example was to a group of clinical scientists. I made the assertion that each clinical study is about one and only one compound. And immediately, hands went up all around the room saying, no, no, multiple contents are involved. And suddenly, they had a great discussion with each other about, well, yeah, but there is a primary... There's the content that's being tested and then there are the compounds that are being tested against, if you will. And it finally came clear that the assertion should be is primarily about or to test one and only one compound. And that sentence was only made clear after six people discussed it for 20 minutes. And that's the kind of discussions that are a very important part of that modeling process. And so a lot of people agree that data governance, that in order to be successful with data governance in an organization, we really need to govern three things. We need to govern the definition of the data. We need to govern the production of the data. And we certainly need to govern the usage of the data. And so there's a lot of organizations that start with the protection and the security and the compliance and classification of data. But what I'm hearing you tell me is that it is extremely important that we start with the definition of the data and make certain, not only that we have definition that we're kind of repeating back to our business folks, that we understand the definition of the data, but then the modeling itself is, again, the graphic representation of that so people can get a better understanding of how different aspects of data connect to each other. I think that's true. Okay. So really, with one caution, and that is that when you talk about definitions, be sure you get several people in the room that agree on their definitions. And they don't actually have to agree, but they have to agree on how their definitions are different. Okay. And what happens when you have different definitions? Is there typically a process to either hash those out to one definition, or if there's multiple definitions, does that mean that we're talking about really different objects within the organization? All of the above. Okay. Unfortunately, there is not usually a good process, and this is what troubles me, because I keep wanting to get people together to have this process, and some very often they resist that. But what I want to bring in the model is that, okay, Charlie's customer is defined this way, Meg's customer is defined differently. The underlying customer concept is X, and here is Charlie's variation on it, and here's Meg's variation on it. So it really depends on the context that's associated with that object. Exactly. But be sure you understand what the underlying object is. The customer is the big trap, and that is a customer fundamentally is the fact that a personal organization is buying or selling one of our products or services, or maybe buying or selling one of our services, or is a candidate for buying one of our services. In this case, you'd better not use the word customer, you'd better use the word candidate or prospect or something else. The data modeling kind of sits at the core of that, so that we have a solid definition of what we mean by customer before we break it down into the different context of customer. My data models always start with people and organizations, and pretty much all of the conversation is about roles that are played by people and organizations, and the trick is nobody understands that because they think this word that they use is a thing itself, and it's not, it's a role. Okay. That seems to make sense to me. I've moved on to the data modeling as art and science for your knowledge, Dave. We talk about data modeling, and there's some pieces of the industry that consider data modeling to be an art, and then there's others that consider it to be a very technical and tactical science, so perhaps you can walk through us your thoughts on data modeling as an art and data modeling as a science. Well, first of all, no matter what the model is, if you are going to present it to the public, you'd better organize it so that it is intelligible to the public. If your data model is a piece of wallpaper with 150 or 200 boxes on it, this is not very useful. It's fine as a schematic to the techie guys, but it's not very useful to the public, especially when I'm doing, basically it's essential models where this comes together. The semantic models are a little tough because there are so many people, participants, and even there you have to kind of give a sight to the aesthetics for how you present back to them. But so in my presentations, I start with a box or two on the screen with a relationship that is an assertion about those two things. These are things of significance to the business and assertions about them. Add three or four more boxes with the assertions. Are these assertions true? Is that true? Am I representing you correctly? And you get up to you fill a subject area that might have 10 or 15 boxes tops, and by that time they realize they understand the whole model. And I'm sort of surprised to see that because it's really complicated and it's way more complicated than they imagined. So yeah, aesthetics are extremely important and unfortunately they get ignored and data modeling, the reputation of data modeling is hurt because of that unfortunately. Data modeling as a science, fundamentally we are trying to understand the nature of the business. That's what we're trying to represent. Ontology is this wonderful 2,500-year-old hot new buzzword. Originally it was the branch of Greek philosophy, Aristotle built, concerned with what exists. In modern terms the term is used to describe a structured representation of a domain of what exists in an organization. And the semantic and essential models specifically do that. And in fact there's a wonderful new thing called the semantic web which is a great way of capturing semantics. It's mostly verbal although there is a new graphic, there's a graphic technique that's associated with it called the web ontology language or OWL. Don't ask why that's the acronym. And this is the science of understanding what's really going on there. When I'm handed an existing system, an existing model, I view myself as a data archeologist trying to find things, insights buried in there. Okay. And so I've seen and I've been involved with organizations that have had models that, you're right, they're more of a wallpaper. It basically looks like a spaghetti diagram of things connected to other things. And so what you're telling us is it really needs to be some combination of an art because it has to be something that people can look at and that they can understand and that they can look for specific items and see relationships between items. But it also has to be a science because eventually those models are going to be turned away from being just models and turned into physical databases. So... There are two things. You made a jump there. The models that I'm doing on the business side are identifying the nature of the business. It's only if you've done that well that you can then turn it over to the technicians to say, okay, now turn this into a relational database or an object-oriented system or an XML schema or whatever. And that's the second thing. Now there is a technology, a skill, a scientific skill involved in turning a model into something. But that's not what I was talking about here. The first science is the one of being sure you understand what's going on in the world. Okay. But ultimately, when we create data models, they're going to turn into something as you alluded to. So we need to make certain that we can't create these crafty definitions. We need to make certain that they actually depict what the business is thinking about as the data. So would you say that data modeling is more of an art or more of a science, or is it just kind of a combination of the two? All of the above. We, consultants, are happy to say. Yeah, and we're always interested in hearing from you guys out there and the participants and the attendees in the webinar as to what you think about whether or not data modeling is an art or data modeling is a science. I'd be curious if you do share that information with us. Please let us know if you're a data model or if you're a data architect and what your thoughts are, because again, it's viewed different ways. They certainly make for nice diagrams that really help to explain the way the business operates. But again, ultimately, they need to be turned into something that's going to be meaningful to the organization. So I think we both agree that data modeling is an art because it has to be aesthetically pleasing to people, but it's also a science because eventually that aesthetically pleasing diagrams from the semantic and the management layer need to be turned into something that are physical between the two. So, okay, that's good conversation around data modeling as an art and as a science. Let's kind of move forward a little bit more and let's talk about the role of the data modeler in a data governance program. I know that from my experience in organizations, the data modelers are the ones that have the savvy to be able to ask the appropriate business questions, at least good data modelers, are savvy enough to ask them business questions, and they're really facilitators of being that kind of liaison between the information technology staff and the business role. So I look at the data modelers being a facilitator, the data modelers being a business role or at least getting the business heavily involved, but then ultimately being a technician as we turn that into real data. The data stewards themselves are also definers. They're definers, producers, and users of data. We've got individuals that have responsibility for subject matters of data across the business, and some of those individuals as data domain stewards may be considered to be the subject matter experts in the organization. What do you, Dave, view as being the role of the data modeler in either a starting or a existing data governance program? The ones that I've been involved with, they were starting programs, and essentially the model that I was building was establishing the language of the terms, if you will, for your data governance to say that, all right, and the subject matter, the organization in subject matter was of course key because that was the whole business who were going to be the stewards and your business of quiet data governance, non-invasive data governance really was relevant because invariably the stewards are people who already have a job. And the modeler was setting up the language and as I say, basically these conversations about definitions, and what do you mean by that? And the assertions that are made in the models about this is associated with one of those or is associated with many of those and what's the nature of that association? Because invariably the nature of the association goes to the heart of what people are working on. So for organizations that are doing data modeling, are the people that the data modelers involve in those sessions? Would you consider those individuals to be data stewards or is it better that they are data stewards? Well, you want to, yeah, the participants, you want to be the ones that are going to be the data stewards because they're the ones that are supposed to know the actual structure of that data. And they're the ones that we're answerable to, you know, did I make this a valid assertion that I made for your business? And the data steward says yes or no. And so if we're going to keep to staying non-invasive in our approach to governance, it's really easy. So for those organizations that might be having a difficult time identifying who the stewards are in your business, you may want to take a look at, and if you're doing data modeling as a practice, you might want to go back and say who were the people that we involved in the definition of the data either at a business level or at a technology level and after their opinions and gotten their involvement in defining things for the organization, those people may in fact be your stewards because as we've mentioned before, they're already in a role of knowing the data of assisting in the design of the data. So it's really staying very non-invasive in the approach to say, okay, the people that we would have traditionally involved in the data modeling process, those people are most likely going to be the stewards of the data in the organization, at least the data definition stewards, not necessarily the producers or the users of the data, but certainly from a data definition perspective. What you say is absolutely correct. Now, actually, accomplishing it, that tidily is a different story altogether, but yes, your intentions are exactly correct. Right, so we don't necessarily need to call people data stewards for them to be data stewards. They could be subject matter experts that are recognized within the organization, but it really makes sense to know who those people are because ultimately, when it comes to answering business questions associated with that data, we're going to go back to these same people and engage them appropriately because they're the ones that have the knowledge that we started with as we were designing our data models. So this is kind of on the same page. Yeah, exactly. Okay, so let's talk one more now that we're going to go to the next slide. We're going to talk about data modeler skills as data governance skills. And so what I've done on this slide is I've provided just a couple or actually three data modeler skills and a couple of data governance skills where the modelers need to really be skilled facilitators. They need to be liaisons between the information technology or the technologists in the organization and the business, and that they're skilled in the modeling. When I talk about the people that are skilled in governance, they're again, they're also the facilitators. Potentially, they may be the decision makers, but they are certainly the facilitators of improvement in data management in the organization. And the governance role in a lot of organizations is to align business and data, to align business and technology. And I see that as being some of the same role of the data modeler. Is that the way you look at it, Dave? Up to a certain point, the governance is much more a management job. And that is, it's all about getting people to do stuff. And my situation is, yes, I want to facilitate, because I want people to tell me stuff. The modeling skill is very definitely one that's important because it has to do with thinking clearly and interestingly enough, language is a very important part of modeling, which you wouldn't think of, but especially the discipline version that we use where each relationship is a pair of structured sentences. The idea is that each of the sentences is a perfectly reasonable sentence, but it turns out it wasn't that easy to come up with. And so those are intellectual skills that are sort of more internal. Getting people to do stuff is not something we're good at, except getting them to tell us things, but that's about it. The governance is much more a matter of, okay, guys, follow this procedure. If you've got a problem, yes, holler and say there's a problem. Get somebody involved. And those kinds of things. So those skills are very much more people skills than the data modelers skills, although there are people and certainly intellectual skills involved in data modeling. So for those organizations that have governance programs in place that are not fully engaging their data modeler skills, at least I'm going to try to repeat what you've said, is that the data modelers really are at the beginning of the definition of good data in your organization. So the data modelers themselves may not be the stewards, but they're going to be the technicians that are going to help us to get the appropriate business definitions out of people. And as I said, I think both of the data modeling skills and the governance skills both really need to be focused on communications. Absolutely. Your facilitator is fine in both cases. Okay. And that's exactly the same phenomenon. Okay, so in more than one sense, are the data modelers, do you consider them to be business liaisons because they're the ones working with business folks to get that information out? Exactly so. Yes, very much so. And they're also skilled then in taking that and creating that graphic representation that you use, the aesthetically pleasing graphic representation because at some point, unless you're just keeping your data models hidden under a rock, those are going to be used to communicate with your business. So you've got to have the skills of making the models understandable. The interesting thing, and I've not always been successful at this, and that is if I am successful at the beginning of the project to getting exeggities, or at least high-level business people involved in this modeling process, then they are, now they have an investment in the model. And if I'm in a situation where I was hired by an IT department and they don't really talk to business people, and I'm not allowed to talk to people because they represent the IT department, that's the problem. Because business people never get invested in the model. I'm with you, 100%. The earlier that we can get the business people involved in the definition of even the objects in the organization that then relate to the data of the organization, the more vested interest they're going to have in seeing the project through to completion and making certain that the end result of the data reflects what they assisted us with early on in the modeling sessions. Okay, very good. So we got one more topic that we want to talk about here real quickly before we, or maybe two quick topics, before we start taking some questions. I want to talk about best practices in terms of data modeling, best practices in terms of data governance. Earlier this year we did a best practice webinar on data governance best practices, and there's two criteria that I've typically used to determine whether or not something is a best practice. And I noticed that, Dave, when you filled in the data modeling best practices, all of the best practices that you shared follow those criteria, and those criteria are they need to be practical and doable within the organization, otherwise it should not be determined to be a best practice. The second one is that we're going to be at risk if we do not achieve this best practice. So when I talk about best practices around data governance, I talk about the fact that we need senior leadership support, sponsorship, and understanding. We need to have resources that are responsible for governance. We need to well define and get approved our goals, objectives, and roles, and metrics. When you talk about best practices from a modeling perspective, you're talking about getting the business community involved, understanding the meaning, providing a clear picture. Maybe you can elaborate a little bit more on why you consider those four items on the slide to be data modeling best practices. Certainly for the modelers, in this case it's a data modeler who's practicing in this case. The governance of the business as a whole has been engaging best practices. If you talk about the data modelers best practices, these are the things that that person has to do well. One is to listen. One is to understand what's being said. And third is to then turn around and provide a clear picture to be sure that people, you know, that you got it right. Now, what's amusing about what I do is that about 10 to 20% of my models are the things people told me. And the other 80% are the logical implications of the things they told me. And that means that if you do a presentation and you put something up there and they say, oh, I didn't quite think about it that way. I thought about it this way. And we say, fine, if you think of it a little bit. But in the process, they come out of it having learned something. And that's a great thing when that happens. So they are also learning about the underlying nature of things. And that's why the model is a good thing to reflect back so that the people in the business now understand what's going on more than they did before. Okay. That makes perfect sense to me. So really, I look at these two sets of best practices as being pretty closely aligned, which is a good thing because data modeling really becomes the governance of the definition and the description of the data itself. The last item I want to talk about here real quickly before we start taking some questions and answers or taking some questions and hopefully providing some answers is leveraging a data model as an artifact of data governance. So we shared a little bit of a definition as to what an artifact is. It's an object that's produced by human craft. It's a tool of historical interest. It's a by-product of a specific discipline. We've added to that the definition of the design of the data is certainly going to be an artifact that's going to be leverageable to help people to understand the data. So we've got conceptual and logical and physical descriptions. Can you tell us a little bit more about how the model becomes a governance artifact? Well, here you have an example of an essential model of bookkeeping of accounting. You've got an account, which is this big square in the middle. It's either an asset or a liability or an equity account. It's categorized into account types and it's grouped into cost centers. Accounts are related to each other. Each account may be part of one or more account roll-up structures, which in turn must be the use of another account. Each account may be subject to one or more categorizations into account categories. Here you have basically the components of accounting. And if you're having a discussion about capturing the transactions, which would be represented separately, and being sure that these values are correct, you have something that you can talk about and you have something that you can discuss. And this is kind of sketchy, as originally discussed by the accountants. This particular thing is a distillation based on many years' experience. How it's turned into a physical system, suddenly all bets are off because the relational database doesn't understand this subtype business that an account is either in a asset or a liability account. And they have to be split out and their design decisions made for that. Well, that's not of interest so much to the business person. The business person wants to see it look pretty much like that in those categories. But the data entry screens, to the extent that those data entry screens recognize that this was the structure of things, they're a whole lot easier to use than if they are based on something much more convoluted. Okay. One of the burning questions that I hear all the time is even back to the days when I started out by doing data modeling, is do we show our data modelers to the business community, to the technical community, or are they more of a tool of the modelers themselves? Ah, yes. Million-dollar question. Well, in my business, I'm in the business of showing them to the business community. This was my mentor, Richard Barker's basic scheme, says, look, these things aren't meaningful unless the business community recognizes what is being asserted. And says, are you asserting true things or not? There is a rule that I have to follow in naming, to be sure those names are intelligible, but the assertions, to say that an account may be in one or more account categories, that's a business assertion. Is that true or not? This is a conversation with the business. And all this happens way before we talk to anybody technological. And we're creating the models for a purpose, so I think take the covers off of your models, and as long as they are designed in such a way that they're going to be useful and meaningful to the business, we should certainly share data modelers with people. So those are the primary topics that we really set out to address in this webinar today. And we've talked about data modeling. We spent a little bit of time talking about data definitions or data governance stewardship and modeling definitions. We talked about modeling as an art and a science. We talked a little bit about the role of the data modeler in a governance program and whether or not governance programs should leverage the knowledge of the data modelers to a great extent within the organization. We compare and contrast the data modeler skills and governance skills. We talked about modeling and governance best practices. And then we kind of wrapped up by talking about using those models as a tool, as an artifact of data governance. So with that, what I'd like to do is I'd like to turn it back over to Shannon to see if we have any questions regarding the content that we've provided today. Dave and David, thank you so much for this great presentation. And of course, we've got a lot of questions flowing, questions and comments flowing in. Just a reminder if you'd like to submit a question, submit it in the bottom right-hand corner in the Q&A section. And one of the most popular questions, as always, people asking if they will receive a copy of the slides and the presentation. Just a reminder, I will send out a follow-up email within two business days. So for this particular webinar by end of day Monday with links to the slides, the recording, and anything else requested throughout the webinar. And if we don't have time for all your questions today, one of the great things about this particular webinar series is Bob will answer any unanswered questions. And that will also be included in the follow-up email. So let's get started here. When creating a list of data assets, would it be best to use the essential model level? It depends on who's doing it and why. The starting point is if you're starting with doing sort of basic research, then not so much. You want to be sure the semantics are correct. If you start with a set of data assets and you look to patterns, yeah, then you wind up with an essential model. Does that where you're going to start? Is that where you're going to start by if you're going to create a list of the things that are important to the organization? Would you start with the essential model? I actually would start with the management overview. That's in terms of the basic categories of data. That gives you the subjects to talk about. That's actually at the management level. It's then when you have to dig into, okay, how do people actually use terms for each one of those major data concepts? Then you dig in more deeply, and then the essential one then consolidates it back into a relatively small set of major data elements. Okay. I don't know if that answers the question or not. Okay. I believe so. Moving on to the next question, would you need to have all business models completed before you move to the technical? I would prefer to. The problem is very often I have an IT group diligently trying to design something while I'm trying to do the data model. They make design decisions that are inappropriate. They would be way better off if they waited. The reason I say this is that the essential model is relatively simpler because it's general concepts and general structures. If you understand those, then your architecture of the system will be relatively simpler. If you start programming with the things that people told you, then you get something that really greatly responds to what this person told, and then another thing that greatly responds to what this person told, a great response to what this person told, and then you try to link them together and it's a mess. The whole idea of having a relatively simple essential model is that the results of that are simpler and more coherent in what gets built. I'd back what you say. It makes sense instead of starting down. We don't want to do the ready-fire-aim approach. We'd rather do the ready-aim-fire approach in order to make certain that we're designing database and data structures and data sources for our organization. To me, I would back up what Dave said as the idea of the business models first and then have them work their way down into being the logical and then physical model. I'm in agreement with what Dave said. This next question is right in line with that. If data modeling is intended to meet the business needs, why do we still use representations that are technically dominated, e.g. logical or physical models? You're just talking about business folks. Don't use this representation in practice. I'm sorry, a little slower. Oh, sorry. If data modeling is intended to meet the business needs, why do we still use representations that are technically dominating? It's like the logical and the physical models that you guys were just talking about. As business folks, don't use this representation in practice. Business people don't because they don't make sense, but unfortunately the techies do and the industry is dominated by those models and that's a shame. I think a lot of the tools that are on the market these days for data modeling help to move us a great deal away from having the models being technical models and making them more aesthetically pleasing as Dave alluded to earlier, make them more understandable. Oftentimes what I was told was let's not show somebody an entire data model all at one time. Let's start with pieces of the model so they can understand what the pieces are before we try to piece them all together. Dave, would you agree that we as data modelers or the people that are data modelers can do a better job of representing the data through the models? Oh, very much so. Yes, very much so. You mentioned tools. Tools up until recent years have been really terrible at that because they really only did database design type models and that's all you had. There was one tool that I used that was very, very good with the Oracle designer but then Oracle got bored and went away and finding tools that do the kind of modeling that I'm saying is hard and unfortunately the industry is dominated by database design models. Very good. It's kind of more on the technical side of things. What is your opinion about extensive use of indicators or flags, yes or no, one or zero in the model design? You so quite again. So what is your opinion about extensive use of indicators or flags, yes or no, one or zero in the model design? I don't do that. Indicator. She said yes, no or an on, off or it shouldn't be for the indicators. There are attributes that are boolean attributes. I don't understand the question. There's no quality of all there. Sometimes that's what you got. It's really dependent on the business need? No, I mean that's an attribute. It's a boolean attribute and this boolean attribute happens to mean true or false. It's an attribute of sex used to be binary, that sort of thing. Right, okay. Maybe the question can expand a little bit on that. But let's move on to the next question. So back to models, logical and physical. You want to govern the changes between being made in the physical model. Don't you want the logical model to drive changes to the physical model? No on the first and yes on the second. You want the changes to be from top down. Now what happens is you're doing something and you discover a problem and your design doesn't accommodate it and so you've got to play with the design and that has some implications for the model, the essential model, although very rarely does it really have serious implications for the essential model. If it does, then you should go back and revisit the essential model. If it turns out you got the semantics wrong, you should go back and revisit those and fix them from the top down, not sort of back into that. And the only thing I would add to that is that yeah, it makes sense. If you've done logical modeling and then you've done the physical modeling from your logical modeling, don't start with your physical models and make your changes there. Go back and make sure that your logical models and your conceptual models reflect what changes you're going to make in the physical models. So I think we're in agreement on that as well. And there are so many great questions still coming in. Just go ahead, like I said, keep them coming in, but I'm afraid that's all we have time for to answer verbally today, but I will get those questions over to Bob to answer before the follow-up email goes out by end of day Monday, which will also contain links to the slides, links to the recording, and additional information. Bob and Dave, thank you so much for this great presentation. As we were talking about earlier, Bob, when we first started, we could probably talk about this all day. It's just such a great... So thanks, everyone, and thanks to our attendees for being so interactive in everything that we do and asking such great questions. And I hope everyone has a great day. And thank you, Shannon. Thank you, Dave. And thanks to the attendees. Thanks, everybody. Take care now. Have a good one. We'll see you next time. Cheers.