 Hello and welcome, my name is Shannon Kemp and I'm the Chief Digital Manager for Data Diversity. We'd like to thank you for joining today's Data Diversity Webinar, Data Modeling Strategies, getting your data ready for the catwalk. The latest installment of monthly series called Data Ed Online with Dr. Peter Akin, brought to you in partnership with Data Blueprint. Just a couple of points to get us started. Digital large number of people that attend these sessions, you will be muted during the webinar. If you'd like to chat with us or with each other, we certainly encourage you to do so. Just click the icon in the corner for that feature. For questions, we'll be collecting them via the Q&A in the bottom right-hand corner of your screen. Or if you'd like to tweet, we encourage you to share highlights and questions by Twitter using hashtag Data Ed. To answer the most commonly asked questions, as always, we will send a follow-up email to all registrants within two days containing links to the slides. And yes, we are recording and will likewise send a link to recording at a session, as well as any additional information requested throughout the webinar. Now I'm going to do two, our speaker for today. Peter Akin is an internationally recognized data management thought leader. Many of you already know him or have seen him at conferences worldwide. As we mentioned, we were just at Enterprise Data World in Atlanta last week. He has more than 30 years of experience and has received many awards for his outstanding contributions to the profession. Peter is also the founding director of Data Blueprint. He has written dozens of books and eight articles and eight books. The most recent is Monetizing Data Management. Peter is experienced with more than 500 data management practices in 20 countries and consistently named as the top data management expert. Some of the most important and largest organizations in the world have sought out his and Data Blueprint's expertise. Peter has spent multi-year immersions with groups that is diverse as the U.S. Department of Defense, Georgia Bay, Nokia, Wells Fargo, the Commonwealth of Virginia, and Walmart. He also has appeared at conferences, constantly traveling. Peter, where are you today? Thanks, Shannon. Hey, it's good to see everybody. I am at the Virginia Governor Data Interns Conference in Charlottesville, Virginia. I have to tell a little tiny joke on UVA that's been so gracious to us that they're actually renting us a room by the hour here at UVA. I just thought that was too much fun and couldn't let that particular piece pass. Again, welcome, everybody, today. What we're going to talk about particularly is ways to approach data modeling. The goal of this particular session is to get you ready for it because many people sort of think of data modeling as a monolithic type of activity that is going to be difficult and not easy to understand. What I hope to do here is to help you get focused with that particular aspect of whatever it is that you're trying to do on this. The reason we call it getting your daddy ready for the catwalk is because there's a lot of important things that are going on in data modeling. We'll cover a bunch of them today, but we do have an hour. We're looking forward to the Q&A session after the end of this. So let's jump in and talk about it. Well, as you've done most of the time, I give you a data management overview and we'll give you a little bit of motivation around systems and components because data is pervasive in our systems but not well understood. We'll go into some specifics on data modeling, what is it, and how it represents our understanding of these fundamental and foundational aspects of systems in here. And then we'll dive into the strategies piece. I've labeled them the power of the purpose statement, understanding how to contribute to organizational challenges beyond traditional data modeling, guiding problem analysis using data analysis, using data modeling in conjunction with architecture and engineering techniques, how to utilize data modeling in support of the business strategy. That's what we'll finish up in about an hour from now and then as always look forward to your questions and answers as we get to the end of this. So let's dive in. Data management overview, I'll go very, very briefly just so that you get it. Most people think that data management is defined as what happens between when you get data, the sources, and when you use it, its use. Well, that's a good definition. It does help us in there. We can at least take that definition and say, okay, that means we have to have some data engineering pieces. We have to have some data storage pieces. We have to have some data delivery pieces. So data management may be a little bit broader than you thought. And if we've got those three pieces, we need some governance around that as well, which means now you need to have some specialized team skills in order to do this. You can't just hand it to your average person and expect them to get it right. That said, how the average person is what probably has, is where, excuse me, where the business rules that you're trying to get access to are. The real problem with this model is that it doesn't show the main advantage of data, which is that it's our sole non-depletable, non-degrading, durable strategic asset. And this model does not well depict data reuse. And the reason I put it out there is because I'm waiting for somebody to give me a better version of this. Here's another version of the same kind of thing. We expanded it for data at the center as a resource that should really be optimized around it. And that our data management tasks actually pervade our knowledge worker environments. Literally everything our knowledge workers do is some aspect of data focus. Again, these are imperfect. One of my favorite sayings is that all models are wrong, but some models are useful. That's a quote from George Box many, many years ago. Again, I'm hoping one of you all will come to me and say, hey, I've got a better idea for how to depict that because we'll put it out there and let everybody see what happens. But you can see here that even with this definition, the purview of data governance is much broader than most people think about how it works. And when we're doing data management, we're really concentrating on these five areas. The idea that we want to manage your data coherently, most data in most organizations is managed very well at the work group level. But when you need to go up from the work group level to a department or an entity type of relationship there, it becomes very, very problematic. That there is a class of persons now who have the professional skills, knowledge, and ability to manage data as an asset. This is data governance. Quality is making sure that data is in fact fit for purpose using the right technologies and the right procedures. This is our piece. This is a pre-stage of the next webinar we have coming up in May where Melanie Mech and I will be diving into this diagram in a whole lot more detail. Again, this is just the intro to data modeling here. So what we're doing now is going to talk a little bit about Maslow's hierarchy of needs because everybody wants to do all of this advanced stuff, everything that's in the golden triangle of data. And I've used these slides for well over 30 years to describe this. You can see things at the top are largely technology focused, but the foundational practices that I should go on the page for four are really the foundational pieces. And if you want to do this well, you need to do the foundational pieces before you try to do the fancy stuff. Again, think of it as jazz. You need your scales before you play. Any sort of improvisations around that particular piece. Another piece of the foundational practices as well is that it's very important to understand that the foundation can only be as strong as the weakest link. And in this particular instance, I'm showing the weak link being data platform and architecture. So putting more money, time, and effort into data quality will not improve the quality of the foundation. And that's a key takeaway from all of that. These represent capabilities of the organization. And what that means is that we're really trying in this case to help organizations get better at what they do so they can use these technologies that are wonderful and work extremely well. But nevertheless, you don't want to hand a brand new Tesla to a 16-year-old that doesn't have any driving experience. People still ask us, yeah, I know what I got to have it done by Friday. Can we do it without doing the foundational pieces? And the answer is yes, you can. But if you do, it will take longer. Costs more, deliver less, and present greater risk to the organization than if you don't. Dama has now announced the DIMBOC version two. This is the DIMBOC version one, but it still is reasonable in here to look at this and see that we have data modeling in context here of data development. So the upper right-hand quadrant on this right at about two o'clock there, you can see data development within a modeling being a component of all of that. And then finally, one small piece from the DIMBOC here as well. We now talk about the overview of what's actually happening. If you don't get anything else from this particular webinar, the inputs are down the left-hand side, the deliverables are down the right-hand side, the activities are in the center in teal, and we have lots and lots of tools. The piece I want to concentrate on this slide in particular is the goals, which is to identify and define the data requirements, to design data structures, to implement solution components that meet these requirements, ensure conformance to an architecture and standard as appropriate, and then make sure that we have integrity, security, usability, and maintainability within our pieces. So that's the data management overview. Hopefully that places what we're going to do now in context. Motivation, we do need to understand why we are doing things. A great time in Seneca Talk where he comes in and says, again, it's Ted Talk, I've got a reference there for you. But we're pretty good at describing what we do. We're not quite as good as describing how we do it, but we're very good at describing why we do it. And so that's an interesting piece. A analogy in there is interesting. Imagine if Martin Luther King Jr. had said, instead of I have a dream, Martin Luther King Jr. had said, I have a plan. It's not quite as inspirational given all of that. Now let's talk about a system. Systems are things that we put together, purposeful structures that we're trying to do, and purposeful is the word there. If we look at a system, they are typically characterized as being comprised of people, processes, hardware, software, and of course data in that whole piece. And the one thing that makes our arguments very strong, you could win almost any argument that you have with people about this is to say the following statement, there will never be any less data than right now. And if you wait five minutes and say it again, you will also be correct. And that does make people stop and think for a minute and say, wow, okay, I guess I ought to get a handle on that. And that's what we're going to talk about from a modeling perspective, because most people think of data models as being this sort of vast wallpaper and it's very, very difficult to perceive and understand. And frankly, in schools we've done a terrible job. That's one of the reasons I'm at this conference because we have a lot of professionals here that are clamoring for something beyond the single course that we teach most IT people, which is how to build a new database using data modeling techniques. If there is a skill we do not need more of on the planet, it is how to build new databases. Because not only do we not give them other things, it's an opportunity cost. If we teach them this, we don't teach them the data as a resource or an asset in there. But the other part of it is that IT professionals, when they take these same programs, and leaders get the idea that data is a technical skill that's only needed when you're developing new databases. So if you're migrating databases, we're not creating new ones, and we don't need the data management knowledge skills and abilities, similarly with software packages and ERPs. Let's talk about why one would model. If you were building a house, you would not generally build the house without at least an architectural sketch. The model is the sketch of the system to be built in the project. And you wouldn't want to just build the project without knowing how much it's going to cost. So the model gives you a very idea of how demanding the implementation work is going to be. If you hired a set of contractors from all over the world, would you like them to speak the same language? The model literally gets us on the same piece of paper here. Again, the same analogy for musicians. I've mentioned that already. Would you like to just test it before models can be reviewed, before you spend thousands of hours implementing that particular piece? If it was a great house, would you like to build it over again? And again, with that documentation, we can now build the same model. Finally, if you maintain your house, as most of us do, would you like a map of where the plumbing electrical lines are in there, the models document all of these for the project in order to do this? It makes life easier and avoids doing things like hammering into a wall and driving their nail into an electrical outlet, which might cause some shocking results. So we use models to store and formalize information. And we can also use them to filter out extraneous detail, deciding what is important or the word we use in modeling is essential. The essential set of information that we're going to have in here. And that is up to the modeling, which should be a joint effort between the business and the modelers that are on this. Again, most people do not learn modeling very well from their college and university programs, which only take them so deep into the subject anyway. So consequently, you really do want to find a qualified modeler. And our qualified modeling community comes out of the CBMP community that we have within DAMA here. We had a number of people get certified last week at the event that Shannon mentioned in Atlanta. About 900 people all of us in the same place there. It was great on that. You also use models to help understand complex behavior, and I'll draw your attention to the Easter Island statues, which has been a mystery for people for many, many years and trying to figure out how they moved these things around on the island. Now, first of all, if you've ever experienced something called island fever, you know at least what the motivation was. But how they actually moved those statues was completely unknown, but they used a series of models to prove that this was at least a way that they could have moved those giant statues that are there. By working with the models, you gain process from the process of interacting with them. You can evaluate different scenarios that are there, and finally, you can monitor and predict system responses to changing environmental conditions. And I'll stop right here and just say, if you haven't seen the movie The Big Short, one of the interesting pieces there was that nobody on Wall Street had financial models that showed what would happen if housing prices fell. Of course, we now know what happened when housing prices fell, but it was the lack of the modeling components that were in there made it very, very problematic. So the goal is to get a shared understanding between business and IT. If we don't have any disagreements, by the way, then there is insufficient communication. If somebody looks at a model and says that's fine, they haven't done what you need them to do. No good information is taking place. In fact, the best thing somebody can say to your model is, hey, I don't think that piece of that model is right. And you say, great, thank you. Tell me how we can improve it, because if we improve it at this point of the process, we will spend a lot less time correcting things when the system is actually implemented. We also need to understand that sharing and data exchange is largely automated and less dependent on engineering. Again, the Found Foundation that I spoke about earlier on, the modeling characteristics are going to change over the course of the analysis, and I'll give you some examples of that as well. You want to incorporate motivation, and this is a first takeaway here. We'll come back to the power of the purpose statement, but I really do want you to think less of definitions and more of purposes in here as we go forward. We have at least three different, and some have found as many as 10 different variants for doing data modeling. Golly, do not argue over the type of modeling. The use of modeling at all is so much more important than the specific selection of the specific modeling method. It just pains me to see people arguing about this. Pick one and let's get on with it, because the models are living documents. They need to, but also can easily adapt to change. They must have modern search technologies. You can't have a model with a piece of paper only because it can only exist in one place at one time. I worked for one of the CIOs at Deutsche Bank for a number of years, and he used to say a lot that he never really understood what the models were or why they were useful for his system, but that he knew that when he went to his office in Tokyo and Singapore and they had our models posted on the walls, trouble using them, there was something that was useful that was being done, so he supported that particular process in order to do that. Again, if it doesn't satisfy a need, it's a problem. I once got yelled at by a Department of Defense senior executive who was telling me that they wanted battleships on their model. If you want to hear the whole story, catch me for a drink at one of these conferences, and I'll tell you the whole story, but it's okay to add color and clip arch and things because it allows people to see how the models get used. So let's talk about interoperability in particular. If I've got a program, that's the focus of a software engineering effort, but if I'm working with a database, I now have a different focus of effort. All three of those programs, in theory here, share the data that's in the gray database. Okay, how are they going to do that? Unless they know what those specifications are and the data model provides those specifications. What keeps, by the way, data blueprint, many of us in the profession and business, is that another similar project will go on with the yellow database and they'll do a great job with that piece. And finally, we have an orange project going on. I worked for one company at one point that had literally hundreds of IT projects going on simultaneously. This is not an unusual type of activity for large companies and for smaller companies. Hopefully the number is smaller in there. But the question is, what are we doing to make sure that the gray data works with the orange data that also works with the yellow data? In other words, if we look at this, the data model is the thing that allows us to go all across the entire portfolio that the organization has. Otherwise, how else are decisions about the range and scope of common data made? The analysis scope is on the use of the data to support a process. And this is how we eliminate or prevent problems caused by data exchange or data interface problems. The goals often connect. They are strategic as well as operational. And one data model is ideal, but we probably won't get to that piece for a couple of reasons I'll tell you about. The primary deliverable becomes a reference model. And here is an example of a data model that is useful as reference. It has not only the data, notice the account charge bill and subscribe when I should start out by saying that those are entities, business things about which you create, read, update, or delete information. But in addition to that, we've also put the definitions there. So what is an account? A personal or a business responsible for payment or a bill for services rendered to these set of subscribers. Now, that may not be the definition that works in your organization, but it's the one that they used in this model. The point is, when you're doing this, you can start to put in place standard definitions for this. And it also shows you that an account is responsible for a charge. A charge must be charged to an account. By the way, the notation here is zero or many charges can be associated with one account, but only one account per each charge. So you can't split charges in this particular. If this was a restaurant and you were trying to split the bill, that simply wouldn't work. Notice also we have subscribers and bills, other definitions here that we can start to use as reference material to say to the organization from our data governance organization, this is what we mean when we need this term. So let's look at a couple more definitions here. Again, modeling is the analysis and design methods used to define and analyze data requirements and to design data structures that support these requirements. You'll notice on the logo for data blueprint, we use exactly that type of notation to show people that's what we are. And the model then is a set of data specifications and related diagrams reflecting requirements and designs. I'll get to that in a minute, but requirements are important because they tell you what needs to happen. Design is also important because it tells you how it needs to happen. So they represent something in our environment. They use standard symbols. Again, I mentioned there's three primary ones, at least 10 variants of them that you use. The only important thing is that everybody said we're going to use the same one here to get an integrated collection of specifications and diagrams that represent the data requirements and design. So modeling is used to articulate the data architecture components, data architectures, or components that are typically models, the styles I mentioned already, object relational, unit ML, IE. I guess there's lots and lots of different ones. The original document, excuse me, the original doctrinal arguments are unproductive. I said that already. And the models are useful in the standalone mode or as a part of a larger architecture. So let's get a little bit further with this. Why modeling and what is it? Well, models in general are used for purposes of understanding. An equation can be a model. A simulation can be a model. A video game can be a model. Sorry, I went too fast on that page. That's all right. What was going on? Physical models, mental models. And Ellen Gupton-Diner did a great job on this one. I'd love to give her credit for this one, where she says, look, they've got to be visible to participants. You can use them for organizing things. It gives you a framework for decision-making. It requires tools for problem-solving and decision-making. It's easier to use a model to prove you invalidate. They can be graphic in nature. They can be textual. It can be a prototype. They can be any sort of a framework. And there's lots of things that can go into this. Let's look at it from a data modeling perspective, in particular. When we're building things new for the first time, which only represents 20% of our IT spent. So 80% of the dollars we spend in IT is spent understanding and enhancing things that already exist. But for those rare 20% that we use to start out with, we start out with three sets of things. As I mentioned before, there is our what for the requirements, our how for the design, and then the thing we created, the implementation of those assets. Each of those pieces are assets because they represent tangible knowledge worker-based products for which the organization has typically paid, in some cases, very dearly. Again, the problem here is that we only do this 20% of the time, and we don't teach people about the process of reverse engineering and the utility of reverse engineering. We may need to understand what the actual data was when it's recreated. We may need to recreate the design because the design may have had some constraints that are important for us to understand. We may need to recreate the requirements from it. We may need to go from the physical as is to the logical as is, and we may need to reconstitute the requirements. If we do that, that sort of takes care of our modeling notices. There's at least five different flavors of it already in there. If we're going to build a new system and we don't have to change the requirements, then once we understand the existing design, we can create the new design for it. If we are changing the requirements, then we have to go all the way back and create the new requirements, which then we have all a new design from, finally getting to our to-be product in here. The most important component of all this is to know that almost nobody who's doing this process actually does what I just described. When they move data from system A to system B, they move it from the upper right-hand corner. Existing as is, data implementation as is, directly to the new system, new to-be data implementation assets. That is where most of this stuff falls down, and we have seen hundreds and hundreds of IT failures that have fallen down because people make that mistake. We put out another aspect of this, too. Of course, all of this is data that is used as metadata. We're not doing our metadata talk right now, but the metadata piece is really data that is describing other data, providing more value to other data. Just so that you don't forget any of this, I've left you a chart with all of these bits and pieces to show you what the variations are. Again, I went over them quickly. We can come back if we have questions on that, but that's more of a reference piece for you as well. Whoops, I went too far. Another trick, and I forget who taught this to me. It's definitely not original, but don't tell them you're modeling. Just write some stuff down and then arrange it and then make some connections between your various objects on the paper. That's really what data modeling does. Let's look at a couple of things that are purposeful in terms of data modeling. The reason we're locked in this room is because we need to understand the relationship between sodas and customers. Here's our model. It is given to the customer, and the customer selects soda. It may be simplistic. It may not be correct for your environment, but for this environment, it was okay. We can walk out the door with an understanding of that particular relationship in there. Look at a second example all the way on that. Let's understand the difference between hospital beds. Here's a component of a model, which shows that the purpose statement for a bed is that it's a substructure within a room, substructure of the facility location. It contains information about beds within rooms. It has attributes. We'll get to them in just a minute. And associations in there as well, so we now can understand what are the top traits that represent that particular piece. Or, here's another one. Could our systems handle the following business rule tomorrow? Is job sharing permitted? And again, I've shown a very poor data model, but an employee has exactly one position, and that that position can be filled by zero, one. Excuse me, that's wrong. It should be zero or one people on that particular piece. I'm going to fix that real quick, because I know I'm going to hand those slides out in a minute. That wouldn't do it. Give me just a quick second there. There we go, zero or one is the proper answer for that in order to look at it properly. So that's sort of why we're doing it. Let's dive into now what you all came for, which is sort of the strategies piece of this. I've already mentioned the purpose statement. Almost all textbooks, data modeling books and things say, you need to define your terms. Yes, that is true. If you just define them, it's not very useful. If you make a purpose statement, you start to get at the motivation component within here. So let's take a look at a soda machine that was building on our example from earlier, where we have the entities, again customer soda, coins and machine, and we have the relationship between those entities. This is what we would call a conceptual data model. It doesn't pertain to anything, but if you're trying to make a model of a soda drink machine, this is one of the things that would be useful in there. By the way, if you've ever experienced frustration at a gas pump because they have two different interfaces built into the same thing, good modeling would have prevented that particular occurrence from happening where you pick your thing, put your card in it, and now pick the thing and now type in your zip code so that your credit card is good and all that sort of thing. Good modeling will help to create the idea that people will interact with things in a certain way because they can test the models, and clearly none of those models were tested or such an awful interface would have never been let out into the real world. Let's take another example with respect to requirements, too. This was kind of a fun one. I had a talk I gave in Norway earlier this summer where we were talking about a situation where in the Department of Defense at one point in time, a number of people, excuse me, a number of the warfighters were getting part-time jobs. It's still true. It's just not quite as prevalent now in here, but a person could have a job as a normal job, but they could also have a second job as a moonlighting job. At least I say this was fun in Norway because Norway being a socialized country, they all kind of went, wait a minute, what is this second jobs thing? I don't understand this, which was interesting and we were able to show them through the modeling precisely what we were talking about, and they said, no, that doesn't work here because people here have exactly one job. But if it was important for your organization to allow people to moonlight within the organization, then you would want a data model that supported the relationship that I described here. It's written, by the way, in business rule notation, which is to say technology is, and we don't really want to do that because if you go to an executive and say, well, we need to buy this software package instead of that software package because it supports the business rule that zero, one, or more employees can be associated with a person, the executive's head might explode. What we really want to say is we need to support the practice of moonlighting because 30% of our workforce moonlights, and you don't want to spend 30% of each payroll time doing manual processing for the exceptions that are in there. I hope that's clear. Here's another example of the same kind of thing here within the same data model, interestingly enough. Zero, one, or more employees can be associated with a position when we're talking about here is job sharing. Somebody could, with this data model, have a position that they can occupy from eight to 12 and somebody else from one to five, giving it simply theoretically an hour for lunch, so job sharing, given that particular piece. So given that, it's important to understand that this type of a model here can also provide a specification. If you are looking at software packages to replace an existing package, it's important to know whether the new package that you're bringing in supports this particular set of requirements. And if the package that's coming in or proposed as a solution doesn't support these, somebody's going to have to make up for it. You're going to have to customize the package or you're going to have to change the way you do business. That may or may not be critical on this, but it's absolutely critical to understand why people do things. So if we talk about the purpose statement, what we're saying is don't define it, but say why we are defining it. And that is such a difference. It's very, very subtle. Clive taught me this many, many years ago. Very, very subtle but very, very important. Do not define things in your data models. Put purpose statements in your models because that way people will understand not just what you're doing, but why you're doing it. Back to our Simon Sinek piece right at the very front. Let's talk about changes beyond traditional modeling. Again, complex behavior going on in terms of the various models that are there. The approach is good models generally and effectively communicate the data requirements and quality of the solution designed in here. The modeling approach needs to be guided by two formulas. One, the purpose of the model and the audience equals the deliverables. And secondly, the deliverables and your time and resources gives you the approach that you take to this. Spend just a minute on those last two. If you are proposing, as I've already mentioned to you, that you should be showing these models to executives. I was doing this to general officers when I was with the Defense Department. It was important to have the models relate to some concept that they had in the world. I got a question one time, for example, of, well, where are the battleships? Well, yes, sir, general. That would be the types of resources that float and resources that float. Some of them have guns on them. Those would be battleships. Other things that float have airplanes on them. Those would be aircraft carriers, blah, blah, blah. I've lost the general five sentences ago. On the other hand, if I put a little piece of clip arch that when you hover over that particular part of the model and it shows you what are the things that they would expect to see there, it makes a good model. I'm also not going to put a lot of detail for executive audiences, whereas if I'm going to build it and I'm talking to people who are going to either build the system or test the system, then I need to have a very detailed component of the model. So the purpose plus the audience equals the deliverables from a data modeling perspective. Again, the other part of it is how much time and what sort of resources do I have and what are the deliverables that I have to have. That may dictate a different approach to doing the modeling. Again, remember, models are going to facilitate the process of formalizing things that are going on at a single precise definition over hopefully the entire system that goes there. We're going to use these models to communicate. It's a great to understand the different people with different levels and different types of experiences. And think about that. That makes the same for houses. When I build the original architectural sketch and I need to have lots of wood in it, then clearly I'm going to have to have carpenters involved, whereas if I'm building a stucco house, I'm going to have different types of people that are going to be building the actual physical house. Again, it helps us understand a business area and existing application or the impact of modifying a structure within that. It may also facilitate training for new businesses and or technical staff. All of our good friend Michael Gorman has a great story about elevator stories and MITRE. I'll ask you to ask him that story because he does a great job of telling that. And finally, models talk about scope. If it's not in the model, it's not going to get built. Now, we have big problems in scope area because we've stopped doing something called a context model, which tells us whether something is inside or outside scope. Again, very easy for those of us in the United States of America, it's April, and we know that in a couple of short days we will be required to settle up with the Internal Revenue Service. In general, the Internal Revenue Service is going to be considered out of scope for most projects because it does not have the ability to be flexible on an individual basis. And their scope is another important piece of this. What we talk about as we teach people this is something we call the ANSI Spark, which is a standards organization, not Spark as in Big Data Spark here. We talk about three types of models in general. There's a conceptual perspective, which is the highest level of abstraction in here. Everybody might have a different perspective of it individually, but this conceptual view allows us all to come together. Then we have a logical view, which hides physical storage from users, but this top one is, again, the requirements. The logical is usually the design that we do, and finally the physical portion of the model allows us to look how it's actually implemented in there. So this is the Spark model that we describe in here. I'm going to show you some analogies to it. If I'm looking at a bridge project in France that was built a couple of years back, the conceptual model is business-focused, and all I'm doing here is saying, you could go by that orange drought labeled N9, and it would take you a long time. However, if we build this bridge over the aqueduct here at Malau, it gives us, just at the entity level, what needs to happen, focus, scope, guidance on the modeling effort. Sometimes we throw them away. We rarely maintain these models, but it does at least help to sell the projects. If you wanted to get from the top of A75 to the bottom, of A75, you could take it on a very fast motorway, or you could take the winding roads all around it in there. Logical models, then. Tell us, well, okay, now that you're going to build the bridge, how are you going to build the bridge? And you can see here at the bottom, in particular, they're going to build this bridge that is as tall as the Eiffel Tower going through a series of piers in order to do this. It's also going to be a cross-sectional suspension bridge, which is really interesting on the whole process. We're going to hold it up in the middle and have the two pieces on the side, because that's the type of bridge we can effectively afford to do. Logical models are required to achieve the plan from that conceptual model to the physical model that I showed you a few minutes ago. They're typically developed to the attribute level, often via third normal form to help understand usability as well as driving up the business rules. And the logical models need to be refined until it becomes a solution in order to do this, because they guarantee the rigor of the data structures. These are more often maintained than the logical, excuse me, conceptual models. Finally, the physical model says, Blueprint, how are we actually going to do this? You've become the Blueprints for the construction. You can see here, again, we're going to put a fake pier up that's going to allow us to move sections of the bridge over and put them in place. Again, it's a little bit of technology in there, but it allows us to actually get with that. So let's take a look at guiding analysis and guiding data analysis in particular here. This is the most misunderstood because it's taught very poorly in most college and universities. We simply say to people, if you get this much rigor in here, you're going to have some form of technology-dependent physical as is. And by the way, this is that same model I was looking at on the pages before, but I've now turned it, let's see, 90 degrees to the right in this case. So I have my azure, excuse me, 90 degrees to the left on here. We start off with, again, we don't want to move physical as is the physical to be. That is almost always the worst thing you can do in any data exercise. So we model the technology-dependent physical pieces and then we move it up to a technology-independent logical model. It's an abstraction that we move it over to the 2B piece and come back down on the physical 2B side. The problem with this is it's taught exactly as the following. So here's our little green piece of paper. We say we move up to there, there, there, and there. And that's actually best practices and we do love to do that. And even if you get that in school, it still doesn't explain the complexity because we don't do that generally unless we have a purpose for it. And that purpose usually involves some modifications. So rather than moving it up to there and stopping, I'm going to change that and say, look, we have other logical as is data architecture components that need to come in and flavor that technology-independent logical data model there. That's why I've got the gradation on there changing between green and orange in there to show that mixture. And only then do we move it over into 2B and then drop it down into our new piece in order to go 2B on that. I'm going to do that one more time just so everybody can get it. Again, it's taught mostly is that we say logical as is, physical as is to logical as is, logical as is to logical 2B, logical 2B back over to the other part of it, physical 2B. Now, that's wrong. In most cases, what happens is we move it up and then we mix it up with some other components. And those other components permeate the data model and make what we need to do really much more complex about the whole process. Another little piece looking at model evolutions in here, I'm simply showing that we have the types of models as is and 2B. And we have the conceptual, physical, logical same thing we were looking at a few minutes ago. But now I've got one other dimension that I also want to add into this as well. Again, thank you, Clyde, for my education in this area. Every model should be treated as not validated until somebody has gone back and tried to prove that it is wrong. So it's a trick. If somebody says to you, is that model good? Say, I don't know. It hasn't been validated yet. Everything that we do within modeling can fit into one of these boxes that we have. And every change can be mapped into the transformation in this network. And what we're trying to do, of course, is get to a validated as is model, because that way we know that the data requirements are actually being met. During the course of any modeling activity, you're going to go through some variations in this. And it depends on what you're trying to do, where you want this to occur. But if you're collecting evidence and doing analysis, you're going to spend more time collecting upfront and more time analyzing at the end. There's going to be less project coordination as you start to do the modeling in there. The target system analysis is what we're really looking at in terms of trying to figure out where are the requirements buried in there. And the modeling cycle focus changes over time from largely refinement to largely validation in that process. So let's get back to our standard definition here that's really sort of a problem with all this. If I just ask what is a bed, search for bed comes back out and says bed is something you sleep in. Okay, well that's not very helpful. That's a definition. The purpose statement on this allows us to look a little bit more detailed. The purpose statement describes why the organization is maintaining the information about this concept. Again, bed in this case and in some structure of room, I read you in that a few seconds ago, and the sources of information about it. It also may contain lists of attributes that are there. So a bed may have a description, a status, a bed gender to be assigned, and a reason for the bed reservation. Now, the reason I'm showing you this particular one is because if we look at this next piece of the purpose statement, it's also incorporating the associations with us. This is very poor notation, but it's still valid. It says that zero or many beds can be associated with one room. Okay, that's good. Now, when we did a little bit more work on this particular piece, what we discovered was that they were going to put RFIDs on the bed. And the RFIDs on the bed, we're going to prevent them from losing patients. Hospitals occasionally do that. Well, here's an interesting question, given that purpose statement. If you're going to use bed as the primary way of locating people in a hospital, then a bed absolutely can tell you which room it is in. However, now a hallway also becomes a room, as did the elevator. Luckily, we were able to get that particular piece quashed pretty quickly before the rest of the system was built. Clearly, it would not have worked the way anybody wanted to work. Let's look at another component of the same system. By the way, these are pieces from the Veterans Administration data model. These are the actual ones that are in production. We built these many, many years ago, and they are still in use today. So here's a conceptual model, just the entity showing that things relate to other things. I'm going to draw your attention to one piece of this, the relationship between some concept called admission and another concept called discharge. If you look closely, you'll see that the relationship between admission and discharge is one to one. What that means is that we can have an admission can have only one discharge. There's our link to it. There's the admission that shows there, and there is the discharge. Every admission must have one and only one discharge. So we said to people, okay, given this model requirement here, is dying a reason for being discharged? Dead silence on the other end of the room. No, you would never discharge a dead person. Okay, this model's not going to work there. Something has to change, even the definitions or some way of describing this discharge or death may be, in fact, a valid code for that particular process. Again, let's move a little bit further here. Again, from a strategy perspective, what we're looking at here is how do we look at these relative to architectures? So data models might ask the question, how do they support organizational strategy? And the answer is, well, were your systems explicitly designed to be integrated or otherwise worked together? Because data has to work at the most granular level possible or they will not work. And if they weren't designed to work together, what's the likelihood they would? All likelihood your organization is spending 20 to 40% of its IT budget compensating for poor data structure integration. And your data structures cannot be helpful, as shown in the models, as their structure is unknown. So we need to get into efficiency and effectiveness and also dexterity, which is how well the organization can learn how to adapt to new things. Now, from a design perspective, this is a design style for modeling, in this case largely used for data warehouses, but it can be used in a number of other contexts as well. Dr. Cobb put this together, and what it does is it organizes data in simple rows and columns, the entities, and it creates the connections between the entities called the relationships to show how the data is interrelated. Moving to third normal form removes data redundancies, although that's a little bit counterintuitive, because you end up with more entities when you normalize, and people don't quite get that. But what we're doing is we're breaking the data up into bite-sized pieces so that everything is fully dependent on the entire key. Okay, that's so helping hard the way we used to describe that piece. But the point of the model here is in this case to show the most flexible and adaptable form of the data. So the data is only stored one time. Again, a statistic. The average company stores git data in 17 different databases around the organization. So if you have less than 17, you are above average. The double form is based on mathematics in this case. It gives you a visual relationship of it. It's a very rigorous technique. It's typically used in most operational data stores given that type of a scenario. Now, again, you can use third normal form modeling for warehouses and other things here on this, many, many different types of uses. Other style, if you will, is one that was created by Ralph Kimball. Again, a very useful piece. We call these star schemas in this case, which is really organizing the data for facts and dimensions. This is a very good reporting type of architecture. So the first architecture that I showed you may be good for analysis the second time. It may be better for reporting in order to do this. The fact table at the center, and this is an invoice item fact, can allow you to create data where you can do time series analysis, location dimension, product dimension. In other words, you can cube this data by each of those four dimensions that I've shown on there. The style allows us to report against large volumes of data. It sacrifices storage efficiency for processing speed. Nothing wrong with it. Again, the question is, what are you attempting to accomplish? Just to note, there are two dimensions, a star schema. So it's like the design on this. If you're really looking at warehousing, it's absolutely critical that you investigate data vaulting as well. This is a compromise between the two, but more importantly, Bill Inman has embraced Stan Linstead's method on this. It's newer, as Dennis definitely not taught in most college and university texts. So Dan did a great job of setting this up on this. What this is, is looking from a data vault perspective to say we can capture certain pieces of information as is. So again, I'm going to give you a highly simplistic example here, but let's pretend I was doing some data that was doing sales reporting in the European Union both before and after a country converted to the Euro. Well, if I was going to do this, I would have, in a relational model, I would either have two tables for sales in Euro and sales in non-Euro, and then I'd have to do some complicated methods of making sure that when I reported, I did the appropriate conversion so everybody would understand in current terms what was actually going on. Or I would have to store it in a one table and then have to test against it to see which way I was actually looking at it. Those are very clumsy models. They are not scalable, and whatever assumptions that you build into them become hard and fixed in there. So the data vault promotes flexibility. You could store a chunk of the data in the EU model and then another chunk of the data, excuse me, in the original currency and then another chunk of the data in the second currency, the Euro currency in order to bring it up in there. Again, a strategy here is to try and say, what are we attempting to do if we're building a new data warehouse and we want to get higher value out of it faster than data vault, data modeling, is a much better way of describing that process because it allows you to make your decisions later, whether you need to move into a Kimmel or an Inman structure on this. So our best practices today are to consider all data warehousing to be a derivation of this particular style. Let's go to one last topic here that we've got before we get to the top of the hour on this, and this topic is really how to support business strategy. We found this extremely useful for engaging executives with this. I'll give you an example here. I've worked through a number of recessions, unfortunately I'm old enough that I can make that particular statement. Models then allow us to get more flexible and adaptable data structures. It allows us to access that data with cleaner, less complex code. It allows us to get the effectiveness measurements that we need to have to build in some future capabilities. And finally, if you're looking at a merger and acquisition strategy, this thing is absolutely imperative to have on this, although I rarely see people do this. So here, let's just take a look at the model here. You can see it's clearly conceptual in nature. We don't have any attributes on it and we're using some very light notation. So we may have an employee, and an employee in this case can be either a salesperson or a manager. Now, what's interesting about it is that the original way of working with this employee was that salespeople sold and managers managed. However, when the organization went through a typical downsizing, remember it's called a business cycle for a reason, and they said managers need to sell. Well, you can see in here there is no place for that manager to actually report sales because only salespeople sell. So it's a very rigid data model, and it made it a problem. It actually ended up with some people in this organization who found out that the managers were logging in and making themselves into fake salespeople so they could show their sales, but then they actually got paid twice, too, which was, of course, not the arrangement that everybody wanted to have. This is critical when you're looking at strategy. So let's look at it from a very high perspective. In this context here, what you're seeing is that the mission is to develop and support products and services which satisfy customers and markets so that we can achieve a 20% return on our investment within two years of entering the marketplace. That's a wonderful piece. I love it. I'd love to be able to do that. Again, let's take it where it is. By the way, this is an example out of Clive's book on this. So you might take the nouns out of that sentence and model them. In other words, clearly it is going to be a market and a need and a customer or a product and some performance in order to do this. It's just listed directly from that particular piece. So let's look at some specific goals then around strategy. We're going to boost the goals up here. There are nine of them in this case based on that particular one statement. And now I can map those goals into this model and say if I'm going to be able to follow through with what's happening here, I can say that goals one, two, and three are going to be related to market need. That was market analysis, market share, and there's some innovation components that go in there. This is where it gets very interesting, however. And I'm going to tell a little story on a company that doesn't exist anymore, but one that we worked with pretty regularly when it did exist, Circuit City. Circuit City is a great company, really innovative. People, wonderful groups to work with. Unfortunately, in circumstances, the company is no longer around, which is why I can tell you the story. So one of the things they wanted to do was a customer data warehouse. And we said, okay, great, we can work with a customer. But what is it about customers that you really want to have happen here? And they said, oh, well, what we need to do is we need to understand customer behavior. Okay, great. Well, we looked at attributes of customer and customer might have an age, a demographic and gender, whether they have a license, whether they bought stuff from us before previously. In fact, if you look at the target database, they actually knew whether you were pregnant or not and what habits that you had outside of Target, which was an interesting piece. Different talks, sorry, I don't want to get too far off track on that. But here's what happens. You could have all the information in the world about your customer. You might know that I live in rural Virginia, that I have internet, that is only a six megabit DSL connection. You know, things like that. But it doesn't answer any questions that management wants to know. What management really wants to know is quite different. And this is only driven out by looking at the real aspect of the strategic data model. So here we have the market, the need, the customer and the product. Notice that the relationship between the two of those and the previous version of the model at the conceptual level was that markets are related to needs. Well, until I resolve that many-to-many entity with the logical level model by putting in something called a market need, I could measure markets all I want, I could measure needs all I want, but until I know which markets have which needs, I don't have the ability to develop a strategy around that or at least not to execute a strategy around that. Let's go to another piece. Again, markets are going to be made up of customers. So we're going to have a relationship there between the markets and the customers. Market needs are going to be related to product needs. If there's a market need, I need to have a product that I can put in place to sell it. So again, I don't need to know the number of needs or the number of products. If I need to know the number of product needs in a given market, now I can start to approach strategy. I also may produce products for the market. I may look at customer needs in particular. And finally, the piece that most customer data warehouses are really trying to get at, which is what Circuit City was trying to do, is what customers bought, what products from us. And until I have at least those three pieces in place, there's no valuable information for me to gain from that particular process. And only when I've done that type of work can I redo this to now say, hey, market performance is important, need performance is important, customer performance is important, and product performance is important in order to get to where it is we're trying to go to. So we've covered in this hour a amount of material. I'll give you the data management overview. The motivation of data models are a part of system components. They are not well taught in colleges and universities. It is not the case that most people just can pick up the stuff and do it. However, everybody can pick up the piece of pen, write down something, draw some lines, connecting it. And so it's easier and harder than most people understand. It represents our understanding of fundamental and foundational aspects of systems that we're working with. And again, we'd like you to do this by taking a purpose statement approach as opposed to a strictly definitional approach to understand how these organizational challenges can be met by various data modeling traditional approaches to here. The problem analysis, using data analysis, allows us to better understand many types of problems, most types of IT failures, and using data modeling in conjunction with architecture and engineering techniques so that we can get everything on one piece of paper and understand it, and then utilize data modeling in support of business strategy. One final point here before we get to the Q and A piece. Don't let the perfect become the enemy of the good in us. I've seen so many organizations where they agonize over the models. Yes, it's important to have data structures and in fact on our data doctrine page with our datadoctorin.com, you can go in and look and see that we all agree that you need to have stable data structures before you do code. But the question of getting it absolutely perfect and delaying a project is never a good idea. So you've got to be able to look at that. And when you put your model in place, your model always should come with a series of assumptions. Okay, I'm assuming that I'm only going to have one customer ID for a family. If I have multiple customer IDs for a family, then things may change in our data model. Very important to get all of that together, and now we've reached the top of the hour, and I'll turn it back over to Shannon and see if we've got some questions for her. Peter, thank you for another fabulous webinar and of course the most commonly asked question regarding slides and the recording. Just a reminder, I will send a follow-up email by end of day Thursday containing both the slides and the email and anything else requested throughout the webinar. And Peter's showing off our picture from MediaDevue. So sending right in here, Peter. Any thoughts on modeling the contents of XML files? Well, that's an interesting question. So XML files, excuse me, I'm going to get to the right page. XML files are hierarchical data structures always. It's the definition of XML. So most organizations have now developed a parser for XML files. If you don't have your own XML parser, there's lots of them online that you can get and freely download. That's in terms of XML spy, I think used to be one of them. But most people, when they're asking the question, they're really trying to say, can I use the structure that is in XML to do modeling activities? And the answer is absolutely yes. If you look at a well-structured Word document, Microsoft very kindly moved the underlying file formats for all of its Office documents into XML a couple of years ago and made it an open standard. So you can look at these things and it will show you that the document has an introduction section and three parts to the section and four chapters in the first part and all the way down the subsections and things like that. XML being an inherently hierarchical structure. Yes, there are lots and lots of tools and techniques that you can use to understand that structure and see how it is in fact used because, of course, if you don't understand it, you cannot make use of it. Great question. Thank you, Chef. Absolutely. So, and don't forget to put your questions in the Q&A section in the bottom right hand corner. You know, Peter, can you recommend books on data vault modeling? Probably want to just Google Dan Linstat. I think he's got training with some things like that online, but it's a great piece. I didn't include anything in this particular webinar. Let me just go back to Dan's name and you can see how to spell it there, but that's where I would start. He also holds a conference. It's usually a Memorial Day in May. Got to work on that one, Dan, so that you can go up to his classes and meet with the data modeling. I've done that conference a couple of times. It's a really, really great event. So, there's Dan Linstat. And everyone's so quiet today. There's not a lot of questions coming in. I wonder, you know, is the data modeling to make our taxes easier? The data structures at the IRS, once you've communicated electronically, are well-defined. Your income doesn't tend to end up in your expense column, so it's actually a very good use of that you know, whether your taxes should be submitted electronically or not. I guess we're just too close to April 14th, right? April 15th. Yeah, it does tend to get quiet around this time of year, trying to get to tax season. We do have another question coming in. So, what recommendations for modeling by temporal data? Well, temporal dimensions is another characteristic of the data. So, I don't want to say that temporal data is the same as everybody else's, but when you're modeling this type of data, what you're trying to do is go back to what we were talking about here. What is the purpose of your model? And time, if it's an important aspect of it, then it may end up being a dimension in a star schema in order to do that, or if you're doing econometric modeling, it may be that this is the one variable that changes whereas everything else stays the same in hypothesis testing, like the scientific method and things like that. But it's absolutely crucial in order to do it. If you ignore the temporal dimension, you will have major, major challenges. Alrighty. So, we actually have quite a few more questions coming in. Now, that's great. I love it. How do we use data modeling techniques in no-SQL databases? That's always a good one. So, a great question. The real question is, what are your temptings to do with a no-SQL database? Remember, no-SQL means not no-SQL, but not only SQL. So, from one perspective, if you're able to access aspects of the structure that are known, then you can use standard relational modeling type of things. But that's not why people buy no-SQL databases to do standard model. We're typically trying to do something beyond this. Now, let me give you my analogy on that whole process. What typically ends up happening when people are moving into what we call big-data technologies on this is kind of like a snake. Now, I've got to make an animation for this so everybody can see it. But you're a snake. You're fairly small. You're in the grass. And you sense something. You know, you hear something rustle over there. You say, ah, could that be a mouse? I'm hungry. I might want to eat it. Well, you could poke your head up. And if you're a thing that you've noticed next to you is a mongoose, you're likely to get eaten by the mongoose. So, big-data techniques allow you to do kind of what the snakes do, which is that they send out an infrared signal. They don't have to raise their head up and get eaten. They can send an infrared signal, and the infrared signal can tell you that thing that you were thinking about eating is about four times your size, better instead to run away. And the snake would slither off into the ground. The whole purpose of these big-data techniques is to kind of get a sense of what's out there. So one of the advantages that they offer is that you don't need to formally model them in order to get good information out of them. Now, good information is a relative term. Good information might be the thing I was thinking about eating is actually very large. So I probably don't want to poke my head up and get eaten. Or it may be, wow, it's a little tiny, little baby mouse. It'll be just perfect to make me a yummy snack. Sorry, mice. That's the way it goes. The need, the no-technology, excuse me, the NoSQL databases are advertised as a schema-less piece. That doesn't mean that you don't have to have a schema, but it means that you don't need to have a schema in order to get value out of it. And there's a number of techniques that you can use profiling and other things in the NoSQL environment that will give you information before you need to model it. If you decide it's worthwhile over time, you will probably eventually model that data and put it more into our structures. But it's a way of getting information faster out of those databases than you wouldn't be able to otherwise. Great question. All right. So, and you referenced the DM box, too, and the question is, when will it be released? And Dama just announced the release date at EDW. They did for the last day of the conference. I think Sue said it would be out by 1159 Hawaii time on the last day of the quarter. Look forward to the third quarter is my advice to you. Indeed. So is it hard to make data vault modeling appealing to the business people? Not really. The main thing that you're telling them, we're moving into a warehousing context here just for everybody else's notification. When you build a warehouse, first of all, the average data warehouse gets built seven times, 50% of them fail right out the door. It's just not a business that has a lot of good, solid successes here. Again, if my dentist was that bad, I would find a new dentist. With experience, people can start to get better at it. But when you're building your first one, what they typically look at, and there are three going on in Richmond, Virginia right now that are $30 million plus acquisitions in order to do this. And each one of them are pretty sure are going to be a problem because they're asking for at the beginning of the project where you know the least about it and you're least familiar with the business environment, everybody to get everything perfect. And of course, that just doesn't happen. So what our guidance is when people want to build data warehouses is use this as a way of evolving your data warehouse slowly but simply step by step and building instead of $30 million and then I see whether I get a payoff or not, which might be a three-year effort in order to do this. Data evolving can give you method results that show payoff very, very quickly. And it is our best practice that we start off on all data warehouses using this particular method because it is so much more flexible and adaptable, and you don't have to build a ginormous amount of technology in order to get business value from it. Maybe we should do a topic on data vaulting. Shannon, might be a fun one. Sounds like it. Hey, so would you recommend different data modeling approach when modeling application process or data warehouse solution? In general data, so the real question is what is the purpose of a data model? A data model is designed to show you the data at rest. If understanding how the data is stored in your application is important, then it might be useful to do that. By the way, you can take any application, even if the vendor doesn't have a data model for it, and by reverse engineering and profiling the data that's stored in that application system, you can reverse engineer a logical third normal form of the data model without trouble. And there's lots of people that will share these things, as well, for example, the big ERPs, PeopleSoft, JV Edwards, Lawson. SAP are all out there in the public arena that you can get a hold of and see what it looks like. Kind of ugly on there. So the question was, would you use a different data modeling technique for a warehouse versus the other? If you're modeling data at rest, you want to do a data model. If you're moving data around, then you're going to use a technique that we don't teach in schools anymore for some reason, called data flow diagramming. Data flow diagramming is a very good way of doing as well as your physical stored data pieces in there. So the right tool for the right task. All right. So do you have any best practices or standards or reference books for, so back to the temporal data warehouse modeling? I would actually go to FAS Institute because they do some of the best temporal built-in modeling that's there, and the documentation I have used in their environment is very, very good. Kind of like, you know, so you've never done temporal modeling before. Here's how to do it. So I'd definitely give them a little quick plug. Which institute was that? FAS Institute, FAS. Yes. Sharing Art, Carolina. Nice. Alrighty. So any suggestions to engage the business group or users when they don't directly engage the data modeler? So a great question, and I learned a couple of tricks. One, color, the barge, you know, not standard data modeling practices, but if they understand that they're seeing their products and services in the data model, it becomes a lot easier to draw them in. And secondly, make absolutely certain that they understand that they are the quality control on this. You as the modeler are interpreting information that you're given. And the best job that you can do may, in fact, not turn out to be the job that is adequate for them. So instead of them looking at it and saying it looks fine, what you say is your job is to point out all of my errors. Now that's kind of tough when you walk into a room full of people and say, I'm going to do this wrong, but you guys are going to help me make it more correct. But that really is their job given that scenario. Finally, if you're really having trouble, introduce an egregious error into the model and see if they catch it. And if they do, and they realize that you're thankful for them catching that, they'll be on your side and they'll be willing to help. And so back to the modeling of SQL. You know, are there tools you can recommend for modeling big data? You know, Ted Hill's new methodology, his common, his notation. What are your thoughts on these new approaches? And again, a couple of recommendations. Yeah. Yeah. So there were a couple that were introduced even at the conference recently. And I think that we may see some, I think they're generally not quite as proven as the other ones here, but if we assume that the others are the only ones that are going to be out there, that's a really bad assumption. So given that what you're really talking about is sort of a mixed mode type of situation, a thing that are known and things that we are hypothesizing. And that really is the way in which we're going to start to get towards this. If you go into almost any big data-ish project, you're trying to sort of say, I wonder what's out there and that this will show you some flavors, some glimpses, some shadows, you know, some indicators. But it's not going to give you a, here's the answer to this equation. It's just not the way it works. Alrighty. And is there ever a time to model things and not data for C-level audiences? Is there ever a time to model things and not data? Well, I'm not sure I understand the question because data models represent things. That's what the entrance are. They are business things that you create, read, update, or delete information about. Did I misunderstand, Sharon? Yeah, I'm not sure I understand either. We can give them a moment to clarify. But I think, you know, do you present a different data model to the C-suite versus, you know, your IT director? Is there, yeah. So again, here's the model that you present to the IT director that says, look, we've got a problem. It takes us this much time to go on the red route, and if you go to the blue route, it'll save that much time and effort off of that. That's a very different model than how are you actually going to build that particular bridge that goes across there? And again, the executives probably aren't interested in the fact that it's a span arch bridge or that it's as tall as the Eiffel Tower or things like that in there. So very, very definitely, you're going to use different models for different purposes. Absolutely. Love it. Alrighty. Everyone's being very quiet again. But I think that's all we've got coming in, Peter. Well, thank you so much. I hope another great presentation. I just love it. And thank you so for joining us so quickly after Enterprise Data World and making it home or to wherever you are from Atlanta. So, or in Virginia. And the team in general. Yeah, absolutely. Yeah, yeah. Yes, we've got quite a few events coming up, and we hope it will all see you at the next DataEd webinar next month. We'll be talking about the data management maturity model with CMLI. So that's going to be very exciting with our friend Melanie Mecca. So Peter, thanks again. Thanks to all of our attendees for being so engaged in everything we do. We just love it. We love meeting so many people at the conference and things like that. And again, I will send a follow-up email by end of Thursday with links to the slides, the recording, and then the other things that were asked for during the Q&A. I hope everyone has a great day. Peter, thanks so much. Thank you, Shannon. Bye, everybody.