Adam Dymitruk, CEO and founder of Adaptech Group, joins host Jeff Doolittle for an exploration of the event modeling approach to discovering requirements and designing software systems. Adam explains how the structured approach eliminates the specifics of implementation details and technology decisions, enabling clearer communication for all stakeholders while keeping conversations focused on the business opportunity. Using concrete examples of event modeling in practice, they examine event modeling in the context of other related approaches and methodologies, including event sourcing, event storming, CQRS, and domain-driven design.
Show Notes
From the Show
- Event Modeling
- Event Sourcing
- Event Storming
- Command Query Responsibility Segregation (CQRS)
- Domain-Driven Design (DDD)
- Behavior-Driven Development (BDD)
- Event-Driven Architecture (EDA)
- Storyteller
- Iron Triangle
- Conway’s Law
- Saga Pattern
- Adaptech Group
From IEEE Computer Society
- The dark side of event sourcing: Managing data conversion
- Applying Event Sourcing in a ERP System: A Case Study
- A Scalable, Reactive Architecture for Cloud Applications
- Improvement and Implementation of a High Performance CQRS Architecture
From SE Radio
- Episode 249 – Vaughn Vernon on Reactive Programming with the Actor Model
- Episode 447 – Michael Perry on Immutable Architecture
- Episode 470 – L. Peter Deutsch on the Fallacies of Distributed Computing
- Episode 520 – John Ousterhout on A Philosophy of Software Design
Transcript
Transcript brought to you by IEEE Software magazine.
This transcript was automatically generated. To suggest improvements in the text, please contact [email protected] and include the episode number and URL.
Jeff Doolittle 00:00:16 Welcome to Software Engineering Radio. I’m your host, Jeff Doolittle. I’m excited to invite Adam Dymitruk as our guest on the show today for an exploration of Event Modeling as an approach to requirements gathering and system design. Adam has over three decades’ experience in information systems, software development and architecture, along with Open Source platforms, open standards, and digital sovereignty. In the last 15 years, he’s focused on ledger based and event driven architectures. He is the author and inventor of Event Modeling. The approach is revolutionizing how information systems are described. Adam is also a core contributor to event sourcing and CQRS theory and practice since 2008. This included introducing PAPQS to the approach and helping with the Microsoft Patterns and Practices CQS journey book. He is one of the top 1% contributors on Stack Overflow for version control, including holding one of the three gold badges on the subject. Over the last seven years, he has built a successful consultancy specializing in authoring event driven systems. Adam, welcome to the show.
Adam Dymitruk 00:01:19 Thanks Jeff. Glad to be here.
Jeff Doolittle 00:01:21 People in the software industry have been gathering requirements and designing systems for decades now. So where does the need for a different approach arise?
Adam Dymitruk 00:01:30 Oh, well it arose for me by trying to do a lot, as in my introduction you said, I had my own company to start and as any startup knows, funds are hard to come by and I just noticed the overhead of specifying software was quite high. So, the magic moment happened when I noticed if we think about systems from the events perspective, then we are able to do more with less. And so out of that realization spun out a new format that was lighter weight and still gave all the benefits of all of the other practices such as user stories, et cetera, that you may have going all the way through as we’ll cover in the episode down to project management, maintenance, et cetera.
Jeff Doolittle 00:02:17 So Event Modeling sounds like in this history of kind of an eventing approach as a relatively more recent development. You’ve been doing it for a while of course, but it’s probably new to some of our listeners as well. But how does it kind of relate when we think about the history of information systems, like how we got started with collecting and defining information and then how does it kind of fit in that flow?
Adam Dymitruk 00:02:36 Right. So good point. The information systems are nothing new to humanity. We’ve had information systems for thousands of years long before computers. And so I often talk about this mismatch that we go through as we start using computers in the very limited form that they allowed us shortly after vacuum tubes and when transistors and integrated circuits happened. I think in my mind anyway, I wasn’t born yet, but when I look at the type of work that was described and the systems and how they worked and how they’re described, really focused on this incredible jump in productivity, the transistor gave us an incredible boost to the processing speed. And we talk about Moore’s Law all the time about how ships are getting faster. So that was a real shot in the arm for information systems to have everything digitized. And unfortunately, we didn’t have the same shot in the arm for storage.
Adam Dymitruk 00:03:31 And so we lost this ledger way of thinking about information systems because up to that point it was really record keeping that allowed information systems to scale and to be organized, to find out why things aren’t going right, et cetera. So the system of account was almost like information systems were accounting systems for information instead of money. This problem, I mean this, it’s not a problem, but this real great advantage of being able to process data really quickly showed a disadvantage of having a really expensive storage. And I always use the example of the 10-megabyte IBM hard drive that cost a million dollars back in 1954-56, I forget the exact, there’s a very famous photo you can look up online if you just look up IBM hard drives in the fifties. And I think the thing took $30,000 per month to run and it was the size of a small room.
Adam Dymitruk 00:04:23 So obviously if you keep every record of every state change as an event, that’s not happen. Your boss is not going to allow you to buy five of those. He says make do with one. And so that’s where we started, erasing data and data normalization was incredibly important in those days because of this mismatch of how quickly information was produced versus how expensive it was to store information. So, in the grand scheme of things, it’s this mismatch that we’re going through. Of course, now, in your phone you have this ability to hold so much information in your phone. You could run a global company from the fifties in your phone. No problem. . So, the Moore’s law on the side of storage has definitely caught up in recent decades, but we’ve definitely set a bunch of ruts in the road that painted information systems that were digitized as different than information systems that weren’t digitized. And I think it’s time to move back because we’re by default throwing information away, which is not a good default to managing information systems.
Jeff Doolittle 00:05:23 Well let’s take that and help our listeners first with a brief definition of what is an event when we talk about Event Modeling and then we can connect that back to some of the things you’ve shared about data storage limitations and sort of the history of things. What is exactly an event?
Adam Dymitruk 00:05:36 Sure. So an event is a really good way of saying fact. There’s many, probably many different words one could come up with as to what happens on a timeline when we’re automating information systems. So, if someone signs up for a website or someone approves an insurance policy or someone files a claim for insurance, these are things on a timeline that happen, and they capture certain pieces of information. Now our technical minds go straight into like what tables do I need to update so that these queries come back with the right thing that’s moving way too far ahead. If we think of the way information systems used to be, back to my previous point, we see that this fact stored on a ledger is really kind of a raw data that’s still not formed by any opinion and in its raw state, this fact or event can then be transcribed to whatever your needs are.
Adam Dymitruk 00:06:30 And so we get to do a lot more with events compared to what we do with what we think the event is and forcing them into traditional, I use traditional in the very short term, obviously our digital traditional format of most likely table structures in RDBMS where we’re quite opinionated as to how it’s supposed to be divided. So it’s kind of a move back and, events are also something that are much more human in terms of they’re the components of a story and their brains work really well. I go into this quite a bit in a lot of what I teach is to really use mechanisms that are really human and more friendly to human. And you see this in storytelling in the linearization of what’s happening. And of course in the text sector we’re quite inundated with I guess activity diagrams and flow charts and graphs. And graphs aren’t easy to remember for humans.
Adam Dymitruk 00:07:26 It’s stories that people remember. And memory is quite important in communication because what good is communication if you don’t recall what was communicated, right? It’s like, oh, this person speaks eloquently describing this graph, but then when I go back to my desk I have to keep referencing that graph again and I have a mismatch of what’s in my head versus what was communicated. And so having a story aspect to everything you’re trying to communicate allows the recollection of what was communicated to be higher. And I think that’s quite important because it does limit the amount of interactions that are needed and so you can focus on high quality communications and use the rest of your time to actually do work. So, we’re all kind of death by a thousand meetings in today’s industry and so anything that can help remove that problem will have in my opinion something that allows better recollection and anything that’s discussed or collaborated upon to have a better longevity in their cognitive low and naturally fits in their heads.
Adam Dymitruk 00:08:25 So that’s kind of like the human aspect of why events are important but more the other good side of events is that they also are a really good home for information from the digital perspective. You have immutable storage, all these really good technical aspects for easier caching. You talk to anyone about functional programming and immutability, they’ll tell you a hundred different benefits and so yeah, why not just obviously use that for everything else as well. And if the two go hand in hand, you’re also going to encourage a much better approach to managing information in on the technical side. I hope that answers it.
Jeff Doolittle 00:09:00 I think it answers a lot. That might spin up a few questions for listeners as well and I’ll add some links in the show notes to some of the concepts that you described, functional programming, immutability and things of that nature. But one of the things that’s particularly interesting to me is first the idea of how this is a human-oriented approach, which reminds me of one of the things I’m apt to say when I present, which is we’ve discovered the problem and the problem is people and the solution is people and that’s the problem. But what it sounds like you’re describing with Event Modeling is we’re actually empowering people to be able to have something that fits the way that the human mind works as we’re tackling some of these problems. Is that correct?
Adam Dymitruk 00:09:37 Yeah exactly. So like I said, something that’s more easily digestible by humans is much better. So Event Modeling allows you to basically look at a storyboard like you would for a movie with the top swim lanes being what the actors, what the scenes are and what the actors are doing and what the key frames are showing key points in the story to get the whole movie to gel together. But down below you have the plot, which is the data. You could have, I always pick on Kevin Costner and Water World and , but you can have a very beautiful movie but the plot is just very bad and you’re not enjoy it, right? So you got to have both. That’s kind of like a very simple way of me introducing Event Modeling to people is, think of a movie, storyboard and both are important, but fundamentally for this communication, if the reality is that a lot of us are visual and another, the other half of us is really analytical.
Adam Dymitruk 00:10:30 So you have to have both to really tell instruct people or explain to people how the system works or how your imagined system is going to work when you’re done with the project. And that’s to have that vision, an end-to-end vision at least so that everyone is pointing in the same direction. And, and it requires that view both from the visual aspects for people that are more visual or even their jobs require them to be visual such as designers, UX folks, et cetera, to the people that are on the architecture side that need to know where the data lives and their SLAs and when do things move from system A to system B and how does that data transform? And of course, this is all done by example. So the other part of Event Modeling is that it heavily does rely on the history, the successful history of specification by example and behavior driven development which is, takes the approach of show enough examples with real data real screenshots of what things are supposed to look like along a workflow.
Adam Dymitruk 00:11:26 And people are smart enough trust those people to interpret that example as a good enough specifications because our minds are actually quite good at filling in the blank. In fact I keep talking about stories and why those are important, but our brains are quite slow processors and we do a, but they’re quite smart processors, they’re slow processors but they’re incredibly advanced in being able to fill in the gaps. Our eyes are not cameras that are 104 megapixels and do 60 frames a second. We’re actually quite low spec yet our brains fill in the blanks quite well. So you can liken that two days processors and phones that allow enhancement of photos, not just using the raw input of the sensor. Our eyes, ears, and senses are an even memory work the same way we’re, we’re a very low five megapixel camera with really, really good processing.
Adam Dymitruk 00:12:19 And so a storyline like that, like a storyboard with the key frames, both for data and for what people are seeing is the low five picture that has high value because the advantage of the lofi is that you’re not spending a year in it, right? So going back to the history of specifying software, you can go, if you over specify things, you probably not with good results will end up implementing all seven UML diagrams and spend a whole year there before you even touch code. And that’s the strong end that people throw in for agile all the time is that big design up front. You’re spend a year doing all this and not get feedback on what you’re doing. You might be building the wrong thing or the market might have moved on you and things like this.
Adam Dymitruk 00:13:01 So we need something that can if you’re really good at Event Modeling, we’ve done Event Modeling sessions for that lasted 15 minutes, right? Or an afternoon if you get really good with it, like anything else you can find a real shorthand for it yourself as well. But you get the same benefits. So, internally we definitely have our own format for Event Modeling if we’re not working for a particular client that we’ll use. But generally we want the standardized approach for Event Modeling so that you get some ways of getting velocity and cadence to how a system works.
Jeff Doolittle 00:13:35 So you mentioned some broad ideas of what Event Modeling entails. You mentioned a storyboard which, like a movie storyboard I imagine is going to have visualizations that can kind of tell the visual story of what’s happening here. And then you talk about the plot kind of being what undergirds that whole process. So, let’s maybe dig a little bit more into that. Tell us some about the language of Event Modeling. In other words, what are the artifacts or the items or the entities, whatever they might be that help someone to actually define an event model?
Adam Dymitruk 00:14:09 Right, so the core component of an event model is what I refer to as a slice. That’s really a workflow step as you move from left to right on the timeline, an event model is meant to allow you to analyze each step with a guarantee that only one thing is happening there. So, a workflow step can be one of two things. That’s either where you’re changing the state of the entire system, but ideally obviously that is going to be shown as the state change in just one subsystem in all of the systems that make up the whole solution. So, it’s either the state change step or a view into the state that’s necessary to facilitate some information being brought back either to a user or an automated process. And that’s kind of the highest-level kind of component is. And the most important component is identifying the state changes and the state views in the system.
Adam Dymitruk 00:15:01 Each of those is made up of, for a state change, it’s most commonly the UI having a button pressed then going to an intention or a command to change the state such as please can I register as a user, here’s the information collected from the webpage and then the acknowledgement of that it passed all the validation, your emails formatted correctly, et cetera, whatever your business rules are. It then flows down to the event and the event is the only way that you store state changes. It’s this ledger approach that you can then analyze. And so far in this event model, these are the events that have been stored so far. It is the truth of what happened in the system and you can make decisions in further steps later based on that. And so those components are we use color coding for these.
Adam Dymitruk 00:15:51 So the UIs are usually wire frames or figma artifacts that designers have already created, if you’re lucky enough to have those. If you’re doing an existing system, you can just do screenshots of the existing system to show that the command is blue. So visually you can see that it’s the intent to change the system state and the events are orange on mural, although if we’re doing this in person, I usually switch that to yellow because yellow stickies are easier to find in stores. , I think there’s been a lot of event driven approaches that kind of standardized on orange as being an event. So we just adopted that. Now the other side to an individual step is looking at the state view, which is really again, a screen that’s kind of showing maybe a list of movie tickets available or concert tickets, but going backwards on this one, that comes from a green box, which is an opinion of what the events meant.
Adam Dymitruk 00:16:44 So it’s a state view. In other words, you can have a whole bunch of steps before where an administrator added a whole bunch of tickets for sale. They’re all individual events on the timeline, but there’s this live report green box that kind of listens for all of them and says, oh well right now we have five different concerts going on in the future that you can buy tickets for. And so that green box will have a traditional kind of a, maybe a table that shows all the tickets and kind of the information that’s needed to make that page look nice. And of course, it’s joined to those events, those orange boxes. So, there’s definitely a cadence, like an opinion as to the flow and what arrows can connect to anything. And by forcing the UI or API to hit a blue box, then have to connect to an orange box, then have to go to back to a green box and then back out to the API.
Adam Dymitruk 00:17:36 These rules of what can connect to what, help ensure that there’s very few patterns that you have now. If you have very few patterns that allows you to have a really nice large sample size for just how long your team’s taking to get this automated. And so, this opinion of being able to dissect each system that you have into a standard set of components is kind of the unit of work and done is done problem we’ve been trying to tackle for a long time. And I think the secret has been to look at state changes at the right level, not have to go dive deep into an implementation of a class that’s highly technical, which helps keep this as something you can share with all the rules in the organization. So, anyone that cares about the project can understand what the system’s doing.
Adam Dymitruk 00:18:24 This diagram has nothing technical in it. It’s simply looking at how information in your system changes over time. None of these boxes have any artifacts that are technical when it’s being done properly. So of course, people have used it for technical purposes on technical teams, but the intent of it is to really gel the entire organization together and break down walls between different roles when you’re working on projects. Cause that’s the real issue with is the communication problems and the multiple standards of different specs that we have. Oh, this is a design doc, only UX people can look at it or designers can look at it. Oh this is a UML diagram. Oh, only technical people, architects and developers look at it. That’s creating silos. And it doesn’t help really coalesce the whole vision of the system. It doesn’t put people on the same page.
Adam Dymitruk 00:19:12 Event Modeling is useful for all those roles, maybe not to the same extent as a detailed UML diagram for a class, set of classes, et cetera. But that doesn’t matter if they can, if they want to do some extra diagramming on the whiteboard and share some things with them. But the contract between all the roles is that the given time in a workflow, the state of the system is this and we can all shake hands on it and agree. And I think that’s a fine enough grain of detail to guide the project and both from the details of implementation, but also to the larger vision of like how far along are we on this large one-year project. And also just for people thinking that this has to be all done at once at the beginning, that’s not true either. It’s a kind of like a token of work.
Adam Dymitruk 00:19:57 So you can take a totally agile approach to this and only think about the next few iterations that you’re going to do and model those and, but the state change is your token, and you can actually say, hey, how expensive is this refactoring going to be? You can actually say it, you can follow the lines and say, I’m have to revisit those other three workflow pieces from the work from two weeks ago. So, I’m not just giving you an extra-large T-shirt size or a medium t-shirt size, I’m actually giving you something more concrete in terms of the complexity of what I’m about to do when I’m at the standup. So it’s very compatible with all these other ways and think it makes communication incredibly fast and we don’t, you kind of remove a lot of the subjectivity where it’s kind of sold us on a really un-opinionated way, hey, anything works just as, as long as you get feedback. It’s like, well we give some structure to that so we’re not taking the bad side of that, which is an entirely subjective opinions of how things are. We want to tie it down to the real world impact of what that is in the solution everyone’s working on.
Jeff Doolittle 00:21:01 So ultimately it sounds like Event Modeling is less of a technical solution, if it is at all. It’s more of a human communication approach.
Adam Dymitruk 00:21:09 Absolutely. And technical people are humans, believe it or not.
Jeff Doolittle 00:21:13 I know some people might not think so, but yes.
Adam Dymitruk 00:21:16 Exactly. So yeah, like you said before, it’s a people problem. And so, any tooling that we can invent or make that helps us be better humans that are jobs, and a lot of that is in teams, in larger organizations is communication. And so, I haven’t found anything really that compares to Event Modeling and I never actually set out to create Event Modeling. Event Modeling is the distillation of a lot of the other tools into a common format that does the same job 80, 90, 100% of what those other tools may do. So, anything from issue tracking project, sprint planning, any of those things are things that we internally do ourselves. And so, my team is really a Guinea pig for the last seven years of like, all right, let’s see if you can do everything using this methodology.
Adam Dymitruk 00:22:04 And so the answer is an astounding yes we can, and it’s compatible with others. Obviously not everyone’s just drop what they know and start using a new methodology, but there are ways to link them together and have these slices that I was talking about be represented by Jira tickets. If you’re still using Jira somewhere, then you can definitely map those. In fact, it can probably automate your canvases, their digital canvases to, with their APIs to create the geo tickets for you and vice versa. And if you finish something, you might be able to push something to your digital workflow, your event model, that’ll mark that slice as having been done. And maybe show visually with some initials as to who worked on it. Think there’s so many neat ways to really extend other tools and other concepts that we’re using to Event Modeling.
Adam Dymitruk 00:22:52 I mean you could hook it up to your CICD pipeline if someone’s done with a particular feature that is expressed as a set of slices when those are done you can have a listener on GitHub or whatever your repository is and mark that off. So yeah, lots of this is just scratching the surface over the last three years. I mean, when I wrote the article initially it was 2018, it really took off, it was a medium article and that took off quite well. I was surprised I was getting phone calls from emails from the blue and I didn’t know what was going on and it ended up being on Hacker News and I didn’t know someone posted that article on Hacker News and it made it to the first page and the top story, I think it was October 2018.
Adam Dymitruk 00:23:34 So, at that point I said to myself, well I have to kind of make at least a website dedicated to it. So, Event Modeling.org started and I just put that medium article in there, cleaned it up a little bit. And so, it’s been it’s the very start when you look at it, it’s the very start of this journey. We’ve only been looking at the formalized method across other teams besides us for the last three to four years. The website didn’t really go live until 2019, kind of maybe a year before COVID. And so, a lot of things have happened. Obviously, the Event Modeling done in person versus online, right? And so, they had to go through that change as well. So, there’s some shorthand on the Event Modeling website that’s more applicable to in person and you’re a little bit more thorough when you’re doing it digitally. Just a couple of small differences, but that’s kind of the history.
Jeff Doolittle 00:24:21 Yeah, and you connected it too with other human communication tools, which ultimately that’s what tools like GitHub and Jira are for, is there to help facilitate human communication over time.
Adam Dymitruk 00:24:31 And yeah. And another one I missed is Storyteller, another BDD frameworks, which really try to bake in the business language into your fixtures. And so that you have a template for how you describe your business steps and fill in example data. This takes it to a simpler format where you don’t need tooling for it. I was a big proponent of behavior driven design, of course I still am just in a different format. All those tools like Cucumber, et cetera, all the things that you would need for end-to-end testing and getting stories articulated correctly, that has been replaced for us at least with Event Modeling since it does check off a bunch of other points. So we’re kind of killing many birds with one stone, not just two birds with one stone. Now that’s kind of the idea. Absolutely, this communication piece with existing tooling and how humans connect.
Adam Dymitruk 00:25:22 Going back to the fact that we did this on our shoestring budget at first, we didn’t have money for a project manager in that time to manage Jira. We didn’t have time to do any of the other 10 things you might find that typical project. So, if we had to do just one thing, we had to coalesce all these other parts from existing tools and make one methodology or one tool do all of them. And that’s how Event Modeling organically originated. Again, I said I never intended to create this, it just happened. It was what we discovered while being, being asked to make incredibly high scalable maintainable solutions, high quality solutions, fast and cheap. It’s like, oh you just squeezed the iron triangle so hard.
Jeff Doolittle 00:26:06 Yes it has to be good.
Adam Dymitruk 00:26:06 We want all three or your company doesn’t exist essentially. And so that forced us to, we couldn’t essentially, we couldn’t do it with existing tools and processes that you find in software. We would have no business. So that’s kind of the backstory of Event Modeling is that it allows you to do a lot more with a lot less. And what you’re cutting out is really the things that are lower valued in favor of the high value pieces. Like we said, communication, specification, being very–using immutable ideas about how information is stored and what facts are stored. Those are really good pillars of solid architecture. And I would say that information architecture is the one that over arches all the other architectures, because that is essentially what the purpose of a system is. Do we get this information in front of these people, are these people allowed to enter in this information?
Adam Dymitruk 00:27:04 It’s all about, in most systems we’re talking about point-of-sale systems and insurance companies and 99% of the software out there that we’re automating is just automating our lives. Since computers came into existence, there is the 1% where someone has a technical side and they’re working on a search algorithm or they’re doing on they’re improving, doing a pool request for the docker project or something. That’s not where Event Modeling is necessarily going to help you, but it’s going help you and the majority of the projects out there where you’re automating our people’s lives and regular businesses.
Jeff Doolittle 00:27:38 So it sounds like in a way you were taking prior concepts, ideas, patterns, things that were working for people in the industry, but you were also noticing that there was a lot of additional heavyweight things, or at least for your context, things that seemed like additional effort, additional work and you tried to distill it down to something simpler and then you needed a name for what seemed to be working and that’s where Event Modeling sort of, it’s almost like you stumbled into it, discovered it, then decided to name it. And it seems kind of similar to JSON which was there until somebody said, hey look at this thing I found in JavaScript called JSON and it’s like, we’re already doing it but let’s formalize it and let’s name it. Is that similar to how Event Modeling came about?
Adam Dymitruk 00:28:18 It is and a heavy process that we used in our company obviously is event sourcing, CQS, domain driven design. And then of course back in 2015 I stumbled across Von and Albertoís workshop format for EventStorming, which is a way to get everyone in the same room to talk about events. The whole time I was thinking I was just doing EventStorming correctly and we were using EventStorming artifacts to be the blueprint, but it wasn’t EventStorming. I went to Italy Bologna, Alberto was nice enough to invite me there for all the people that were practicing EventStorming around the world or at least leading the cause of it and popularizing it. And it was kind of weird because I said, well this is the way we do it, it’s way better. Our projects are on time, we don’t have any of these problems of translating the event, storming artifacts into solutions.
Adam Dymitruk 00:29:12 And that’s when I saw, okay, well we’re dropping certain things like we’re not doing policies, policies are just not something that we bother identifying. It’s already captured in the naming of processors and other things, models that we have or stage views that we have in Event Modeling. And so I said, okay, well I guess we’re not doing EventStorming, we’re doing something else. That’s where the name came from is that well we’re doing something with events, it’s not EventStorming obviously it’s got a much more a different way of a different structure and it’s a little bit more opinionated to, for some benefit of being able to measure your size of projects and then also drive implementation directly from it so it’s not EventStorming. So it is event something and I said well we’re kind of modeling entire system so just call it Event Modeling. And that’s kind of said that’s probably a better name for it anyway. So, from there it’s just was kind of a thing I thought of in a day and it stuck. So far no one’s really suggested any other names and most people recognize the practice by this name now.
Jeff Doolittle 00:30:11 Okay, so let’s say somebody’s familiar with EventStorming. Well actually let’s talk about both if you’re not familiar with any of this stuff. But let’s say you’re familiar with EventStorming to some extent and start there, what would be different for somebody who says, I want to give Event Modeling a try, what would change? What would they stop doing? What would they start doing?
Adam Dymitruk 00:30:29 Oh yeah, that’s a great point. Yeah, EventStorming is quite popular actually. EventStorming made it to the center of the tech radar by ThoughtWorks, right? So that was in 2018 I believe, or I think around there was the only practice to adopt , which is crazy. Out of the hundred technologies and approaches that they review, EventStorming was the only one that made it to the center. So, EventStorming is kind of a more elaborate brainstorming phase of Event Modeling really. So there two are quite compatible if you’re doing EventStorming already to your initial brainstorming session. In EventStorming is thrown away after the event. Storming primarily was designed for get that environment for people to collaborate and get everyone in the same room for that day to talk about all the different problems, hot spots and other problems in the problem space and all of that and get everyone to get on the same page as to how they understand the intended system and all of those things.
Adam Dymitruk 00:31:25 But then it’s kind of thrown away and then people go back to their desks to go back at least before they added a couple more forms of EventStorming. But primarily it was about a discovery process. So, Event Modeling has that as a component. It doesn’t have things like key differences, doesn’t have policies in it. As I said, it has a way to do the same thing by naming processes and naming state views to replace that. Also, it’s highly opinionated. Event Modeling is highly opinionated in terms of the storyboard aspect. The timeline is forward only EventStorming allows branching and other connections. So, it has a little bit more of a free flow. And so generally if your goal is the same thing and you want to use Event Modeling instead of EventStorming, you’re find that you’re mostly just concentrating on events with Event Modeling, putting them down into a storyline so that you have some way of starting to talk about a whole workflow and get a storyboard going for that.
Adam Dymitruk 00:32:20 Another big difference is that UX and UI is a first-class citizen in Event Modeling. So having that visual aspect and the UX and customer experience at the top of the list is quite important because even for backend heavy processes there are still visual people involved in specifying those and implementing those. So even though you might have 12 steps that are entirely behind the scenes with no UI on it, you still want to add a UI for a system operator or an admin that may say, oh this process is stuck at this step, this queue is not moving messages or payment requests through or something like that. So, it’s still important. So, Event Modeling really does focus on the customer UX experience, that type of mindset all the way through it never loses it. And I think that’s one of its strengths is that never stops that human connection with how we as humans, even if it’s systems operators or programmers see things, I mean I would put sometimes an event like a log, a console log is one of the screens in one of the swim lanes because at this point yeah there may be a backed up system here and it’s going to be a system admin that’s be looking at a log and I show that visually that this part of the workflow is kind of treacherous.
Adam Dymitruk 00:33:37 You’re have this actor that’s the system admin as the only one that can help you . You can visually see that, right? Even and it’s helpful to the system admin, but it’s also helpful to people that are using the overall system that hey, this is a highly technical part of the solution. If there are problems, this is where we go to second level support maybe. So, we can definitely just talk the whole time about the two differences. But I think that kind of rounds it out about EventStorming is really about the one-day collaboration Event Modeling is about having a schematic for the life of the project. And then once the project is finished, it’s a schematic that you use to maintain the system. That’s the intent of the event model. It’s really to, how you had TVs back in the day with vacuum tubes, you would have a schematic of the circuit board on the back of the tv.
Adam Dymitruk 00:34:20 So when a vacuum tube burnt out, the TV repair man would know exactly which wires to check where the connections are and which vacuum tube to replace when it burnt out. That’s a maintainable system. It comes with a schematic. I mean even my Commodore 64 back in the day, the large manual that you could buy for it had a fold out schematic of all the chips on there. The whole circuit was a full you would open the last cover, the back cover of the manual and you’d fold out into thirds or sixes or whatever, but it would be a really large sheet that would just show you the, how your computer was put together. So, what we’re doing is the same thing for information systems and I think we’ve got the right the right level of scope, which is the state changes to do the exact same thing.
Jeff Doolittle 00:35:04 Okay. And I think that answers the question a bit as well about what a team would do if they’re starting from nothing and they want to do Event Modeling, they could still use EventStorming, they could maybe skip the policy portion of it, but essentially you still want to have a discovery process for what are the business, whatís going on . .
Adam Dymitruk 00:35:20 Yeah, exactly. That’s the storming part. Exactly.
Jeff Doolittle 00:35:24 Yeah, that’s the storming part.
Adam Dymitruk 00:35:25 You could do either or like, I mean if people are already familiar with EventStorming, it’s really easy to translate policies into names of processors and things like that and just drop the purple stickies and transform it very, very easily. In fact, a lot of our projects have been initial EventStorming projects where the people were stuck on the implementation moving from EventStorming to implementation. So there’s a number of projects that we moved forward because the event model gave the schematic that gave them the, okay, here’s how I start coding with confidence, I’m building the right thing and that we’re still using the ubiquitous language and other things that we discovered along the way in the storming part, right? So, when we gather ideas, it’s nice to also have a place for where they plunk in in the future solution as well.
Jeff Doolittle 00:36:12 So let’s transition and give our listeners a bit of a flavor of how Event Modeling is practiced with a concrete example. You’ve mentioned in a previous conversation with me that there’s seven steps that a team will go through as they’re doing Event Modeling. So walk us through those steps and if you can give us a concrete example in those steps of maybe even a project that you’ve worked on that our listeners can kind of visualize hopefully in their brain, sort of how this process
Adam Dymitruk 00:36:39 Works. Oh yeah. The seven steps are really a guideline. Event Modeling is really a language of how to talk about an information system, but if people don’t know where to start, the seven steps are great to do that. So I already mentioned the first one, you kind of brainstorm all the things that would happen. And so we’ve done a number of projects that started at this level. One of them was a recruiting company that’s disrupting the industry. So, they’re allowing people that want to be in the recruiting space not to have to go work for one. So, it’s about having independent recruiters. So that required to make sort of a quote unquote marketplace both for where you post jobs and where people apply for jobs or the types of work they want to do. And instead of having one recruiting company go and do that for those companies and for those people, you can say well here’s an open market where then individual agents can go and say, hey, I actually am quite good at C# and so I see there’s five companies that are looking for developers and C# and then I know all these people here say that they have dot net experience but maybe some of them don’t say that they have C# experience but I know they’ll probably be a good fit cause they seem like they’re senior.
Adam Dymitruk 00:37:52 And so from that point, the individual agent can then connect that person to that company whereas a general kind of buzzword matching recruiting company will miss that, right? So, it’s a really good cause. And of course, individual agents are way less expensive than recruiting companies. So, then there’s a benefit to everyone. It’s a win-win win situation. So, in this case, hope everyone understands that business prospect there for automating a business. So, what we did was we got those events that had to happen such as job application posted or profile of submitted profile for a developer agent a registered, all those different things that happened. And then of course even the management, all the different events that could happen such as even the payouts cause there’s a different amount that you get from the fee that the platform charges. So, all those events were brainstormed and then we put them on a timeline on physical stickies on the board and we started to look at, well what do we want these screens to show?
Adam Dymitruk 00:38:55 Because we already have a kind of a, so that’s the first step is really just getting the events down and the second step is get the events into some sort of a storyboard order. So, we might start with the company posting something and then some agents sign up and then after that maybe some people will finally go to the website and put up their bios because they’re looking for work and then the agent starts to look at some listings on both sides and starts to match and connect them by email. So, we have all of these events in orange stickies across the wall and then we say, well how do they do these things? What do they have on the screen that they’re looking at? And so, we get the other part of the storyboard. Then that’s step two is get the UI up there.
Adam Dymitruk 00:39:39 UX is really important and sometimes we flip those two, it’s, this is just one way of doing it. But sometimes we flip those two, if someone already has wire frames in terms of the screens they want in their system, they already have a pretty good picture in their head. We can start with step two and go back to step one. That’s fine. They’re interchangeable. So once you get that step of here are the, how the screens look over time, we always have example data in there so that people can relate to it. We try to anyway to make it. That’s another important point actually having example data allows you to do an audit of if you have something called information completeness, are you making up facts , where did this information come from? Do I have a step somewhere in the past where someone entered in this information? If I don’t, I know I’ve missed out some important requirements.
Adam Dymitruk 00:40:25 So it’s really good to be able to audit that without getting into the weeds just at the information level it’s still very manageable and very light to do that. So it’s a nice audit to be able to do. So after that, those first two steps kind of have a storyboard the basics of a storyboard, but then we start to connect the screens where people are actually changing the state of the system with those blue boxes and linking them down to an orange box. And anytime that we have an orange box that kind of appears out of nowhere, we know that there’s a process that we’re missing. So we start to put in gears for the processes like oh this ranking of this person’s skill in C# was done via some AI thing that we included. So that would be a gear on the workflow that the system is doing something for you. And so once you start interrogating the basic storyboard, you start to identify all the blue boxes and the green boxes I had described before. And those are steps three and four into what’s going on in terms of changing the state. Then kind of
Jeff Doolittle 00:41:21 Blue boxes being your command
Adam Dymitruk 00:41:23 Yeah, blue box is being a command.
Jeff Doolittle 00:41:25 Have attention to change the state of the system.
Adam Dymitruk 00:41:26 That’s right.
Jeff Doolittle 00:41:27 And the orange or yellow in the real world box, which is an event which is reflecting the fact that the state of the, the system did in fact change and then the green being the views or the representations of an opinion’s, right On those facts. On those events.
Adam Dymitruk 00:41:41 Yeah. For example on this. Yeah. And in fact that green book’s, a good example in this recruiting system is a list of candidates. That’s a searchable list and if you put in the keyword C#, you have a short list of that and obviously one of the columns in that green box would be, skill set or it might be a join to a table that has skill sets and you could filter on that with a very simple query. Ideally the green box is when you’re implementing kind of like your select stars, you’re kind of like making those models to be exactly what you need for that step to be done really quickly. Right? And then Event Modeling forces you to look at a multi-model implementation, which is actually a good way of deconstructing coupling issues where, Jeff, you can work on one screen for the candidate’s listings and I can look at the job listings page and we’re not stepping on each other’s toes because we’re not competing on how a single table is going to be used for both of those displays.
Adam Dymitruk 00:42:35 I might be stepping in your toes or vice versa, but if we have our own projections off of the events that we totally own, you own your green box and I own my green box, we can work in parallel and really not have to fight over the formats in those tables because we have our own. And so that’s a really important point because Event Modeling does allow a higher level of parallelism, which allows larger teams we no longer go by the pizza size team internally since we can do a lot more by understanding where these things are. So back to the point , the last step is really organizing these swim lanes so that I may have a candidate system, I might have another system that shows the job postings and I put those in swim lanes down below. So, all events that relate to job postings go in one swim lane, all events going for applicants can go in the swim lane.
Adam Dymitruk 00:43:26 That’s if we decide that thereíll be two subsystems and we do that by these swim lanes. And likewise on top, we organize those different screens. So, some screens may be seen just by job applicants, some screens might be seen by the agent and some screens might be seen by the companies putting up jobs. So, there would be three swim lanes at the top. All the screens through the workflow that are shown to a particular user, are shown in their own swim lanes. That gives you an ability to kind of interrogate the storyboard as to okay, well we can see this as an agent heavy, system, we’re probably have to have more development here. It actually starts to give you feedback on where your focus is. Also, it shows you kind of neat flows through the system. A lot of times our swim lanes for the events are a cascade of information where things kind of are onboarding in the very first part of the workflow when they cascade down to the middle management of dealing with the information and then they kind of cascade down into either sales or reporting domains at the very end.
Adam Dymitruk 00:44:22 So it’s kind of neat to see the progression of information where the connections are. So it’s a very highly visual organized workflow to show you know exactly where the handoffs are. And it does we call it Conway’s Law because it’s those communication pathways that Conway really identified and you see those right in front of you here. It’s when you have people organized to develop these systems, which teams are going to talk to one another and what information, what contracts are important to make sure they’re talking about those ahead of time and you can focus on them. So, Conway’s Law really plays a big role in how we build these systems. We really sensitive to when we have handoffs of information from one team to another.
Jeff Doolittle 00:45:03 Right. And just to remind listeners, Conway’s Law essentially states that organizations will create systems that mimic their own communication structures. So, since Event Modeling is a tool for human communication, it sounds like what you’re saying is let’s get Conway’s law on our side working for us.
Adam Dymitruk 00:45:19 Yeah, exactly. Or at least always think about it and not ignore it unless I think a lot of times happens in the industry and then we pay the price by having really awkward project implementations. So definitely Conway did the whole industry of a big favor by identifying this long ago and those that understand its implications are far better off and how they put systems together. For sure.
Jeff Doolittle 00:45:42 And what I appreciate about Event Modeling is you’re showing not telling, in other words, it’s one thing to tell people Conway’s Law matters, but what you’re doing is you’re showing you don’t even need necessarily tell someone Conway’s Law
Adam Dymitruk 00:45:54 exactly,
Jeff Doolittle 00:45:54 They’re get the benefits of Conway’s Law whether they recognize it or not.
Adam Dymitruk 00:45:57 You bring up a really good point because one of the things with limited budget that we can do, we couldn’t really educate a lot of people, not only just on Conway’s Law, we couldn’t educate people on, domain driven design or event sourcing or any sorts of things. So, one of the things that Event Modeling does is it starts out with the goals of all those practices being shown as the artifact. So, someone can do Event Modeling for a year and then say, hey wait a minute, I have domain driven design. These look like bounded contexts. Wait a second, this is an aggregate, I have transactional integrity on this. Wow. So, they can go backwards, kind of stumble Kramer their way into it and fall backwards into domain-driven design. And that was kind of out of necessity, like I said, the luxury to be able to say, Hey team, go study domain-driven design, go study event sourcing.
Adam Dymitruk 00:46:44 Go study CQRS, go study Conways Law, go study hexagonal architecture. That would take a long time to do and to understand. So, we needed to start off with an example and these slices are formulated exactly specifically for this purpose so that they end up fitting any of these really good approaches that takes time to learn. Right? And when someone is new or junior, you don’t want to have to wait for them to level up. You want them to go through the proper motions and to backfill why they’re doing it later, but also do that from a really good place. Not just that someone told them to, but that they have a convention that allows them to move quickly through that as they’re learning and not be worried about know blowing up the system. Like these slices in our implementation are done through event sourcing. And so they do contain, they’re small. If there’s an explosion that’s small , if someone implements a slice badly, it’s just replaced. You’re not really likely to really destroy the system if you’re working on a team that’s doing this.
Jeff Doolittle 00:47:47 Yeah. And that’s what I refer to as complexity containment. You know you’ve contained complexity when there’s a significant change in your system and it’s isolated to a small portion of your system. And you know you have a bad design when a change in your system affects multiple parts of your system.
Adam Dymitruk 00:48:03 Exactly.
Jeff Doolittle 00:48:03 Fact that this helps with that.
Adam Dymitruk 00:48:05 It does tremendously. And combining this with implementations that are event driven and event sourced specifically where we don’t lose any information, we always have a breadcrumb trail to go back to. So Event Modeling really does allow you to push forward in your event driven architecture goals and your event sourcing goals. It’s been I think some people have said that it’s the only way to learn CQRS and event sourcing properly that’s the benefit for them. And that’s not me. I was just kind of looking on Twitter, like what people are saying about it. Not even people, they didn’t mention me. So, I was just looking for Event Modeling and I found these cool quotes that like, hey, this is like, this is how I learned how to do event sourcing properly is because I described the system using Event Modeling.
Adam Dymitruk 00:48:52 And others have said that, oh, Event Modeling allowed me to start my project within days instead of having false starts for forever. So, Event Modeling was also used to restart failed projects. So, we had a lot of large projects that were do or die situations and they’re already past their second attempt at implementation. And coming in with Event Modeling really allowed everyone to get on the same page and brought out the misunderstandings and it brought out the incomplete pieces that in terms of specifications and that identification of those pieces and doing something that Chris Condron has a CTO of event store brought up, is this information completeness, I mentioned it earlier, but it’s quite important, especially for non-trivial systems, being able to trace through where each value in the system came from, where it’s shown.
Adam Dymitruk 00:49:42 This kind of audit, this is the highest responsible level. You can do this kind of audit without if you go the other way, you’re into UML and then you’re to have a specification that’s on the class level, method level is take a long, long time. But focusing on state still allows you to do that completeness in a much, much shorter time. And he coined that term at the time that he was helping a company go through exactly this and not a very nontrivial sized project, which I talk about sometimes, which dealt with trading on the New York Stock Exchange and other like not trivial systems billions of dollars at stake. And to have those types of problems be solved by Event Modeling was really good. And by the way, this is not a magic bullet. It doesn’t remove work like you still have to work. But what it does allow you to do is to organize your work and really remove unnecessary detail to a responsible level so that you can get through the work at the highest efficiency. That’s kind of how I would say it. Because a lot of people say, oh, it sounds like a silver bullet that you’re talking about here. It’s like, no, it’s kind of like a way of doing things at the most responsible level of speed with retaining the quality that you can still attain those same goals.
Jeff Doolittle 00:50:49 Right? It’s a way of working. It’s not eliminating the fact that you have to work, but also it sounds like the goal is as well, is to refine your work. So, you’re focusing on the most important things and shedding a lot of things that might otherwise just be unnecessary or not as helpful. Maybe there’s some value in them, but it’s just not as high as the value of what you’re focusing on.
Adam Dymitruk 00:51:10 Well I would say that all of the different practices are valuable, but I think the time that it takes to fill them out completely is non-trivial. And it’s extra time. So, that’s a precious thing we preserve. So Event Modeling does allow the responsible level of ignoring implementation detail but sticks the stakes in the ground at important points such as state transitions and state views to not go too high up and just be handwaving kind of really epic user stories that can be interpreted in too many ways and don’t give enough guidance. So that’s, and even just executing on projects, like people love the fact that they can follow an event model step by step. And when you’re implementing you’re not distracting.
Adam Dymitruk 00:52:03 You don’t need to use the Pomodoro technique; you don’t need to do these things. You, when you’re concentrating on a blue box or this screen, you finish it, you move on to where the arrow points to next, et cetera. So it’s a really good backbone to the effort, the actual everyday workload that, that someone might have in implementing a solution. That guidance gives you all the check boxes you’re looking for from Jira or from standups and all of that. Like we don’t have standups because we know on the event model who’s done what. And we do that on a push pull basis when there’s a comment on the mirror board that someone’s hit a blocker. That blocker is immediately taken care of by anyone else that’s looking at the event model because they come up as red comment bubbles and we just make sure that there’s no red comment bubbles ever on the event model . It’s faster than standups, right? Those feedback loops, we kind of squeeze them so tight that they disappeared because we’re, instead of getting feedback between people and communicating, we’re collaborating and collaboration is real time. The feedback loop is so tight, it doesn’t exist, if you can imagine. Right. Collaboration removes that. Yeah.
Jeff Doolittle 00:53:11 . Yeah. And it also sounds asynchronous, which especially in a world of distributed teams and that’s not going away. To be able to have that collaborative approach now to be able to asynchronously respond to things as well, seems like a huge benefit also.
Adam Dymitruk 00:53:23 Thank you for bringing that up, because we’ve had a ton of projects that are very successful that were globally distributed and met the same timelines as if you had a co-located team. And it was about the clarity of communication. When people say you need a co-located team, it’s probably because of inefficient communication, right? So when you bump up that communication to a level that Event Modeling does, you say well I can do a distributed team in different time zones. I’m way more likely to succeed using a methodology where I have design guiding people. I have the same vision, everyone’s pulling the same direction, and I have these real ways of communicating my concerns immediately and not have to wait for an artificial process to kick off for my feedback loops to work.
Jeff Doolittle 00:54:15 Yeah. I appreciate as well, you mentioned it before, that this approach can actually help reduce the jumping to technology that a lot of people often tend to do. As soon as you talk about event sourcing, for example, somebody wants to talk about, well, what storage mechanism, what persistence mechanism weíre going to use. You know in meetings, I ban product people from using words like Kafka and Kubernetes, but unfortunately the software people are trying to teach them what those things are. And I appreciate that with Event Modeling, you’re sort of taking the how out of the equation. Let’s talk about why, what and who. And once we get that established, of course we need to talk about the implementation details, but the ability to defer that is, I think, another significant advantage that I’m seeing from this approach.
Adam Dymitruk 00:54:56 Exactly. It’s a good point you bring up. But it also is a struggle for a lot of pupils. We’re used to certain ways of working. We’re used to our own silos, right? This is breaking silos for better communication. And a lot of times when I see Event Modeling being done just by developers because they’re the ones that picked up the practice, I see these things sneaking in, right? We have recent one I saw, we have upserts in here, oh, this is upserting this application. A businessperson doesn’t know what you mean by upsert, right? It’s like an insert slash update lingo from techies, right? And it’s like, that doesn’t belong on there. That’s not describing the system. So that’s one problem with Event Modeling is because people are being pushed into areas that they’re not used to working at.
Adam Dymitruk 00:55:41 And from the opposite side, the level of participation on the solution from the business is hard to get people’s time. Businesspeople are used to sitting in meetings and talking just to one another most of the day. And so that’s the other challenge of Event Modeling, is really allowing people to reach out into, to truly collaborate with the others in other roles in their organization. So again, on the silver bullet, hey, this thing’s help me tomorrow if I adopt it. No, this requires change. Any better way of working is not going to allow you to continue to work using your bad habits , right? So, improvement requires change and people have to realize that Event Modeling requires change to take full advantage of it. You can take aspects of it, doesn’t mean all or nothing.
Adam Dymitruk 00:56:32 You can start to move to these things like I think I mentioned if you are using Jira, you can map these slices to Jira tickets and so forth. So that’s just one example, but there’s lots of aspects of this. Some there, I think in Mural you can link Figma, for example, to be embedded in there. It’s kind of a weird little integration you have to do. I always have trouble doing it, but you’ll see more and more of these types of tooling integrations I think, as we move forward. And so, embedding the designers work straight into an event model is possible. It’s been done. I think there’s even some companies that have just done Event Modeling within Figma and just adding the decorations of this. So, it’s really, you can do it in person on a digital whiteboard or whatever, it’ll work. But yeah, it’s nice.
Jeff Doolittle 00:57:22 Well you’re hearkening to something else too, which I think is interesting, which well, actually two quick thoughts. One is you mentioned, when developers are doing this, oftentimes the technical stuff leaks in, but this is a great opportunity to help software engineers to improve their communication skills with the business and to help them learn to speak the language of the business. But on the other side of things, it seems like there’s also an opportunity here for non-technical people. I mean, from everything you’re describing, it doesn’t seem like there’s significant barriers to say a product manager or even or UX designer to be able to sort of lead the charge on Event Modeling.
Adam Dymitruk 00:57:57 Absolutely. And they should be, it should be on equal playing ground for people to collaborate. It really should empower those that care and then that can take charge, that have domain expertise, et cetera. It’s leveling the playing field. So you have contribution from everyone in the organization, and each organization is different. You might have a tech heavy organization where some of these things may be highly technical. You may have a high marketing company where you need more input from the people that are driving the sales funnels and the system should respond to that. You may have something else where it’s an entirely different aspect, I don’t know. But Event Modeling is meant to allow any role to take charge at for the whole project or parts of the workflow and have that common bond.
Adam Dymitruk 00:58:57 And I think the common bond is really what information is in the system. Can we agree on state and have that unified vision that has, that sees no borders for roles at all, and is highly usable by each role. And that’s the gift that kind of fell out of that effort initially in my company. And I’m happy that it just happened. And people in my organization contributed really well to it. Like, for example, the idea of to do lists. Our CTO Nicola basically said, oh, these are all kind of like to do lists. We kind of worked on it together and said, any kind of process, because you got into sags and all these enterprise integration patterns and things like that, it’s like, how can we not do all of that and still move projects forward without middleware and all sorts of other things.
Adam Dymitruk 00:59:50 And without studying the 50 patterns in the enterprise integration book. Itís like if every one of these patterns is really attaining a goal, and when I have a goal, like going to the store and going grocery shopping, I bring a shopping list with me and I check things off as they’re done. So, these to-do lists allow things like fulfillment documents that you might find in long running processes and sags and processors, A fulfillment document. Yeah. That’s another checklist, like a to-do list. So you’ll notice an Event Modeling any automation, and then any of these where you find these larger patterns, they’re always replaced by this to-do list pattern. You have a green box that a processor listens to, and then it issues blue boxes or commands to other parts of the system or the same system. And it might have three of these steps like that, that are locked together to implement what you would traditionally see in some observer pattern or something else you might right
Jeff Doolittle 01:00:45 Or a sign like you mentioned before.
Adam Dymitruk 01:00:46 Or saga or any of these things. So that was a big problem, I think in, in larger distributed systems is that you got into the weeds of tech talk really quickly and it stopped, and it stopped the participation of the business. People will say, well, we have a distributed system now that has to go to the architects. It’s like, no, that’s not fair. You need to keep that open, that channel of communication open. And so, by introducing this to do list pattern or component to a pattern, it keeps the event model simple for others to understand. That’s why there’s always on the four patterns, right? Yeah.
Jeff Doolittle 01:01:28 Right. Now, to be clear, you could still use saga as an implementation detail, but what you’re saying is we can keep that implementation detail out of the Event Modeling so that the business is not getting overwhelmed with technical speak and patterns they don’t understand about.
Adam Dymitruk 01:01:39 Absolutely. If you already have middleware that you’re making use of and patterns and you have projects, a lot of companies have a platform team, right? In the platform project where they have a lot of these things in there. You don’t have to throw that in the garbage. That’s not what I’m saying. You have a better way to represent what’s going on without needing to kind of bubble up all the information about the platform to the business and get them in a room and say, this is how the technical stuff works. It’s like, they just know that the system got to state they’re happy with at this point in the workflow. And having that separation between understanding and implementation is really, really key.
Jeff Doolittle 01:02:19 That’s great. Well, I’m sure we could go on and on and on, but this has been a fascinating conversation. And at this point, how can listeners find out more about Event Modeling if they’re interested in digging deeper?
Adam Dymitruk 01:02:31 Yeah. Event Modeling is on, eventmodeling.org. It’s spelled with one L. It’s an American spelling of modeling. So those that are spelling in grammar folks, I do apologize, but it is valid. I did check. I also wanted it to be kind of different than what you would have. And also on, I think on logos and all that, a single L from a design perspective looks better than two Ls. So, eventmodeling.org for sure. Or just Google Event Modeling because it’ll match the other spelling too. So, it’s a top hit that’ll come up. I’m available also on Twitter and I have a Twitter account specifically for Event Modeling and event centric tweets which is its own account. And of course, if you’re looking to get in touch with us, to help implement your own solutions using Event Modeling and event sourcing, Adaptech Group is a great place to go. That’s a group of people that have only been doing this for the last seven years and have basically given birth to this approach through trying to do the right thing on projects over many years. And yeah, if you get a hold of them as well or work with them, adaptechgroup.com is one way. But of course, I can point you that if you get a hold of me on any of these channels. Also, I’m on LinkedIn and other social media platforms.
Jeff Doolittle 01:04:06 Awesome. Well, Adam, thanks so much for joining me on the show today.
Adam Dymitruk 01:04:09 Jeff, thank you. It’s been a pleasure. Always love talking about this and thank you so much for having me.
Jeff Doolittle 01:04:14 Absolutely. This is Jeff Doolittle for Software Engineering Radio. Thanks so much for listening. [End of Audio]
SE Radio theme: “Broken Reality” by Kevin MacLeod (incompetech.com — Licensed under Creative Commons: By Attribution 3.0)
