 Hello and welcome. My name is Shannon Kemp and I'm the Chief Digital Officer for 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 business-centric data modeling, sponsored today by Couchbase and Irwin by Quest. 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, or if you'd like to tweet, we encourage you to share your questions via Twitter using hashtag DA Strategies. 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 panel, so you'll find those icons in the bottom middle of your screen to enable those features. As always, we will send a follow-up email within two business days, containing links to the slides and recording of this session and any additional information requested throughout the webinar. Now, let me turn it over to Tim Furbrie Ford from our first sponsor, Couchbase. Tim, hello and welcome. Great. Thank you, Shannon. Thanks everyone for joining us today. Just got a few slides I'm going to take you through real quick. We're talking about Couchbase and how our database supports business-centric data modeling. So let's get right to it. And as I began, just very high level, I want to talk about the fact that over the past few decades, database requirements have changed a lot. I mean, historically databases and data modeling were really first built around things that were very operational tasks. If you think about order taking or financial transactions or ERP systems, that's what, you know, the bread and butter of relational databases, right? And then over time there was the addition of the move to data analytics, right? Understanding customers, understanding behaviors, understanding the patterns of what happened. And today the need for databases and data modeling has expanded to kind of another more common use case as well, which is kind of the interactions and the experiences we have with customers and partners and employees, right? If you think about the web pages and mobile apps we use, they're all driven by data that needs to be stored in a database and modeled for those interactions, right? So we have dynamic catalogs, personalized experience and so forth, and that requires greater flexibility of the data model and the database. But that gives customers, sorry, companies competitive edge when they're building these experiences and applications, right? And the data has changed due to the number of data, the way the data is accessed, the way that we develop applications and so on. We use a lot of core legacy components that are still super valuable to databases, right? So how do you build that and what's the best way to do that, right? You know, if you can model the database to the application and have that flexibility, that allows you to build a better application. So what is CouchBase as a database? Well, we are a no sequel database. We store data as JSON documents and as opposed to relational tables that you might be more familiar with. And what that means is in building applications you have more flexibility in the design and how data is presented. But it's great for things like user profiles, personalized catalogs and things like that. And it's partially due to the way that we store data, often denormalizing the data from what you might think of. If you think of like a user profile in a relational database, you might be splitting out that profile or information about a customer into many, many different tables. And in CouchBase what you do is you store all that related information within a document, right? This makes it easier to get at that information quickly because you're not doing a lot of joins across tables. But it also allows you for more flexibility in changing that document over time and evolving your application and involving that experience with the customer. But how does this relate to relational? Well, CouchBase in addition to JSON documents has a very dynamic logical containment model. So, which is when we say dynamic, it's optional, right? So data can just be stored within the database which we call a bucket as documents. But we can also add in those documents can be organized in scopes and collections within the document which can be aligned to a relational schema in a relational world. So we can do that for parts of an application or parts of the use case that needs more structure. CouchBase can support that. If there needs to be more flexibility, we can model that as well. And so what makes CouchBase different? Well, it's really the fact that we have a lot of different capabilities within our database platform. And over a decade ago with the merger of two technologies and integrating an integrated cache technology and a JSON document data store and have over time added capabilities like SQL query. So we use SQL as our query language, relational capabilities, some I just highlighted, but also a cost based optimizer and other key components. And then other services like full tech search. So for example, Louis Vuitton uses our full tech search capability in their application that their employees use in their store. So they're trying to drive a great experience with customers. They can use their mobile apps in store search for products, looking at by photos, finding it in other stores, helping improve that experience with customers. Operational analytics dominoes, for example, uses our analytics to drive better promotions with their customers. They don't take the data out and put it in the data warehouse. They have real time access to the data. Things like eventing, these essentially data change capture and triggering events off of those changes in the data carnival cruise line, for example, uses this to drive better customer experience. So if you're on a carnival cruise in your room and you order a sandwich and you decide to walk down to the pool, Carnival has an app and it knows that you've made that move and your sandwich will arrive to you at the pool. And then in terms of things like mobile database, United Airlines uses couch base for their crew scheduling so the crew can have wherever they are very easy access to their schedule, they can trade shifts with employees and see what they're doing. All of these different applications I highlight, give these companies a competitive edge and a lot of flexibility and how they interact with their employees and customers. So all of this combined is what kind of separates couch base from from other vendors. It's at its core. It's the flexibility, which is the JSON document structure that I highlighted, and multimodal services, all of these services combined gives give the platform a lot of great flexibility. The familiarity of SQL as a query language the dynamic structures where for those who are coming from a relational world, work well in couch base supporting asset transactions and our patented cost based optimizer for JSON documents. So all of these things are key to couch base as a standout database. And in the end what this means for customers is to allow them to innovate faster, build applications that meet the business needs that they're trying to achieve with less time. So thank you for that. Thank you for allowing me to give that quick introduction to couch base and back to you. Thank you Tim for kicking us off if you have questions for Tim or about couch base you may submit your questions in the Q&A as he'll be joining us in the Q&A portion at the end. And now let me turn it over to Andy for a brief word from our second sponsor or one by quest Andy hello and welcome. And there's my mute button. Good afternoon everyone. Thank you. And thank you Shannon. I appreciate the opportunity to be working with Donna and data diversity again. I'm going to give you a quick run through of what or when data modeler brings to the, to the table as as as Donna is going to show you, we're going to be focusing on or she's going to be focusing on business centric data modeling. And this is definitely something that I show all the time. This is a conceptual model, and then we have our logical models and Donna is going to walk you through the business benefits of working with that. I do want to point out that Erwin data modeler, as you may know has been around for quite some time, and over the past few years actually in the past three years. We have made a major shift to being able to support all of the popular data structures that are out there today so is not just your relational databases. We can also work with no sequel databases, along with, and specifically around couch base to so I just came back from a road trip with couch base talking about how Erwin data modeler can be used to normalize your relational structures into couch base buckets, full native support basically means that we can reverse engineer, we can forward engineer and we can compare our physical structures to the physical structures as they're implemented on the we can do those changes we can build objects from from scratch. For all of these platforms from Amazon key spaces all the way down to terror data and many points in between so Mongo Jason Avro parquet data bricks couch base etc. Erwin's approach to data modeling is to do a combined model without having to have a separate logical model in a separate physical model, and we can do that. Really quickly I speak to lots of customers all the time, and they need the ability to document what is out in their data landscape, but you know when we have something like this over to the end users. It probably introduces way more questions and we're willing to answer. What are these fks why is that red how what is what are these abbreviations mean. So we can take the data modeler and pointed at your physical structures and then start building out your, your logical and your business business centric models, all at the same time. So this is coming from the same database and what we've done is we've actually translated the abbreviations and sequel into the business terms we found a table called cost, and then we create an entity called customer, and then all the attributes follow through that naming process. Now this is obviously simpler than a schema diagram. But again it could introduce more questions so we can distill that down a little bit further into an entity definition diagram and this is definitely getting more towards the conceptual side of the house here. As you can see is just showing the entities along with their relationship, and the business terms, including the definition of these entities. So it when you're having a discussion about your data structures. This is very, very simple to understand what each one of these components means. And then finally, we could break it down even further or distill it even further into a conceptual model where we're literally just showing the entities and how they're related. So all of this can be done by pointing out your physical structures, creating a logical physical model and then using the diagrams to space everything out and to use this information to share with the business users and it's all tied to reality, as much as we can get it to there. And then one last final thing, and I'm really looking forward to work to seeing Donna's presentation with couch base. I just spent a few weeks on the road with couch base in various cities and my partners and teams are over in Europe and Middle East. And we were talking about how we can use Erwin data model or to convert into couch base format so what we're looking at here is the actual documents that can be created by just denormalizing your relational models. We're working with them in the couch base format, your unstructured format here. And as we look over here, you'll see that we do have all of the specific couch base components, most particularly with scopes. This is very important in this in the current leases couch base so we can work with all of those. So that's what Erwin can do. Thank you for joining us. I appreciate your time I'm looking forward to Donna's presentation and back to you, Shannon. Thank you Andy for this and if you have any questions for any or about Erwin by quest you may submit your questions to the Q&A as he'll likewise be joining us in the Q&A portion. Thank you to both couch base and Erwin by quest for sponsoring today's webinar and helping to make these webinars happen. Now let me introduce the speaker for the series Donna Burbank Donna has 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 begin her presentation hello and welcome. Hello Shannon and nice to see some familiar faces in the audience from all over the globe and it was nice to see people kind of chime in on that. Welcome, and thanks to the sponsors as well so sponsors gave a great overview of kind of some data modeling solutions and some technical solutions. Today we're going to kind of bring it up a level and talk really about business centric data modeling to give my little pitch for this series if you had this is the first time you've joined us. And we'll see that there's been a wide range of topics throughout the year. Data diversity is great about keeping all of those in their archive so if there's anything in the past, BI or data governance that might be of interest to you that is all available. And there's some cool stuff coming up this year and hopefully next year. That'll be published soon. Hopefully next year definitely. I'm sorry to make you nervous, Shannon. This year we're going to have McGrath databases EA data architecture. I think a lot of what we'll be talking about today really will tie into that December webinar. Because I do think at the business level tying in these high level business data models to something like a wider enterprise architecture and process models and component models and user journeys and a lot of that stuff can be really helpful but I think we're going to have a better set of ourselves today. We're talking about business centric data models and I'm going to keep stressing that it is powerful to be able to take one of these business data models and turn it into the tech with the guys talking about in the beginning. We're going to not talk about that today so much, because I think there's value and I don't want to say it's a lost art because we do this all the time. And really creating these visual models to get the business rules, and they can be super successful and they have their place so their place is really that second bullet which is that visual way to communicate data centric business rules with the business that can be then translated to the tech, which is a really powerful tool because they're so visual. And I love some of the demos in the beginning of the data modeling tool you can kind of see different ways to show it for different audiences. So we'll go through that I can provide some practical, hopefully some concrete examples will show a few case studies, and hopefully give you some good background around data centric modeling so we need to start with a cartoon. So one of the books in my profile earlier was data modeling for the business which is just on this topic. And we have cartoons and when you have data model cartoons you have to show them because who has those right, but I did want to start here. I don't I will we may be I may be biased because at our company we always start with the data model, and they're generally very very well accepted I do sometimes hear of folks saying I want to skip that or you know we don't have time to build a model let's just jump to the coding or we're agile we don't need a model. You know I feel like my mother is sitting on my shoulder saying, you know if you don't have time to do it right you have time to do it again. And yes you may build a solution faster, but will those business rules be right and in kind of the joke there maybe it's not funny at all but it might not be funny unless you've experienced it you know we're almost done with user acceptance testing and everything looks great we're building this new marketing application just one small question. What's a customer. And I did not get this joke I've been going to diversity and Dama conferences gosh for probably 20 years now. And remember someone told that joke early on and I was young and I said, yeah, how hard is that a customer as a customer right. Oh how naive I was anyone who's doing master data management or you know single view of customer is it a, you know, is it a wholesale customers at a retail customer is the last customer is there's so many different aspects of that and you really need to get to the nut of that or none of your applications got to be right and I have worked for and with multinational companies that will worry name nameless who have made embarrassing costly and sometimes, you know, legal implications of mistakes on, what is a customer one that will definitely ran out named sense renewal notices to prospects, they someone went to the customer database and sales uses that all the time you're going to talk to my customer, you know, we don't hopefully you lose friends when you talk to you know, actually it's not a customer it's a prospect, you know, but it's slang right we say a customer, but in that case, you would not send a renewal notice to someone who doesn't have the product right so hugely embarrassing, you had to, you know, undo a lot of things, but it was it was a reasonable term someone on the database side that saw a database called customer. But again, there's a lot of nuance around that. Also in that terms of that last saying I want to touch back on that as well if you don't have time to do it right. Do you have time to do it again. There's often a misconception, I think that that doing this business data modeling has to take a long time. You know, I found, you know, we do a lot of kind of I don't like these word actual but you know rapid development you know we always kind of pilots and really get to the nut of some quick wins really quickly and we're able to we always start with a conceptual model even if it's whiteboarding it in an afternoon or a few days and I've found that generally you get to 80 or 90% of that data model. Really quickly and have some huge aha moments with the business of how things fit together. I'll show some quotes later in the presentation of business people that have really been relieved to finally see a model of their business and how it understands and I think, again, we do these kind of workshops with whiteboards or virtual whiteboards in this day and age. Again, you might get 90% of the way in a few 90% of the way there in a few hours, and it might take you six months or a year to get the rest because sometimes that's where you get the really difficult issues about customer business rules or product hierarchies but you can really focus in on those through the data model. We often do kind of, you know, cartoony highlights of, you know, honing in on that problem area of this one, one cardinality rules what's causing our problems or this one hierarchy so it's causing our problems so really a great way to really get to the end of the issues and really just communicate so don't don't want to over hit this slide. I think I just talked a long time about that one slide but it really is important to have this way to document these business centric data rules. There are levels of data models and folks argue over levels or whatever but there's there's some few industry standard ones. What we're not going to talk so much about today is though are those physical models, whether it's a relational model or a key value pair or a JSON file or but not important when we're up at the business level because they are business centric data rules of, you know, does a kind of customer have more than one account. It doesn't matter if that's on COBOL or DB2 or Azure database, customer can still only have one account right so that's where we are that kind of that dark blue conceptual model layer. Sometimes there's even a layer above even these high level subject areas of customer product, you know, especially in a larger organization even to kind of subset it up there, you know, even even just, you know, discussing what is an employee. What is a customer what is a product. And again if you're new to data modeling, you might might sound crazy until you really get into the net of things. So those examples have been working with customers this year that really find some, you know, gnarly rules around those down at the logical level that lighter blue that's still a business centric model. As Andy showed though that's where you get to a little level of detail so at the conceptual level you really are talking about terms and definitions. I like the example that Andy showed it was quick but they kind of had the business definitions almost your glossary in the data model. It's nice to sort of a glossary on steroids in a way that you can add those business roles, you know I have the definition of a customer product, but I also show the relationships between it. That is an effort in and of itself, you know you can't go any further if you can't agree on those basic business terms. And then at the logical level that's when you can start adding attributes, or you know the more detailed keys and things like that. I often, and all of this is controversial we data modelers tend to be very dogmatic things so I can see people probably rolling their eyes that some of these are going to have a I know we will have a very vibrant conversation later at the end when we opened it up to Q&A. But you know another, you know do we show attributes at the conceptual layer, I often do you know because that helps describe I often say, at the conceptual level your goal is communication. And I didn't include the examples in this deck but I've used pictures I've used a picture of a customer. I've used a picture of a product in a box on the data model and if that helps communicate what it is, I'll power to it so I often put attributes because are we talking about a customer and his first name last name. Then I know that that's a human being customer versus is it a company and is it the VAT number and the company ID, you know, in my Dunn's number. Then that's probably an organization right and so even simple things like throwing a few attributes in there really helps qualify. What is a customer a product is this a financial product or is that a product in a box with dimensions and colors and so you can you can learn a lot by putting those attributes, but definitely up at this conceptual layer the blue colors are definitely are definitely where you really want to capture those business rules and the difference is that level of detail. And I'll talk about some examples later in this presentation. You know I tend to not be dogmatic in my data models because if it works, I want to get the rules right but how I show it. I can be a little flexible, you know what one company might see as a conceptual, maybe too detailed for another company that you know what wants just a higher level so kind of kind of your level detail really depends on the use case as well. So here's an example of a conceptual data model. This is one that uses those definitions that that I like. Because you can understand what was an employee employees a full or a part time worker on the active payroll, right that very sentence probably could be a whole conversation. I can be an employee but not an active payroll, maybe I'm not a maternity leave I'm still an employee, or we don't consider part time employees employees in that sense of the word or. Okay contractors aren't employees actually they're in a whole different system we don't even want them in this model, you know, a lot of conversation can happen from those definitions. Relationships are super important here super type sub types I use a lot of those in the data model again when you roll roll that down in the database or how you do that in the master data management system. It's very different but I think super type sub type is really easy to understand for most business people an employee in this case could either be a sales rep or supports or we only have two types of employees in this company who support customers. So most folks might say well about finance and maybe on there where but it's a very easy way to understand the different types of things we kind of learned that in kindergarten which of these things is not like the other. And so that's a very intuitive way to look at things. I like conceptual data models and when we do some data modeling classes and our company I often just throw up data models and say what kind of company is this and I find it fun because that's what I like about data money it really explains a company on one page and that's why business people like it because you're explaining their company in a way and getting those business rules out. So with that with this company this person definitely sells some sort of service or software or product. Some sort of customers have support reps. Some companies have a sales reps or maybe the larger companies have a dedicated sales rep here. You'll see and I'm going to I'm going to tease Andy a little bit his conceptual model did not have verb phrases on it. But that's, you always would have a verb phrase on a model, because these things should read like sentences, you know, a company employs customers. That sounds funny but maybe that's how they have it we don't we don't look at the, the custom, you know, the company as a customer is the customer is employed by a company right you turn, you learn a lot so I don't know I can see a support rep provides support to a customer kind of self defining. I don't know the definition between a sales rep and a company I can assume, but generally you'd have a verb phrase here. This is a training course this is a webinar, but we have a lot. I have a lot of fun I hope the students do a lot of fun in our data modeling classes of kind of turning sentences and the data models are reading data models like a sentence and that's why these are nice because a business person can read these and really understand them and start to have these definitions about about customers they should definitely tell a story and they should make sense. In the data modeling for the business book we spent a lot of time on that argument of, can business people understand the data model I say, these are fighting words absolutely. And if they don't then you're modeling wrong. And this particular notation is kind of the ERIF notation. I found this very easy to understand kind of that crow's feet that most folks can sort of understand that this is one or many or one, even without explaining it, I generally do some training with business people and 10 minutes tops on how to read these models, and then they get it and sometimes folks will say remind me what that zero means or but but you know this is exclusive type or an inclusive folks get those concepts, you don't have to use the fancy words, but I've had a lot of great experience. Doing that and in the book we actually took a little bit of a survey I am a strange person but I went around a lot of my friends and different industries a carpenter, a music teacher and accountant and had them read models and most folks could even without the things that have understand this because it, you know, it makes sense to sort of intuitive so have a lot of great experience. I would say, use the language of the goal, I'll say it again the goal of a conceptual or logical or any business centered data model is communication. So we don't want to get overly dogmatic and worry about terminology, keep it simple. You know the I almost call it a PowerPoint style conceptual model I mean business people look at diagrams all the time it could be an work chart. They do a lot with PowerPoint so to me, seeing a model in a simple way as most business people sort of get that intuitively. The other thing and I'm sure I'll have some chat at the end. These are also I guess fighting words although I think it's intuitive. Use the language of the customer if, if, if, if there's a difference between, I don't know a client and a partner, or yeah, a client and a partner or a client and a employee, don't generalize that into something like party, maybe in the database, you know you can have it all in one table and roll it up, but you don't want to oversimplify it I actually was doing a conceptual model data model of an unnamed company, and they literally had party related to thing. And to me that was so I've no you would not at all know what that company was because they, yes, could have, you could store everything at a table called party, but you know that intuitively, I mean we have party. It's an individual or just plain old individual has a name and an address but we know that an employee is very different than a customer right or a physician is very different from a patient in terms how that data is used and what that data is related to, and it breaks down when you start doing relationships to other entities so I know from kind of an academic point of view or a clean this point of view would be nice to roll everything up into a single entity or object. But I think you're losing a lot of the valuable business rules and I would prefer to kind of have them separated out if the business season separated out and have some funky relationships, and then you may have to resolve that. I think database is a certain way but if those relationships are funky and that's a technical word. It's probably because the business is a little funky there and we need to understand it and I've seen too many bad examples of you know bad customer service and I still have a company I work with that I can't seem to figure out that I have a different mailing address for my physical address. So while in the data model of why why their system isn't working. That's a very simple business rule that you know maybe it was simpler to do it a different way in the application and, and we're living with the consequences so please do use the that you will you will often find some really great input but by separating things out. Yeah, or put both on there and say okay I'm hearing the word client and I'm hearing the word customer. So, is there a difference in the definition. Maybe you won't see the difference in the definition but you start drawing relationships and you see that these have relationships to very different things and you'll sometimes flesh out the details there so I definitely see a conceptual data models are working living document it shouldn't be perfect when you go go to the business, you know start with something and then that you should be getting feedback and change it and ask a lot of questions. So just that terminology, avoid excess detail that's in the eye of the beholder. I'll give an example of a kind of an architecture company we worked with that really like that detail because they're used to a lot of detail. You know we're working for a retail company, they might really want it summed up so so understand your audience because you're trying to get to the knot of some issues so the simpler the better. If you want anything you don't know and you want someone to explain you want it in simple terms you want people get to the, the level of detail that you can understand. I'm sorry moving on. And I do think this is a great opportunity for a data architect to really have a quote seat at the table. I think a lot of business people we work with a lot of, you know, C level execs that have come to us because they know they need help with data, and often have a digital communicating with it, and love this idea of a data model they've had someone that can finally talk in their language their language, not tech language, but then also understand data enough to ask those leading questions. I mean if you love that type of thing and you like working with people and you like that sort of core logic. I think it's a great opportunity for you to kind of jumpstart your career because it's a way, you know I'll show some quotes later in the prep, the presentation we've had so many positive experiences from data people saying thank you. You have elegantly done this on one page that I've had trouble describing before. And again, I, and you can argue with me but I've had very good experience with business people understanding a data model and you can probably tell my voice I'm kind of passionate and a lot of our workshops get very animated. I had the pen out of my hand and start drawing their own data models and, or coming to me later, and saying okay I heard what you said in the workshop that I was thinking about it I think the relationship is more like this, is this right. Because again it's a simple language and, and if you want to be that advisor and really kind of get your voice heard and be that more than that that business executive communication this is a great place to be. I don't really like the data modeling aspect. And this, I've been using this slide for probably too long, but I like it so I'm going to keep it, and you might wonder what is on earth is that guy in the left. But I would and I haven't always done this perfectly myself, because we did architects and I will, I will talk about myself and if you would like to apply this to you and that's fine but I don't want to offend anybody, but we tend to be kind of unique and agree that we get very passionate about this. You know, we, we came into data for a reason, we're super interested in it. And I definitely have done this let me tell you about my data model and I know we spent up all late last night getting the lines right and all the cardinality. And I have to remember that not everybody is quite as excited about business that the we are so think of the business exec in the middle they're super busy everyone, everyone's busy but you know they definitely think they're busy, they're very results oriented. They probably have their, you know, their quota to make or their deadlines to make and just like anyone it's sort of the, you know what's in it for me, and so this this data person is going to come to me and draw boxes and lines on the wall. And I care so what you don't want to do is to sort of get very academic and tell this person you know the world's going to end if your data model is not in third normal form and that picture that guy with the, you know, walking down the street with a billboard on himself saying you know, the world's ending tomorrow because things aren't in third normal form and and the business person is going to say what on earth is third normal form. And why should I care and that's the right answer you should not use words like their normal form you could say we need our data to be consistent, or we don't want you we want to remove redundancy or things like that they might understand or care, you know we're trying to get a single view of customer might be a better way to go than say we need third normal form. I tend to do that and sometimes it slips in but again use that language of the business. So, you know the difference if you're the data advisor, you kind of say you know anyone of my team has heard me saying this what's the so what. So we can do the model it might be accurate but what's the story, why would a business person care about this. So you could say it could be those relationships wow if we could link our customer data with the product we could increase sales now they care because it's going to be something I like to think on the positive the other thing where I'm sort of judging us and it's not a bad thing it's very good thing in the right the context of we're sort of paid to find problems and fix problems right. That can often be seen as very negative in the business, and I know I've done this myself you do a presentation and you say, here's all the things that are wrong with your data and we're going to come fix them. We have the right intention but what sort of coming in from the business is you just told me I'm messed up. And they may know that and you often get a lot of buy in by finding these problems and saying, you know, you got you folks have had trouble linking your customer data with your product data we find out why and we can get these roles fixed, we're going to help you. That can be very good. But often, we kind of overdue that and we might want to say look at the opportunity we could have if we did this right and it's just a flip of the words. We tend to do that a bit. So, again, these data models can and should be super popular with the business because you're speaking in their language, you're showing them the so what in terms of we're trying to get these business rules so we can get a marketing campaign out or we can, you know, make your customer data more accurate or you're not going to get fined or, you know, etc, etc. And your student and student grades linking to attrition rates or something right so but you need to kind of put it in their language so that they can understand the why and I think we often forget that when we're in the correctly in the weeds trying to understand a database so I'm not knocking the idea that we need to understand a database. And I've done this to myself to two of you and I've been up all night the night before trying to figure out the database, and then you have to explain to the business kind of to stop and take that free to breath and say who's my audience. I want to simplify I want to kind of talk about this so what. So, yeah, tell a story and yes here's another data model. But we do I heard on the radio a couple of years ago that stuck with me that you know humans are storytellers think of our ancestors around the campfire right be all our history needs to be verbal right before we wrote everything down. So someone kind of summarized it and you can't even sleep without having dreams, which are stories, you know we're such storytellers even when we're asleep we're telling ourselves stories and that one kind of stuck with me because it's, it's the message it's the messaging. I was in marketing for a while at one point and that was probably the most helpful part of my career because it really helped you distill the message to people. No one care, I tell myself this all the time no one cares about your data model. But they really care about the results of the data model and they understand they care about how that impacts their business so you will get people interested in the data model, but not for the reasons perhaps you're interested then no one cares that you spent all night, you know getting those lines and I know I feel you all the people out there who do that, but they definitely will be engaged in your model and they will care, because, you know, the customer here we have in this data model a customer can buy more than one product but a product can be bought by more than one customer and they might say no we only have one customer on an order, you know, right now, they'll start to get very engaged when you get those business rules right, or you could put your children to sleep reading them in the evening. So, again, these are very popular with the business. A lot of again business people start using themselves to kind of communicate with it. These are some very actual quotes from some of our customers and not to pet ourselves in the back but I think it was more about yes this guy can be popular and the different types of people saying this. So one upper left was a basically a kindergarten teacher, and she was there white boarding with us defining what a classroom was a virtual classroom the same as a physical classroom and that was their whole discussion and there's a lot of nuance to that. And that's still a quote classroom with the curriculum is the same but you don't have enough physical building right there's a lot of conversation around that right now. And her comment was this is really really elegant you just summed up our organization in the single page. She directly said that so I stole it from her mouth, but we hear that same type of thing a lot. Thank you. I've been trying I knew we had this problem and I could never explain why, and some of those rules were wrong. And I might the VP of software development that was almost from the opposite perspective, this was a VP of software development and was writing applications. And we did some workshopping with kind of some some customer journey mapping and some data models kind of overlaid on that and understood what data was used where in the customer journey. And that was this was so helpful because I've never seen the data from the customer's perspective before. And he said this will really help me with my app development. Thank you very much and he was. Surprisingly, one of the biggest proponents of this kind of conceptual business like modeling at the end of the workshop because, again, he might have seen the table called customer, he didn't know all the nuance behind it and he needed that for developing his software application so it's not only a business model. It's and it's business and tech. One of the low ref is cheap market marketing officer you know her quote was, I don't know what this data model stuff is but you're the first one to explain to me why my campaigns aren't working. And to them it was a relationship between some of the data. The first one was over in the right. We did up this big utility company on the east coast of the US, and we had been there. I think about a week maybe two. And I was doing the readout and explaining all of this, you know the relationships between pipes and I can't remember now but it made a whole lot of sense. And this person said wow how long have you been with the company, you know clearly you must have been here about 20 years and I said, one week and it doesn't mean that I'm particularly smart. So it's the data modeling methodology of I just asked a bunch of leading questions. People told me their business. I put it in a model and we read it back to them in sentences. And it was just because we had talked to a lot of different people in the org and everyone sees their slice they had never said another big benefit had never seen all of the slices put together so yeah that was kind of the power of data modeling. We've been here 20 years and we had only been there a little over a week. And then, you know, we have more people asking for these data models and, and that happens a lot to, you know, we work with one department or one organ and a lot of folks want to have those same benefits. So, one do want to get down to that logical level and I am conscious of time because I see some chats and Q&As in there. And here's where you want to get into the little more business rules and data modelers are probably arguing about this model already and you should be right. Some of it is getting the, you know, the attributes, you know, do we have a customer identifier as the identifier or do we need more of a natural key? Do we go by first name, middle name, last name? Is last name the right term? Does every culture use their last name as the family name? Should it be family name? You know, what is a gender? You know, all of these different things need to be argued out or fleshed out. You'll see this one does have bird places. So, you know, a customer can place zero more one order. I might have a problem with that. Is that person a customer if they haven't placed an order? Yeah, that that's actually a very, there's no one answer to that, right? So, a question I often get is should I just use an industry model? Why should I go through this effort of building my own model? And I say, well, if you just kind of are, you know, cookie cutter business and you do nothing unique, and yeah, I would think you're probably not in business if you're just cookie cutter and have nothing unique about your company. So yeah, you might start with industry model. They're a great kind of jumpstart. I think often something as simple as that that'll cause an application you've bought not to work of, you know, you might say I include all of my pre-sales customers and my customers all to offer customers. We treat them the same. They get the same emails and all that sort of thing. And I can't put the customer in the system until they've bought something might be a problem with this data model. And often it's a problem the business is having that goes down to a circle on a line or a cardinality one or more. Is it one thing or is it more than one thing? And so it is helpful to go through these either to understand what you have already or to kind of flesh out those business rules. One of my favorite stories was one of our nonprofit clients. A lot of young folk that kind of were in the nonprofit industry and stereotypes are abounds in the world, and they were doing some negotiations with the vendor. And the vendor was sort of saying, oh, we can't do that. We can't do that. And they said, well, here's our logical data model. We'd like you to match that. So the vendor was flabbergasted, but the vendor made some changes to accommodate them as part of the onboarding that would not have happened had they not had their act together. So surprised that vendor didn't expect that from a bunch of 20 year olds and a nonprofit, but they had their act together and they were able to make those decisions before they bought the product and get that customized rather than finding it two years later when we had already implemented a lot of these things that would have cost a lot more to fix it later. So here you are a little bit more getting towards a data structure. I'm going to tease Tim this time a little bit from the beginning when he called things like asset transactions legacy, I don't think they're legacy I think they're foundational I do want my, my bank to have assets. And I, you know, deposit money or I buy a stock transaction. So, yes, they are still absolutely a lot of the rules you are getting in this type of model because you do want to kind of those core. This is often a first step to something like master data management where I am trying to get that single unduplicated clear view of what is the customer not all data analysis leads to this I might be doing more exploratory graph patterns and trying to see relationships. But if I don't know what a customer is like if I want to see the patterns of customer. I don't know what a customer is it's a lot harder right they did that wrong or data quality so these types of. Even what data is important so one of the things here in the left, speaking of data quality we had worked with a customer that had done a lot of data profiling, had outsourced some of that and some of the results came back that there are facts number was empty 90% of the time. It's a fax number that might not have been the key data elements I should have been focusing on so this process of starting to put the attributes on a logical data model can help you focus of what do we need to worry about facts number probably isn't one anymore but the cell phone number should be and have had some very healthy discussions with marketing teams of now for a customer. What are those key data elements or key attributes that I need to track around a customer and maybe what isn't so important. So, again, I talked for a long time but one tends to model like this could be a, you know, a two hour workshop with business users really getting a lot of great information about their business and something like this. One of the thing here that I kind of touched on it but if you're like me, you probably want things right and a lot of us in tech, you know, get nervous I don't want to put this up here because it might be wrong. I've totally gone the other way now I just put it up there and knowing it's probably wrong and someone will tell me, and that really generates a lot of conversation in the business, and that can be really helpful. A couple of success stories here and I won't talk a lot about them because each one of these has a full webinar behind it that we did with the diversity. This one is one of my more fun ones, because it dealt with fish and cows, which was fun with the environment agency of England. One thing that I want to mention here is we often talk about the business, as if that's a thing. And I just think that's, you know, it's it's it's us in the rest of the world. And they're all the business and the business here were scientists and our sponsor was, you know, a clinically trained scientist super smart super technical we often say oh the business isn't technical well she was certainly technical it's not the science that I ever would. But what we did was talk to those different science scientists and try to get some core terminology, you know what is a living organism is a, I had a lot of fun with this one is the fish, the same as the cow this same as bacteria in the water. Actually, it sort of was you were taking samples right and so we had a lot of workshop with the folks learned a lot and that was their biggest takeaway is we as an organization helped ourselves work together more efficiently and share data more efficiently and also help kick off their data governance, because we realized that we were sharing data. And if we don't have those core definitions about some of the scientific terms we're using. We can't share data we can't publish findings on the web to the world to do more research around the environment. So this was a great success story about something that's a little different that you might not think about another success story. That was a couple years old that we did last year, maybe on the call I didn't check names they often join us here on the calls is key with and I love this example, partly because we always an art and data architecture use the example of it's just like if you were building a just like a regular architecture. And these are architects literally they are building some of the major infrastructure in the country and building the big buildings. So, they really love data models. And again, are you going to tell these guys that are building you know nuclear power plants that they're not technical or super technical to these guys and gals, you know built super technical models so I don't bore you too much you can watch that webinar, their conceptual data models actually started to kind of lean more towards that logical maybe even physical technical because they like to see a lot of detail. I wouldn't have showed me data models of that technical nature to maybe an investment bank because they probably wanted a little higher level. They, they got models in a second because they live in breed models they see diagrams they see architecture diagrams all the time. So they were a different fun client or again, we often say, well the business is not technical. Gosh, you know, to tell someone again building a major infrastructure or someone doing advanced scientific studies their technical just in a different way so they often really get models, or I use finance as an example of not being technical that's not true either and they do numbers they know, you know, algorithms and they often get this really quickly as well. So, I do want to just touch on this quickly. I also do want to get the questions but we use this analogy and it fits nicely with this keyword example of that a difference between designing and building and we get that intuitively. I have some folks building a deck behind me and we designed it right we know how long the structure wasn't without a picture and a piece of paper. There's no way I can. I can confuse what we did on the, we actually use CAD models to draw it out with the guys taking dirt in my backyard today. The key is a little easier to mix those two up to two to two up right that when are we showing a physical data model or a database structure versus what I show the business and but I had you thinking of that example in my head don't show one of those models that Andy showed before with all the data types and foreign keys and all that to the business just like you wouldn't make the homeowner dig in the dirt when they're you know the owner designs with you. If you want to have the buildings in the rooms this way, the homeowner doesn't swing the hammer. Generally, once they ask right. So, that's maybe sometimes that the easier way to kind of understand the difference don't mix them up. But they're super important and I don't want to belittle that because the beauty of putting a data model like this in a proper data modeling tool is that it can consume and show it in their language and skip a lot of steps, and then generate things like VDL or technical code. Also, you can whiteboard it I've done it with sticky notes we've done it with pictures right. Absolutely if that's what gets those business rules out I will you know do interpretive dance or whatever they get the point across. But generally at some point if you're the architect, putting in a proper tool you know even so you know there's drawing tools out there and I won't name them you know which ones they are. They can draw a picture, but it is also nice to have a true modeling tool of metadata that you can generate either reverse or forward engineer back because I definitely talked about the top down approach. Andy and his had kind of talked about the bottom up and generally it's a middle out right you often you know have with the business said, and then look at the database and that can be some of those aha moments will you said a customer can only have one order or one account. But we have 16 customers with multiple accounts and that's what the database structure says so which one's right that can be helpful, but I would generally start when you're talking to the business with that top down. This is what a physical data model looks like we already showed one earlier but you know they are sort of well suited for things like relational database structures because there is a point to that getting a lot of those business rules is a great use case for relational models isn't the only way to do that though I wouldn't say don't do a conceptual data model if you don't have a relational database although most folks do because you're still getting those key terms that some of it might go into business glossary. Some of it may be in your application development code, but you're still getting those core business rules. So we won't go into depth here we already talked a few, but no matter what industry you're in you can use a data model and we've had, again, the method is the same the results are really different from I talked about the environment agency early childhood e commerce universities, construction agile software development companies have still use data models. Etc etc etc so you know doesn't matter the industry it's the methodology. So, use data models, it does make you more efficient because you get to those core things that might have taken you two years to fix up early. Speak the language the missed business in the data model and that's going to make you more of a data advisor, unless data architect to put on a different hat when you're talking to the business, but it does help with the physical implementations. We will talk in a totally different note on graph databases next month if you can join us. We do this for a living if you need help and we are hiring so if you, and the point in times that hey these are our people she's talking my language. Give us a look up in LinkedIn we're hiring, and I will pass it over now to Shannon to open it up to questions. Hey Donna thank you so much for another fantastic presentation and just answer the most commonly asked questions just a reminder I will send a follow up email but in a day Monday to all registrants with links to the slides and links to the recording. So diving in here and trying to get to as many questions as possible. Would you mind sharing insights on alternative data modeling such as data modeling of social media website emails and satellite images. Um, yeah well the one word talking about social media depends on what I mean what they might be talking about is there's different physical database storage right so for, say a website and usage I might use something like a key value pair. And it's still probably helpful the business level though, again that conceptual model and level. A lot of those tools kind of grew up in our land, but it doesn't matter to say what are we trying to get from this data structure I'm trying to say, a customer has a web interaction, or has a social media post. We actually are working with one of the big social media companies right now, doing data modeling, and just that what is what is the, what is the link between a user and all those types of interactions is it just a web click, is it a post, is it a, you know, there's a lot around that. So, again, separating out, I still think just these high level business rules can be helpful, but there's other you know if you're doing application development sometimes a UML model is a little better suited because that's kind of meant for application development. But again, I would think when you're at that business level you're trying to get understand the business and the business rule so maybe let's think less about implementation and more about use case but but there are you know again UML might be good for app dev and there are some other ways to you or just sticky note it. What are we trying to get from this web application or what are we trying to track, and that might help you decide what data modeling usage you're using for both social media company when they're trying to see how many users are paying their contracts might use a I'm trying to see who's related to whom it might be a graph model right but they still need to understand their business in a certain high level business model. All right, I'll be quiet so you can ask another question Shannon, or I'm sorry, did Tam or Andy want to chime in on that. This is going to invite you and near Tim if you have anything additional. Well, I just chime in in terms of social media LinkedIn is a customer and they use this for many different use cases. Right, but you know around user profiles, one of the most common ones. But that said, obviously they think they're a huge organization huge business they have many many applications many many use cases and they'll use, you know, the right, the database that suits their needs and they're doing data modeling and business modeling, you know, first before they're putting data in the database and building those applications right so it depends on your business goals. They're trying to build. Right. Perfect. So, what about public service data insurance employment for example. I'm sorry, did you repeat that. I didn't quite hear it. What about public service data insurance employment for example. I'm not sure the question I would say anything could could be modeled. So we're we are working with one kind of insurance company that summarizes public data and public, some of it's public and some of it's internal, and they use a data model of whether you know sometimes they can own it and sometimes they don't, but yeah I would think anything could be modeled but I am also maybe I didn't understand the question so they know if Tim or Andy if you have any other input there. I think you said it well. I'm going to slip in at least one more question here. How do you handle past, present and future tense in relationship past present and future tense well yeah I think I see where the person is going it's the business. So you're not trying to model history unless that's a star scheme then that would be a date right I want to know transactions over time you would like it to the date, but these are more kind of present tense rules can a customer have more than one account at the present time, it's not have over time with history. Are we looking out so that might be, you know, maybe separating out of are we thinking to mention all in terms of reporting or business rules in terms of applications. And there's also, you know, kind of defining the context of your model it could be is this as is or to be is another one I often ask are we describing what it is now or what we want it to be. And often you have both, you know, or are we trying to talk about trends over time, or kind of more of a transactional application this kind of kind of good to set your intention on that if that makes sense, but open to Tim and Andy starts there too. And my one thing on that, or my one point is data models, if you're going to be talking about present state future state. I think that lends itself more towards an enterprise architecture model, but the data models can be incorporated in that this way you can do your slice, you know your points in time and to your point you know a date in a business model is, is very different than what is going to look like in the future so I've, I've, I've gravitate towards enterprise architecture, if you want that future state. And I would agree with that because I think a, because a data model is a good part of it enterprise architecture at the business level it's kind of where that's fitting, you know when you're thinking and so I wouldn't disagree. But Tim, any thoughts there. There's nothing really to add there in terms of, you know, future state and versus present state now. Great, there's so many great questions there's one here Donna about if your books the best, but maybe I can get that those details place to learn how to do this. Maybe I can get that from you to send in the follow up email, because again just a reminder, I was in a follow up email by end of day Monday for this webinar with links to the size links to recording and the additional details requested. So much thank you again to couch base and to everyone by quest for helping to for sponsoring and helping make these webinars happen. Appreciate it as always you guys have been great thanks for attendees hope you all have a great day. Thanks everyone. Thanks all. Thank you.