ELM Patterns Templates with Remco Broekmans - Episode #61

Foreign.

Welcome to the Agile Data Podcast where we talk about the merging of Agile product and data patterns in a simply magical way. Welcome to the Agile Data Podcast. I'm Shane Gibson.

And I'm Remco Luckmans.

Hey Remco, thanks for coming on the podcast. Today we're going to have a bit of a chat around ELM and probably start off talking about model storming because it's a shared love of ours. But before we do that, why don't you introduce yourself to the audience?

Yeah. Thanks Shane. Looking forward to this podcast because it really focusing on two of the parts I'm working on latest. But to introduce myself, Remons. I'm living in the Netherlands, near Rotterdam. I work for Genesee Academy. Mainly I'm doing training on Data Vault and the ELM approach. Do a lot of workshop with customers to help them out to go for what kind of information, what kind of models we need to come up with, what kind of data we need to come up with. And that basically my job for the past, I would say six, seven years that I'm really working with customers to say what do we need to do, what do we need to capture? And I was just thinking there are some ways to do that one. It's not just look at the data boom, here it is. So I came up with, together with Hans on the ELM approach, we do model storming. Of course we nicked it from Lawrence core his ideas as well as others as your ideas. Right. So. So we find some ideas, we find some similarities. This is something which is working for us. So I'm happy to talk about that one for sure because it really is something I'm very fond of. By the way, my background, I've been a lab technician, I've been an environmental engineer. So I have a completely different background than a whole bunch of people in the data world, which I think helps me having a different view on stuff than some other people have. So I know the importance of communication with non IT people.

For instance, great fan of Lawrence's work and I think about it as innovation. We find patterns that are useful and then we innovate and iterate them to make them slightly better given our context. But we always recognize the people's work that we're leveraging and I think that's the way we should do it. Lawrence often talks about the seven W's and for you I think there's actually like two B's but maybe a third because you, you were a baker, I believe, and you were a brewer. Yeah. So bread and beer Two of my favorites. Now if you happen to be a barista in your career, you would have nailed all three. Or a chocolatier actually. But that's a C, not a B. You're never a barista, right? That's the one that's missing.

According to my wife. I drink so much coffee, I have a similar with a barista. Now I've never been a proper barista. I'm just using a machine which creates a coffee for me. But I think there might be a career change coming up. Maybe someday.

Yeah. And then chocolatier. Right.

Because you're in Europe, of course. Without a doubt.

So model storming. This idea of running interactive collaborative workshops with our stakeholders where we work together to use some pattern templates to solve a problem, either problem solved together or to elicit some requirements or some shared understanding. And I call it pattern storming. I think you and Lawrence call it model storing. There's brainstorming. I think Scott Ambler from Memory was agile data modeling or model storming as well. So it's this idea of word in front storming. Talk me through the process of how you model storm with stakeholders.

Yeah. And I think you might recognize as well, Shane, it all starts with getting the right people in the room. Because what I found out is that of course when I did my modeling in the past and you need to get information. You want to talk to business people. And of course the first time you said, oh, I need to create a data model, Dear business, would you please help me? And then you make an appointment and you're the only one in the room because they don't like the term data modeling. And then you try different angles. Of course I said the secret is in the donuts or soap waffles. Hey, I'm going to invite you for a workshop on data modeling. And I bring donuts. So then physically they might be in the room, but mentally they're still doing something different. So I just thinking I need to do something different. And I think the most important thing is before you can do panel storming or modelstorming, whatever you want to do is to invite people into a workshop from the business, from the organization, without using any technical terms. And for me it's very easy because I'm always new in an organization so I can just say, oh, I was hired or asked for by whatever the person is hiring me to do some work for your organization. But before I can do that work, could you please tell me what your organization all about? And since I'm new and people business People love to talk about what they're doing, are most of the times perfectly willing to do. And I try to stay away from the terminology like conceptual model or logical model or physical model, they don't care. So that's why I need the first time really get the people in for an hour and a half, two hours, two and a half hours, whatever time you think it's fit for that business function, for that domain. And when we have the people in, I don't want people in with a laptop, I don't want it people in. Often you get people in. Yeah, I'm the business analyst. Okay, Are you the business person analyzing information or are you the IT person which has a little bit more understanding of business people? Or you can sit and are you then business analyst? Because the first one are the interesting one because the people from the business analyzing data and running the day to day business, those are the people you want to have in your workshop. And of course then the whole idea is not to chase them away. Don't come up with, yeah, I'm going to create, here's the whatever system it is and here's the data. And we need to model this and we need to do crow's feet and they're gone out of the way. So that's one thing. The other thing is use that terminology. If they are talking about clients and prospects and employees, don't say, yeah, you mean person. Because if they would meant to talk about persons, they would say, yeah, we have persons in our organization. Use their terminology in every single bit and every single sense. That's where I think good workshops start with get them into the room. And yes, of course, I always bring soap waffles or donuts or licorice or whatever to get them going. In the Netherlands, it also helps when you say, ooh, lunch is on me. There's no such thing as a free lunch. They don't know it, but I know. And that's where we are starting off.

So there's some good patterns in there. The first one is people can listen and interact for a period of time and then they're done. So these model storming workshops typically aren't full day things, are they? They're normally, I think you said between two, two and a half hours. There's a natural window before they get burnt out.

