 Hello and welcome. My name is Shannon Kemp and I'm the Executive Editor for DataVersity. We would like to thank you for joining today's DataVersity webinar, Big Challenges in Data Modeling, Data Model Patterns. And this slide is narrated by the esteemed Karen Lopez. Just a couple of points to get us started. Due to the large number of people that attend these sessions, he will be muted during the webinar. For questions we will be collecting them via the Q&A section in the bottom right-hand corner of your screen. Or if I'd like to tweet, we encourage you to share your highlights or questions via Twitter using hashtag BCDModeling, Big Challenges in Data Modeling. As always, we will send a follow-up email within two business days containing links to the recording of this session and additional information requested throughout the webinar. Joining us today are, well, we hopefully are two great panelists who we are both returning panelists to the series, Paul Agnewa and David Hay. Paul is an author, consultant, and speaker with more than 20 years experience in the data modeling and data integration field in many different industries. Paul has extensive experience working in many different industries including financial services, insurance and re-insurance, healthcare, healthcare informatics, sales and marketing, and manufacturing. Paul is an expert in solution architecture, data architecture, data quality, master data management, data warehousing, big data, and data governance. I'm also joining us and hopefully joining us and I'll just do a quick introduction to see if we can get him on the line is David Hay, who has been producing data models to support strategic and requirements planning for more than 25 years. A president of Essential Strategies Incorporated for 20 years, Dave has worked in a variety of industries including, among others, banking, clinical, pharmaceutical research, and all aspects of oil production and processing. Both David and Paul are also an author and I will be sure to get you the information for both of their books in the follow-up email. And of course, I'm very pleased to introduce the moderator for this webinar series, Karen Lopez. Karen is a senior project manager and architect at InfoAdvisors. She specializes in the practical application of data management principles. Karen is a frequent speaker, blogger, and panelist on professional data issues. She's a Microsoft SQL Server MVP specialized in data modeling and database design. She's an advisor to the Daima International Board and a member of the Advisory Board of Zachman International. And Karen wants you to love your data. And with that, I will give the floor to Karen. Hello and welcome. Thank you, Karen. You always do that so well. Thanks for all you do to make this happen, Shannon. And also thanks to Dataversity that hosts all these and a whole series of exciting webinars and you can go find the webinars and all the great stuff and blogs. I also blog there at Dataversity.net. And I also wanted to thank again CA Irwin, data modeler folks who sponsor this webinar series and are helping us make available to you every month and bringing all kinds of experts and diverse opinions and hopefully some wit and snark to the whole big challenges in data modeling. We're always looking for ideas about what topics we should be covering or who we should be inviting on. So you can always contact Shannon or use the chat or just know what you'd like to hear in future webinars. And reminder, if you want to tweet or Facebook or E-plus or other social media since they all have hashtags now, use hashBC modeling which is right there at the bottom right-hand corner of the slide. The other thing I wanted to talk about is this isn't a presentation. This is a panel. There won't be a whole bunch of slides or anything. So if your screen's not moving, that's okay. That's just how we like to do it. We want to focus on the conversations. So I wanted to talk, oh, before that, I wanted to ask you a little bit about how you are and sorry, Shannon, is that under share? The poll channel will be muted. Yes. If you go to the top, there's a drop-down and you see a poll or there's a poll icon at the top right. Oh, yes. Sorry. This guy. Got it. I used too many platforms. Thanks. I want to talk a little bit about you guys who are attending. Who are you? And I want to know what your title is. I want to know who you are or what your dream about. Okay, maybe nightmares, but what do you do? What's your primary focus? And we see the poll results coming in. It's so exciting. It's just like Election Day. You are having a hard time deciding who you are and what you do for a living. We won't tell your bosses. So I'm going to go ahead and close that poll, which gives you another 10 seconds. And she might give David some help. I think maybe he's got the wrong dial-in number. But he's here. So he'll be joining us soon. And I'm going to go ahead and show the poll results. That's a little thingspin. And what we're opening out is about half of you as attendees are data architects or modelers. We've got about 6% of project managers. And some of you are developers and DAs or other IT professionals. And 20 of you are busy talking to your boss about why you're on a webinar or something and didn't answer. So let's go to the next question. Which is, how do you use pattern models? So pattern models, I mean third-party models that you didn't create in-house. So these are pattern models such as the book that David and Paul have written or third-party proprietary models that your company has purchased or data that you found on the Internet or industry standard data models. So I'll just let you think about those for a minute. And I'm going to go ahead and close that poll. You've got 20 seconds to make up your mind whether you've actually done something or not. That's happening. For my own disclosure, I've worked with industry standard data models, both being on standards body for them and implementing those. And we're going to talk about those. I'm going to go ahead and show you the poll results. I hope you can see the poll results. Let's see. And what we have here is a small percentage of you. About 15% of you use pattern models on almost every project. About a quarter of you have done it once or twice before. About 15% of you haven't done it, but you'd like to. 25% of you haven't used pattern models at all. And we'll talk about that, hopefully. And some of you refuse to answer. So that goes to why I wanted this topic. So like I said, I've been working with some form of pattern models for a long time. So I've used both David's and Paul and Lynn's models from their books and their models that are available. And I've worked mostly, though, with industry standard data models, which are using the word standards kind of a strong word there. They're usually industry associations that have gotten together to define some data standards around mostly data sharing among industry partners. So for instance, the modeling standard I worked with was for retail. So it focused mostly on point of sale and inventory and scheduling and some niche markets. And it was focused on, they were focused on building a standard so that if a retailer wanted to go buy a package that you would measure that package data requirements or supported data requirements against the standard model. And they would also use their standard XML files for exchanging data in a standardized way across suppliers, vendors, potentially even customers, and other retailers. So that was an interesting, I've been working on that one for a couple of decades, so I've seen it grow over the years. But one of the things I noticed when I first started working with the standards models is that the use and adoption of standards models has really changed over the years. When I first started, that was a very niche thing. We didn't really, there weren't a lot of people doing and not many people knew what they were and now I've just seen an explosion of those. There are all kinds of proprietary, expensive proprietary models. We're talking six or seven figures to buy some enterprise standard model or enterprise pattern models, which are inexpensive ones that are in the tens of thousands. Books that you can buy, there are websites dedicated to just sharing patterns for each other. So there's a few more of those, but that's also resulted in a series of food around them. So fear and uncertainty and doubt. And I think part of that I want to talk about with my panelists is how do you ever overcome those things with pattern models? I think there are so many myths about them, so I want to talk about those. I think there's a lot of skewed expectations for them, like what role they play and the number one reason and the number one myth I deal with is salespeople for the proprietary ones will say, if you buy these models you don't need data modelers or data architects because it's all done for you. I also think that it changes how we do our work as modelers. I mentioned what is a pattern model. So I said industry standard models, pieces of patterns, which is in the book, so very small sets of models, the proprietary ones. And also I don't even consider internal models, the things that you guys have developed in-house. They may be part of your enterprise data model. They might be just patterns from previous projects that you want to reuse. They all kind of, whether or not they exist or not, kind of changes what you do. One of the other things that's interesting about them is what forms they come in. So the most common ones, and David and Paul's ones are ERD-based, so relational data models, but I mean them in UML format, in XML format, and just as picture and diagrams, one that I work with is only released as embedded diagrams in a Word document. It makes it very hard to reuse those. I've seen them in spreadsheets, or I've seen them in verbal specs, so specifications that list data requirements. Here's my introduction there, and I want to get started. I think that I'm going to ask, start with Paul while we try to get David on the phone. Paul, what do you think the biggest myths are about implementing data modeling patterns? The biggest myth is, well, I'd say the first one is one's right and yours is wrong, and I don't do it that way. That's a complete other cobblers, if you ask me. I mean, I said it's about data modeling in general. Is this not such a thing as a right or wrong? It's more like whether it's useful or not. So, if you apply something that's not useful, then it's probably not going to work for your particular situation. So, I mean, say that this is the right way to do things or the worst it is the wrong way to do things. I find that's a huge myth, and it really just bugs me when I hear about it. And in general, one of the great ones, and this applies to patterns and data models in general, the patterns is that they're independent of technology. I've heard that old chestnut for years. Why is that an issue? If you're going to use patterns and stuff, you've got to realize that things that you're using are set up for a particular way of doing things. So, myself and David and Len Silverstone use relational patterns. Guess what? They're for relational databases. They're set up to sort that, because we're using the old math that Jen and those guys put together, and that's all relational, not set-based math. If you're using data modeling patterns, they're modeling patterns that, you know, Janna and Helm and Johnson and John Vesides put together for OO software. You know, it's a completely separate type of solution. You are forcing yourself to go into a solution. And that myth is that patterns are all being known. All I'm trying to see for your data issues is not, I don't think, is going to put it in a much more set, maybe a little harder, especially for me. Does that really then depend on what you're using the pattern for? Or are you using it for inspiration to understand? For instance, one of the patterns in your book is about just contact mechanisms and phone numbers and email addresses and things like that. You could be using that for inspiration to understand that one of my pet peeves lately is that businesses need to give up the fact that they believe that people only have one email address and only ever have one email address. And so you can't really implement the tracking of email addresses a billion different ways, okay, maybe not that many, but a billion different ways. But that doesn't mean, you know, patterns expressing the implementation. Well, be aware that bottles in general have two different purposes. You know, they have two different purposes. And I want to describe this purpose number two. I don't think it's purpose number one, but okay. Well, as a purposeful woman, I'll actually give you that, and I think that's a completely different expression of requirements for data models, particularly data models. Traditionally, data models have been used as a basis for good database design. I think that might have been attuned into my brain over the years as well. I just think that modeling patterns if you take it from your perspective as a good basis for requirements, sure, I can say you have to be, it does have to be implemented in a way you could say that they are an expression of requirements. But for that expression of requirements as being used in notation, that's been specifically designed for a relational world. Just be aware that it's that that's, you know, don't care. In other words, your thinking and view of the world are affected by the inputs that you get. And remember that the pattern input you're getting from a lot of the relational patterns is relatively, you know, focused. But I think that's one of the things. Be a caveat mentor. That's all I'm talking about. Yeah, exactly. So I have one of my... I have one really... Okay, go ahead. The last favorite one is business cares. They trust me. They don't care if it's going to cost them a whole bunch of money. And I don't know what I mean. Because if you decide to go one way or the other, they're like, that's why they employ you. But they care about cash flow. They care about profits. They care about the shareholder value. They care whether you're using Paul's designs or David's designs or Len's designs. Sure, you don't cost me a whole bunch of cash. That's true for all decisions that we make in IT and, in theory, in the whole business, right? Is that really... You know, I like about how, you know, our jobs in IT, but specifically data people, are to help the company make more money or decrease costs or more money to decrease costs, decrease the risk and keep the CEO out of jail. And the pattern models can help with all of those, right? I think pattern models can help with all of those things. They can help you reduce... I mean, that's the cost-benefit of the models. I mean, if you are off film, what do the Romans do for us, mate? You know what I'm saying? If you have that question, what do the Romans do for me, mate? What do the Romans do that they build roads? They build schools and they build roads and they build roads to a standard. They build them to a pattern. I mean, the heroes didn't wake up in the morning and look out onto the desert and say, you know what? That's another big point you think, what were they called? I mean, they had a pattern. They had a template. Every bridge that you look around manhattan can't leave a bridge. They have some patterns and all those besides it. I mean, what Peter turns to, you know, are industry-standard models, like you described. You know, the excellent work that David's done, whether it's the actual work that Landon's done, and the stuff that, you know, the people around the world have done, it could just, you know, start off with a blank page. I think that's the name of one of my presentations, right? They don't start with a blank page. Yeah, starting with a blank page and, you know, not doing that, not starting with a blank page. One of the myths that just drives me bonkers in this space, and then I hear the sales guy saying it and Gal's saying it. Every time I go to one of these pitches, it's that it saves time. And my feeling on that is it doesn't save time. It doesn't mean it just goes faster. It just allows me to spend time on the more important things. So, for instance, the core of a blank page or, for instance, the core differences my business has or the uniqueness to it, so that I'm not spending a whole bunch of time researching how email works or postal addresses work or how I should model statuses and categories, that those things aren't line of business differentiators. They're just, you know, stuff that, you know, we should be reinventing every single time we create a data model. What do you think about the it saves time thing? I agree that it saves time, but if the time is available, we'll use it up for whatever we can. Exactly. Exactly. If you give us six months for a project, we'll take six months for a project, but at the end of the six months, you'll have a much better data model. I mean, it's not going to like, I have this rule of thumb that I use, and it's basically, it basically works off actually two rules of thumb because I have two thumbs. The rule of thirds is one of them, and then the rule of patterns. The rule of thirds that I use is if you can look at every data model and look at it and treat it with everyone does it, our industry does it, and this is the thing that we are the only ones to do it. So in other words, everybody does emails. Everybody does addresses. So if there's a pattern available, whoever pattern that belongs to, it will be used in that pattern, and it will be on the basis. In the telecoms industry, if I'm in the genetics industry, which is the guy I'm in, I mean, a lot of the specific to that industry, but every genetic testing company in the world uses it. Every kind of company in the world is going to have a network. Every financial company in the world are going to be doing trades and all kinds of things, and have securities, and you should be consistent. But it's that third. It's all special as a company. We need a difference that makes us competitively different. For patterns, you can't use patterns. That's where the patterns fall down because it's unique patterns by their nature are not unique. And what we do in our view of the world is that we say, let's handle the first two-thirds. Let us help you with the first two-thirds at the beginning. And the last third, that's where we really need to concentrate, our data modeling effort. Yeah. And that's great. And so I'll just agree with you a little bit, is that I've helped clients implement these industry standard models when they wanted to change their old world views of the data in their business space and bring it more into the modern era. So things like they didn't track any electronic communications at all. They, you know, believed that people who live at the same address always have the same last name. They, yeah. Or people only had one residence or that, I mean, these all sound like really basic things, but even when you get into their core parts, like, so for instance, one of the big ways that this pattern model helped a lot of my clients was actually correctly supporting international data. So even if they weren't an international business, per se, their customers were all in the U.S., they needed to start re-engineering some of their systems to recognize the fact that they actually had suppliers outside. And now they are. Yeah. And so that's the, some of the benefits of some of the patterns can help people with their core bits, even the uniqueness of it, that they could decide, well, we want to support this type of internationalization but not this type over here. So international stuff, that's because you're a Canadian. Yeah. Actually, it's all your Canadian stuff coming in there. Yes, it's my Canadian influence trying to change the world. The world needs a little bit more Canada. It needs a lot more Canada. Oh, David's on. Thank you, David. You must have been driving you crazy not being able to hear. Can you hear me? We can hear you loud and clear. Can you hear me? You can hear me? My God. Technology. I hate computers. Excellent. So, David, since you just came on, Paul and I have been talking about some of the myths of pattern models. What's your favorite or most favorite depending on your point of view? I was listening to you guys. The thing that was upsetting is if I could hear you guys, you wouldn't even hear me, which is particularly frustrating in my world, in my mind. I'm not that kind of guy that listens and doesn't talk. I miss the data modeling. One of the problems is the one that you mentioned, Paul, about being actually being technologically biased. And my problem is that, yes, most people who do data modeling are technologically biased, but I don't think that's how it should be. I view data modeling as a way of trying to identify the underlying simplicity in what otherwise looks like a really complicated world. And I do that by looking for, as Richard Barker said, the things of significance and the facts that connect them together. And it's true that the tools that we use that are true to be aware of things like foreign keys, which drives me nuts, because what you have is two things that are related to each other, and that's what's important. And early on, again, because of my particular training, it was the other modeling the semantics of the business. And in fact, in my first book, I talked about the semantics. The patterns were in effect semantics standards as opposed to syntactic standards that everybody was talking about. So it was very funny. A few years ago, I thought that maybe data modeling was becoming passe, and nobody was interested. Suddenly, the word semantics became a hot topic, and I said, hey, I'm cool again. That's what I do. Yeah. So, David, let me interrupt you for a second, David. Go ahead. Before you go on. So, on that topic, David, do you think even, so specifically we're talking about pattern models, do you think that this is sort of one of the bigger issues in our whole industry is that we do a lousy job of explaining all types of data models and why we're a data model, because we're lousy marketers? I would say there's something to that. I recommend everybody go to YouTube for some kinds of data models. I will find my little presentation on exactly that subject. You can go to our clients and complain that, you know, usually we don't use language very consistently, and we've got to come in and help you straighten it all out. But we have this problem that, okay, what do you mean by a logical data model? What do you mean by a conceptual data model? If you've got people there, there are at least six different opinions. And yeah, I agree. That's a serious issue. And that's campaigning to realize that what we're supposed to be doing is creating ontologies. The ontology you should recognize is the first 2,500-year-old hot new buzzword. That was the branch of philosophy that was concerned with what exists. And the idea is that if you do it right, your model is going to be a representation of what exists. And then new technologies going on for modeling that. I don't know if it's a semantic web, but some of you have probably heard of it. Yeah. Which is interesting because you can take your data model and put it into OWL, but you can also allow stuff that is completely unaddressable by what we do in data modeling. Right. Because all that interesting stuff in the semantic world, like I'm also following and paying attention to what's going on there. And one of the things that, as I attend the semantic stuff, is that, you know, part of their approach is to kind of think about data as a pattern with things like URIs, these universal identifiers, and URLs, and all this other stuff, is that at least unlike many traditional IT projects, I think they're trying to recognize the fact that there's data we have about things, even though they would just say we have things so we don't have data about them, that there's data we have about things and we shouldn't go redefining it for every single project in our company, not even every single project across companies, right? Right. So learn that from that. That's a piece of it. And the whole notion of the universal ontology, which is sort of what I tried to do, that was an attitude behind my last book, was sort of a universal categories here. And it was with that. Now, one of the amusing things, if you get hanging out with those folks though, is that, to point out that, if we're coming with a world of databases and relational databases, we have what's called closed world assumption, which means that if data doesn't follow our rules, it's out. We're into that. But if you're doing an exploratory kind of thing, which one is the open world assumption, which says that if data doesn't violate a particular rule, it could be true. And that helps the world a whole lot of interesting things. Yeah. It's not that we are interested in data models and our data model patterns and we look at it, give people an opportunity to say, okay, here's a basic set of things we think are true. And use that as a starting point. And then go do your exploration and see what else you can find. That's a really good point. So one of the things I tell people who are working with pattern models is don't treat them like legislation and law, unless legislation and law requires you to follow them to a T. Right? So I remind people that even the entire Internet is built on not standards, technically, but what are risks for comments that we implement as standards? And we realize that if you want to build your own email system and you want to exchange emails with people all over the world, if you violate the RSC, there's a good chance that your email won't get through or you won't receive it. So it's kind of a self-policing, I mean, you can get certifications and stuff, and there are certifications in data models. I wanted to ask Paul, what do you feel about what David is saying here about all of these different types of models and everything? Good. David's view is very interesting, and I think the first part is absolutely correct. I do have a few minds, but I have an mentor, which is something that, in a way, we must have, David, our anti-data modeler, you know, we are affected by this. I've got the Heisenberg and certainly the principal of the modeling. Certainly by the fact that we are actually going out there and designing things in a particular way, whether that's relationally or UML, or however we've taught the system in some way that we've affected it. So that's the, I mean, whether that effect is detrimental or not, that's a totally different question, but be aware, but Hollandaise, just be aware of that. But David, so just be careful everybody out there. Don't lock yourself into a viewpoint. Don't lock yourself into one way of looking at the world. I think David is absolutely correct in what he said. It's an ontology type of way. And what we, David and myself do, is that it becomes complicated. We're trying to give you the tools, the patterns, and maybe make less complication out there. We're looking at the fundamental particles of data modeling, and we're trying to figure out what those fundamental particles are. I guess that's what I would say. Paul, you did a really good job of, in your book, doing sort of global data model patterns, of doing the atomic patterns. And they're absolutely the raw materials, if you will. They're more sort of global, and I try to put those together in something meaningful at the next level of, but you're right. It's a matter of having any patterns in the models that you build, a sort of raw material structure that people can build on. It's the notion of it being a foundation that people build on, not that this isn't the thing. However, in order for the foundation to be right, it has to be based on relatively true things. And my book has six basic categories of people and organizations and geographic locations for these physical stuff in time. And that's the who, what, where, when, why, and who, where, when, how. Why actually happens when you get more complex and you're talking about where you're selling things with contracts or rebuilding things, and that's at the next level up of attraction. But if you get the right raw materials, if you get the right components, then the rest of it becomes a lot easier. In a way, I want to echo that as well. And I think that in a way that it's a key for me that also to modelers, the thing I hear a lot and I hear from them is, oh, data modeling is as much art as it is science. And when I've heard that, I just go crazy. I go nuts. I just, I'm with you. And the reason why I go nuts is it's not science and it's not art. It should be engineering. It's a engineering discipline. However, to do the engineering, I guess, from perspectives, people like myself and obviously David are working on trying to get a little bit of science, a little bit of science behind physical particles. And in a way, David looks at things from a, he's like a cosmologist. He looks at things from the universe. Whereas I'm a form of the metal. I'm a Einstein. Right. I'm already exposed in type of dialogue. Okay. Right. I think that's true. Yeah. Hopefully, it's not engineering. It's philosophy. You understand that after my undergrad to a degree in philosophy, it never occurred to me that I would actually get a job which was being professional for both philosophy. What is the nature, what is the fundamental nature of things? What's going on here? Yeah. Excellent. So some of the other topics, I want to make sure we get to all these things so I know we can eat. We're all, the three of us are kind of philosophers as well. I mean, we think a lot about what we're doing and why and that kind of stuff. Yeah. I'd prefer to be the physicist. Okay. The physicist. So there are philosophical physicists as well or physics philosophists. Right. Okay. Here we go. And so one of the things is that one of the criticisms I hear about these problems, especially the proprietary ones, but even the industry standard ones, is that they're too generalized. And I mean abstract, generalized. So we don't see, you know, there isn't a box for department and vision. There isn't a box with some lines on it for state. You know, they've entered a foundation and it's funny about that. Let me interject here because I have done my models to business executives and I've done models to IT people. Business executives, if you go to them and you say, well, you've got an employee here and you've got agent there and you've got somebody who's both an employee and an agent and so on and so forth, how do we call this, you know, they have no role in that. So they're quite happy to generalize. They say, you know, you're right. Those are members of a larger category. The IT people go bonkers. The experience of thinking in very specific categories. And if you talk about different categories and the ones that they know, they can't deal with it. That's because my experience has been exactly the opposite. The business people go bonkers that I don't have a box for employee, temp worker. And I might have subtyping to do this. But these abstract generalize contract concepts in their data models and their implementations. Now I keep trying to remind them that end users don't have to be exposed to that terminology in the data model. You can still call a screen. But they really, at times, are very frustrated by that because they want to think in terms of their business lingo. You know, if they call their, you know, they call their invoices orders, like some company do, or receipts invoices, which are common in parts of the world. And, you know, they're very frustrated that the model doesn't act. If their model shouldn't it be that way? Well, that's one of the things I touched on in my video, that you add two layers in there. One is what I call a semantic model, which is actually what you say, exactly the semantics of the business. In their own region, you capture that as best you can. And be sure you get those terms defined. And be sure you're in a position to point out that what this guy calls A, this guy over here calls B. Do you guys understand that it's really the same thing and so on and so forth? The trick then is to get those and distill those into more fundamental type concepts. And what you should do is, and this is my idea. I have had varying degrees of success in this. When it's been successful, it's been spectacular. And when it's been failure, it's been equally spectacular. But you come to recognize that what the different people are talking about is really equals of a more common thing. And when you get that, and they'll come to you and say, wow, how many years have you been in this business? I say, well, about a week and a half. But get them to understand that these are really examples of the same thing. Then they learn something. And appreciate the experience of having learned that. They have to be willing to go into it with an open mind. And that's the problem with everybody. And one of my problems I get is since I get hired by the IT department and I come up with something slightly abstract, the user will never buy it. And well, we don't know that. They just write these people off about they'll never understand it. Yeah. So Paul, you've done some writing and some talking. I know you and I have talked about this generalization specialization thing. Do you have anything that changed over the years? Do you see it? Or just as something that one person told me it was just a lazy data modeler because eventually you end up with things related to things. So what's your thoughts on that? Well, in the book that I wrote with Landon Pam, we think there are levels and layers of approach. You need to be generalized. Some things you need to be fundamental. Some other stuff. It depends. And sometimes you're going out on a date, you know? Hey. I mean if you're talking, every time we talk to IT or to business or whoever, you know, it's very easy to talk about the movies. I mean, it's just, you know, that stuff is, you know, on your audience. However, what you guys just raised, something that occurred to me when you were talking there is maybe a fundamental problem or fundamental hurdle that we have to get over in patterns. And that is in template patterns. It's that when we create template patterns around orders or contact mechanisms or other categories that David expressed or your own, we apply a set of semantics to them that people like Seth and David and Landon have really tried to be careful about however. The problem with the pattern is that there are semantics. We try to be careful. We try to be as general as possible so that an order means an order. And we try to define those things. Can you apply that pattern to an organization that doesn't think that potato is potato? They describe potato as palm de terre. You can still make mashed potatoes and french fries from them, but they call them something different. So that's semantics is important. And it is a little weakness that we should be aware of. When you apply a pattern to an organization, you just have to be aware of however. Having said that, when you go and build a counter-level bridge across the eastward in New York, it's not exactly the same. The Manhattan Bridge doesn't look like the Brooklyn Bridge, doesn't look like the Williams Bridge. They're all different. They're all basic fundamental patterns that have been applied, but they get applied differently given the different circumstances. So interesting thing about how the patterns work. I'm wondering if either one of you has ever been plopped into a project where management, either through golf course acquisition or various convention acquisition, has purchased a very expensive or other data model and none of the internal architects, either data or process architects, have been involved in evaluating or assessing it. Have they ever had to live with patterns that were acquired through not-grotexure reasons? I'll let you know first to know. Well, I have been in situations where they had done that, and my first objective is to throw them out. Yeah, they've been committed to their $6 million. So you get them to throw away $6 million? Well, the point is it's not so much that... Well, you know, what I had was industry patterns. They hadn't actually paid anything for them. They didn't have the oil and gas industry. And everybody was thrilled because this is the oil and gas industry standard, and the thing is it didn't make any sense. And I had to... The first job was to kind of gently show them that it really didn't make any sense. And there was a similar thing in the banking because I actually brought in to help them select an industry model because they didn't want to do their own model. So the first thing I did was to draw the model of banking because I needed them in order to judge the other models. And in one case, we bought... We finally selected the one that I thought was pretty good just before the bank got bought by somebody else, so the whole thing came to an end. The second one, we wound up getting the IBM thing, which is an actual monstrosity. It actually had a whole lot of really good stuff in it, so I couldn't fault them for picking it. But it was very clear that the job of managing this model was going to be horrendous, and nobody had shown much justification in modeling that they were going to be able to do that. And it was ironic, many years later, a friend of mine worked for that company, and the model is still there, and they saw it and figured out what to do with it. What about you, Paul? Actually, you don't have to be honest there. Nobody... I've always come in and... It's not what pattern models that existed from somewhere else. It's the existing thing that's built over, built at so many points, and it's dragged out. You think that's a good thing? No, I'm not saying that. It's never... You see, I refer to my answer earlier on, the Lord. The question is, is that... Yeah, Milady, it's things that are, in a way, I kind of say they're not bad or good is whether it's used or not. I mean, what David said about the oil and gas industry model, I've had the exact same experience, and it wasn't the fact that it's a bad model or a good thing. It wasn't useful for those circumstances that we were in. So it was like, anyway, we're proving usefulness. Okay, good? It isn't useful. Yeah. Since you've brought that up, how do you very quickly define what's a useful pattern model? Well, I think, you know, that's a really... That's a really good question. And the way I always do it is scenario-based. I mean, there's just standard... In a way, if you... I refer to the Third's rule, because the entire company does addresses and phone numbers, so you show a scenario at that, and that applies to everybody. Every company comes, every company supports networks and supports plans, telecommunication plans, or every financial company does trades and risk and really analysis and does, you know, forwards and options, et cetera. Trotos scenarios, is that a Trotos trading scenario? Is that a... The best one is when you trode the last set of things, the last set of scenarios, that the businesses that are completely unique to that business. So I was at an engineering company, and we were evaluating a project planning kind of model that they were going to apply, and the scenario is that this great engineering company just blew the crap out of the model, it just wouldn't work for it, because they were so different. Interesting. So that's how I approach it. Very good. Very good. Let me repeat the question. Yeah, how do you define what is useful for a company? Well, the easy answer is, you know, they can use it to build something, which is kind of punting, which is not really the answer I want, because I want to know that it's useful because the share elegance and buoyancy and so that suddenly comes to bear. I have a really hard answer. There are places where it becomes evident that it's useful. There are other places where... because they're not in a position to use it, it's not. It's the whole business, so when you're teaching, you know, are you teaching them what they want to hear, what they're in a position to learn? It's like the old book on this childhood, that if a person is preferred to deal with what it is you have, then its goal is wonderful. If it's not, then which one isn't useful, because it's not doing what they're after. Now, that's a very good generalization. But I don't know how to be more specific than that. Interesting. That's also something... you know, sometimes I'm asked to help people evaluate pattern models, and I'm usually lucky in that I am only doing it for one specific project, so I can treat it almost the same as evaluating a software application. You know, we know what we need to do, we need to see whether it covers the same scope, whether it meets the principles of the business, whether it follows the culture of how we do design, and to show my bias is the type of projects I've been working on lately are definitely we're building something, necessarily acquiring it for some strategic enterprise reason, but to assess whether this pattern and a whole bunch of other patterns, XML patterns and software patterns and tools and support tools, whether they're going to help us build something and get it into production, keep it in production. That actually grades a different point, and that is that I don't strictly speak and sell my patterns. I sell books, and I'm loving when people buy my books, but the patterns are tools that I have. And each project, in a sense, is starting from zero in the sense that I've got these tools in my pocket. Oh, that's an example of one of those. Fine. That's an example of one of those. That's good. That's an example of one of those. And I can do a model very, very fast because I have the patterns in my toolbox. I don't really go in saying, in fact, I get in trouble if I do. In some cases, I try to say that, and they go, they threw me out because you don't know anything about this business. What are you kind of saying? You've got models for this already. And so I tend to try not to say that to say, well, all right, let's see what we can do here. Well, yeah, you've got the product structure and you've got some sort of ordering thing going on. And it's happened. In fact, it's funny. And I tend to do that in general to start with. And I do a much more particular model. And then I do another model. And I do another model. I say, well, I should have started with more general because we're, in fact, going to the same place. But no, it's the modeling experience that is where the patterns are useful. The patterns as a product per se, I don't think work because people know how to use them. And it's my skill in using the patterns that is what they pay me for. Interesting. So since we're talking about usefulness, one of my interests when I look at these third models, I mentioned at the top of the hour, was formats they come in. So certainly the patterns that I've seen from you guys are ERD-based. But as I tweeted during our thing, is the most common format that these data modeling patterns are released in are XML. And I think partly that's because people bring them that people who are building them aren't data modelers but they have XML. And that's how they think of data. I am actually seeing those. But I have been fighting the, there is this thing in the government called NIEM, which is their attempt to communicate between agencies and some of the XML. And the problem is that they don't have the underlying models to understand what the stuff is that they're sending from one to another. And many agencies discover that and they sit down and they say they do a data model but they really are off to the bad start just because of that. So I'm familiar with NIEM and definitely it will tell you it's not a data model. It's an infant sharing standard. So if you're going to share this information, here's the actual XML messages. So it's definitely a very physical type pattern that is intended to be implemented. It's not a logical model of any type. And that's one form of it. But we'll talk about XML data model patterns. I'm talking about persistence layer. Here's how you think of customer. Here's how you think of location. And for me, XML is a bad fit for that, not just because I'm a data modeler and tend to think in ERDs, but because it's really hard to express the complexity of data at rest. Data is much more complex at rest than when we're sending it. And I've also seen UML models, both class models and various different forms of them. An awful lot of them come as pictures and diagrams. So there's what I say not really a model, just a picture. But I'm wondering, part of the reason why these people release them in that format is nobody's asking for them in something that's easily consumable by data modelers. Sorry, can I? Sorry, can I? Human beings. Good. I actually have a fundamental problem with what you've put. Okay. Great. I think that is, I think we're using a trick, guys, right? So what we're expressing is a fundamental pattern around data, right? Yeah. If we really want to express it, it's like a diamond. That there are multiple different facets. We have to concentrate our, the facets we have to concentrate on is the relational facets. There's an object-orientated radiation of it. There's an XML rendition of it. There are different conditions, different ways of looking at this particular diamond. And for completeness sake, for data in a complete fashion, we should be addressing our data modeling patterns and looking at the opposite object patterns that support and work with them, prompts an XML that works with them. There are also different facets to give us truly, you know, how the detectability... This gets to a distinction that I make in my video, and that is that the essential level, what I call an architectural level, this is the anthropology. This is the nature of the world. As soon as we start talking about a relational database or an object-oriented model or XML, you're talking about a particular way of representing the data, and this is very specific to the kind of technology you're talking about. What's the next layer down? That's the next level. And I believe all of those, no matter where you came from, you want to start with this essential model and derive each of those things from that. If you start with one of those, then you get in trouble when you try to go to a different one because there's no direct translation across. That's why we have architects, right? So just to clarify with what Paul said, so what I'm saying, expressing an XML is wrong or an OO model is wrong or a UML model is wrong, but so I'm giving you a couple assumptions here that if it is a data model that isn't an implementation component, it's not a component I'm buying, like SNP if it's a code, is that the further away it is for the harder it is for a data modeler to consume it and then start working with it and tailoring it, the harder it is to be productive with it. So my big belief with this is that some of the most expensive third-party models are only provided to you in Word documents in PDF format. The thought of having to retype, even if I'm tailoring it, potentially hundreds of thousands of object definitions and even consuming them in XML form if it's a true thing to think of as a data model. And definitely, XML can express the data model as well. I can produce my data model in XML, right? Is that making it harder to consume is also one of the biggest cost barriers and makes it less useful. That was my point. Yeah, the thing is with the models you're describing are what I call archaeology. I get that occasionally. Basically, my job is to go in and figure out what's the underlying, what's real there. And that's such as the intellectual exercise, but it's not useful quite as well. If I look at that, I can come up with a model and then you can read and manipulate and understand, and then we can talk about it. I can't tell you in the original models. In a way, Karen may be the only true way to express a pattern correctly is mathematically. Okay, you've lost me there, but it sounds really quotable. I wish someone would tweet that. I'd like to see that in my tweet stream any minute. Okay, and we're actually getting close to the top of the air again. We've got five more minutes. So because we have five minutes, David, I'm going to ask you to give your one or two sentence take away. And I know that's a huge challenge for you, so... One or two sentences only. Okay. Okay. I'm sorry. Oh. Sorry. Hey, try to clarify the underlying simplicity. This is ostensibly a very complicated word. Paul? Go build a wheel. Go buy David's book, buy Land's book, buy my book. Buy those models. You can use them. You may not only use them, but at least, you know, go through them and that might give you some inspiration. So I'm trying to reinvent the wheel of yourself. Yeah. I know that's really kind of my takeaway. I mean, both of you are spot on here, is don't make it over complicated. And there's just no reason to just start at a blank page and start thinking, hmm, what information should we keep about our customer? And we shouldn't just go to our old systems either, right? We shouldn't just have to do that as well. It's that we should be able to look at patterns and products and all of those things. So, you know, every data modeling class I've been on, well, most of them, don't even mention the concept of you don't just start from a blank page. The vast majority of work we do is within the context of preexisting systems and data patterns already there, right or wrong, and third-party patterns and the industries worked on them. I think that's all great. I'll go through the chat since we have a couple more minutes. And I think in general, our third panelist, the audience, was in agreement with what I said and what Alba said, and they also shared some other insights and experiences they have. I know when Shannon does the follow-up, we usually try to summarize this stuff and there are no slides to share. Oh, I have one more poll. I should do that really quick. You can get it to come up. Let's poll three while I'm talking. So, you're more or less interested in using pattern models. Is that a vote current? Yes, you can pick a poll. Yes. All right. Thank you everyone for voting away. And I'm going to head and start closing the poll, which will take 20 seconds while it comes up. What's happening? I wanted to make sure to thank again our sponsors, CA Irwin Data Modeler and the people at CA for making this webinar happen. And David and Paul for being such great, moderated speakers. I know both of you could talk for hours on this, as could I, which is also partly a time to be a dispassionate moderator on all this. And I'm going to go ahead and show the poll results. And I'm talking to about 22 people. About a quarter of you are now more interested in pattern models. About 35% of you is that, yeah, I'm just the same. And one person, I certainly should guess who that is, who's less interested, and a chunk of you who gave no answer, which means you're not, I guess, or you forgot to look at the poll. And I want to thank everyone for doing this. It seems like the time went by so fast this time. The normal time period for our webinar is actually Thanksgiving Day. So we're going to let you guys all be thankful in the U.S. and the rest of the world will just be a million times more productive while everyone in the U.S. will be happy and not bugging us. So we're going to move it to, I believe it is in early December, the first Thursday of December. And that topic is going to be the data professional holiday wish list, and we're going to have a group of people and we're going to talk about what toys, gadgets, tools, and wishes we have for data professionals for the coming year. So you can join us there. So Shannon, you have some closing thoughts if you'd like to go. Thank you. Well, this, of course, I want to say thank you to Paul and David. Thank you for joining us. I'm so happy that we got you on and got you working. And thank you, as always, and also to reiterate the sentiment, thank you to CA as always for sponsoring and just enabling us to do these webinars for free for everybody. So that's just great. And I love the chat and I love the engagement that just goes on. We'll make sure and get a copy of that out to everyone as well. And I'll send a link to the recording along with the links to the chat and as well as links to David and Paul's books so that you guys have access to those as well. Excellent. And we generally stay on for a few minutes after after the recording is turned off and the few attendees are welcome to stay after too. And if you have any other questions, especially ones that you'd like to have answered with the recording turned off, please go ahead and do that. The recording is now...