 and welcome. My name is Shannon Kemp and I'm the Chief Digital Manager for Data Diversity. We'd like to thank you for joining the latest in the monthly webinar series, Data Architecture Strategies with Donna Burbank. Today Donna will discuss business-centric data modeling strategies for maximizing business benefits sponsored today by Irwin. 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 and we very much encourage you to chat with us and with each other throughout the webinar. To do so, just click the icon in the bottom middle of your screen to activate that feature. For questions, we will be collecting them via the Q&A section or if you like to tweet, we encourage you to share highlights or questions via Twitter using hashtag DA Strategies. As always, we will send a follow-up email within two business days containing links to the recording of the session and additional information requested throughout the webinar. Now let me turn it over to Danny Sandwell from Irwin for a word from our sponsor, Danny. Hello and welcome. Hey, thanks Shannon. Thanks for having us and thank you everyone for attending. We're really pleased to be sponsoring this session. I will try not to get in the way of the reason we're all here, which is to get the experience, expertise and pithy commentary from Donna. So just a quick overview on Irwin for those of you not familiar, not up to date, or just looking for a reminder. As a company founded in March 2016, built on the back of our long pedigree in the data modeling world and leadership in that space with Irwin Data Modeler, through that time we've combined a number of technologies through acquisition as well as through internal and organic growth to bring together a combination of tools really focused on enabling organizations to get the most out of their data. Lots of customers, lots of users across the world, 300 employees also across the world and a very strong connection to our customers both historically and moving forward, ensuring their success. So, you know, as just a quick review of what the data modeling products and additions that we have for you to utilize to put into practice the insights that Donna's going to pass along, we have full capabilities in data modeling, whether it's our standalone and industry leading ERD modeling solution, Irwin Data Modeler, of course the ability to bring all that together and allowed modelers to collaborate effectively and under control, new components to actually go out and transform ERDs or build JSON-like document models in the NoSQL world. So, a very strong physical modeler with the full round-trip engineering in that space. And then, of course, lots of capability to discover data models specifically from those troublesome packaged applications that seem to be everywhere in our architecture and infrastructure, as well as, you know, strong capabilities to let people know what's in those data models and to really strongly collaborate those around those data models for the betterment of the business. And all of this is within what we call our Irwin Edge platform. And this is, again, a set of components that are offered both in SaaS or on-premise where we bring together the key elements required to deliver and get control of your data assets from both a data governance and data management perspective and then manage that process, you know, throughout its life cycle, as well as bringing key visibility into the rest of the enterprise and the business processes that drive it forward. So, you know, built around our business glossary, metadata catalog, data dictionary, and our extended view into data usage. We have expertise in a number of modeling disciplines, enterprise architecture, business process added to our traditional data modeling, as well as a strong capability to do enterprise data mapping in a metadata-driven model modeling approach where you basically graphically map things in a natural language, you know, and then discover your lineage from that, as well as start to automate and take control over all of the different technologies that are moving data around your organization. All of this built into a platform that gives you all the things that you would need to bring different stakeholders from across the organization together, have them work effectively and efficiently. Basically, the idea is to get every stakeholder in the data value chain working from the same page in the HIM book, informing each other, providing context and visibility into, you know, the role that they play and the requirements that they have. All of this built around intelligent automation that will, you know, enhance capability across the organization, increase your efficiency in lower costs, and of course, make sure that you're collaborating effectively and really, really seeing the return on the opportunity that your data assets represent to you as an organization. With that, let's pass it over to Donna and get into the real meat of what we're talking about today. Danny, thank you so much and let me give a quick intro to our speaker for today, 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. She has worked with dozens of Fortune 500 companies worldwide in the Americas, Europe, Asia, and Africa, and speaks regularly at industry conferences. And with that, I will give the floor to Donna to get us started with the presentation. Hello and welcome. Thank you. Always a pleasure to do these, and thanks. I see a lot of familiar, familiar names on the on the session, so thanks for those who attend regularly. And for those of you who do attend regularly, you'll know that this is a monthly series, which has been very popular. Thanks again. We see a lot of the same folks that join each month and are sort of fans, which is great. And for those of you, and this is always a question that Shannon's willing to patiently answer, but are these available on demand? They all are, not only this year, but last year, the year before. So if any of these topics look interesting to you, you can see them all, get the slides all on demand. Next month, or actually we're skipping a month, this is with the holidays. We're combining November and December, that will be on self-service reporting and data prep. And we'll talk about some of those topics we'll be talking about in this session, in that with the rise of data just being so hot, that more and more business users are wanting to get involved. And this will be a panel, so we can kind of get some thoughts on how well that's working, what some of the challenges are, and the opportunity. So hopefully you can join us next month as well. And then just getting into the core of the content, as you know, the topic today is on business centric modeling. And the beauty of a data model, and I am clearly a big fan, you'll hear that throughout the session, is that it really gets a good view of the data that drives the business. And it's a nice way, as a communication tool, for both business and technical stakeholders to communicate. Some of the feedback I get, or people that are looking to engage in a business centric data modeling approach, it does seem like a lot. If you're trying to model your organization, it can be a big effort. So what we'll talk about in this session is how you can just do this with some practical, concrete steps, how you don't have to have it be overwhelming and do it all at once, and how you can get that proverbial quick win. So we'll be going through that more as we go. And I mean the real rise of why we're talking about this is the idea of the data-driven business. And unless you've been living under a rock, I think you've probably seen everywhere in the news. And on purpose, you used examples from business magazines and online resources. So Forbes, Harvard Business Review, The Wall Street Journal, they're all talking about my favorite quote of the data scientist being the sexiest job of the 21st century. The new generation is the data-driven business and or the digital business, which to me is just another way of saying data-driven because you can't do digital transformation without that data underpinning. So data is hot and you're seeing it everywhere, not only in technical journals, but more and more in business journals. The other interesting aspect of this is that this idea of, and we're favored to say this a lot when we're talking about technologies, kind of business users and tech users. I think that's starting to make less and less sense. I think these roles are merging. Business people are becoming more tech-savvy. Tech is getting easier to use and it's just a lot more opportunity. So people are realizing that and a lot of, we'll talk a lot about this in the session, these quote, business roles can be very technical. You're telling me that finance isn't using data or that underwriting and actuaries aren't using data and insurance. I mean they've been doing data for a long time. They've been data scientists. But that merging is continuing. So these are again some quotes from similar Harvard Business Review forums, Wall Street Journalist idea of how to be have a data-savvy HR or this proverbial citizen data scientist or tech-savvy CFOs. And I'm seeing more and more of that, which is great. I mean, in other presentations, you might have heard for years, we in the data side, if we're going to pick sides and say data, tech versus business, which I again, I think is blurring, we say we're not getting the attention of the business. The business doesn't care about data, sometimes they say be careful what you ask for because there's a lot of visibility in what we're doing now. And with the lens, it's responsibility. So we just want to make sure we're ready to have these conversations with the business when they are increasingly willing to talk to us. So there is this rise of the data-savvy business professional that again, I thought this is a brand new thing, but it is growing. The challenge is that how do we communicate in the right way to this business? You might have read something in Forbes or Wall Street Journal and wants to do some data science or wants to do some analytics. I think the skill set is growing. And you'll be surprised with a number of business people that may be in their MBA program had some data modeling. Actually, all three of us, Danny and Shannon and I, were at the data architecture coverage in Chicago a few weeks ago. And one of the presenters actually had a great list of some of the leading MBA programs that had a data modeling program or data analytics and data modeling in their session. So I'm pleased to see that this is becoming more and more. There's a lot of great online courses including Dataversity that has some great online courses in data. So people are, as they hear more about data, are skilling up. But that said, most business users don't have a computer-sized degree or a data analytics degree. So it can be challenging to take these very technical data concepts and communicate it in a way that a business person can understand. Yet you, as if you're on the data side, can still build the models and analytics and things you need to do to keep the business running and build that data-driven organization, which is where the business data models come in. And we in business love definition, data modeling love definition. So I'll start with one. What is a business data model? So on my viewpoint, this is my definition. I made it up. Is it graphical location that describes the key business assets of an organization and their impact on business operations? So I think a lot of us in the call, you know, Shannon's the first to say anything in Dataversity with the data modeling topic is always one of the most well-attended and this session is no exception to that. We often think of the piece on the lower left, this idea of a conceptual data model or a logical data model, kind of the boxes and lines, ER model. Well, as Danny pointed out in the beginning, and I'll talk a lot more about as well, there's more than just data models, more we're talking about a business. And one of my favorites is the business capability model, which is really starting to map back to what are the core capabilities of a business? We have HR, we have finance, and then as I mentioned, these citizen data scientists live in these areas. And then what's the data overlay? If we're going to pick some of these quick wins, we'll talk about what is the most used piece of data across all these departments and where are the heat maps of data across an organization? So literally mapping out your organization and then seeing how data maps to that. Business process modeling is another one of my favorites. And we'll go into detail in a lot of these of how can you not, in a way, look at your data without understanding how it's affecting the daily business processes of an organization. There's a lot more. And I'm only picking a subset of all of the different types of business data modeling. What we're not covering is Fabio in his business suit. You know, that is a different kind of modeling, but we always have to tell that bad joke when people say, what do you do for a living? I tell them I do modeling, and they get a funny look. And I don't know why, because I don't know. But anyway, I had to put that joke in there, but that is not the kind of modeling we're talking about, but we are talking about primarily the one on the left, but also some of these other tools. And if you're not familiar with these, I think my recommendation to you is to add some into your toolkit. You know, a lot of these come from more of an enterprise architecture domain, and they can be a really helpful way to give voice to your traditional data model that you might be developing that's more of the one that looks like what's on the left. So to drill into that one that's on the left, you'll have this idea of a business data model or conceptual data model, which is that we could spend a whole presentation on what do we call these things, right? But I'm not going to do that, because I think we lose all, it's not always valuable discussion. But I'll call it a business data model, and it's those boxes and lines. The beauty of these models, and they are beautiful, and I'm a fan of them, and a business users are a fan of them, because they very simply just get at the nut of the problem or the opportunity, right, it's the core definitions of a business, and it shows, importantly, the relationships between those data objects. And when done right, you can really tell a powerful story, and I use these all the time. I try to be polite in presentations. Danny might argue we've worked together for a long time in past roles, but I once was a data modeling session, and actually I had to stand up and disagree with the speaker when he said, business people never look at a data model. And I said that is, but 100% not my experience. I have found when I build the right level of a data model, business users love them, because it really helps them again, communicate those really difficult problems they might have seen in their ERP, so why isn't the ERP system working? I just, it doesn't seem to match our business process, and often just building out how the data model of these systems are can really help get at that. So this particular model can tell a story. I have employees, I have employees that can be sales reps, support reps, you know, this really is traditional, you know, super type, sub type relationship. But if you look at this carefully, you'll see that there are some business rules in here that, well, support reps have a one-on-one relationship with the actual customer. Sales reps are assigned to a company. Well, that's fine, but what if I wanted to get the rep, the actual contact information from that customer? Am I able to get that? Perhaps, but maybe not. We're kind of linking the sales rep to the company, not the actual customer contact. You have sort of a one-on-one relationship with that sales rep to the company, so obviously your key accounts may or may not have. You'll see that there's an optional relationship there. Maybe you may not have a sales rep, probably depending on the size of that, you know, company, et cetera. Everybody gets a dedicated sales rep, but a customer can talk to many support reps. Is that the right? Maybe these high-level or key companies might have a dedicated support rep too. I mean, again, we don't know the answer to this. This is something we bring up to the business, but it might be something that we kind of start to bring up to say, hey, we're looking at some things here, but maybe this will help nut out a problem. And even just picking small little use cases like this can be super valuable because the idea behind these data models is that they tell a story. My advice to you is to use the language of your audience. And this kind of a, yes, I have data model cartoons, so you'll know that I throw them in whenever I can from one of my data modeling books, so can you make this look like PowerPoint? And we could sort of laugh at that or we could embrace that because when we say, quote, business users aren't technical, business users are doing technical things all the time. And then even a PowerPoint, even an org type diagram is a model. And so when done simply, these models actually do sort of look like a pie of put data models in PowerPoint. You'll see in a few slides that I actually put pictures around them. It's whatever it takes to communicate these core data concepts in a business terminology. Put too much detail in. I know that's hard to do. It's a lot harder to make one simple clean page than put a lot of detail. And I know I'm challenged with that all the time when I'm building these for the organization. How do I keep it to one page or a very simple level that really gets at the detail, I mean the core concepts that we need to understand? Use business terminology. I might have some arguments here on the call, but I am not a fan at this conceptual or business layer of terms like the party model or entity, just these very high level constructs. Yes, if we have a customer and a salesperson and a consumer or what do you call it, a prospect, they could all be parties or they could just be a generic person. But then you lose the whole point of the model. You're not understanding in business terms. That might be your logical or even your physical layer to maybe optimize because yes, everybody has a name and address and you want to do some normalization there. But when you're trying to tell the story, use the language of the business as much as possible. I'm also a fan. I've shown pieces of these in other organizations. I put a picture in there and the tool Danny was talking about and it allows you to do this as well. I generally do it in a PowerPoint. But take a piece of the model that you're trying to tell the story. So this is the same model that I showed before, right? We have employee sales rep support rep. Some business users love this. This is a way where you can actually show the definitions and there's a lot in there. The employee is a full-time or part-time worker, but contractors are not complete. Well, that's good to know. If I had a contractor that was a part of support, they wouldn't be part of this model. So there's a huge value to show these definitions. Big fan of that. But also it can be very helpful to actually show the pictures. What are we talking about here? We have a sales rep, a support rep. Oh, right. When we're talking about a company, that is the actual organization. There's no people involved in that. And that could be part of the issue or the story we're trying to tell. Could we let the sales rep see interactions with support? That's really going to help them serve this company better. That we know we have three customers calling with some big issues. Next time they go visit this company, they'll know who that is. Do we let the sales rep see all of the customers within that company? So when she goes on site, she knows, again, a picture is worth a thousand words. So I literally will put a picture. And again, I'm not going to necessarily do an enterprise model with all these pictures, but when you're trying to tell that story, it's great. And I've told this story before, but the very first one I did of these, because I often would start this myself. Because what I love about, I run a consulting company, as many of you know, was that when I love the data modeling projects, because one of my favorite things to do is go in fresh with a clean slate and understand an organization through a data model. And I often would start to draw these pictures myself to say, do I really understand this organization? What's the story in my hidden background? I was an English major at one point. I love a story, right? It's probably the most helpful degree I have. How do you communicate, right? And excuse me if I'm coughing, I have a little bit of a cold today, so if it's sounding strange, that's why. But the very first time I did this, it was a very, very large insurance company that was operating in New York City in London for high net worth individuals. You're very, excuse the words, Stodgy, a professional, serious organization. And I drew a picture like this with literal pictures of their customer, of their brokers, of their insurance policies. Probably could have helped me understand it was a very complex business. They had, you know, about 100 city areas and trying to understand that. I showed it and there was a sort of a pregnant pause where everyone just sort of looked and I said, oh gee, this was probably not the customer to test this methodology out on by showing cartoons, right? But the head of the project, who was sort of doing a lot of the marketing, actually walked up to it and she said, you know what, that doesn't look like one of our customers. And I started to sort of laugh because of the picture and she said, well, because there's an older man and that used to be our high net worth customer, but actually it's sort of the 30-somethings that are now out in Silicon Valley. And this is actually really helpful because our assumption is that it's the older, older guy that lives in Connecticut and likes to get his mail with his physical mail and open it with a letter opener and all that. But now it's the tech and they're young and they want things all online and this is part of our digital transformation. So that one, this one data model that had pictures of it, actually just prompted an entire digital transformation story because she could see her business in the pictures. Every time I've done this, that is actually one of the first feedbacks, pieces of feedback of is this my customer because they literally see a person. I worked for a school and I put up a picture and they said, you know, that person isn't part of our demographic. I think they would probably be Asian and a little bit younger and whatever. We changed the picture and it's really interesting because that starts to engage you, literally see a picture of your organization. Or, you know, maybe I have a product and I have a box of a product. Well, no, we sell an online product. It doesn't come in a box or whatever. It really helps me as a consultant and the company to really understand. So big fan of pictures steal my idea. I won't blame you. It's a great tool that you can use in your toolbox. And again, when we talk about data models, the DBAs on the call might have looked at that and said seriously, I'm going to, you know, take my table. No, no, you probably wouldn't take your physical data model necessarily and put the picture right because it's a tool for every purpose. So the models, I'm showing a really up of that conceptual layer, the business concepts. You might do it for a logical, you know, there's a bit of an overlap and again, another thing we could debate all day long between what's the difference between logical and physical and do you put attributes on your conceptual and opinions on that as well. But the ones I showed were probably somewhere, you know, more of a conceptual type model. You can also do some enterprise. Again, for a large organization, even one of the main domains, we have customer and product and supply chain and things like that. So again, the other reason that showed as shown as a pyramid is that as you get into the physical model, you know, even that model I showed might have hundreds of tables to support customers and products and support and things like that. But the conceptual level is should be just the very core concepts and try to keep it to one page or simple models as much as you can. You don't want these things taking up an entire wall in your conference room. It should be something that's very clear. And if it does take up a wall, break it up into small subject areas so that the story that people can understand and you'll keep hearing me talk about this concept of the story because it's just how we have evolved as human beings if I want to get philosophical, right? Because, you know, I heard this quote on the radio. It was a story teller. He was a novelist and he said, you know what, we can't even sleep without having stories in our heads. That's called the dream. And I thought that was a kind of a clever way to look at it. Our brains are just always telling stories about anything. We see a tree and we sort of put a face on it or clouds. We turn it into something. Our brain is always telling stories about the things we see. So with your data model, you want to turn that into a scenario. Or, you know, I tell myself this all the time and I'll say it to you and don't get offended because I have to remind myself nobody cares about your data model. And it's not that they don't care about your data model. They don't care about the model. They care about their story as explained through the model. You know, as a novelist, no one cares about your words. They care about the story you're creating. So think of that with the model. Because I know, and I can tell by my voice, I get excited about things. I will and I'll be late at night and I'm developing this model. I'm like, yes, I finally got that right super-type subject relationship or the cardinality. That's the problem. And I can't wait to show somebody the next day and I have to remind myself nobody, nobody, but you cares about that. But they will care if you explain why that has an impact on the business. Why did changing the cardinality of an email address related to customer? And actually, you will show an example of that why it did have a big business impact. That's where you want to show the people, not that you have a pretty model or you change the colors onto whatever, right? And so this is a picture I've reused throughout many years now, but it keeps working. So I show it again. So the one I've reused the most is the little gentleman in the lower left. And you're probably wondering, what the heck is that? But my advice to you, if you are a data modeler and probably there's a large percentage, given the topic here, is be more of a data advisor and less of a data architect. And that's my, no one cares about your data model, they care about their problem. So a business, and I'm totally stereotyping here and I would probably put myself in all these catalog categories. So I'm insulting myself if I insult anybody. But we tend to do have stereotypes in an organization. So, or I know in my different roles, I'm the same person and I've sort of acted differently in each role. So when you're in a business executive, think of what the business has incented on to make money, to have opportunities. They tend to be very optimistic. Yeah, we can go do this, we're gonna go around, we're gonna make, and they're also, I guess you could say everybody is, what's in it for me? Selfish, right? We, a data architecture, can often be rather, head in the clouds, big picture. And you might wonder why this guy in his little dress there, okay. He's that guy in the corner holding up the sign and going, the world is not gonna end. If your model is not in third normal form and we can be very passionate, we can be very dogmatic, but people start to think we're a little weird. Because we do get very passionate and religious a bit about our models and that only turns people off. So yes, maybe amongst ourselves, we can argue about cardinality and subtypes and modeling notations, but please don't do that in front of the business executive. We want to tell people, but I do it myself. I'm so excited, I wanna tell people and because we are this mix of technology, but also communicators, but we need to tone that down a little, including myself, and not talk about words like third normal form and cardinality and all of that, but talk about the business. So instead of saying lecturing the person of why his model needs to be in third normal form, like hey, if you could link this customer data with your product, we could, talk in his language, he talks sales, he does product, he talks. And the other thing we tend to do, and again, we're actually paid to do this, is to find problems. And we often can be serious rather negative, oh, that'll never work, or I know you have this great idea to do digital transformation, and I know, but it's gonna be hard, well it is gonna be hard, everything's hard, but maybe start to think of the opportunities, but if we could link our customer data with our product usage stats or our support call stats, what, look what we could do, and that's how you're gonna sell your business and if you're a project, and if anyone has joined one of my workshops at the adversity, I always have you do some of an elevator pitch, and those have been very popular, so how do you sell your data model? How do you sell your data project? How do you talk in the words of the business and think of that as you are talking to these folks? Because business users, when you are the person on the right and can think of it as a data advisor and you use it in their language, I have had only majority positive experience from getting these models right, and I thought I'd just throw some quotes from actual business users just in the past probably 18 months that I've heard. But we'll go up to the left and actually we'll talk about that success story in a little bit. There's a chief marketing officer, chief marketing officer of a major retail store, and she said, she's a trip actually, she was very, very animated. She's like, I never thought I'd use the word data flow diagram, but I love it. What is that thing you're showing? It's a data flow diagram? I love it. She loved it because it explained to her why her campaigns weren't working. There was problems with contact, it was how the data flow through, and we were able to use that model to explain a problem to her. She didn't care about the data flow diagram, she cared that it fixed her problem. All right, so she loved it. She said, I don't care what you call it, I love it. The one on the right, and this, we'll talk other data modeling notations. This is something where we used a customer journey map and mapped it, did a data overlay on top of that, and this was, again, your business user could be anyone. In this case, our business user, one of them was the head of software development. He wasn't in the data team, and he was a bit skeptical of why we needed to do these things called data modeling and all, but once we explained it from, here's your customer journey, here's where data sits, and here's some of the new ideas. We can use that data if we linked it together. He was bought in, and he actually thanked us. He said he was, he was a skeptic, and he said, once we did these workshops, I really saw why this was valuable. I had never seen it from the customer's perspective. On the kind of lower left, this idea from an early childhood educator, and again, business isn't always just sales and marketing. This was a teacher, right? And she said, you know, this is really elegant. You just summed up our organization on a single page, and I think that is why people like these. They are elegant, they're simple, and you're talking about, you're flattering them in a way, you're describing their organization, right? On the right, there's a bit of a compliment, but it's not me, it's the model. And we were working with a big utility company, we went for a week, and we came back, we played back the model, and they said, how did you learn so much about it? Have you worked here before? And I said, no, I just asked leading questions, and you do, you will look very smart, whether you are or not. If you learn kind of that data, and you've, the data modelers in the call, you knew that, you kind of listened for nouns, you listened for verbs, you put it in the model, and you spell out their business. And I'm not saying it's magic, but some of these core fundamentals can be really, really helpful. Because we think of that the different way, and not everybody looks at it that way. The other thing in the bottom there, and I tell customers this all the time, they don't always believe it, but we built a data model as part of the clinical health organization. It just kind of a test, and we showed it, and then we had other departments saying, we want one of those too. A, they got a lot of attention. B, they were able to see some business problems, and we had other people kind of lining up saying, when are you gonna do the dead model for us? We think that's really cool. So again, done right, people love them. And if you're not getting that reaction, maybe just think of some of the things she said before. Was it simple enough? What, did it tell a story? Did it solve a problem? Did it use their language with a small, and you will get positive feedback. I don't want to say I guarantee it, but I strongly recommend that you probably can, speaking to the right people in their language. It hasn't all been positive. I thought I'd show some of the negatives of what maybe not to do. And I know it's weird. I say what not to do in the first one, says I love this data model, right? But it's the next part, and these are actual quotes from real people. And she said, the last architect we had, he told me I couldn't possibly understand this stuff. And it was. And we can sometimes be of its novice and data. We're smarter than them, because we know this particular thing that they don't. Well, go into an actuaries job, or finances job, or anybody else's job. Nobody knows anybody else's job. We're not smarter than anybody else. We just have a skill that we tend to know. So she was very pleased in a way, said, but when you showed it to me this way, it makes total sense. It's logical. You have boxes and lines, and it tells my business, I get it. I wish the last architect had done that. So don't be that guy. Don't be that architect that kind of insults your, you know, she was actually, when you look at her, if you're not familiar with student or university, or this was actually a child school, her evaluation, she's basically doing data science on children data. I mean, she had SPSS, and she had SAS, and she's actually a very detailed technical person in data, but she didn't do data models again. So we tend to do that. You don't know the one little skill I know, therefore you must be, you know, not as smart as me, which is ridiculous, but I've seen too much of that. The one on the right, it was actually a very extreme version of that, and it was so funny we all laughed about it, but this was more, again, she was the head of digital marketing. She's a very smart person, and she has a mathematical background. Anyone in marketing knows that marketing's all about numbers, and they were just sort of in a very fancy term, but dissing her. Basically, she couldn't understand. They would, you know, kind of talk down to her. And finally, she was so frustrated. She said, guys, I am nerdy too. I was head of the math team. I am a nerd. And she, like, defend herself against being nerdy enough. So don't do that. I mean, everybody, again, these people, they can be understood. Most business people are feather intelligent. They just probably know slightly different skills than you do. On the one at the bottom, we'll talk about two. You may get this pushback of, uh-uh, data models, done that. We had these full day sessions with hundreds of data entities. They locked us in a room, and I don't want to do that again. And don't do that to people again. You can be much more agile. You can do workshops. You can use design thinking. You can do a lot of that, because I think the waterfall days of, I don't know, one that ever worked, actually, locking someone in a room all day, I would get, I couldn't stand that. And I'm a data modeler, right? So don't do the big bang approach. Do it something that makes sense until stories that have an impact. Why are we doing this model? Not, I mean, I could, I actually probably could model all day because I think it's fun. And it is an academic exercise. But don't make it an academic exercise. Make it mean something. I thought it would be helpful for some real-world use cases for these business data models. And again, these are real-world companies we've worked with just in the past year. And again, this is a subset. And I tried to pick kind of a random subset to show you that it isn't just sales and marketing. It isn't just customer data. It's everywhere in different use cases. So I tried to pick different types of companies and different types of use cases. So the first one, we'll actually, the next slide, actually tell you who it was. And they actually did a case study with us out in our website. I'll tell you. UK environment agent there, England, environment agency of England. And our, quote, business user, we're scientists. And our sponsor came to us and they're very similar. She talked about being technical. She was a scientist, right? That gets pretty technical, but she didn't know data modeling. And she came to us. She said, I know we're trying to do scientific, they were doing open data publication of their scientific results. And we're all using different terminologies. We can't align our data. Each system has different data issues. I've heard of this thing called the data model. And I think it's what we need. And it was. And we had workshops. And there was some pushback in the beginning. But we had roomfuls of data, of scientists, field scientists, getting together, arguing about what a living organism is and how we collect a sample. And they loved it because they were finally able to align their business, which happened to be environmental data. So that was kind of a fun one. I took some of the quotes from this next one, early childhood development. So their remit was how do we create better outcomes for small children? And they had, they were trying to look at all of the data impact impacts or things that impacted children through data. So could it be that they had the number of parents involved, the number of extra-clear activities they did, how healthy the children were, what zip code they were from, all of that. And that's pure data science, right? But to be able to see all of those factors, we actually developed a data model. And a lot of the things we're going to talk about in this session with aligning it with, with the organization, aligning it with the business process, all of that. And again, you probably don't think of that with a school. But we did. And it was really kind of fun. And they liked the data model because, again, they were logical people and it explained their business. The third one, on the app, we've done several of these this year. This whole idea of digital transformation, e-commerce, data-driven business. If you don't know where your data is and how your data is affecting this digital transformation, that's not going to be successful. So we pretty much always start with the data model. We are a little more creative. We've done a lot of, I will have one example later, customer journey mapping. So if I'm going to do a digital transformation, what is my customer's journey and where is data used to cross that journey? Great place to start because it's definitely your high-impact data elements. Kind of the older version of that early childhood education, we did some work with the university and actually they will be speaking at Enterprise Data World this March. March or April in Boston. So you can come here and them speak about it. And again, we did not a customer journey map, but we did a student journey map which was really fun. And mapped the data model of students, university students and mapped that with a student journey to really say how are we going to get better graduation rates, better admission rates, better, you know, all the things to help universities, better research grants, all the kind of things around the university. So again, this isn't always just customers and products, right? On the lower left there, we'll talk about business process. That's another quote, data business data modeling away because I always do a data overlay with my business process. So these pieces of this process, where is data touched? And I'll go back to the good old fashioned crud matrix where is data created, updated, read, deleted. Master date management is a perfect use case for this because often if you've done an MDM implementation, it's not the technology. It's actually not that hard to create a model in these are the attributes for mass of customer or whatever you're mastering and these are the sources and I kind of do the data integration. That's hard, but the hard part is getting everybody aligned. Who's touching this data? Who owns the data? How are data stewards going to check the match rule? So you have to look at business process and take data and understand the business around that. I kind of mentioned the customer journey mapping. Marketing is often a good use case for that. Agile software development. Again, when you might not have thought oh, we're talking about business data modeling, we're going to talk about agile software development because often they are kind of the antithesis but we've done a lot of that. If you're talking about user story and you're doing a sprint, what data is involved? What's the small little piece of that model that we can develop that just tells the user story? Is any data that needs to be created or updated? When we're on the lower right, I am actually pleasantly surprised that I'm seeing more and more of this because I've been preaching this and Danny probably has too for a long time of before you buy a packaged application, do you have a data model that you can talk to your vendor and compare it against? Because this is that nagging sort of thing that happened. You buy an office shelf product and they do invoicing, we do invoicing, this is great. And then a year down the road, it doesn't seem to work and it's not matching your data because their business rules didn't necessarily match the way you did business. And then you get these gnarly data problems that take months to clean up. And I have two customers doing this very right now that have their enterprise data model and when a new vendor comes on board they ask for their data model and they ask to compare it. I have the number of vendors that are shocked by that. I sort of like to see that. But some vendors more and more are coming to the table and saying we had one vendor who just last week and they said thank you, you're the only customer that has ever asked because they actually wanted to do a long-term project and be on-site and they said while you were able to, we found a problem that the way they mapped invoicing wasn't the same as ours and we actually fixed the problem before they were even implementing so it was great. So the more you can do that that's just kind of your specs in a way. This is how our data looks, how does your data look and how do we integrate. It's so obvious, right? But it's often something we forget. So in terms of some use cases and stories I mentioned this one but just a picture so you can see the fish that we were tracking. You don't always get to put fish in your problems. Anyway, put them in there. They actually have this app with mobile talk about digital transformation. You can get your phishing license on your mobile app when you're phishing just so the phishing whatever person is looking for your license show them your app. Anyway, so their business quote was how do we take a sample? How do we, is a living organism in water the same as a living organism on land and all that sort of thing. We got the site that's working together and the ultimate, not only for the scientists within the organization to share information but they were doing open data publication and a lot of this is online. You can go to the UK Environment Agency and see a lot of the data they're publishing. You might only use it in your own research and feel confident that they've done a lot of modeling behind that to make sure it's consistent. So that was kind of a fun use case. They'll actually also be speaking with us if any of you guys are across the pond at IRM UK this November and you can hear more from the horse's mouth or from the fish's mouth or whatever. So hopefully these stories, because I get passionate, you can clearly tell, about things. And one of the things that I got annoyed with is in partly because it's vendors or partly because it's people want to just be different or contrarian that nobody's using data models anymore. I don't know where they get that because I use them all the time. Whenever I use them with a business user, they tend to like them. When you do development, they're more efficient and this is some data behind that. So we had done a survey with the diversity and we asked who was using a data model and 96% of respondents are using a data model. So yes, I know these are diversity folks, so probably higher than the average organization but that's still pretty darn high. So don't listen to people when they say data. I don't even know when data modeling was dead. It's been pretty consistent. So yes, methods of modeling and maybe being more agile with modeling and et cetera, et cetera have improved but it certainly hasn't gone away. So we won't talk about that anymore because it's just not true. I will say, and we talked about some of the things not to do or maybe things that might have given data modeling a bad rap would be the one I already alluded to, this idea of death by data modeling and I've been in these rooms or I've gone into clients where they say, here's our enterprise data model and there's thousands of entities that take up multiple walls in an organization and they expected business people to sit there and say, okay, we're going to start in IAM. What's the data type for a count code? We'll just go entity by entity. I mean, I would die doing that. So don't do that. It's not the most efficient way to do things and know that maybe some business users might have that remembering and probably deep in their DNA that they are triggered by this and don't want to do this again. So I would suggest a more agile way of doing data modeling, not necessarily agile methodology with a capital A with the whole, but just more quickly, right? You can do things, or you could use agile and do this in sprints. We have done it. So this is actually from an anonymized version of what I had done with one customer where they were using it as part of their agile development life cycle. And again, it just makes so much sense. You align with your business needs, you do some top-down design, you do some bottom-up review, and you did each sprint, you iterated and refined. So you have your user story and then once they iterated, they published out to the Water Enterprise, got feedback, and then went back if there was any feedback and continued to iterate. I think the only difference that might be when I do this with an agile, I think there is an up front and we've done this sometimes we have a sprint zero where you do the high-level conceptual model because I think you have to sort of compare to your overall. This is the entire high-level scope, whether it is the subject area level or conceptual level, and then we're going to kind of fill in the pieces as we go. So maybe just pure agile and not doing... Only looking at each sprint might not be big picture enough. But again, that has been sort of a common way of doing the high level and with the first sprint and then can each other sprints kind of map in that big. High level enterprise. I seem to have worked well. One way, and this is again, this next company, they didn't do official agile but they did it again in an agile way. Short, quick, quick wins, I like to say. And this was a retail company. This is the one where the head of marketing got up and said, I love data flow diagrams. But this is why they knew that they had some issues. They had a very popular product. You may be familiar with I can't say the name but it was integrated with IoT and it was a very high end product that they had a very loyal customer base and from that point of view, they were doing very, very well. They had issues in terms of just kind of linking up their customer data from when the person purchased it to when they could track their own. They could not track the person online. They might call customer support and they couldn't tell that it was the same customer. Theoretically, their product could do customer usage tracking because it was Internet of Things enabled but they couldn't link it back to the customer. They had a loyalty program. They actually had a story where someone had called the loyalty program and they had to call them back to get their phone number and they said, didn't you know it? I told it and they said, oh, that was the other system. I mean, you probably can shake your head at a lot of things they've done here. So actually what we did here was all of the architecture pieces you might expect from master data to governance to architecture but we did it in a very small sprint. We did a customer journey map, a crud matrix data flow and we just did it in little sprints. The first story was how do we get a customer's email address from when they first joined to when they called tech support and just eyeballs were opened. So the chief marketing officer, she was the one that said, I love data flow diagrams. My favorite quote was the head of sales, head of sales, that after all of this said, shouldn't I govern? He actually used the word govern, how my sales enters the data. He never saw how it flowed downstream. So of course his sales team was incented to sell product so they're not going to worry about getting the right email address but when he saw where it was used, i.e. in marketing, he saw the value of that so he was actually willing to change how he did things. So great success story of doing all of these things, data models and crud matrix data flow diagrams but just in a very small thing that told the story. Even better when you can do it up front. Again, my data modeling jokes, you know, we're, hey, we've built a new system, we have this great new marketing application, just one question, what's the customer? Right, so the more you can do that up front and not wait till after the fact to have to fix the things, a lot better. So again, it's much more agile to do these things in small sprints up front and then find out some of these issues. One thing people often ask me as should you buy in terms of doing this and more agileized, some of these pre-built industry models, you know, there's already a model for insurance or retail or shouldn't I use that? This could be a whole webinar but I would say they're a great reference. So as a template, you're not the first person that's ever done invoicing or contact management, et cetera, but use them just as that. Don't take them verbatim out of the box because your business is out of the box. You're not exactly the same as every other industry so it can get you 90% of the way or 80% of the way there but you probably set last 10% that's going to cause your problems down the road. It's the way they're storing contact information the same as you do, et cetera, et cetera, et cetera. So yes, they're great. Please don't take them just out of the box because you know, that your company is out of the box. So data is definitely part of a wider enterprise architecture and we'll talk a bit about business and process and mapping data to process and it really is part of a larger ecosystem as well as part of your, oops, wow, I jumped to the end tonight, as part of the larger larger data strategy, which if you've joined my webinars before you'll see, you know, it isn't the only thing you'll be doing it's part of a larger governance it's part of a larger business strategy and data strategy but it's a key piece that's going to help everything else work. You can't do MDM or warehousing or BI or governance without an architecture or a model. So just some quick examples and again, each one of these could be its own webinar but I mentioned this idea of a business capability model a great way just like you're doing a high level model of your data this is a high level model of your organization. This is a great place when you're trying to see where to start you know, where is customer used across the organization? That's those kind of little dots and there's a lot of ways you can do this. I often make up my own ways of doing things or you know, where's product used? It's again a great way to prioritize information. Data flow diagrams, workflow diagrams, whatever you want to call them. You might be familiar with this idea of swim lanes. Huge fan of this. Even at a high level you don't have to do fully detailed information. This is a BPMN diagram business process modeling notation. And again, I always customize and add my own thing. One of the things I like to do is add a little picture of you know, is this in the database? Is it sent through an email? Is it sent with a spreadsheet and really start listing kind of what data is sent in each piece of the process especially with MDM. These are super helpful. Cred matrices are another one. There's old fashioned, maybe what old is new again, this idea of where is data created, read, updated and deleted. And this is often where you see issues. You know, I thought this was exactly that problem with that retail organization. Data, customer data was created and it was created again and then it was overwritten again. But nobody was doing that in a consistent way. And so you can often highlight some very gnarly business problems just by starting to ask some of those simple questions. Who's using it? And I often do these process models and cred models together because it's sort of nice that it's each step of the product process. Who's touching the data? How are they touching the data? And where is it used? And this was actually, this was sort of the high low version of that retail company I mentioned about. At each step, where is customer data used? Is it when they receive the order or when they process the order, when they fill it, when they send the invoice? How are we kind of looking at these key pieces of information? And is it consistent? So again, especially when you're talking to business users, they know their process. They understand that. So it's a good way to speak in their language. Customer journey map that I mentioned, you may have seen these if you're working with marketing and this is obviously a very stylized one. It kind of is just a trendy version of a process model. Excuse me if anyone disagrees. But it's more, not necessarily step ABC process, but more of phases in their journey. What is the customer doing when they're just starting to discover versus actually consider or when they purchase or when they go into support? And then what, maybe just at a high level, like at the bottom, what types of data are touched? You might say, oh, our customer's data is touched across each piece of this journey. Are we linking this up? Can we link this up? So that can be a really helpful way to show that information. One of the success stories we had with process. And again, I just hopefully is helpful to kind of show these different types of organizations. It's not always just, you know, product and salesperson. This was with a big pharmaceutical company. And again, our quote business users were PhD scientists developing new drugs to save people's lives with cancer. Right? So certainly we want to be condescending to them of, oh, you couldn't possibly be technical. Way more technical than me. Just not in data, right? So and they had had a bad experience with data in their past. And they didn't want to hear the word data model. They that place where you locked me in the room all day and make me create these horrible diagrams all day. So we call them blueprints. And we did, if you remember, with Cypalk models, we did that. We did process models. We did data models. And we mapped that together. And this was literally their pharmaceutical drug development process. And then what data was touched to these step of the process. They loved that because they'd never, no one had ever had the time to actually walk through how data was used to these step of the process. Not only do they optimize their development, clinical development process, but also some data issues. My favorite feedback on that was that when you went to the scientist office, they actually had the data in process models printed with little sticky notes or things scribbled on it when they found issues and things we could go back and fix. So that was literally they were using it in their day to day business. So again, we didn't call it a model because they had had a bad experience. But once we did it in the right way, loved it. It was a key part of their job and printed out on their wall. Can't get much better than that. So in summary, and I know I went quickly but there's just so again, so much to cover and I want to give some time to questions because I see them coming in. But data is hot. This idea of the data driven business, we could be cynical and say it's always been the case, but even more so the case with internet of things and e-commerce and data is driving the business. So the good news is that business people are paying attention. And the good news is that we as data architects or data professionals have a voice in the company to really be that data advisor and be able to tell that story to help really show some quick wins. So pick a story. Use these data models to tell the impact of data in a story either positive or negative, either, hey, there's just new opportunity if we just linked customer support logs with sales data or etc, etc. Or it could be negative things. We can't link customer support logs with sales data because we don't have this relationship, etc, etc. Enjoy it. Data modeling is cool again. It always has been cool. So enjoy that. Just a quick plug again if you are around in December and want to join our self-service data prep, please join us there. The study I mentioned is available for download. We do this for a living if you ever need help. We're happy to help. And I'm going to pass it back over to Shannon to take questions. Donna, thank you so much. It's always for this great presentation. And just to answer the most commonly asked questions that always come in. The reminder I will send a follow-up email by end of day Monday for this presentation with links to the slides and links to the recording. So Donna, diving into the questions here and Danny, please feel free to join in. This came in pretty early and you talked a little bit more about this, but maybe there's something additional you want to add. Please talk some more about what language to use and not to use when talking about this with the business, such as whether or not to use the word entity and what to say instead. Any other words to avoid like data modeling? Yeah, a couple. I did talk a lot about that, but a few things. I mean, I would think the main thing is to talk about them, right? It's their business and you might use these constructs. I mean, I generally have a little slide deck more often when I show these models, I'll do a quick 101. Here's an entity. Here's a relationship. Here's cardinality. One to many, like it's like four slides. People can get these very quickly. I think, if people have had a bad experience with data modeling, I might use a word concept or a business asset or a business asset or something like that instead in terms of entities. But I've been pleasantly surprised. Again, I think some of us are overly traumatized of people not liking our models. Especially new generations that haven't seen the old way of doing it have loved these things. And at first few times, like seriously, like no, no, that data model, that is what I mean. I want one of those. I like those. So maybe we judge the reader if they don't have a problem with it, call it a data model. But if they do, either just talk about their business or use more generic things like a data diagram or a data flow map or whatever. And if Danny viewed any thoughts on that? They stopped letting me talk to customers long ago. No, I think you're spot on. I think that the terminology in the standard data modeling nomenclature is still a fairly human thing. But you're right. It really depends on who you're talking to. It's always best to try to really understand the person, their experiences, their fears, their the rest, and really talking in their terms. So one of the things I found is just sort of have a quick conversation with them in terms of those specific things and then ease them into it, use terminology. But entity, a person, place, or thing, it's something that I think just about everybody can get their head around without having it feel too threatening. So do you have any information or advice on involving data modeling with novice business and data stewards in a fledgling data governance program? A few things I would, I mean some of the same things I mentioned, keep it simple. I mean that retail company, they actually did all of this through their data governance organization and kind of created work groups. So have it have a purpose. You know, maybe have for, and I would say this for any data governance, we're going to solve problem A and this model is going to show this area or this problem or something like that. You use the terms of the business, keep it small and just keep it to a story and keep it high level and make sure you get the right business data stewards from the right business area. So one of the larger companies at work was we did it, we did it, you have it different ways, but we did it by organization. So we did kind of the clinical subject area and then we did the development subject area, et cetera. We did it that way or I've also done it where you get everyone together and you pick a business problem that spans all of those. So really depends on your organization, but keep it small, use their language and just communicate in the right way. I think, you know, you're spot on, but what I have seen is as the business data steward understands that the capability and the information, you know, one of the biggest challenges they have is, what data is really in my area of responsibility and it's not necessarily as easy for them to get that inventory in a manageable place and when they see it visually, a lot of the times it really kind of breaks down some barriers for them. Yeah. And I've even had the positive experience back to Danny's comment that these are pretty simple. One thing I had the other day, we were just whiteboarding some of this and the business user came back and had drawn one on her own whiteboard and said, is this what you mean? And she had boxed it, she was right. It was actually a very good data model. She'd been data modeling for half an hour, but she modeled her business so she understood it. It was not that hard for people to understand. That's sort of the beauty of this. They are rather easy to understand. And just to comment here too, for an additional question that came in, yes, all slides will be shared. So Danny's slides will share those as well. So Danny, if you would make sure to get those to me, I'll get those out to everyone. And Donna, you know, did you mention a data model scorecard or if they have any value in the discussion? I did not mention. I know someone who does have one is Steve Hoberman, who's a co-author in some of my books. I think they can have a value. I think at this level, the business level, it's not as important. I think, I mean, some of the pieces of a scorecard does have a well-formed definition. That sort of thing would be very valuable here. I think as you get more logical and physical, they're certainly valuable because this, I don't want to call it an old-fashioned methodology because it's still very valuable, but it has a rich history and the things you've run into have probably been found before. So a lot of these methodologies can kind of catch some gotchas for it. Some of the tools actually have some things to check within the tools, you know, some common gotchas and data modeling. So I would, yeah, I would definitely recommend that. I think at this level, it's more at the business and make sure the definitions are good. And there's a lot of methodologies about how to write a good definition. That's my two cents. Yeah. And I think a data model scorecard is a helpful reference for the data modeler as they go through the process with the business people because, again, you're telling their story, you're talking in their language. You're really trying to mold your approach to their comfort level and their needs. So it's a nice sort of sanity check as you come back to make sure that you got everything you needed through that process as you were, you know, really trying to make it much more comfortable for them. All right. Well, that does bring us to the top of the hour. There's some great compliments in here. So I'll be sure and get those over to you, Donna, make sure you can see those. But that is all the time we have for them. Just a reminder, I will send a follow-up email to all registrants by the end of day and Monday for this presentation with links to the slides, both Danny's slides and Donna's slides and the recording of the presentation. So again, thanks to all of our attendees for being so engaged in everything that we do. We love all the questions that come in throughout and Donnie and Danny, Connie has combined the both of your names. I'm just going to pick you on first and Donna and Leonie, thank you so much. We do look a lot like, yep. Yeah, yeah. The mistake is a lot, no, but listen, I'll take that as a compliment after you. Great job, Donna. It's always incredible. Yes, indeed. To both of you, thank you so much and to thanks to Irwin. So all right, guys, I hope everybody has a great day. Thanks. Thank you. You too. Bye.