Yeah, absolutely. Yeah.

No distractions. So it's turn up, be present, let's get through it. And if we're done early, we're done early. But we need to get through it and you need to Be engaged. And that's a trick as a facilitator, do it. And no proxies. You actually need the people who understand the business processes, understand what the data is going to be used for to help do the work. Not one of the people they volunteered. So it's the right people in the room is really important.

Yeah, basically the people running the day to day business know what they're doing, know what's going on. And yes, of course if there is a business analyst or data steward or whatever or an IT person want to come, they're welcome to sit in the back and they can make notes and help me scribing because my handwriting sucks, but they can help me on that one. But they are not the one participating. And also the very simple reason I don't want to have data or laptops into the workshops because when people say oh let me look it up then they are going to be IT focused instead of business focused. I think what you want to do from a modeling perspective, what you want to capture at all and how are we going to store it and where or whatever, I don't care that much at that moment in time. But we want to know what is going on in the business, not how the IT perspective of what's going on in the business has been done. Because the worst case you can do is say oh look what you have now, what's in your source system and let's model that one. It doesn't work that way. So we really need people running the day to day business. And like I'm now happy to talk about my work and what I'm doing. You want to do the same. You love to talk about what you're doing. Business people in your organization love to talk about what they're doing and they can tell you what's going on. And I don't want to focus on what is your issue at the moment, what is your problem at the moment. Because it's not about what the problem is now. It is how they run their business, what is going on. Because if you say what is your problem? This SAP system is not doing what I wanted to do. I think yeah, that's not what I want to talk about. I want to talk about what your stuff is going. And of course if Junior Workshop says we are having an issue because it takes too much time to look up if we already know a customer so we going to re enter a customer and then we need to have some process, I'm making a note out of it. But it's not going to influence my data model. And I think that's important.

When we're talking about data model, you're not talking about a physical data model. You're not drawing tables and columns. We're probably not even talking about a logical data model because you're not capturing all the attributes of the data. That may or may not be important in this workshop. Conceptual data model is probably the closest thing that we have in the data world. Although what you're capturing for me is more starting at a business model and then going down to some of the conceptual modeling patterns. But it's sitting between those two. And I think that's the important thing is you're not going in and actually drawing third normal form or star schemas or data vault models in this workshop. That's not the purpose of the workshop.

No, it's not the purpose of the workshop. And also, by the way, it is a series of workshops, right? I cannot do everything in one workshop. What you say you can get people in for a good two hours, a little bit more, a little bit less. Whatever it takes, you can get people in, but you cannot create a model with a group within that span of time. So we need to have follow up stuff. My basic role in the first workshop is first capture their business terms, the core business concepts, just writing them down. And maybe also we'll talk about your artifacts later, but maybe also do some categorization. So get some first idea about what's going on. And then we have a follow up workshop. And yes, the end result after two or three workshops we will go to whiteboard and draw boxes and draw lines to see how things are going together. Why? Because it will help us, guide us and the people. And that's the interesting part. The business people do know, although they said conceptual modeling data, logical data modeling is scary, but in the end result, they are the ones being able to draw the boxes and draw the lines, understand what they're doing. And I think this is very interesting and very important. Not talking about those terminology at first on modeling. I don't care that much about the terms. Again, I have a different background. Yes, I've been a baker, I've been a brewer, lab technician, did all the other fun stuff. I don't want to talk about conceptual modeling or business process modeling or whatever. I like Steve Hoberman's terminology. He's talking about align, refine and design. And I think those are brilliant. And basically align is what we in IT world would say. Conceptual modeling refined should be logical. Data modeling and design of course a physical one. But by using those terms, align, refine, design, it also makes it easy because that's what you want to do, right? You want to be aligned with the business. You want to map their information to something else. And you need to use their terminology and don't make it technical.

And I think that for me that's what you're doing is you're creating a map. The map has a series of boxes and in those boxes is a series of business words, terminology from the organization. And that's what you do at the beginning. And we know that people can look at those maps and very quickly tell you when you got the map wrong and tell you how to fix a map so you get that instantaneous review before you go into any detail. Because people understand how to look at maps and figure out whether they're telling them the right story or the wrong one.

And one of the things we talk about getting ideas or improvement or using work from someone else to improve, like Lawrence Core stuff is idea about how to already directly write down in examples what's going together and just use it. We have that kind of approach in this as well. Last couple of years I'm introducing more and more something I learned from Marco Wilbert from Case Talk about fact oriented modeling to say basically if you have something which is related to each other, right? The lines between the boxes, instead of just drawing the line and maybe give some critical name, just write down a sentence. I have a customer box and I have a product box. And just draw the line in between and say, oh, by the way, with this line we mean customer has bought product, whatever. But just put it in because then it helps people from the organization who doesn't understand what do you mean with grow foods, many to many relationship or one to many cardinality. They don't know shit about it, but they know ooh. However, customers related to a product and why? Because the customer bought a product, it's been written down there, which is perfectly fine. So I know the reason of the relationship and I think that's very important.

If you got a customer box and a product box and there's a line saying customer bought product, it's a very different line to customer submitted warranty claim for products.

