Design - Data Design - AgileData Gone in 60 Seconds

Welcome to another Agile Data Gone in 60 Seconds. Today I want to talk a little bit about design and how we design data that goes into agile data. So if we have a think about the catalog area, as we've said before, there's 3 types of things we care about. We care about concepts, things we want to count, part of our core business concepts in the organization. So things like customers, products, orders, those kind of things. We care about the detail that's recorded against there. So customer name, customer date of birth, product SKU, product name, product type, order value, order quantity, those things that we use to describe these concepts and may want to report on. And then events where we see these things happen together as part of our core business processes. So customer orders product, or customer makes payment, or employee applies for leave, those kind of things. So how do we design this? Well, it's very, very simple, as you would expect with all things in agile data. If I go to the topic canvas, this is where we start from. So we think of designing our data based on topics. You may call them subject areas, you may call them domains. So we want to focus on a part of the business that we're going to design out first. So the first thing we do is we go and create a new canvas. I'm going to give the canvas a name. So in this case, I'm going to go and design sales. And I'm going away and creating a blank canvas. Now what we typically do when we, when we do this work is we get a subject matter expert to actually remotely see the same screens we're seeing. We have a virtual call and we actually map out these data designs with them. So we find it's a very quick and painless process, something we can normally do in 15 to 30 minutes with a subject matter expert from the organization. We believe all data should be designed upfront, but it should be a light design It should be an agile design. We should only design what we need for now and build it out in the future. We don't believe that we should rip in and just start creating code, because what we know is we know that we end up with spaghetti. We end up with code everywhere, data everywhere, silos, and no single source of truth, no golden record, no way of answering the same question consistently the same way in the future. So what we need to do is we need to understand the core concepts here and how they work together where we see an event. So what we typically say is who's involved in your organization, and we may hear a word such as customer. So I'm going to go and create the concept of customer. And when we do that, we may define it as a who, a what, or a where. So this is a who. I'm going to go create that. I'm going to go and search for that concept, and I'm going to go and drag it. So the next question we ask is customer does what? Okay, the customer buys something, they order something. Okay, and we have a little bit of a conversation around that. And what's the term we use in your organization? Is it buy? Is it purchase? Is it order? And in this case, it's order. Order is not a who, order is typically a what. So we create that, go and find it again, and bring that order down. So custom orders, and what do they order? And we may hear that they order product, right? So again, we go through and create that concept of product. Go and find it and drag them down. And now what we've got is who does what, you know, a customer orders a product. And then we may hear some other words. They may go, oh yeah, but actually they order a product from, from somewhere, from a store. Okay, easy peasy. All we do is we go and create the concept of store. It's typically a what or a where. Let's call it a where this time. Create that. You get the pattern. We go through, we look for store, we drag it. So customer orders product from a store. That's the core business process that we see. And as you can see, every time I drag a new tile, go, a new one gets created to the right. So you can create as many concepts as you like within these events. On average, we would normally see between 3 and 7 concepts being part of the core business process. So what happens if there's a second process? We say, well, customer orders a product from a store. What do they do next? Well, The next thing they do is a second event. So what is it? Well, customer pays for the order. So, okay, well, we already know we've created that concept, so let's reuse it. Let's reuse customer. We haven't created payment, and look, let's just check that nobody else has. So look, there's no concepts there, which means nobody else has created that concept of payment previously, which we can use. So what do we do? Easy peasy, we create concept of a payment, which is a what. Create that there, drag it down. Customer pays for what? And this is a really interesting one because sometimes they pay for a product, sometimes they pay for an order. So in this case, after a conversation, we say customer pays for an order, and we already know we've done orders before. We drag it down. And so customer pays for order. Another event. And we keep on going, new events, right? So we go through the core business processes for this domain, for this topic of sales until we're finished. And then what happens? Well, effectively, we've started building out our design. So if we go into the catalog, you will see now we've got a bunch of new tiles up here, right? We've got some 3 concepts and 2 new events and they're draft and there's no data in them. What does that mean? Well, that means that actually these are conceptual tiles, we call them. They're tiles we know we got to populate with some data via rules, but we haven't done that yet versus these tiles where there's the full line and there's a row count in there. We know that somebody's already gone and created the rule to take history data and populate it in there. So last one is we may want to have a quick look and see how this looks from a mapping point of view. So we'll use the event matrix and that will go and show us that we've got Customer orders product from a store, and these little dots show where the concepts are involved in that process. And by doing this, I can see that I've got a draft concept of customer, but I've also got a physical or populated concept of Shopify customer. So now I might want to go and have a conversation or have a look at the data for Shopify customer and actually see when was it created, who created it, maybe have a little bit of a chat with them to say, is this the same customer record? Should we be doing what we call conforming? Should we be creating a golden version of this customer. Or for now, should we actually just— maybe this data is not coming from Shopify, maybe it's coming from Salesforce. So maybe we should rename this Salesforce customer and then Shopify customer stays. And at some stage we want to create a single view of customer. So we're going to create another concept and a rule to populate that. So easy peasy, that's designing data really quick, really easy. We shouldn't be putting ourselves into cupboards scratching our beards trying to do an enterprise data model that takes 15 years and no value. Well, it has value, but 15 years is too long. What we should be doing is we should be modeling and designing really, really quickly. We should be doing that with the business SMEs collaboratively, as we've just seen. And then we should go and find the data for that model, populate it, see what happens, go back and refine the model once we know some more. So that was another Gone in 60 Seconds. I hope you have a simply magical day.