ELM Patterns Templates with Remco Broekmans - Episode #61

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 Lukmaans.

Hey, Remco, thanks for coming on the podcast. Today, we're gonna 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, Remon. I'm living in the Netherlands near Rotterdam. I work for Genesee Academy mainly. I'm doing training on Data Vault and the ELMA 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's basically my job for the for the past, I would say, 6, 7 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, the Elm approach. We do model storming. Of course, we nicked it from Laurence Koor's ideas as well as others, as your ideas, right? 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 Laurence'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 are leveraging, and I think that's the way we should do it. Laurence often talks about the 7 W's, and for you, I think there's actually like 2 B's, but maybe a third because 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 were never a barista, right? That's the one that's missing.

According to my wife, I drink so much coffee, I am a similar with a barista. No, 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, to either problem solve together or to elicit some requirements or some shared understanding. And I call it pattern storming. I think you and Laurence call it model storming. 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 this 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 strobe rifles. 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'm just thinking, I need to do something different. And I think the most important thing is, before you can do brainstorming or model storming, 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 is all about? And since I'm new and people, business people, love to talk about what they're doing, are most of the time perfectly willing to do. And I try to stay away from the terminology like conceptual model or logical model or even physical model. They don't care. So that's why I need the first time to really get the people in for an hour and a half, 2 hours, 2.5 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 cross-feed 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, hey, you mean person? Because if they would, would meant to talk about persons, they would say, yeah, we have persons in our organization. Use their terminology in, in every single bit and every single sense. That's where my, what I think good workshops start with. Get them into the room. And yes, of course, I always bring stroopwafels 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 2, 2.5 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 to 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 their people, their volunteers. 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 a 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 we're 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 is being done. Because the worst case you can do is say, "Ooh, 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 during your workshop says, we are having an issue because it took, takes too much time to look up if we already know a customer, so we're going to reenter 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 here, 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. A 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. And what you say, you can get people in for a good 2 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 the 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 2 or 3 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 modeling, 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 the 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, refine should be logical data modeling and design, of course, the 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 the 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, we talk about getting ideas or improvement or using work from someone else to improve, like Laurence's 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 Casetalk. 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 cryptical 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, oh, I have a customer is related to a product and why? Because the customer bought the 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 boxes 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, "Ooh, 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 has bought product. Customer has a warranty claim on the product. Customer likes the 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, yeah, invoice line, everybody in the organization knows invoice line, but it's an IT term. We in IT world introduced that term because we need to have that— in third normal form, we'd say associated entity between invoice and the actual products or services. And there can be many of those. So there's a many-to-many relationship. We need to have that associated entity. Ooh, we need to give it a name. Let's call it an invoice item. And everyone in the organization is called 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 concept 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 and say, ooh, we have a whole wall of nice photographs of all our customers and Shane's coming in and we're looking at, yeah, 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's 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 wanna be able to manage our orders. We can identify an order and we typically wanna 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 wanna 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.

We are aligned. 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 it, the templates later on. For us, those are events or transactions, our 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 it 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 an 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 the very simple, my 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 6 artifacts, we start with artifact 1, and we end with artifact 6, 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 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, they can help me. And 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 1, '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 is that, '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 1 hour of your 2-hour workshop finally agreeing that there is no definition of customer and we can't actually identify them easily because there's 5 definitions of customer depending on which business unit you sit in.

Yeah. And that's, 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. Then 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 bat. And in one of my templates, basically it's the first one after having writing 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 bat. Okay. What's a bat? Is it an event, a a person, a place, a thing, or something else? And of course, my marker was 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., 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.' Initially, we had the same term, but two different definitions. We got that argument in our workshop. Small argument, but 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 bed, 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, of course, oh, and please refine the definition next week because we are 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. 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, if 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 6 artifacts of Elm. Do you want to talk us through those?

Yeah, of course, no problem. We have 6 artifacts and basically the first 3 are focused around the core business concepts. 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 write down the words and then I'm going to have columns next to it, so swim lanes. 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 1. 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 customers. 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 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 1, so basically it's a list with the categories, swimlanes, 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 1.

Those templates, those artifacts are open source, right?

Yeah, they're completely open source. If you go to elmstandards.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 BitLocker products which are similar what we are having on the first template or, well, 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. So it's a very simple one. And the template itself, if you download, it's just one sheet. At least 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. An 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 is also known as different products or synonyms or hierarchies is 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 ones we can fill in. So that's why it's also some kind of homework. But that is TVC list. The wording and the categories is template number 1. Template number 2 is what we call CBC form. And they are on one sheet. So that's fun stuff. As a facilitator, after the workshop number 1 and number 2 and 3, if needed, I'm creating that one for people. So that's why I can give that homework. They 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 was in 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 5 swim lanes. So for event, person, place, thing, other concept, has the 5 swim lanes. And we just use Post-its to say, ooh, we found out in the category events, these are all the business concept, business terms, business concepts we named. So we put them in just as they come in, etc., etc. 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 kunde. Oh, 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 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 deduping. 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 that because they're learning it. And we have in one of our cases, and it's about a bookshop with a coffee corner and some pastries, et cetera. And the business case is just something very simple. Customers comes into a 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, 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 everything, 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 as 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 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 a 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 a— it is a newspaper, this is a book, whatever, we can still see that on your report. It will show, but it's 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.