Absolutely. And that will be two different lines and two different boxes in between. And I think this is something which we in data vault world or ensemble world because same for anchor and focal, we have the same kind of idea behind it that a relationship between two bucks is unique and specific. So between a customer box And a product box. We can have multiple lines, multiple different relationships. And instead of what IT worlds would say, oh, but there are different kind of relationships. Let's type that relationship. We just say, no, Every relationship is unique and on its own. So we need to draw it one and probably also create it physically because it makes sense to have it physical as well. Easier for data and just have the names within customer. At bought product, customer has a warranty claim on the product. Customer likes a product, whatever. As the same token, something like a sale line or a line item or an order item. Those are terms from an IT department or an invoice line. Right. And everybody said invoice line. Everybody in the organization knows invoice line. But it's an IT term. We in IT world introduced a term because we need to have that in third normal form, we'd say associated entity between the invoice and the actual products or the services. And there can be many of those. So there's a many to many relationship. We need to have that associated entity. Oh, we need to give the name. Let's call it an invoice item. And everyone in the organization scold invoice items.

So I just want to come back to you use the term core business concept, which is a term I use a lot. And I don't know if I got it from you or somebody else, but it's one that I use all the time and I have a description for it. But before I think about my description, how would you describe what a core business concept is?

For me, a core business concept is everything where a term, where the organization said, for me, this is important to know something about. I can define it and I can identify it and I can describe it and have some context to it. That would be for me, a core business concept. Some people say we have a customer. Customer is a core business. Because what's a customer? It's a natural person who is buying a service and or product from our store. So we can have a definition on it. We have a term for it. We can identify it. How do we identify a customer? If you're very lucky, you have a customer code or a customer number. If you're not so lucky, you can identify a customer by coming in, say, ooh, we have a whole wall of nice photograph, all our customers. And Shane's coming in. And we're looking at, yeah, is Shane's our customer? Because we have the photograph of Shane as well. Whatever it takes for the business to identify this is someone we already know. That's Important. Oh, by the way, what do we know about this person? We know where the person is living. We know first name, last name, date of birth, all that kind of fun stuff. So we have some context. For me then it's a core business concept. What your definition, Shane?

So I tend to talk about it's something that the organization can identify and they want to manage it or count it. So it's a thing typically customer, employee, supplier, product. And then the interesting one for me is I treat order and payment as a core business concept as well when I do it because we want to be able to manage our orders, we can identify an order and we typically want to be able to count number of orders. So for me that's what it is. And then we hold detail that relates to it. So your term of context, we want to know customer's name, date of birth. There's a lot of information about a customer, about a supplier. So I think we're pretty aligned on that.

By the way, the counting part, that one thing, if I'm looking at my training slides, counting is also on that one. And by the way, yes, payment or order or sale or whatever for us and we come to talk about the templates later on. For us, those are events or transactions are core business concepts as well. So they exist on their own.

I agree. So again, if we look at storming, model storming, pattern storming, it's more than just a workshop. What for me is it is a workshop that is run in a semi structured way using some templates or artifacts. So it's not structured in that there's a number of steps you've got to do every minute. But there is a core structure to the workshop, a beginning and end, some stuff in the middle, and some templates or artifacts that help you get from the beginning to the end with the stakeholders in the room. And typically they can see those artifacts being filled out as you're having a conversation. So it's not like you're talking to them, making notes, going away and filling something out and then sending it to them via email and watching them ignore it. You're actually filling out the templates or artifacts as you run the workshop. Is that your understanding of how you storm your workshops?

Yes and no. And a very simple workshop. And then I'm going to slowly introduce the artifacts. Yes, I completely agree. It is not a true structured one. There is of course in your mind the ideal workshop, the ideal flow is we have six artifacts. We start with artifact one and we end with artifact six. And then we have the data model and they are just following up each other. But we also know that on every workshop, when we do a workshop, we can jump ahead from even at the starting point to already something at the end. Or when we are almost think we're at the end, go back to the complete beginning because there's a new business term coming up and we need to put it on, etc. I think where I make a small difference is that I give the business people homework in between workshops. And the interesting part is that if you engage them well enough, and luckily I am happy to most of the time engage people well enough, that can help me and that the thing that can help me with. Remember we said about the core business concept, what we are talking about, we need to be able to define it, to have a definition for it and maybe some kind of what kind of attribute or context you want to know. But creating the definition, having the actual definition is something I tend to give to people from the business say after workshop one, oh, we have now this whole list of business terms, core business concepts. I put them in, I put them in templates. And one of the things said, could you please fill in the definition because it's not my definition, it's your definition. And I only want to have a couple of sentences, just enough for the organization to know what it is. But I leave it normally as homework in between. Especially when you have 15, 20 terms on your board. Doing it within the workshop, it takes a lot of time to fill all the other stuff as well.

And also people can never agree. You spend one hour of your two hour workshop finally agreeing that there is no definition of customer. And we can't actually identify them easily because there's five definitions of customer depending on which business unit you sit in.

