 Hello and welcome, my name is Shannon Kemp and I'm the Chief Digital Officer of Data Diversity. We want to thank you for joining the latest in the monthly webinar series, Data Architecture Strategies with Donna Burbank. Today, Donna will discuss the benefits, the business benefits of data modeling. Just a couple of points to get us started. Due to the large number of people that attend these sessions, you will be muted during the webinar. For questions, we will be collecting them via the Q&A panel. And if you'd like to chat with us or with each other, we certainly encourage you to do so. And just to note, the chat defaults to send to just the panelists, but you may absolutely change that to network with everyone. To open the chat and the Q&A panels, you will find those icons in the bottom middle of your screen to enable those features. And as always, we will send a follow-up email within two business days containing links to the slides, the recording of the session, and any additional information requested throughout the webinar. Now let me introduce the speaker for the monthly series, Donna Burbank. Donna is a recognized industry expert in information management with over 20 years of experience helping organizations enrich their business opportunities through data and information. She currently is the managing director of Global Data Strategy Limited, where she assists organizations around the globe in driving value from their data. And with that, let me give the floor to Donna to get her presentation started. Hello and welcome. And yes, we are live from DGIQ in DC, Donna. This is really exciting. It is. We very rarely are in the same physical place, but today we are. So that's kind of fun. So that's the good news. The sad news is that this is the last webinar of this calendar year, but good news, we will have a whole other lineup next year for those of you who enjoyed data architecture strategies. And the other good news is that Data Diversity does a great job of keeping all of these and thinking perpetuity on their website and also out on YouTube if you want to catch a replay of energy, other topics that you might have missed. So without further ado, let's dive into the topic of the day, which is data modeling, which Shannon tells me is always one of the more popular ones whenever Data Diversity does webinars, because data modeling is awesome and we will go through why that is. So why data models are great, especially with the focus today being on business value and business focused data, technical data models are also have this business value. But one of the great things in particular about, like, say your business level data models, like a conceptual or logical model is really a nice way to communicate between business and technical stakeholders, right? So I want to kind of go through that show some success stories and maybe some more practical ways of how you might get value from your data models if you don't feel like you are already. So one thing just point out there, and I don't know why. I think it's vendor hype or whatever. We keep hearing about how no one's doing data modeling anymore, right? And that's old fashioned. And now we have, you know, insert technology here. I think it was big data and then it was cloud. And then it was AI. And then it was whatever else is going to come next to why you don't need to design your information the way your company runs. And that if we know data models, you know, that just doesn't make much sense. Nothing is magic behind the scenes. And so I thought this was a, you know, good metric for you who might be doing data modeling or considering data modeling. It is normal. Everyone is doing it, or at least in this dataversity world of ours from a recent survey. I mean, my company at a university each year put out a survey on data architecture and data management trends. And from the dataversity crowd over 96% of folks were using data models. So that's pretty much everybody. So be proud. They're great, but they're not always used in the most effective way or we could always optimize, but that's true with everything, right? So let's go through that and be a little more nuanced. So and I may feel sort of naggy with this one, right? But, you know, that that famous adage of, you know, if you don't have time to write, to do it right, do you have time to do it again? And this is a cartoon from one of my data modeling books that maybe isn't all that funny. But, you know, this idea we're already done with acceptance testing. We've launched out this marketing application. But what do we mean by a customer? And that might not seem funny until you've been through that. I know when I used to go to the dataversity conferences like DGIQ and that's almost a classic joke instead of a presentation or in the conversations and someone would say that. And everyone would laugh. And I was young and I said, why, I don't get it. How hard is it to define a customer? Ah, what little did I know until you try to model a customer? Is it a current customer? Is it a lapsed customer? Is it an enterprise company? Is it an individual? Just that one question I've seen cause headaches and cause misunderstandings across groups when one was talking about the organization and one was talking about a human being, even getting that clarified, right? And we'll talk more and more about that because a data model, especially at the business level has not only the, you know, the structural definitions, but the business definitions that sort of, I like to call it a glossary on steroids, right? Because not only does it have your business definitions, but it has the relationships between these concepts, which is super important. But it is often tempting of, well, we have a big project or here I go, we have an agile project with agile sprints and we'll just skip that documentation because it's faster, but that may not be faster in the long term and I'll go, I'll sort of end this presentation with some real-world examples of massive multimillion-dollar mistakes and, you know, that literally, if you don't have time to do it right, you have to have time to do it again to redesign a system that's already been implemented with the wrong business roles or the wrong design, or that's just from a technical perspective. What about from the business process or the business impact of making some of these bad decisions can be massive, right? So a little planning down the road, I will give us data modelers a little bit of a hard time of it doesn't have to take years to do it, right? We can still, you know, I think we sometimes get a bad rap in the industry of are we getting too academic about it and are we, you know, spending too much time where we really need to put the crux on the business value. So we'll go through all of that. So part of the discussion today is the different levels in a data model. They are all valuable and they all have business value. So, you know, we could have said, because this topic of this conversation is the business value of data model, we might start with the business level data models, like conceptual and logical, but physical data models show efficiency, cost savings, time savings, quality improvements. So we will cover those as well, as well, even though you may not show those models to a business audience, right? So walking through this, if this is new to you, there are different levels and types and we'll give examples of data models. So I'll start with the dark blue when they're conceptual data model. We love to play around with names in the industry and call it different things. It could be an enterprise model. It could be a business. I like to call it the business data model because it shows really the business view. But part of the reason is conceptual is not because it's high in the clouds. That's why that word sometimes has a bad rap. It seems theoretical, right? But it's very practical and it's talking about the concepts of the business, things like your product, customer, patient, employee, student, you know, stuff that runs your company, what are the definitions of those? What are the relationships between each other? That lives in your conceptual data model. Sometimes and I think it's helpful for most organizations, but if you're a smaller org, maybe it's not as critical as to have that little tip of the iceberg one, which is the enterprise subject area. Is there a subject area of consumer which has companies and, you know, people, customers and locations of customer, all of the things around particular high level subject areas, domains, that can be really helpful too. Now we've talked about the dark blue, which is a conceptual, the logical, which is the light blue, is also a business focused data model. And that gets a little more detailed. You're going to have your business rules, your latch or butch, maybe some data types, but you still should have the audience be a business person or maybe a business analyst at that point, right? Maybe not your pure business person. You'll see that I have a data architect in those levels too. And we'll talk about this later in the presentation. I may be going out in a limb. I do see business people creating their own data models because it's the logic of their business, but generally a data architect would help kind of facilitate that conversation where the business understands the business rules, the business definitions and the architect understands data modeling and data architecture and the implications of that. And it's a nice teamwork of how, you know, hey, this is the business role, how might we best represent that data language so that can work really well. The physical data model, please don't show that to a business person, but it has massive business value because what this, what is this? This is a pyramid trying to show. It is that the volume, so where your enterprise subject areas, maybe you have five, ten, like you should put on a page, right? Your physical tables for those five subject areas might be thousands of implementation on a database or a system. Think of if you've used something like SAP, which is a, you know, enterprise, an ERP system. There are thousands of tables in that system. And what does it do? One of the things that manages customers, right? That might be one box on your subject area or PeopleSoft, right? That's our, you know, we manage our prospects and customers there. What's the difference between a prospect and a customer, right? Anyway, but, but, you know, the conceptually those concepts are huge, small, but the number of tables to support that are huge because it's running a system, right? It's not dismantling the business rules. So hopefully that's helpful in terms of the audience, the usage and generally the volume of data. I will show you some exceptions to this in this very presentation, but generally at the conceptual layer, it should fit on a page-ish, right? If you have a thousand tables on or boxes on your conceptual model and you've gone a little too deep, right? It should be at a high level. And I make that mistake all the time because it's, especially if we're architects, we love to get into the rules and the weeds. That's probably you're getting into a bit of a logical model there or maybe even a physical implementation. So be careful of that. That said, I sometimes go back and forth, sometimes you have to get into the weeds and then zoom out again. And that's why these models all kind of fit together in a pattern. Okay, enough of that. So let's give a little more detail. Sure, another thing, that's a fancy word that I'm going to mention is when we build a data model in and I have people disagree with me, but I'm right and they're wrong. There we go. No one here to disagree with me. I'm a single voice. No, but I am right. So when you're talking in a business data model, use the language of the business because you know, think of what the business is good at. They look at PowerPoints, they look at diagrams, they look at org charts, they look at process models, folks get boxes in lines pretty easily and they understand their business. So you know, a simple sentence like on the right, a customer can buy many products, a product can be purchased by many customers. That's a very simple business rule. But please do not oversimplify. I mean, you could say, well, maybe that's just party. It's a party and it's a thing, you know, maybe if it's a party, there are valid cases for a party and a model could be parties in a lawsuit or something like that. But in general, I've had conversations with architects like, well, really in the back end, it's just one table in the symbol. Then you're now getting into the physical implementation. Yes, just does an employee and a individual customer, both have a first name and last name? Yes. But to the business, how you treat an employee and how you treat a customer and not in terms of from a human level, but from a data level, maybe both from a data level are very different things. The privacy of one versus the other, the attribute, you wouldn't have a higher date for a employee, even though they both have a first and last name. So yes, maybe you can do some generalization at the physical level. Maybe you shouldn't. What's the value of tables or I'm going to get some controversy or tables are cheap, right? But but what's the risk of mixing data that really shouldn't be mixed just because there's some similarity. The whole point of data modeling is to understand, you know, we have we're a hospital, there's patients and employees and doctors that all are treated very. Do you do you have a certification for a patient? No, but you do have a certification for a doctor, right? So just think through some of those things. Also keep it simple. And again, I mentioned how challenging that is. It is harder to make something simple than to make it complicated. And you know, sometimes we get pushed back up. Oh, so you've been working on that for, you know, a month and you have five boxes. And like, well, that's the beauty of it. We took the complexity and we simplified it into five boxes, which is really hard. Right. But those boxes are right. And they're valid. Those rules are valid. I say I get that I see that I get that less and less once those five boxes resonate or 20 boxes or whatever it is, because people don't necessarily care. Well, yes, we're billing time no matter who you are. But it's more the value of it. Once they see that this can be successful to help them with some of the core business rules of the business, people are bought in. So think of that. This is the purpose of the previous slide. The purpose of a conceptual data model is to communicate key concepts and rules about the business. So you can and should be a little more flexible, whereas, you know, at a physical level, there are rules of database normalization. And you have to have keys with tables and you can't have bizarro data types, you know, so that you should be being a little more strict because the goal is to implement a physical database. So if it's a date, make it a date field. And if it's, you know, you should really be thinking of that the conceptual level, you're trying to communicate concepts. And yes, let's have logic in there. But really, the goal is to get those those business rules out. So this is one way I often show a conceptual data model. One of the things I like about this tool is that it does show the business definitions right there. And this is what I meant earlier by, you know, a glossary on steroids, right? Of, you know, the business terms are right there. So if somebody said, you can read it right there, an employee is a fuller part time worker on the active payroll for the org, contractors and employees, you know, and someone might say part time, we don't have part time people as employees, aren't they interns, right? Right. So then they can see it and have that that that conversation, or we can, you know, see the relationships that a company has a relationship with a sales rep represents multiple companies. What does that mean? It should be business rules on some of those, right? So it starts to tell the story, you know, and get some of those key terms in this right out there. A common question we get of our do you put attributes on a conceptual model? I generally do. You don't have to. Yes and no, right? So one example of no is it's very clean. You're really focusing on the relationships between entities and on their definition. Sometimes throwing some attributes can really clarify something. I'll give a couple of examples. One was customer, right? If I'm showing a customer and I say first name, last name, gender, I'm pretty sure that's not a corporate customer, right? But if I say customer and it's, you know, Dunn's number and, you know, address or something like that, then you can clearly say, okay, now we're talking about just by looking at the attributes, right? We were working with the consumer package goods company and they had one of the things they sold was beverages, right? And we're talking about products. Is that soda and beer and, you know, carbonated water? We could kind of tell by the attributes. Some of them are optional, but you could say there were hops and things like that. Okay, so I guess we have beer and sodas, caffeine also, right? And so, and then you start to get into really seemingly philosophical questions that are actually core to the business. So folks love to tease us. We feel all academic like, what is a customer? What is a product? But the number of C level people I am working with, with using a data model to really core define their business. We are, for example, working with a, they do conferences, they're kind of like the diversities of the world, but they don't do data conferences, right? They do, I don't know, fashion conferences and, you know, other conferences that people in the world go to and they are now looking to offer more actually diversity like services. They can do blogs online, they can and so really, we had a whole, I kid you not, this is true, a data modeling conversation with the execs to really think through what is our product? What is our core? Who is our customer? And who's the core value proposition and what are our products? Is a product only a conference registration? If you purchased or downloaded a white paper, is that also a product? And who are customers? Are our customers the vendors of the conference? Are they the people who attend the conference? Are they the organizations that either attend or sponsor the conference and how do they relate? Seems really simple. And the data model at the end of the day was, you know, 10 to 20 boxes, but it was critical to really understanding that conversation, right? So yeah, it can seem theoretical. What's a customer? What's a product? But if you're running a company, that is your business, right? Or, you know, I don't want to only look at for-profit examples. We've done a lot of work with universities lately. What is a student? And even just telling that out, it could be a, is it an on-campus student? Is it someone in the military who happens to be overseas and they're logging in online part-time? Is it a returning professional that maybe takes one class? Is that truly a student, right? Really understanding all of those nuances can be really well done in a data model. Okay, I will move to the next slide. As you see, I get passionate about data models and I can talk all day about one slide, but Shannon gives me an hour. So I will move on. Another way, as I mentioned earlier, be flexible in the presentation. I often, and some of the, you know, data modeling tools are actually kind of good at this some bit of another, you can actually put a picture or put it in a PowerPoint, right? I mean, I know I'm a technical person, but we're at the conceptual level. So we're talking about a sales rep and a support rep and a customer versus a company. Now, look at the one at the bottom that very clearly calls when we talk about a customer, that's a human being, and the company is the organization. And then you're going to have questions around it. So I did this for the first time. What was I thinking? For a very one of the biggest insurance companies in the planet that was doing a merger, and they've been around between the two companies for over a hundred years and work with high net worth customers. And they're very, you know, a state, you know, you go to a suit when you go to that company, right? That type of company. And I was trying to explain the data model and I showed pictures like this. And there was a pregnant pause from the the head of marketing there. And I said, oh, dear, probably picked the wrong customer to be kind of cutesy like this. And it was something like the person down on the right. And it was high net worth customers. And actually, we this was a kind of result of that first and to be totally stereotypical, we had kind of a gray haired white guy, right? She goes, that's interesting. And I'm still like waiting, is she going to still puke all over this? Does she like it's like that? You really made me think that historically has been our customer. But now looks kind of like the guy there now. It's often someone from Silicon Valley, who might be 30 and a very different dynamic. And what we've learned from that is the interaction patterns of where's the old vessel or older, you know, they want to get a physical letter or have a count rep. The other folks want to have a mobile experience, right? And that putting the little picture on that expanded the data model we actually had, you know, how interaction method is it mobile or, you know, kind of snail mail or do they want an account rep? Do they want to be self served? Right? So just by putting the picture, you know, something simple like is it a company or it's a person, but even trying to kind of match it to their company. Or, you know, I could have said when they said product, put up something of a box there, right? Like a box with a package in it. And they'd be like, well, I wouldn't do that because they're saying, well, we're an insurance company, our product would be a policy, right? So it also shows you as the data modeler really understand their organization. So don't always do this lately. I've been doing it less and less, but it does a picture where they say a picture is worth a thousand words. So it is another tool in the toolkit to really get the point across. Because again, the goal is to have communication and really get your point across. Okay. Onwards. Again, to over hit the point, but I think it's super valuable. A data model tells a story. Okay, I have all my goofy data modeling cartoons pulled out here, but and maybe that wouldn't be the story they customer buys products and they live happily ever after. But when you're reading back the model, do you have verb phrases on it? Well, the thing I love and I'll have some quotes about a data model, it sums up the company on one page, right? And you may feel like, oh, isn't that silly? We're storytelling. But I heard a thing on the radio on a podcast the other day and that stuck with me. They said, we can't we're such storytellers as human beings. We can't even sleep without creating stories in our heads, which are dreams. I'm like, actually, that's funny. We do just create these stories and we tell them to each other. So the more you can tell your data model in a story where we have customers and there's two types of products and we find that really, I know that's a simple example. But generally, some of the problems in the organization are exhibited through a data model, not always. But as you may know, I run a small consultancy and most of our consultants pull out a data model. When we really need to tell the story, it could be a data quality problem. And we're trying to explain why the account codes don't work or right? So often it's a data logic or data, you know, that you have multiple your hierarchies for your product catalog are different across your we're doing that right now today, right? You have three different systems and you have one product, but the product hierarchy across your three systems is different. So how do you expect your SKUs to be lined up right with your accounting, right? So and once you explain it that way, we've had so much positive. Thank you. You really got to the nut of the issue really quickly. We're like, ah, that's a data model, right? So folks, once they see it in a clear way, really, really like that approach, when it's appropriate, isn't appropriate for everything, but it often is. Okay, onwards. So if I'm going out on a limb, but I'm right, you can't argue with me until the Q&A. I have had good success with with the business users seeing data models. And I would venture to say, if you haven't, well, you're either picking the wrong story, maybe we're not addressing the right problem or using the wrong method because I have had really good experiences, right? So here's just a few. I'm not everybody. I'm not going to walk to everybody in the organization and show them my data model, even though I'm proud of it, right? You pick the right scenario. You pick the right audience and you are very distinct by telling the story and what they're solved. You're solving for them, right? So that's the huge caveat of why we have success, right? I mean, I just don't go to the janitor and be like, let me show you the data model of your supply room. Maybe they'd be interested. So anyway, here is one quote from an early childhood educator. This is really elegant. You just summed up our organization on a single page, right? Really liked it. We had a great, we had teacher, you know, early childhood teachers on the whiteboard. What's the classroom? What's a student? What's a course offering? Is a virtual course offering in a classroom or is that a virtual classroom? Are they the same thing? Right? These are core concepts of what they're doing, which is delivering education. This one on the other side was from us the VP of software development. So he was building applications for their customers, and he had never really seen it from the customer's perspective. So we kind of had that business view. He's like, this really helps. Now I understand what the customers were saying and why we had some problems in our apps, but I never saw it from this perspective. So thank you because they were looking at the code or even the database level. Another one, and this is a caution as well as a positive. I love this data model. The next one irks me. Please don't be this person. The last architect told me I couldn't possibly understand this stuff. But when I presented in this way, it makes total sense. It's so logical and this wasn't analytics and evaluation lead. So this person was kind of technical. They should have gotten it, right? But we tend there are too many architects on the planet that do that instead of, oh, you couldn't possibly understand this hard stuff I do. Well, I would say to that architect you're doing it wrong. Because especially if you're at the logical conceptual level, your job is to make it understandable and in the language of the business. Yeah, physical data model, you know, maybe a business can't understand that but, you know, often they can too. It's not the, you know, if it's named correctly that even some of those make sense. This one happens all the time. We built some data models. This was for a clinical health organization. And we have two more departments casting. Could they get some of those two for theirs? Because people saw these from the business. They saw the benefit and like that was a really way to helpful way to problem solve. This one's my favorite. This was me doing it and we worked at a large water utility. And at the time I knew a little bit now, but at the time I knew nothing about water utility. So I talk about imposter syndrome, right? And I did a bunch of workshops and we kind of read out at the end of the week to all the different stakeholders across, you know, things I'm so knowledgeable of, you know, the inter-workings of the pipes below the cities and then water dynamics and marketing and sales and billing and all of that. And we played back at the end and one person came up before us like, how did you learn so much about our company one week? Are you sure you've never worked here before? I said, we've never, we've never heard our company describe so well. And it wasn't me being a smart person. It was the data modeling technique. All I did was listen to their words and I'll give you the tricks of the trade. There's no secret and played it back to them. And again, no one had had either the proclivity to do an enterprise wide, you know, initiative like that or the skills or the whatever to put it together. But it was nothing. It wasn't a rocket science. It was just talking back to them what they had told us in a model. Another quote, I like this one because again, this was your chief marketing officer. And as I said, tell the data model like a story. And she said, well, this explains why our campaigns aren't working, right? You could literally see why the data wasn't linked up in the back end. And of course they're not going to work right? Business people are often very logical, right? They're either on accounting or finance or marketing is very data driven, right? So they will often very much buy into or be like the data model concept, which means me to my next one. And I'll talk more about this in a minute. We do a lot of whiteboarding, we do a lot of like, workshopping around this, because I can't, I've been doing data modeling forever. And I can't build a data model on my own of a company until I can take a start by looking at business documents and websites and everything. But really, it's a business. I can't describe their business until I know their business. So we do workshops. And so often I get this next quote, hand me the pen, right? Because they're engaged and like, let me model this out for you, which shows that at this high level, the business gets it. Oh, you have this hierarchy is four levels, it's really three. And let me tell you why. And sometimes you'll get into arguments and that it's a healthy debate. And I love that question, I hand them the pen, right? Because that they know the business and data modeling concepts at the conceptual level are fairly straightforward. It's just a nice, again, the goal of a conceptual model is communication. So that's to me is the best compliment. Hand me the pen, let me draw it out for you. And that's a great conversation to have. So how we do this often I'm a fan of if I'm in the room with people, a whiteboard or sticky note session. Sometimes the sticky notes nice because it really helps you succinctly come with your, you know, I often start, how do you start a conceptual data model? I often start by reading the website. We are an internet and I, well, I'll keep going. We're an international product company with locations around the world serving customers in many regions with 4000 employees, right? If you're a data modeler and heard that sentence and you're like me, you've already created several entities, right? It's employee, it's location, it's product, it's customer, it's region. What's the difference between a region and a location? Right? That's, that's actually a core chunk of your conceptual data model. And that very quick question, you know, maybe 90% of that was easy, but what's the difference between a regional location might take three workshops to solve, right? But you got to that really quickly. And then you can start with the conversations that make sense, right? If there's no new issue on what an agent is, all right, we're done. Let's just define that. But you can get to those core conversations. So what I like about this too, you know, if you were to look at this and take a guess what kind of company this is, give you a second to read it. It's an insurance company, right? How do I know that you have agents, you have policies, you have claims, you have accounts and customers, right? So some of these could be any kind of customer, you know, customer or product. But this is pretty clearly an insurance company. What I love about this too, and we do a lot of work on insurance. We had one big insurance company up in Canada and we did this kind of model and their whole goal was to be more customer centric and really understand the customers and all of their policies across home and auto and etc. When we looked at the data, this was the conceptual data model. You know, customer can have more than one policy and a customer has a family and has all this. And we looked at the data and finally we made the really hard decision of we don't know who the customer is. We know policies. We know who we have a life insurance. We have a, you know, a car insurance and a home insurance. We don't know that John Smith owns that or anything about John Smith. And we had that discussion again through a data model, right? And had that discussion. A question I get all the time is do you also do the boxes and lines? We absolutely do. And I'll get in. Sorry, I'll get into that as well. This is just a nice way to again, a workshop is a nice way to get the core concepts really easily. And a negative stereotype we have about data modeling. Oh, it takes too long. You guys will be there for years. We don't have time. We just got to build stuff. Of course, you know, my answer to that are going to build stuff that's going to break if you don't design it. But take that to heart. We don't have years to do these kind of things. So what I like about this, again, you can get that 80, 20 or 90, 10 or 99 and 1 percent of the things that get the easy stuff out of the way that can be clear. And then you can have the conversations that are usually business centric that you can, you know, kind of discuss. So again, my family thinks I'm crazy because some or they joined in at this point. One of my favorite ones that we did sound crazy was what is a flavor? It was for a kind of ingredients company. And we had again, seemingly really philosophical is chocolate, the flavor of chocolate. No, chocolate is chocolate. Ice cream can have the flavor of chocolate, but chocolate has to have a favor of nonchocolate like mint chocolate or milk chocolate, right? Is like, and that actually is core and very important of their business, but that you can see where people walking by would be like, we're paying these guys like the essence of the meaning of chocolate. But it was absolutely core of their business because that's what they did for a living, right? So don't knock it. It's super important. So again, how do I build these things? You can do. And that's what I love about it. I have proclaimed this publicly before and I have no embarrassment about it. It's awesome. I was probably the only kid here, at least in the US in third grade, you know, what are we, eight, ten years old that loved modeling sentences. I don't even know if they teach that anymore. But basically, if you are and a lot of people in data do come from library science or the humanities or music that kind of can think logically. So when you model a sentence, one of the first things is what are the nouns, right? So I have a sentence that employee can work for more than one department. What are the nouns in that employee department? Those are the boxes on your diagram, right? A customer can have more than one account. Those are your boxes. The department can have an employee, right? And you model sentences. I forget how you underline the box that or something like that, right? But that is data modeling and how I do that often when I can't do a workshop or before I do a workshop as prep or whatever, just read a bunch of again, read the website, read documents. You will see these nouns all over and you can start to have some really healthy discussions. I did a big workshop that was super beneficial and telco over in London earlier this summer. What's the difference between a prospect, a customer and an account? And that was core to their whole master data management initiative, right? A prospect, I think we all know, but a customer can have more than one account. But you know, and then part of it's with slang, you know, maybe people call accounts customers, you know, so separating the slang from the business logic. But again, you can build these pretty easily and get to the knot of some of the key issues. Then if we continue our data modeling, data sentence diagramming journey, underline the verbs, right? And there you have your first data model, a department can contain more than one employee. And I'm not going to go into all this magical data modeling it, but basically the thing on the right is zero, one or more, like they put up a few fingers and it looks like one or more. So it's kind of easy to see and always put verb phrases on your data model, right? This isn't the most stunning verb phrase there, but you know, a department can, you know, it can hire an employee, can they, et cetera. So what are those rules around it? And the thing about these sentences, they read backwards. So this says a department may contain an employer may not contain an employee. Why that could be super important is, can you have an apartment with no employees in it? Maybe we haven't, we're having a new space data management group and we haven't hired anybody, but the department exists. That could be very different than no, we can't have a department unless that has an employee in it, right? And in this case, if you read it backwards, the employee can only work for one department. It seems simple enough, but is that true? And I've ranted about this before on webinars because it still irks me. I worked for a company and I did, it was a software company and I did a little bit of product management, you know, developing the product. I did some customer support. I did some pre-sales and I took a business trip. And on that same business trip, I had to report some of my expenses to sales and some of it to customer support and some of it to product development and in the rule in that ERP system and employee, how they've set it up and employee can only work for one department, but I worked for three, right? So gave me a headache trying to, you know, some of that's again, it feels theoretical and you're really, you're getting a bunch of high paid people to sit there and talk about two boxes on a diagram, but those two boxes have major business implications. Like how many hours I spent and I had to do separate business for it was a pain in the butt. But anyway, something these actually have business implications. So, so when we do a workshop, we, you know, this was sometime, especially over COVID, we would do some of these, we had a virtual whiteboard and these little dudes move around and you can move the lines. We can have super types and subtypes and verb phrases and all that. And again, we had some really helpful aha moments, my favorite one and can definitely not promise this very often, but we were doing a data modeling training at a university up near Toronto. And in the workshop, we just we picked a sample business problem that made sense to it, sense to them. And they had 20 minutes to build a data model in those 20 minutes, they got to the knot of the thing they wanted to solve just by kind of saying, you know, what is a campus versus the location and can you have one and many, they didn't do all of the solutioning of that there. But they actually two groups that weren't talking well together were at least understand why they had a difference. That's the quickest when we've ever had 20 minutes and they learn data modeling in that process. So folks that do are like that architect that kind of talk down to people and say, oh, you couldn't possibly understand. Yes, there's some nuance to these. But generally, I do the five minutes or fewer. This is what a data model, this is one, this is many, this is what a box means, this is what a line means. And people go and that's when they say hand me the pen, I can figure it out and let's start having a conversation. Of course, you can guide the conversations in architect because there are some nuance, but the general rules, I think people can start to build themselves. And I have had people come to me later and say, I was thinking about what we talked about in the workshop and I drew out this data model. What do you think? Right? My absolute favorite and can't always promise this, but one of our clients is early childhood education. And one of our clients, her job, she kind of grew up into an architect and at home over COVID was drawing data models. She sent me a picture of her little girls coloring book. I kid you not, she wanted to be like mommy and she had boxes and lines and she was I'm creating a data model too. I can't say it was in third normal form and it was correct, but you have the kids and credit she was like three. But anyway, that was fun. So yes, family enjoyment data modeling together. Okay, so that was a lot about the conceptual, but I spent time there or the business layer data model, because if you can't get those core concepts of what's the difference between a client and a customer or a policy and a customer or don't keep going because it's not going to make sense. However, sometimes as I mentioned earlier and creating these lower level down can help again, identify some of those bit again, the easy one is that a customer has a birth date and a name, then that's a consumer versus a done this number or corporate ID, then that's going to be a corporation, right? But again, you know, I have so many, you know, a colleague of mine in the industry, she publishes a book and then like comments on LinkedIn and things, you know, the crimes against data. And I think we all once you start seeing this you're like, and another thing. And, you know, I even have family members that say I went to the bank and I told them that, you know, the reason I had an issue customer service issue, it was their data model wasn't right. You know, kind of customer have more than one address cost more and more people are getting that right. But the number, especially earlier, I have a PO box and the people that don't understand that a PO box isn't the same as my physical address. And you could say that's been solved. We're working with a big aerospace company, actually two companies right now a big telco company and a big, both of these are multi billion our companies. And what's what's holding them up is that a company, whether it's a supplier or a customer has different types of addresses, right? A mailing address, physical address, a ship to address that may have different locations on a campus, right? And it's been implemented incorrectly and cleaning that up after the fact is a massive effort. But a data model might have solved that pretty easily, right? So or even seeing things that make sense, like, you know, fax number required field, why do we have fax number on there who uses those anymore, right? So it's a really helpful, helpful conversation. Just some some case studies and I put these here because the nice thing is that both of the case studies I'm going to talk about actually gave presentations on diversity with us so you can you can see these in the Diversity Library. This was one of my my favorite ones to for many reasons. This is the Environment Agency of England. And one of the reasons I love it is that it's obviously a non for profit. It's not a retail company. And we always talk about kind of the business as if that's just one amorphous blob salespeople ish, you know, our business here were scientists and the woman who brought us in, she's like, I've heard about these things called data models and I think they could help. I think it would be logical, right? So our audience talking about imposter syndrome was like PhD scientists. And their business problem was things like, you know, they they go around the country and they collect water samples or land samples or a kid, you know, they count cows and sheep and things like that. And then the Phillis, again, seemingly philosophical conversation, but wasn't at all, is what is a sample? Is an air sample and a water sample and a fish sample and, you know, whatever things are in the water? Are those really just a sample or a specimen? And they were doing a lot. One of the reasons they were doing that was to publish open data and share some of this with the communities. And they love this concept, right? And so again, we often underestimate business people as not being technical gosh, I couldn't even begin to do these people's jobs. And they very quickly got these simple, you'll see kind of a little subset there on the right, they had orgs and stakeholders and assets and natural environments and really kind of got into the nut of some of their key issues and saved them a lot of time and actually helped collaboration across. So anyway, they can speak to it more than I can and better than I can. So that was a couple of years ago now, but it's still available if you want to take a look. Another one I love, and they spoke to kind of over the pandemic with us on diversity is Kiwit, probably one of the massive companies on the in the country in the US that you may not have heard of, but you've seen all their work. So they're one of the big construction companies. They build big highway ecosystems, they build combined cycle power plants and they build nuclear power plants, you know, these huge big infrastructures that take years and years and years and years. And they had some similar problems around how do we optimize these projects and get the best pricing and really understand. And you could say, Hey, these are construction guys and gals that, you know, they really want to data model. They loved data models. And it really got to the crux of things. Because when you think about what they do for a living, this whole idea of designing and building and looking at diagrams, I mean, they got it faster than many because they're they look at diagrams all day. And it might be where the electrical system is or whether windows are, but that whole concept of looking at something conceptual and then building that thing that came from that conceptual model, like that's what they do. And they have the same in construction. And again, we as our data architects found that a lot of fun to learning their business. They really have the same concept of conceptual logical physical. Think when you build a house, right? The architect gives you a general is this a one story house, two story houses that have a porch, right? And then you get into the wiring diagram, then you get level detail like we're just so used to that and other things. Do we do that with data as well so that that conversation went really well. And they got a lot of benefits from it. So using and again, you can hear them talk about it better than me. So if you want to take a listen to that, I just found that is a really interesting use case. But that idea that analogy and the other thing that you've heard us use that all the time as architects say it's just like building a house architecture. But that idea of designing and building same thing in building a database. Now I'm in the physical data model world, right? That maybe on the left is your data model design on the right is your SQL statements to create the, you know, the great then alter tables, right? So you can look at code. Some people like that better, but a lot of people like the view on the left because you can start to see the relationships and things and you could show this to a business person if you needed to or anyone is kind of that common lingua franca as they say. And it's also, you know, regardless of database so you could create a physical data model and then optimize it for different platforms if you needed to. So here's an example of a physical data model. You'll see the difference. Like you still have some in many cases, not always words like customer and employee, but you'll have, you know, more physical. It's not usually this pretty. You can have, you know, abbreviations and you can you should have your data types and your nullability rules and and here are some of those rules should make a whole lot of sense. But it still can help is it is a business value because you're creating you're optimizing for speed. If you're doing a data warehouse, you're creating data standards. You're building once and reusing many times and it can really be a helpful way to optimize the organization. And I'll talk more about that. But please, if you are trying to share with business people, do not share the logical or physical model if it's massive, right? A logical model for a particular question. Yes. But I go to too many clients that are like traumatic reaction to the word data model because, you know, we I remember we had these like war rooms where you'd go and I've seen them. You go in and it's all three walls or four walls of the conference room are filled with thousands and hundreds of entities. And we had the business in there for a few days going through each attribute. And funny, they didn't want to come back. I wouldn't want to come back and I love data modeling, right? So keep that square that kind of sticky note white boarding bring the business in for the right conversations. Or if you do need to get down to this level, just break it down into small chunks and then come with a particular question, right? So, you know, yes, maybe your physical model is huge, but you have a very, you know, simple question. Can a customer have more than one account? Can they be a customer without an account? You know, what's the difference between a client and a customer, right? Just break down all of the key things from that model and just you can have a short conversation about it. OK, but at the physical level, it's still super valuable. And I will say this is one way you can kind of look like a superhero because I have before, you'll think a lot of these really good data modeling tools like you can point to the database. I'm only slightly exaggerating, but not much. You press the button and it generates that model in the middle, right? So classic, you know, we have an old Sybase database that no one's used since 1993, and we don't know what's in it and you can't get your point the data model to it and you can at least get an idea of the structure and are there are there keys? How is it set up? And the other nice thing is you can create certain data standards and you know, count code and they'll come back to this, you know, product number can only be 10 characters and it should absolutely be 10 characters and it's alphanumeric and we're going to create those data standards across every data platform, right? So the good data modeling tools can do that. Even something like a PowerPoint or a Visio or something can at least create that picture, but the power of, you know, multi-platform and supporting these different systems can really be done well with the automated tool. The kind of slime for that is reverse and forward engineering, but you know, you can both reverse and see what's in the database and then create changes and then it'll spit out the SQL for you or the DML for you so you can actually create the tables if you so wish. So again, I don't mean agile in terms of the agile manifesto. I mean agile in terms of being iterative and fast, right? And I don't like that a whole group of people stole a great word in English and took it for their own use. We can be agile without being agile. That makes sense, right? You can do things in small chunks and iterate over time. So when you can do it across all of those levels of the data model, create a quick conceptual data model. Are we on track? And I have done these in the true agile way. We sometimes add a sprint for data modeling, right? Two weeks, we create the logical and, you know, conceptual and we get by and then we go onto the next, right? Even just for the small scope of that sprint. So do we have the right or do we compare it against the existing conceptual model to make sure it aligns? And then we've done the top down. Do we also do the bottom up and do the physical data model and do they match, right? So sometimes you learn things in the business, you know, back to that side-based database in 1993, you could say, well, the business rule there was that only, you know, accounts from this region can have more than one rep associated with them. Like, oh, right, that was a rule. And oh, I think that still is a rule, right? Sometimes there's business rules hidden in the code that people who have left and didn't have a great data catalog have lost. So you can cut, it's an iterative session. So, you know, publish it, communicate, go through data governance. Is this the right rule? If not, iterate, refine across each step of the way. And we've had a lot of success because it's, you know, a lot of people ask, where do you start? Is the top down, bottom up, middle out? It's kind of all the above, right? You need to look at it holistically and then keep changing because it's different audiences and you'll learn different things at each stage. Moving on. So I had a whole webinar earlier that year on this, but, you know, I've been kind of heavy on kind of your ERD, you know, especially at the business level that still kind of works. You don't have to put that in a database, but some of that core logic, you know, do you have a thing, do you have more than one thing? What's the name of that thing? You know, that still works, right? It can also work really well. Yes, that's a goofy data model joke over there on the left getting into third normal form. There is a use for a relational database. A star schema would be more for a dimensional model. I've had help, we show those to business people too. It's so, I mean, we also use other things like a bus matrix and things like that. But the fact that you have a fact in the middle and you're slicing it by region, by product, by campaign, by, et cetera, even in a data model is fairly intuitive. But there's others not all then themselves to data models. But especially at that conceptual level, I would say, and I'm sure people ask or argue with me in the chat, at that high level, the enterprise conceptual, it should absolutely be platform agnostic. A customer is a customer and a client is a client, whether that's on NoSQL or in the data lake or in the data warehouse or in a Word document somewhere, right? That's just a core concept of the business. But yeah, at the physical level, it does make sense how you're modeling that. So some real-world examples of data models and I think I've given some as I go and I do wanna open up for questions. But I've talked about some of these from, would my company benefit from a data model guess? From an environmental company. Actually, I kind of joked about going to the janitor and they might start modeling out their supply closet. That's only half a joke. The sponsor from the environment agency in England, she was saying that over Christmas after the, we did the data model, she and her daughter, again, these poor parents are putting up on their children. They modeled the kitchen, right? And they had fun, what's a food item and what's, and then so she thought that was really way to fund with her kids. It's just basic logic, really, right? We talked about childhood development, schools, e-commerce, digital transformation. Again, what is the client? What is the client different now that, or is the product, is the product different now that it's a digital product? Is it not, right? Universities, water utilities, construction. Yes, agile software development can use data models, membership orgs. We've had like actually almost any company on the planet including your own home, including your kitchen can benefit from a data model. And once you do get data models in your head, you almost are scarred for life. You kind of turn everything into a data model in your head, but they're really helpful, logical tools. I do want to sort of end up with some actual, we can very quickly sound philosophical and theoretical on these, but I have in the past several years, even just solve some major, major issues in a corporation through data models, or we've found them through data models, right? This one still irks me to this day. Why did our website go down? We lost two days of online sales. Well, there were no physical data models. This is a physical data model, physical data model standards, and a data engineer shortened the product identifier from 12 characters to 10 characters. Still don't know why that was a good idea or why someone didn't do impact analysis, which these tools can do, or have any standards on something as critical as a product item code, but a simple data model, physical data model enforcement or governance would have saved the millions of dollars in sales because literally their website went down and they had to fix that. And one of the ways we solved it was through a data model. So there you go, physical data models are business benefit too. Goss, this one just happened last week. Why do we have so many duplicate suppliers in our system? And we did workshops, we discovered, and one of it is the business rule is a supplier can have more than one address. The particular system they were using to put those suppliers in wouldn't allow a supplier to have more than one address. And so the person just created a duplicate. And so the same company has three or four different names with just a different address, which isn't the most elegant way to do that. So it created duplicates, right? So if you just did data profiling, you'd be like, oh, there's a bunch of duplicate suppliers. We'll clean that up. Well, you can't clean that up because the logic on the system is wrong and no one's doing anything wrong. As a business person, they're working around a bad design decision, right? So the more you could have caught that up, did the developer not have time to do a data model before we built the application? Did we ask the users in the right way, right? This one happened ironically at an unnamed data management company, not my own. And it was a software company and someone sent renewal reminders to people who didn't own the software. That was your classic, what is a customer, right? We just sent out a generic, hey, it's time to renew and someone picked the customer database, which was actually prospects, right? Which is fine in the real world. A salesperson says, I'm gonna visit a customer. You don't correct them and say, well, actually, that's a prospect, you can't. We know in slang, you say customer, but someone should know that that database was prospects and not people who own the software. So they looked silly, especially because they were a data management company. And these are all, you know, fairly real world examples. This one, I love this one. And I think not enough people think of this. So the name of the company I work for is Global Data Strategy. We do data strategy also, and we use data models all the time. I will say you get extra superhero points for this one. Think of that conceptual data model and you're planning your roadmap. And I have three or four customers right now using a conceptual data model for that. What is the scope of our data across the org? Here, we have a model for that. Can we fill in with highlighted colors of where we think we're good? Well, we have customer master, that box is filled in. Product catalog, we're having a little issue. So product is gonna be next month, right? And it's a really good way for execs and tech people to really help scope out through your enterprise data model. And I think a lot of folks don't kind of think of, hey, data strategy, data model, how do you not? I think, because we do it so often. Again, that's at your enterprise or conceptual level. So with those extra superhero points, I will just wrap it up of, again, when you're talking, think of each model layer as its own unique thing. When you're talking business layer, talk like the business, but at the technical layer, it has its own set of rules and they absolutely, anyone and everyone can benefit from these and solve real world problems. We do this for a living, if you need help, come find me. My email is in the first or second slide and I will open it up for questions. Over to you, Shannon. Donna, thank you so much. As always, excuse me for a great presentation and just if you have questions for Donna, feel free to put them in the Q and A section and to answer the most commonly asked questions. Just a reminder, I will send a follow-up email within the next two business days, Monday, Thursday, with links to the slides and links to the recording. So diving in here, Donna. So tell me, how is the semantic model different from conceptual and where does that fit in? So I would say as an industry, cobblers, children often have no shoes. We use words, I've heard a lot of different definitions of semantic model in the past few years, but I would say in general, a common one is kind of a before say the data warehouse to the visualization tool or even at the virtualization layer. And generally there is a data model representation of that. It might be say your star schema and a very business-friendly view. So I would almost say that's kind of a logical or sometimes even a conceptual view of your reporting structure and I'm a huge fan. And I think a lot of people, we've even just clicked, I don't wanna mention tools, but some of the tools have this embedded and we talked to the BI developers and they hadn't seen that modeling layer. And we say, this is how you, when you have all the slicers and the measures, you can see how they're related together. They're like, oh my gosh, this is so nice. And they just hadn't seen it or it hadn't been developed for them in the past. So yeah, I would put this that semantic layer kind of in that logical kind of model view and I'm a huge fan. Love it. So should the data model reflect the story of a particular business process or a particular function within the business process? I would say just be, I get that one a lot. Just be explicit. And again, what story are you telling, right? So if you're saying, I don't know, I've seen this a bunch of times, I'll just use a, it's not the best example, but you'll get the point. We're looking at accounting and they use these, they have this regional hierarchy. And now when we look at sales, they have a different regional hierarchy and they don't match, right? And maybe that's fine. Maybe there's a good reason for that, but you call it out that way. But our enterprise standard is this. And then you can have that healthy conversation of do we need, you don't always need to standardize. Maybe you call it sales hierarchy and finance hierarchy and they are truly different things or are you gonna argue it out and say, actually, if we're talking about a region, that needs to be a physical region. And we have to say, is Europe, what countries are in Europe and decide it once, right? And all three of those could be, something could be group only, some could, or process, I used to department, but process could be the same thing. And I think by calling that out, you get a nice benefit of, when can it be process only or department only? When does it need to be enterprise wide, but at least making that explicit so you can have that conversation? So there was a, it depends answer. All the way. So then we just have less than two minutes left, but I'm gonna try to set up a more question in here. So what's a good authority source that defines the different models? This webinar, no. I would say the DEMA DMBOK data management body of knowledge, if you haven't seen it. I've got some books, Steve Hoberman's got some books. There's a lot of good books out in the industry. I mean, there's IDEF that has some standards. So yeah, is there one of the, gosh, I mentioned Cobbler's children has no shoes. A lot of people like two kind of wordsmith and argue names and things like that. But I would say that hierarchy I showed with kind of enterprise conceptual, logical, physical, people might argue on names, but the kind of what those levels are and what they're used for, I think is fairly standard across the industry. That helps. It does indeed. Well, Donna, thank you so much. It's always a pleasure to see you in person. Yes, it's been a great conference. Yeah, right. I just hope to see more people in person. And thank you. Just a reminder, I will send a follow-up email by end of day Thursday for this webinar with links to the slides and links to the recording. Thank you to all the attendees who are so engaged with everything that we do, love you so much. Appreciate you. And thanks. Yeah, have a great day. Bye-bye.