All right, so CBC List, CBC Form, CBC Canvas. Take me home with the other 3.

And then, yeah, and then I think from my perspective, even 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 CVCs, which business concepts, which are directly involved? Oh, 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, but you 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 5 business goals we all just named. And 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. So 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 it. Most times it's a number. Let's, for instance, for a customer, I don't want to see customer 1 or a technical number. Just fill in who's the customer. Customer is Shane. Who's the MP? Well, it's Remco. 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 Shane, 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 are 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 MBR form artifact. And the MBR form artifact is basically example records. And we have a complete breakdown, and it can be 3, 4, 5 iterations 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 need to, in the end, create the data marts and the dashboards and the reports. So what we do, we summarize the information we got from the event canvas and from the MBR forms. We put them on an MBR matrix, which in the end looks pretty similar like a burst matrix or BI matrix from Kimball. 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 model as well, for me to be able to create a dashboard. Because let's be very honest, if you're looking at Kimball's idea about fact and dimension, which I think from a reporting perspective is still the way people are thinking. Even if you are not really creating a fact table and dimensional table, but do everything in one big table, as Rick van der Laan used to say, one attribute set interface, you still want to do that one. You still need to know what are the metrics. What you want to measure, which basically what's coming out of your events, out of your transaction. That's where you have your measures going and what angles one do want to look at that one. Well, that's basically what we are 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 define my own.

Shane, I'm going to nick this one from you.

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. 6 artifacts, 6 templates. So the first one is CBC list where we are basically listing terms and categorizing them. Number 2, 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 3, CBC Canvas, a way of taking those core business concepts and grouping them and then understanding when we need to de-dupe them. Number 4, 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 5, we then start doing data by example. So we start getting examples of data to fit that event and CBC 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 header-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, where 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 comes together, we all have the terms already in the column headers. And then you see IFA. Supplier column, because it's very important. Supplier, it's important, dimension it. But it's not involved in any of the other parts where we are discussing it. So it's a loose end somewhere. And then we can say, wait a minute, supplier is important, but how is supplier related to what we discussed before? Supplier is related to the product because they are delivering, basically delivering the 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 an 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, is hideous, I think, but it's fun enough for people to understand. I start drawing and originally 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.

It's a great idea for an LLM. You can actually take a photo of the words you wrote in one of the templates artifacts. And get it to draw a diagram of the business process. And we're gonna come onto 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, right? 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 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, it, it, that it's, I'm still calling it a core business concept because it's a term, but it's categorized or identified as an event. Right. And I don't wanna introduce another term, which you're saying, right? I have core business events and core business process. And they're kind of interchangeable. So 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 business 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 are 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 gonna 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's 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 build 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 is everything we got out of this first workshop or the first business process versus 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? We have nothing, we greenfield, we just go in. I'm starting to realize and think more and more, and it, 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, ooh, you are talking about a customer, but the business function before has 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 experienced 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, there's so much going on in the world. There's new tools coming in and there's new ideas coming in and the models itself are improved. So there's so much going on, but what I have now, or we have our own data modeling GPT. And what I found out is that the Elm approach 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. It's basically saying, this is my bias because I'm introducing bias. I'm going to— 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 concepts. 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 modeler, 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 3 to 7 questions back from the LLM. 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 sets 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 it's really interesting what's happening. It's, I think, 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 had your knowledge? And so for me, it's guidance. I talk about 3 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 eBusiness 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 are not. And I think for me, that is a proven use case. And the more people that can do that is great.

Yeah. By the way, maybe your experience is the same, right? I gave a business model to Claude, to ChatGPT, 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 a ER 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, it's 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 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's what's happening with tool vendors at the moment. They are introducing AI as an assistant for data modeling and they basically say, give me the information and we will create a data model and all the scripts 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 hard. 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's hard because that's actually a hard process. I think it might get there. I think once the knowledge of how to model a business organization and 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 modeling 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, whatever, this is the 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 3 organizations, 3 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, right? 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 of 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, elmstandards.com.

elmstandards.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 Publications, and it's called From Stories to Solutions, and ping me on LinkedIn if they want to get more information on that one as well. But it's describing the whole process on how workshops need to be set up, what you need to invite, how the workshop runs. 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 are data people and we are 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 Techno Publication at the moment. I wasn't anticipating it going that fast at the last bit. I was writing a book, it's hard work. I think I'm working for it 4 or 5 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— boom, it's there.

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

Yep, same. 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.