Yeah, and I think that's interesting because I'm using that same kind of idea, especially when people have the same idea or disagreeing about what a term actually means than it's something I do within the workshop. I give you an example. I work for a healthcare organization, hospital and they were talking about a bed. And in one of my templates, basically it's the first one after having written down terms what it is, I categorize each item. Is it an event, a person, a place thing or something else? So I was just talking about the whole stuff, right? We had hospitalized all that kind of fun stuff. And then we had bed that okay, what's a bed? Is it an event, a place, person, a place, a thing or something else? And of course my My marker is already on the. It's a thing. I know what a bed is. I sleep in it every night, and I know what it is. And someone says, yeah, it's a thing. And someone else said, no, it's a place. So we got a discussion. Because something cannot be two different categories at the same time. Cannot happen. The same term cannot be said. Okay, why do you think it's a place? In the hospital world, a bed is a place because it's a place in a hospital room and there's oxygen attached to it, and there you can hook up monitors, etc. And the fun part is a physical bed doesn't need to be in place. It could also be a wheelchair or chair or nothing. It's still a bed. We call it a bed. That's our terminology. And the other person said, yeah, I'm from maintenance. So the bed is the one with wheels underneath. We can roll it down and we need to repair it. When initially we had the same term but two different definitions, we got that argument in our workshop, small argument. We got an argument and said, okay, the same term cannot be used for two different things. So we need to come up with some kind of idea. And then we come up with, we have a bad, which is the hospital term, and a physical bed. So then we made two different business concepts. So then I'm using that definition within the workshop. And then I gave it, of course. Oh, and please refine the definition next week, because we're coming back next week for the next workshop or the week after. So that's how it rolls. Yes. Workshops are free format. We have some ideas about what we want to do. In my head, I know from start to end what I want to do, but the order might be different, and I'm the same.

It's got a canvas. It's got 12 areas. I typically start in one area for a reason. I typically go around in a certain order. I will always end up bouncing between the areas. As something comes up, you fill one out, you get to the next bit. They say some stuff, and you're like, hold on, it's true. Then we should have put it in here. And so you bounce all over. But the template, the artifact, gives us a form of structure because we know what the goal is. The goal is to capture the information in that template, because that template is trying to capture things that are useful for us next. So that's probably a good time to move on to the six artifacts of elm. Do you want to talk us through those?

Yeah, of course. No, Problem. We have six artifacts and basically the first three are focused around the core BIS concept. And the first artifact is really the starting point is basically writing down all the terms just on the board, row by row. That's my first starting point. And I'm not really starting with a template, but I first writing down the words and then I'm going to have columns next to it or trim lines. And every swim lane or column is either an event, a person, a place, a thing, or something else. If you cannot decide what it is, it's something else than the other stuff. And that's template number one. It's just basically the list where you are having the words and you can tick the boxes which category belongs in. And the importance here is that you need to have within every business function, with every domain, you need to have events. Because without an event, nothing happening. There's no relationship. We have customers. Okay, but what are customers doing? But now we have customers. Yeah, but how do you know they're a customer? Yeah, we have customer. It doesn't work that way. Even if you say we have customers in your product, but there's no event. Yeah. Then you have two lists and there's no relationship in between. So we need to have those events. So that's one important thing. We need to have an event. All the other stuff, it's basically for us to help. And template number one. So basically it's a list with your category swim lanes to just say let's look in the swimlane. Do we see terms which might mean the same? Yes or no? Are we having synonyms or are we missing some? Or we need to add some stuff. So that's template number one.

Those templates, those artifacts are open source, right?

Yeah, they're completely open source. If you go to elmstanders.com you have to register, but basically you can download them for free and to use them. And they are Excel based or Google sheet based, whatever you want to do. It's not a fancy product. There are nice bit glossary product which are similar what we are having on the first template or the first two. But you know what, I just wanted open source, easy to use. And let's be very honest, people in the organization love Excel. It is a very simple one. And the template itself if you download is just one sheet at this template, the CBC list as we call the first template. And the second one is CBC form. They're basically one sheet because if I click on a business term, it jumps to the page and that's what I'm As a facilitator, by the way creating. But it jumps to a page, says for this term, this is my CBC form. And the CBC form basically says this is the name, this is the category, this is the definition. You can find it in these domains. You can have these main attributes. The first thing pops in mind when I'm talking about a product. What are the first things you want to know about a product? Probably price and weight and the dimensions, whatever identifier is there. And identifier is not just the one. Could be multiple parts together which are really identifying it. We have some relationships and then we have also a place for it's also known as different products or synonyms or hierarchies as part of so IT complete and all the other stuff and a whole list of what are all the attributes we need to know about it. Not only the first one pops in mind or the other one. That last bit is really something a data steward can fill in or the IT business analyst can fill in because they know all the single attributes. There is not saying these all need to be in a report, but those are the one we can fill in. So that's why it's also some kind of homework. But that is TBC list the wording and the categories is template number one. Template number two is what we call CVC form. And they are on one sheet. So that's fun stuff. As a facilitator after the workshop number one and number two and three if needed. I'm creating that one for people. So that's why I can give that homework that can just click and fill in to help out discussing. Because if you have a very long list, I happen to have lists where you're writing on a flip over and then they are still popping up new terms, flipping the page next flip over, etc. Then it's very hard to see who within the swim lane. What do we have is the same yes or no. So we also come up with something we call the CBC Canvas and CBC Canvas. Basically it has the five swim lanes. So for event, person, place thing, other concept has a five swim lanes. And we just use post its to say oh, we found out in the category events. These are all the business terms business concept we named. So we put them in just as they come in, et cetera, et cetera. So we do all the other ones and then we can easily say now they're nicely tied together, all the persons are nice together, all the place nice together. And then we can see we have a customer, we have a Client. We have a kunt. It looks like the same term, so they are synonyms. So we need to pick one. What is the term we are going to use? Going back one step on the CVC list, as a facilitator, you need to know the mistake if people are using the term. Yeah, we have a customer and they're coming into the store buying a product and later on we can have a client on a call for warranty on a product. If they're using those terms and you hear them as a facilitator, write them down as they come in. Don't make the mistake at that moment in time. At least that's my opinion. Don't make mistakes. Oh, but you talked about customer before, now you're talking about client. Is it the same yes or no? Because the templates will guide you to the moment in time where it's the right time for saying, oh, we all categorize this person. And now we see customer, client and kund. Is it the same yes or no?

Yeah, I agree. I think when you've got the stakeholders in the room and you ask them a question, you can watch them think about it briefly and then they'll start talking and then they will naturally run out of words and they will stop and think some more and they will go to start talking again. And that's because they're trying to give you everything. And there's this natural break where you go, I've got the most important things at the moment, I can get more later. Now's the time to figure out what to do next. But I'm with you. If they go customer and client, and as they're talking to you about their business, about the business processes, you go, oh, is customer and client the same? You now interrupted their flow and you're going to find it hard to go back and get that flow again. So let them talk, capture it down and then go back and deal with the next bit that you need to deal with, which in your case is grouping and de duping. That's effectively what the CBC canvas is there to do.

Basically, that's what it's doing. I experienced doing training, but also in workshop. But when I'm doing training, I have other people trying to run workshops kind of thing because they're learning it. And we have in one of our cases, and it's about a bookshelf with a coffee corner and some pastries, etc. And the business case is just something very simple. Customers comes into our bookshop, they buy books and newspapers and they can get a coffee and a tea and a pastry. What I see happening that people writing down on the CBC list, they're starting off with book and then oh, but wait a minute, it's also see newspaper and coffee. Oh, product. I said as soon as you make that general idea about product, instead of using the terminology they're using, you can almost literally see the business people standing up and walk out of the room. Because what you're telling them, I know better how to organize what is going on than you are. And I'm not taking you serious. And those are really two mistakes you don't want to do as a facilitator. Just write them down. And that's the cool thing about the CBC canvas where we have all the terms together. Then you see, oh, I see a book, I see newspaper, I see coffee, I see pastry, I see tea. They're all things, right? They were all categorized by things. Do you really want to see them on that level or can we do some grouping? Can we call it a product or can we have it a edible products and non edible products or whatever terminology we're going to use? Is that the term we want to go or do you want to use the terms you just used on that level? Yes, we see, of course if we call it product, we still see it was a flat white or a cappuccino or double espresso. And we see that it's New York Times or it is the whatever you want to do. We still see the names, we can still make distinction and we can have this newspaper, this is a book, whatever. We can still see that on your report. It will show, but it more like how do you calling it? How do you treating it? Do you treat a book different than a coffee? Yeah, of course. Because a book is printed up front and a coffee is created on the spot. Hopefully.

I agree.

Right.

So CBC list, CBC form, CBC canvas, Take me home with the other three.

And then. Yeah, and then I think from my perspective when looking at modeling, the hardest part is all about relationships. Let's be very honest, getting the core business concept is easy. It's. Even if you go technical, it's pretty easy. But getting the relationships right and getting that one going, it's way harder. And that's where on the CBC list we have our category of events and our first idea about going into the the relationships going so the MBR parts natural business relationships. We say let's take one event, a sales event. Okay, what are the business concepts directly involved with that sale? We have a Canvas for that one, it's almost looking like the CBC canvas, but instead of swim lanes, it only has a place for one event. One event only for this event. What are the CBCs, which business concepts which are directly involved? We see that in the person line we have a customer employee. In the place we have store, and in the thing we have, let's say product, very simple. And someone says, yeah, we also have a supplier for the product. Yeah, but is a supplier for a product directly involved with the actual sale? Because let's be very honest, if it's not on the shelf, if it's not being supplied, you cannot sell it. So a supplier, yes, it might be important, but not for the sales event. And then what we say out of this canvas, the event canvas, we say there should come a relationship between all five business cons we all just named. Then we need to find out is that the correct relationship. And then the grain comes in or cardinality. Or we said, you know what, let's use it as another template, a very fun one. It's just basically a table. There's some more to it. We can have some metadata to it, but basically it's a table. Say, let's fill in some example records. And I do this with business people, right? Let's give me some examples of a sale. And just using a sales id, identify most times a number that's for instance, for a customer. I don't want to see customer one or a technical number. Just fill in, who's the customer? Customer. Shane, Who's Champco? What's the product? Flat white. Can Shane buy within the same sale? Multiple products? Yeah, on the same sale. So let's go 501 customer chain, MP, Remco, double espresso, et cetera, et cetera. And then you see, we are repeating for every single product, we are repeating all the other parts. We basically, out of the event, we said it's all one. And then we know from what we're looking for in our ensemble modeling patterns, we need to get that product out of the equation and have its own relationship to the event. And that we do with our MBRFORM Artifact. And the MBRForm artifact is basically example records. And we have a complete breakdown and it can be 3, 4, 5, iteration before you have all the correct relationships going again in a workshop. And most of the time it's a second or third workshop. We get that one going and we get the information, and then we have that information. We know what the actual relationships are going to be. Then we can just put them on the board. And of course we are trying to communicate with business people. We're also trying to communicate with people who needs to in the end create data marts and the dashboards and the reports. So what we do is summarize the information we got from the event canvas from the MBR forms. We put them on MBR matrix, which in the end looks pretty similar like a bus matrix or bi matrix from Kimbal. And it gives you the idea about I probably need to create for reporting perspective because this is my transaction, it has a name and this is everything involved. I probably need to create that one for my data much as well for to be able to create a dashboard because let's be very honest, if you're looking at Kimball's idea about factor dimension, which I think from a reporting perspective is still the way people are thinking. And even if you are not really creating a fact table and dimensional table, but do everything in one big table, as Rick van der Launch uses say one attribute set interface. If you still want to do that one, you still need to know what are the metrics. So what you want to measure, which basically what's coming out of your event out of your transaction. Right. That's where you have your measures going and what angles one do you want to look at that one. But basically what we're doing as well.

Yeah, I use slightly different language now. So when I'm coaching people or teaching them, I talk about facts, measures and metrics. So for me, facts are the numbers that are generated in the source system. It's the system captures that fact order quantity 20. That is a fact. It's indisputable because it was typed in. Then I talk about measures are effectively calculations. We do on it in terms of sums, averages, those kind of things. And then metrics calculations we would normally do in Excel as a formula. So this divided by this times this. Right. I used to get really grumpy about people couldn't describe what the differences were. So when that happens and I can't find anybody else's, I effectively go and find mine.

Shane, I'm going to make that one from you.

Yeah, it's fine. And I think we both use data by example. We use it a lot. So people should experiment with the power of that pattern by asking for real world records, our stakeholders can give it back to us really simply and then we get so much insight around what's happening. So yeah, it's a very powerful pattern. Okay, so let me just play it back to you. Six artifacts Six templates. So the first one is CBC list, where we're basically listing terms and categorizing them. Number two, CBC form, where we're effectively providing detail or context about each of those terms. And then you've pulled out all the standard context and details we typically want to need and that's what's on the form. Number three, CBC canvas, a way of taking those core business concepts and grouping them and then understanding when we need to dedupe them. Number four, event canvas. Effectively we are now understanding the events that happen in the organization and how they relate to the core business concepts. So which core business concepts are involved in this event? Number five, we then start doing data by example. So we start getting examples of data to fit that event and CVC model. Because we're looking for a understanding of some terms, we're looking for confirmation we've got it right. And then if there's anything that turns up, like you said, can I order more than one product? Can I order more than just a flat white when I'm in the store? Those data by examples give us context. So as data people we can go, ah, okay, I can see the pattern. It's now headed detail, parent, child, unbalanced, hierarchy. All those things we know, but they don't and they don't care. And then the last one is MBR matrix. We're effectively summarizing everything we've got into a simple map so people can actually understand what we've done. Is that right?

That's absolutely right. And that's also where the MBR matrix comes in place. But what I was talking about, we have our events data by example records, but for instance that supplier on the products. If you do the MBR matrix where everything coming together, we all have the terms already in the column headers. And then you see I have a supplier column because it's very important. Supplier, it's important dimension it. But it's not involved in any of the other part where we are discussing it. So it's a loose end, some there and then we can say wait a minute, supplier is important, but how is supplier related to what we discussed before? Supplier related to the product? Because they are delivering basically delivering product. Okay, one delivery. Is that a new event we need to discuss or it's just a relationship? I have Supplier, product relationship. That's just it. So that's why the MBR matrix is not only the handover point to the dashboarding and like the BI matrix, but also gives me idea. I have terms which I didn't use or never have related to any of the events that I talked about before. And with that information, I can come up with all the other relationships which are in place and are important. And I have one other thing during the workshops and I think you might experience the same. Sometimes you're hearing some stuff and they're explaining it and you don't know. Do I hear this correctly? Yes or no? Am I understanding it? What I do is I'm making a drawing on the board and my drawing is hideous, I think, but it's fun enough for people to understand. I start drawing and richly. I draw small people and I draw a desk and a computer on it and I draw a form or a truck or whatever I need to do to draw the business process as how I see that one. Just to have people say, oh, you're wrong or this is going to happen or whatever. And the first thing in mind when people say, yeah, this is not correct, it's different. I give them the marker do it yourself.

That's a great idea for an LLM. You can actually take a photo of the word you wrote in one of the templates artifacts and get it to draw a diagram of the business process. And we're going to come on to that next. But before we do so, I use the term core business event and core business process interchangeably. And it is the relationship between those core business concepts. The customer orders product, customer pays for order, store ships product, or do they ship an order, customer returns product or do they return an order? So that's how you see it. Events typically being quite closely related to to core business processes. Not administration processes, not accounts clerk approves invoice, but actual core business processes. Like back in the old days of bpm, business process mapping. These are the kind of things that we are treating as events. Is that the same as you?

That's the same. The only thing for me, I'm still calling it a core business concept because it's a term, but it's categorized or identified as an event. And I don't want to introduce another term what you're saying, right? I have core business events and core business process and they're kind of interchangeable. Basically you're going to say I'm introducing two terms for basically the same. And effectively what you're saying as well, right? It is something which is very important. So in your terms, it's for you, it's also a business concept, but because it's an event or a process kind of thing, I'm going to call it differently now and we try. I think if I understand, I think I understand correctly, we just go, it's a core based concept. It's something where the business says for me this is important, I want to know more about, I can define it, I can identify it, I can relate all the kind of fun stuff and it happens to be of the category event. Fine.

Yeah, I think we do it the same way because for me the driver of the event, the order, the payment is the core business concept. And I do flip in between core business process and core business event. And I know I shouldn't, but I haven't got out of that habit yet. Before we get on to LLMs, those matrixes very valuable for scoping iterative development. And what I mean by that is in that example you used, if I can see in the matrix that for the order event there's a bunch of core business concepts that are really important and supplier is not one of them. That means I can deliver the data for order and that event and the core business concepts without having to bring supplier in. Supplier is valuable, but it may not be valuable right now. But if I had a look at a delivery event, then okay, I'm going to focus on supplier and probably not customer. So when we're looking at those matrix, they're really good for being able to put circles around things and say we can deliver that bit first and it has value and then we can extend it out. And that's part of the reason that we do it because it gives us a map and we can then use the map to tell a story. Is that how you do it?

That exactly the same. And of course because I'm using when I'm going to a physical model, I'm going to data vault or anchor or focal any of the ensemble patterns. That's basically how it's working. Because there's also a very agile modeling approach, right. I can start off very small and I just can bowl on top of that one without changing what I already have. And I think that's very important and that's the matrix will help on that one as well. Say okay, this everything we got out of this first workshop or the first business process, business function, this is what we're getting. Where are we going to start? What's the first step? Number one we need to do interestingly enough by the way, because we now talking about starting off from a starting point, right? There's nothing we greenfield we just go in. I started to realize and think more and more and it's working when I'M coming into another part of the organization, another business function. What are you going to do? And my approach at the moment is I start from a blank slate. Again, completely blank. But if I hear the same terms, I just write them down and categorize them to make sure. And then in the next workshop or maybe at the end of the first workshop, I will definitely discuss, oh, you are talking about a customer. But the business function before, as a customer, do we have the same idea? Do we have the same definition? Is your customer and their customer, is it the same kind of customer? Yes or no? So I try to start off with blank slate always instead of just giving, oh, I already have these terms. Are we missing something for your business function? Because that's very scary and especially because people in the organization you probably your experience. Well, right. They in different part of the organization, we're using the same term for different things. And that's scary.

Yeah. And I think it's also about buy in. So why it takes, in theory, more time for you to run the workshop from start with a stakeholder in a different domain compared to just giving them a list. What we know is when we give people the answer, they don't engage. They look for a couple of spelling mistakes. They may look at it and pick out something that you've missed, but they're not engaging, you're not learning from them. And you certainly, like you said, you don't pick up the differences, which is the important part of data because we know that customer is never customer as soon as we cross domains. All right, just to finish out, I know that you've been experimenting with LLMs in this space as much as I have. So do you want to talk a little bit about what have you been doing? How's it work? Have you found it? What's the point?

What I found out and yes, I'm experimenting that every time and I have some resting pause in between because I have some different stuff to do as well. And then I'm picking up again and I'm surprised that there's so much going on in the world. There's new tools coming in and there are new ideas coming in and the models itself are improved. There's so much going on. But what I have now we have our own data modeling GPT. And what I found out is that the Elmo probe we just discussed. Right. With all the templates. Basically, because this is how we humans work best. We can just organize small steps and they are very small steps with very small, structured, organized steps. That's basically how the LLMs works as well best. And so I created my own. I'm using ChatGPT at the moment but I also looked into Perplexity, which is a very interesting one by the way. Claude will do the same kind of stuff, is basically saying this is my bias because I'm introducing bias. This is my knowledge and they are all about the ELM process, they are the templates. There are some examples about my modeling process. Only use my bias, only use my information and go from there and say here's a business case, find out what are my core business concept, categorize them, give a small definition and give me the event canvas. Basically that's what we're doing and that is just there enough to help to assist out of your first workshops, to assist the model, the facilitator to say we missed something or I need to ask more questions on this one or because that's also what I did. Oh, and by the way, what question do I need to ask the business next time? So I'm getting three to seven questions back from the lm said oh, you need to ask this one or this one. So this gives the idea about how it's working at the moment. It will be publicly available, open source, free to use for everybody somewhere the next couple of months we're going to deliver it free on ChatGPT. Not sure how it works on the other stats as well like indeed Perplexity or Claude, but I hope if it's available we use the same kind of pattern because they're all the same. And I think really interesting what's happening. I think it's doing interesting stuff. I'm not an expert. I know maybe a little bit more than a whole bunch of people. I know way less than a whole bunch of people. So I'm not an expert. I'm doing what I'm doing and I found out that the ELM approach for data modeling on an LLM works pretty well. So what is your experience on the LLM? Because I know you're doing fun stuff.

It's the same that where we have a set of patterns and templates that have been proven and they do one thing really well and they have a language and you have examples. Effectively that bundle of knowledge can be given to an LLM and it can use it to act like you. And then the trick is what's the use case? So what do you want to achieve? What do you want a person who doesn't have your knowledge to actually be able to do as if they have your Knowledge. And so for me it's guidance. I talk about three things. I talk about Ask AI, assisted AI and automated AI. And for me this sits in the ask or assisted, it doesn't sit in the automated. So I'm not a fan of the idea that a person with no knowledge can put something into an LLM and get back a data model that matches the business organization's processes and events and somehow will take data out of SAP and Oracle E Business suite and Salesforce and transform it. I don't think it can do that yet, but it is very good at taking our knowledge and making it available to somebody else when we're not. And I think for me that is a proven use case and the more people that can do that, it's great.

Yeah. By the way, maybe your experience is same, right? I gave a business model to Claude to chat to copilot and just say create a data model without any extra information. Here's a business case. Create a data model. It's coming back perfectly fine with, with a PR diagram you say oh, and I want a visual of course. And even if I say oh, by the way, make a data vault out of it, it's nicely is going to take basically the er diagram and says oh, every entity should be blue and yellow for a hub and a satellite and all the lines should have a green box on top of for the relationship, for the links. It's doing that work. But basically the scary part is that indeed people are doing it and think oh, this is correct and this is because it's looking great and it's correct and I just push the button and go into full blown production. And that was happening with tool vendors at the moment they are introducing AI as assistant for data modeling and they basically say give me the information and we will create a data model and all the script and all the loading patterns and we do everything for you just push the button and say if it looks right just go into production. And that's scary because let's be very honest, data modeling is art. It's not just a technical thing because then you get a technical transformation from source system to another, from one modeling pattern to another modeling pattern and just a technical transformation and doesn't have to do anything with real data modeling.

I think for me data modeling is not hard until we say model an organization in a way that's fit for purpose and then make the data systems that capture the data fit that model and that's where the effort is because those source systems have been designed to run In a way that works with the system, the transactional system. They have not been designed to capture data that matches the way the organization works. And that's why data modeling is hard, because that's actually a hard process. I think I might get there. I think once the knowledge of how to model a business organization, the process is a little bit more refined and how the systems are relatively templated, then potentially it can do it. But right now it should just be an assisted process.

I think what's interesting and I think that's something I'm looking at with our data Mullen GPT. Right. It's giving input from a business case and with tools like Firefly or whatever, automatic note taking, you can just have it run during a workshop. Normal works as we normally would do, just run it and just after that one let the Firefly or the other tooling just capture the information, capture the essence and create a written report out of what has been said, including sentiment. Push it into my data modeling GPT and it will come back with these are the business terms, these are the event person page, whatever this is, event canvas. And it might even come up with a data model or it now not doing it. And I still think I just want to have that own drawing myself because I want to get in my fingers. But also be interesting because then you have the business view on the data, on the information. Right. This is how we are modeling data. And then of course you have. I know that you're working that one as well, right. Look at all the legacy system we're having, all the system in my organization. Find out what is the metadata, what's going on in that information. So you have basically a map of the sources, how they actually are generated by AI and LLM. We have the one generated by AI and LLM out of the workshops. So how do the business sees them? And then we should make the connection. And I think that's one of the hard parts we need to come up with. But I think that's doable as well. Just one push button, go. I think there will always be an iterative process just like we are doing real life right now.

The example I always use is you go look at Stripe subscription management payment system and you go, good. So it's fairly obvious what a subscription. If you're a software as a service company and you use Stripe, it's pretty easy to count that core concept of a subscription. Until you work with three organizations, three different companies, and they always have a slightly different rule for what is a subscription.

Yep.

And that's the term. And the number that we have to give is their definition of what a subscription is. Now, we can argue whether that's good or bad that they do that, but that's what they do. That's where the complexity comes in. So small steps. If it adds value, if it assists you, if it helps you review your work, if it gives you ideas, if it gives you feedback, if it makes you think about something you haven't thought about, if it reinforces you're doing the right thing, that is all good and that's what we should use them for. And they will get better over time and we'll be amazed. As we were couple years ago when ChatGPT turned up at what the machine can do that we used to do. So an exciting time. All right, so just to close it out, if people want to find you, if they want to find the templates.

Elmstanders.com Elmstanders.com is the one where you can find the templates. Another very, very last moment excitement thing. They can also buy my book where everything is being written on excellent.

And they go to Amazon for that. No doubt.

They can go to Amazon or Technic publication and it's called Free from Storage to Solution and ping me on LinkedIn if they want to get more information on that one as well. But it describing the whole process on how workshops need to be set up, what you need to invite, how the workshop run. It's all about the templates, including an example case completely written out, an ontology in there. So all the fun stuff.

And because we're data people and we're the masters of temporal data, there's a high chance that this podcast would just happen to go out when the book hits Amazon.

Scary enough, it's already out on Amazon and on technical publication at the moment. I wasn't anticipating it going that fast. At last bit I was writing a book is hard work. I think I'm working for it four or five years now in a row. And I was thinking, okay, I now have my document ready. Now all the other stuff is going to happen for a long time. And then it was rooms there.

Excellent.

All right.

Hey, thanks for coming on the show and I hope everybody has a simply magical day.

Yep, James, have a great time. Cheers.

And that Data Magicians was another Agile Data podcast episode. If you want to learn new patterns that you can apply to craft your own Agile Data way of working, head over to agiledata IO.