#75 - Domain Storytelling: Building Domain-Driven Software Collaboratively - Stefan Hofer

[00:01:33] Episode Introduction

[00:01:33] Henry Suryawirawan: Hello again, my friends and listeners. It’s me again, Henry Suryawirawan, with another new episode of the Tech Lead Journal podcast. Thank you for spending your time with me today listening to this episode. If you’re new to Tech Lead Journal, subscribe and follow the show on your favorite podcast app and social media on LinkedIn, Twitter and Instagram. And if you have been a regular listener and enjoying this podcast, subscribe as a patron at techleadjournal.dev/patron, and support my journey to continue producing great Tech Lead Journal episodes every week.

Getting the right software design is hard. Getting the right software that works according to the business requirements may even be harder. There can potentially be a number of misunderstandings that could happen when domain experts try to translate what they want from a software to the software engineers who will build the software. And these kinds of misunderstandings are costly and play a big part on why software projects tend to fail. Historically, there have been a number of ways and modeling techniques that try to help overcome this challenge. For example, you might have heard about UML diagrams, use cases, user stories, Impact Mapping, BPMN, and so on. And today we are going to learn another different technique called Domain Storytelling.

My guest for today’s episode is Stefan Hofer. He’s the co-author of the recent book titled “Domain Storytelling: A Collaborative, Visual and Agile Way to Build Domain-Driven Software”. In this episode, Stefan shared the story of how he came up with Domain Storytelling and explained how this technique can help us understand business domain better in order to bridge the misunderstandings happening between software developers and domain experts. Stefan walked us through how the modeling works, including some notations and other pictorial aspects of the modeling, and he also emphasized the importance of the collaborative aspect of Domain Storytelling. Stefan also explained how Domain Storytelling differs from other similar modeling techniques, such as Event Storming. And towards the end, he gave practical tips on how we can run a successful online collaborative workshop based on his experience running Domain Storytelling workshops online.

I enjoyed my conversation with Stefan, learning a new modeling technique that seems quite intuitive, and I’m very much interested in learning how this technique can help us to build better software. If you also enjoy and find this conversation useful, I encourage you to share it with someone you know, be it your friends or colleagues, who would also benefit from listening to this episode. You can also leave a rating and review on your podcast app or share some comments on the social media on what you enjoy from this episode. Let’s get our episode started right after our sponsor message.

[00:05:16] Introduction

[00:05:16] Henry Suryawirawan: Hello, everyone. Welcome back to another new episode of the Tech Lead Journal podcast. Today I have with me a guest named Stefan Hofer. He’s actually one of the co-author of a book called “Domain Storytelling: A Collaborative, Visual and Agile Way to Build Domain-Driven Software”. He actually created this technique and we’ll be talking a lot about this technique, knows what’s the purpose, what’s so unique about it, and how we can get started to use it in our day-to-day software delivery. So Stefan, looking forward to have this conversation with you today. Thanks for spending your time here.

[00:05:49] Stefan Hofer: Hi Henry. Thanks for having me.

[00:05:51] Career Journey

[00:05:51] Henry Suryawirawan: So Stefan, maybe in the beginning, could you introduce yourself. Telling us more about your background or maybe some highlights or turning points in your career?

[00:05:59] Stefan Hofer: Okay. I studied software engineering in Austria, and then I came to Hamburg, Germany for a five month internship. And now I’ve been in Hamburg for more than 15 years. As a matter of fact, I’m still working at the same company, Workplace Solutions or WPS for short. That is a university spinoff. The people I’ve had the pleasure of working with there, they really shaped my views on software development. They also inspired me to do a PhD thesis, which I did while I continued to work part-time at the company. So I did my thesis in an area of what I would call enterprise modeling. That was also the beginning of my transition from working as a software developer, more to consulting and training. Today, my job is to help teams develop better business software. That means I helped them to work with requirements, with business processes and applying Domain-Driven Design. So that means I do a lot of collaborative modeling with them. For example, with Domain Storytelling.

[00:07:01] How Domain Storytelling Started

[00:07:01] Henry Suryawirawan: So it seems that you invented this technique, Domain Storytelling. Throughout your career, you’ve been doing a lot of what you call it, business modeling, right? Applying DDD as well. Because from the name of it, we can see a little bit of mix of a few things. First of all, there’s a domain, which probably is Domain-Driven Design. There’s also a story. Maybe it correlates to user story. And there’s the storytelling part, which is one technique how you actually express the requirements or the things to be done. So maybe, can you tell us a little bit history how actually you ended up inventing this technique?

[00:07:34] Stefan Hofer: Well, I have to be honest. I didn’t really invent it, but I did name it. There’s the saying of standing on the shoulders of giants. That’s the case here. So there were actually a couple of predecessors. One of them was a technique that I first learned when I joined this company for my internship, and although they used it and they had a modeling tool for it, but it was kind of enterprise modeling method with different model types. You could model organizational structures. You could model, let’s say, a model of terms, you could model use cases. But there was also this one type of model that showed little stick figures that worked with what they call work objects. So, let’s say, there’s a stick figure called “moviegoer”, and then there’s an arrow that says “buys” and there’s an icon of a ticket stub, and it says “ticket”. With this technique, for example, if you model going to the movies, then the story would evolve around this moviegoer and show us how does this moviegoer actually experience that? What do they do? What activities do they have? What objects do they work with? Do they interact with other people, with a cashier, for example? So it has all been there already, but it was a bit buried, I would say, in all this other model types and stuff.

So what I did, again, together with my colleagues, for example, with Henning Schwentner, my co-author. What we did is we kind of distilled the essence out of that. Made it easy to use without all that other baggage that the predecessors had, and we gave you the catchy name, and you’re absolutely right, it’s “domain”. Well, of course it’s a story about the domain, about something that happens in a domain. But it’s also a bit of a reference to Domain-Driven Design because we thought, well, this was really the key realization for us. Because for years, we’ve been working with this more university shaped method, and struggled to find people in the industry, in the software development community who got it, who understood it. And who said, “Well, yes. This is a good idea”. And then when we found out about the DDD community, we said, well, this is our community. These are the people. They value collaborative modeling. They value visual modeling tools. They want to gain deep insight into a domain. This is the perfect tool for the DDD community. And hence, I named it accordingly.

[00:09:52] Misunderstandings Are Common Problems

[00:09:52] Henry Suryawirawan: So, it’s really interesting, right? Because you have mentioned a couple of times about modeling about domain, and one of particular line that I picked from the book, actually, this statement saying that “misunderstandings between software developers and people from the business departments, or you can call it, the business domain, are a common problem”. So tell us more about this. Why do you think there are a lot of misunderstandings between developers or engineers and the business domain experts?

[00:10:19] Stefan Hofer: I think that has always been the case, at least in my experience. There are techniques in software development that people came up with that try to address this problem, for example, this whole Agile methodology. I think one of the reasons that it was invented, or the people came up with it, or that it became so popular is because, well, you want to bring together the people who know about the domain who have that requirements, who will use the software and the people who develop the software, and to try to find out about these misunderstandings early on, and not like, the software built for two years, they worked on the software and then finally they shipped it, and then the user said, “That’s not what I wanted”. So domain storytelling and other visual modeling techniques, they’re just additional means of helping mitigate this problem, because you get something very early on that gives stakeholders, domain experts, future users, the chance to say, “Oh that’s not what I meant. No, No. That’s not what I want you to build”.

So what we often do is you can use it for different purposes, this technique, but one of them is to learn about the domains. So if you’re new to a domain, if you haven’t worked in that before, if you are a contractor, for example, then you need to gain some initial domain knowledge. That’s the first possible point where you can get misunderstandings by not understanding the concepts of the domain, the terms that people use. We can mitigate that by using domain storytelling in that phase. But we can also avoid misunderstandings when we model what we call “to-be processes”. So how do you want to use that software that we are going to build? How do you intend to use it? How is it going to change the workflows in the department, for example? We can model that, and that also uncover some misunderstandings. That’s one of the major things I think about as a method.

[00:12:08] Importance of Understanding Domain

[00:12:08] Henry Suryawirawan: And hence, I think one of the biggest advice from that particular chapter is that to build a usable business software, you must first understand the domain. This is sometimes not so counter-intuitive for many engineers. Because they just read the requirement documents and just translate it, so to speak, maybe spec-by-spec or step-by-step. What do you think would happen if, let’s say, developers really understand the domain before they actually start the work?

[00:12:32] Stefan Hofer: So I think one of the big advantages is that if you ask users what they want, they are often not great in articulating how a piece of software can help them with their problems, because they are not experts in software development. They don’t know about all the means available with modern technology, and it’s not their job to know because they are the domain experts. They’re not the software experts. So I think it’s great if developers, if development teams have understanding about the domain, because then they can propose better solutions than if you just rely on, well, this is what the users told me what they want to have, and this is what I’m going to build. But maybe there are other better solutions out there.

I think it’s your job as a software developer to have these thoughts and think about how can I solve this problem from a user’s (perspective) in the best possible way. And that’s not necessarily the same solution that the future users have in mind. They’re often limited by what they know. They are limited by existing software systems that they’ve become accustomed to use. So, this additional out of the box thinking, knowing about new technologies and stuff that would be one of the advantages to leverage that knowledge, that software development teams today have.

[00:13:46] Domain Storytelling

[00:13:46] Henry Suryawirawan: So let’s hear more about this Domain Storytelling. Because it seems very crucial to understand the domain and using this modeling technique, maybe can help. So tell us more, what is Domain Storytelling?

[00:13:57] Stefan Hofer: I say, it’s a combination of two things. One is a pictographic language, so it’s a notation for modeling business processes. Now, this is a bit difficult to describe in a podcast because it’s very visual, and we’re just using words and talking about it. So, if you don’t know what it is and what it looks like, maybe just look up domainstorytelling.org. That’s our website and they have consistent examples. But the basic idea, like I said before, is we have a set of simple icons. So we have “actors”, those are the people our software systems that do things, and stories evolve around those actors. So they are the active part in the stories. And what do they do? Well, they create things, they work with things, they interchange things, and those things we call “work objects”, so those can be physical things like documents on paper. Let’s say, I modeled some business processes in a harbour and there they have containers. So then I model containers. I use little icons for physical containers and load it onto ships and so on.

Then we have arrows that depict the activities. So we say, okay, this actor, like this moviegoer, buys a ticket and the idea is that the pictographic language follows the natural language. So you can read it out aloud. Stories are made up of more than one sentence. So how do we express a sequence? Other modeling techniques, they model from left to right, or from top to bottom. But here, we use numbers. So we number the arrows and that gives us the chance to lay out the story more freely. For example, group parts of the story together that belong in the same sub domain, or that happened in the same location. So that gives us a bit more freedom to lay out the story to express some additional meaning. That’s basically it. That’s the pictographic language.

The second part of Domain Storytelling is that it’s also a workshop format. Maybe that’s even the more important part because what I also sometimes do is you can use Domain Storytelling on your own. So we have an idea. Something that resembles a business process or workflow, and I just sketch it on a piece of paper and that’s it. And I just do it for myself. But usually, it’s a collaborative activity. So that means we have people who have questions and people who have answers and we bring them together. For example, the people who have the questions are members of the development team and the people who have the answers. They are all sorts of stakeholders. So we have future users of the system. We have other stakeholders. We have maybe product managers or POs, Product Owners, and managers, and so on. We bring them together in a room or maybe in a Zoom call. We have them tell us stories about their domain.

What is a story? Well, it’s a scenario, it’s a concrete example of something that actually happens in a domain. So we are not talking about business processes in a sense of these are all the possible things that could happen and either this or that happens. Nope. They give us one concrete example. For example, the typical case or the most common case, or the simplest case, or a common error scenario. And we take that scenario and tell it from beginning to end, without any ifs, without cases. We only look at the most important examples. Maybe two, three examples are enough to really understand a business process.

While the domain experts tell the story, there’s a moderator. He or she, they record the domain story visually, meaning they create the picture of the pictographic language, and it happens at the same time. That gives us a great tool for, again, dealing with these misunderstandings. So it’s important that everyone can see the picture as it is created. If I, as a moderator, make a mistake, if I used the wrong word, or if I used the wrong icon, or if I draw the arrow in the wrong direction, people will point at it and say, “No, that’s not what I meant.” And so this workshop format and this kind of dialogue that is created there, that is at least as important as the final picture, as the final result. Because often, in my experience being present at a workshop, it’s like a campfire experience. If you look at the finished picture, the people who were present at the workshop, they know exactly what it is about. If you just show it to someone else, if you send it in a mail and say, “Hey, we had a great workshop. Look at this result here”. You’ll say, “Well, okay. There’s a picture. There’s a lot of numbers and icons. Okay. I can understand it”. But it’s not the same thing as being there while it is created. So that’s why I usually say that even though you could use both independently, the pictographic language and the workshop format, you get the most benefit out of it if you use it in combination.

[00:18:34] Henry Suryawirawan: I like the way that you explained from the fireside chat that thing. Because sometimes I also see diagrams in my work. Because I wasn’t there, I really couldn’t understand what’s the context behind it. I think this comes back to the second term that you use. It’s about storytelling. Maybe in the collaborative workshop where the domain expert themselves actually explain in a storytelling manner, I guess? Like what use case that are particularly common, or typical errors or those kinds of things that you mentioned earlier.

[00:19:01] The DDD Angle

[00:19:01] Henry Suryawirawan: So one question is about the domain, right? Does this mean that it needs to have a Domain-Driven Design concept from the technical angle, or it’s just a business domain angle?

[00:19:12] Stefan Hofer: You don’t have to use Domain-Driven Design to apply this technique. We’ve applied it years before we moved into this Domain-Driven Design community, and it still worked. It is domain-driven in a sense that it is about the business, about the domain, about the people, about the tasks and activities of the people. So in that sense, it is domain-driven. But it is not bound to this particular approach of Domain-Driven Design. However, if you are into Domain-Driven Design, you will hopefully see that it can help you with certain activities or certain problems that you have in this area. For example, finding boundaries for your bounded contexts, or developing implementable domain model.

So those are things that I think Domain Storytelling really enriches the DDD toolbox. But it’s not necessary to use DDD for that. As a matter of fact, you can use Domain Storytelling even without the goal of developing software. So people have used it for optimizing workflows in the organization, or for making “make or buy” decisions. So they think about buying some off-the-shelf software, or should we build it on our own? I used it, for example, in an insurance company to compare several vendors for a CRM system. We also did it with domain stories, and we didn’t build software in the end. We just bought the software.

[00:20:34] When Domain Expert is Unavailable

[00:20:34] Henry Suryawirawan: So this seems to imply that actually you probably don’t necessarily need a business domain expert. Because sometimes, in a typical startup, or maybe some companies which try to innovate something, they don’t really have domain experts. So what if you don’t have it? Does this technique still work? And if it does, how could you make this work with Domain Storytelling?

[00:20:55] Stefan Hofer: So, again, there are different purposes that you can use Domain Storytelling for. If you look at the classical purpose of analyzing a domain, then I don’t think that will work without domain experts. But if you’re in a startup situation, for example, or if I’ve had very technical domains where the people wanted to discuss and think about how do software systems communicate with one another. Not on a very technical level, like which protocols to be used and stuff like that, but more on a level like, okay, which system is responsible for what kind of data? How does the business process flow through a series of software systems? Stuff like that. Then you can do it with the technical experts.

I haven’t talked about this before, because it is so recent. So that’s a first for you now, Henry. I’m consulting a company that wants to open up a new area of business. So they have a business model in mind. But as far as I know, not much more than that. So it’s just an idea in the managers' heads. What we’re doing there is, I’m working with the managers that had this idea for this new area of business, and they have this business model in their heads. They are trying to tell stories about this new business idea that they have. So there are no users yet. There are no other domain experts yet. It’s just an idea in their heads. We’re actually bringing in together in these workshops, product managers and also software architects, because in the end, someone will need to figure out how these processes will work in detail and how the software has to be built. It’s really interesting because those two managers, they go back and forth, and try to figure out the story, and the other people listen and ask questions. So I think this is a good example for what you asked. It’s not a startup company, but it’s similar to that. And again, can you make a story out of that? This is so crucial. Otherwise, it’s just a business model. But bringing it to life, making it alive, that’s something you can do very well with stories. The other people then now understand, “Okay, this is what you want to do. Okay, I get it.”

[00:22:59] Domain Storytelling Tools

[00:22:59] Henry Suryawirawan: So it seems that there are a few key things here, right? The diagram, maybe the pictographic language that you mentioned, is something like the deliverable of this workshop. And you may need to understand a few key important areas. I think you mentioned a little bit about work objects, arrows, and things like that. But for people who are new to this modeling, because I’m sure many other people have learned about some other modeling techniques. But how do they get started with this domain storytelling? What kind of tools? Maybe what kind of important things that they should have in mind?

[00:23:27] Stefan Hofer: Okay. So this pictographic language is quite different from other notations people usually know. It looks quite different from, let’s say, UML activity diagrams or BPMN and stuff like that. So I would recommend to first practice a little bit this pictographic language. For example, take out a piece of paper, a pen and start drawing processes like shopping in a supermarket or booking a train or whatever you find interesting, or maybe even a problem that you have in your work right now.

First, get a sound understanding of how this is written down, because this will influence the speed of the modeling session. On one hand, you don’t want a modeling session with a lot of people where you are the person holding everyone back. So you should become quite fluent in this pictographic language. That’s the easy part. Because the more complicated part is, of course, working with people. And that’s something that is, I think, not uniquely a problem with this technique. It’s a general problem whenever you work with a group of people that have different perspectives, different opinions, and one says, “I think this is a good solution,” and the other one says, “No. I think the exact opposite”. When people disagree on this is how we do it, no, this is how we do it, or when they complain about things that go wrong at a company. That’s the complicated part.

So, how can you prepare for that? And what I usually recommend and what I do is, first do a kind of one-on-one interview style storytelling workshop. So find a coworker, for example, and have them tell you a story that you then try to visualize. Because then you only need to deal with one person and usually, they don’t disagree with themselves, so it’s a bit easier. And then, build on from that and do it with more people. I’ve done workshops with 20-30 or more people. If it gets that big, I usually have a co-moderator, because then it can be complicated to A), follow the story and B), keep all the people in check and listen to all the conversations. You have to stop people when they shout at each other and stuff like that. That would be my general advice. Of course, you should buy my book and that’s always a good idea. But as I said before, there’s domainstorytelling.org. So the basic info you will find there. That should get you started. And then you can practice with the pictographic language, and then practice this interview style of domain storytelling, and then switch from interviewing one person to doing a workshop with several people.

[00:25:51] Pictographic Language

[00:25:51] Henry Suryawirawan: So, when you say pictographic language, what kind of details should be there? Does it have to go through all the workflows one by one? Like for example, think of it like sequence diagram, and a story happened from A to the end. It has to have all these in some kind of flow format, or does it only cover a certain high-level picture? So tell us more.

[00:26:11] Stefan Hofer: Yeah, I think it’s a really interesting and important point. Domain stories can play at different levels of granularity. So we can have a coarse-grained overview of something, or have a fine-grained story. So let’s go back to the cinema example that I gave before. A coarse-grained story would be, again from a moviegoer’s perspective: you decide on what movie you want to see. You buy the ticket. You buy some snacks, popcorn or whatever. You watched a movie and you go home. But buying a ticket. Well, that in itself can again be another story on a more detailed level. So what do you do? Depending on the country you live in and the culture, you either choose a seat before, or maybe not. And then you choose a payment method. You pay for it and then you received the tickets. And again, the different possibilities, do you print it? Or do you have it on the cell phone? Can you buy snacks before? And so the different possible stories that you could tell there. But again, this isn’t about just one step into coarse-grained process. And now you detail it. Maybe you have a scenario where you buy the ticket online. Then you have a story about the moviegoer interacting with some online booking system. Or you could have a scenario where you go to box office and buy the ticket from the cashier, and then the cashier needs to do certain things and so on.

So different levels of detail. That’s what we call “scope” of a story. So the scope of the story is made up of several aspects. So you have this granularity. That’s one important thing. And then another factor that I already talked about is the point in time that you look at. Are you looking at things as they currently are? Those we call “As-Is” processes. So that’s more of the analytical way of using domain stories, analyzing them. Or do you want to design something new? A new process and how software supports it? Then it’s a “To-Be” story that plays in the future. Depending on the purpose that they aim for, you choose a different scope. This also determines how much level of detail you have to put into your story. If I do very coarse-grained stories, really very coarse overviews. I often use one icon just for the whole company. So I don’t even go down into these different roles within the company, or different departments, or different software systems. I just treat the company as a whole. And that can also be useful. For example, showing how do they interact with other companies, with suppliers maybe, or with their customers, and so on.

[00:28:38] Henry Suryawirawan: So where is the technical aspect here? Do you also include systems, or maybe some kind of APIs, or partners, those kinds of things?

[00:28:47] Stefan Hofer: Yes. If you go down a little bit in granularity, you will see software systems and they too are modelled as actors. Because they are also usually active in processes. So they provide you with some information. They calculate something. They generate reports or whatever they do. So it’s typical for a domain story that it has a handful of actors in them. So you would have the person that uses the system (and the system) itself. Maybe even some system in the background that has no direct users. That is just some kind of a service software running. If you go into a bit more detail, you could even distinguish between, let’s say, front-ends and back-ends. Maybe a several front-ends, and one user uses handheld device as a front-end. Some other user uses a desktop or web-based front-end, and then you have a back-end in there. So, yes, that’s definitely possible.

But when it gets too technical, you said APIs, for example, or before I mentioned technical protocols, then I usually switch to some other form of modeling method. Maybe UML diagram is then suited better, or the C4 model of Simon Brown. Maybe you want to do more of an architecture and diagram then, and not a business process model. So that’s also typical that within one project, I often combine different modeling methods so that I have the perfect tool for every task at hand. You could still do it with Domain Storytelling to some extent, but usually, I would refer them to some other modeling method that is better suited for actually modeling how software works.

[00:30:23] Translating Into Software

[00:30:23] Henry Suryawirawan: So how do you then translate this domain storytelling, you know, like artifacts? Maybe you will have the diagram, with the icons and everything in a story workflow manner, 1-2-3-4-5 steps. How do you then translate it further to the software development life cycle? Maybe do you translate it into user stories? Or do you just go direct to software code? How do you translate it?

[00:30:44] Stefan Hofer: Different ways are possible. I think most commonly, we first translate it, or we use it to derive, come up with requirements. For example, user stories. It doesn’t have to be user stories. You can have some other format too, use cases, for example. Whatever you like. But I found that it is a very good technique. At least if you follow the classical Connextra template, which is just a template, you don’t have to do it. Especially in the beginning, it is useful. That, of course, connects to the way domain stories are visualized because you also have the actor there. Those are the users. Well, what do they do? That’s the description of the arrow of the activity. So it’s easy to translate it. So for all kinds of requirements that are processual in nature that refer to the business process. You can come up with them really easily by modeling the domain stories and then translating them into user stories. And then, of course, you will need to add some detail to the requirements. So that’s a kind of refinement step that you do.

So from the domain stories, we derive coarse-grained requirements, and then you will continue to put some more work in them and come up with acceptance criteria and stuff like that. From there on, you go into software development. But that’s not the only way to do it. Either as an alternative or additionally, you can look at a domain story that is rather fine-grained. So where you see in detail the interaction of, let’s say, with the cinema example, with making a reservation. What did they do to make a reservation? Well, they choose a movie and they choose a time when it will be screened and so on, and maybe they will choose a seat.

So if I look at this, I can see, okay, reservation. This work object, this will probably become, let’s say, a class. If I’m using some sort of Object-Oriented Programming language. This will probably become a class in my software. What can people do with the class? Well, they can make a reservation. They can cancel it, for example. Maybe someone else can confirm a reservation. Whatever you discover in this domain. Okay. So those will become methods then, or operations, or commands. You can also look what is necessary to work with this reservation. Well, as said before, you need a reservation time, a movie, maybe some form of ID so it can be referenced. Those will become the properties of this class. If you use Domain-Driven Design, well, the reservation is probably going to become an aggregate, and things like movie or time could become value objects and so on. So it’s rather easy to derive a first implementable domain model from detailed domain stories.

[00:33:24] Difference With Event Storming

[00:33:24] Henry Suryawirawan: So when you’re talking about all this, there’s one thing that popped up in my mind. This thing called Event Storming. So this is also a workshop technique. Normally also popular with Domain-Driven Design or Event-Driven Architecture. What’s the difference here between Event Storming and Domain Storytelling? It looks like there are some similarities.

[00:33:44] Stefan Hofer: I usually say that Event Storming, Domain Storytelling, but also other techniques like user story mapping or example mapping, they’re all like family members. So they are all members of this family of collaborative modeling methods, which means they have some things in common. But still, they also have some areas where one fits better than the other. So assuming that your listeners are somewhat familiar with Event Storming, because I won’t explain it down to detail. But the modeling language, of course, is a little bit different because they have these sticky notes and they are color coded. And the most important element of the notation is the “event” or something that happens in a domain. You express the business process as a series of events from left to right, so that’s your timeline. And that’s already a big difference.

So before I do a collaborative modeling workshop, I don’t say, well, this is going to be a Domain Storytelling workshop and hence I will do Domain Storytelling. I say, okay, this is a collaborative modeling workshop. Which tool fits best for the problem that my client has? And I’m trying to find that out before we have the workshop. If it is a problem or domain or business process that has a lot of people involved where there’s a lot of interaction going on. This is of interest to find out more about this interaction after several systems involved. We want to see who does what with whom. Then I would pick Domain Storytelling. If I know that the domain is more about, let’s say, status changes, more about this sequence of time, then maybe Event Storming is the better choice. Sometimes can also be interesting to ask how mature the process is already. So is it something that people can actually speak about? Then, again, I would rather use Domain Storytelling. If they need this brainstorming aspect of Event Storming, it’s just… there’s a facilitator, but it’s not as strictly moderated as Domain Storytelling. So everyone just starts with sticking orange sticky notes on a wall. So if I have the impression that this will be helpful just to let them express freely what they have on their mind, then I would rather go for Event Storming.

So there are different factors here at play. I often use both techniques in the same project or in the same workshop. I would say that in the last two or three years, I’ve used Domain Storytelling and Event Storming about 50/50. It’s really interesting to see how these tools can be combined. For example, what I did once was we had started with a big picture Event Storming workshop, and then we had, let’s say, one slice of this stream of events where different people, different roles were involved, and it was a very important part of the domain. So I said, well, I think the time would be good invested to look at this part of the process with this other technique – with Domain Storytelling because now, not the time is the most important element, but the actors are. So that the people and the software systems are the most important thing. We did that to get some more insight into the domain, and, “Ah, okay, now I see better how they are working together.”

We also did it the other way around a couple of times. For example, I started on a coarse-grained level with domain stories, it was an insurance company, to show the overall process. Within this process, we marked a series of sentences that were in the focus of this project, that this one team that I helped were supposed to do. And that’s helped him to see, okay, this part of the process, this is where we will change things, and before that, and after that. The process continues with some other people that also need to do things, and now we are aware that, okay, when we change something here, it will maybe affect other people there. So they said very helpful to scope the project. But then on the implementation level for software design, we switched to Event Storming because it was about money, about transactions, and stuff like that. And we thought that Event Storming is the better choice here for a software design model that is closer to how the software actually works.

[00:37:47] Henry Suryawirawan: So it’s very interesting that you can actually mix and match both techniques, maybe in one business domains, but different workshops, probably. Or you can zoom in using one technique and use the other technique if you want to zoom out. Thanks for sharing that.

[00:38:00] Online Collaborative Workshop

[00:38:00] Henry Suryawirawan: So in this pandemic era, obviously the first question is always collaborative workshop. How can we do that over maybe Zoom calls or Google Meet?

[00:38:08] Stefan Hofer: To my surprise, this works really well. I’ve been doing online collaborative modeling now for close to two years. I couldn’t have imagined that it would work so well. But still, you need to be aware of some things. This whole community of collaborative modeling practitioners, they shared their experiences in blog posts and in meetups. So it’s not just my knowledge that I can share now. It’s a collaborative knowledge.

I think the most important aspect is that you have an online modeling tool or some modeling tool that you can share and that everyone can see. So either a virtual whiteboard or some other modeling tool that you use, the moderator would then share, and everyone can see and interact. That is, of course, an important part. And then I also found that especially for larger groups, it’s really beneficial to have a second facilitator or moderator. Because it’s more challenging to keep an eye on people in a Zoom call, in a virtual meeting, than in a real life meeting. If you’re all in one room, body language gets easily lost, and sometimes people turn off the cameras, then you lose a way of getting feedback. If I’m in a real life meeting in a meeting room, and someone sits there with crossed arms and looks mean, and doesn’t say a word, then I would actively engage the person and say, “Hey Henry, I can see you have some concerns here. What is going on? Can you share what is on your mind?” This is hard if it’s a Zoom call with 20 people and your camera is off.

So one small trick is, for example, that the other person keeps track of how active are the people. So it’s just someone that hasn’t said anything yet, then we can actively ask for this person’s opinion, for example. Because usually, you end up with three, four or five people who say something and you, as a moderator, are so focused on them that you actually missed the other 15 people in the call who are silent. What’s going on there? Was it a mistake to invite them? Or why don’t they say anything? Yeah, so, this whole dealing with people thing, that’s a bit more challenging in remote settings. But I think the most important tool when it comes to collaborative modeling is that everyone can see the model. So you will have to use some software tool for modeling. Classical whiteboard or modeling on the wall is out of the question for this one.

[00:40:27] Henry Suryawirawan: I’ve been into some of these tools through collaborative workshop as well, you can put post-its or something like that. Sometimes it’s not so straightforward because especially, if you have so many things on the virtual whiteboard, where you zoom in, zoom out, it becomes very small. You can’t see what other people are doing. So maybe do you have some suggested tools that you like? A favorite?

[00:40:47] Stefan Hofer: Yeah, so, in general, for all sorts of modeling, I like to use Miro. I guess it’s one of the most popular ones with a rich set of features and moderating tools. But when it comes specifically to Domain Storytelling, we built our own little open source tool for that. It was actually before the pandemic. Because even in real life workshops, what I would usually do is I would connect my laptop to a presenter, and then presented in the meeting room onto a screen. Because if you want to do a lot of models, several models in one session, which is typically the case, it can be cumbersome to do it on white boards or on flip charts, because you can’t copy paste and you can’t compare them well, and so on. So for occasional modeling, that’s perfectly fine. Just go to a whiteboard and model on the whiteboard. But if you know that you will have maybe a dozen models or more, than a digital tool is definitely an advantage.

So the tool that we built is called Egon.io. That’s also the URL where you can find it, Egon.io. I’m sure it will be in the show notes. Actually, we are renaming it right now. Before, it didn’t really have a name. It was just called domain story modeler, but it’s not really a name. So we came up with something short and memorizable. It’s open source. I think one of the major advantages is that it can replay a story. So that is actually one of the reasons why I built it. Because if you use just some general purpose drawing tool, drawing is not the same as modeling. So drawing tools are not aware of the notation and of the syntax. Even though the syntax is very simple in our case. But what we can do with this tool is once you modeled several steps, you can click on a play button, and then you see the first step, and then you click next and then you see the second step. So it’s an animation. It helps you to narrate the story and to get feedback. That’s one of the most handy features, to replay the story and visualize it in that way.

[00:42:47] Henry Suryawirawan: Wow. It sounds really cool. I haven’t used such tool before. Like I’ll accept PowerPoint or like Google Sheet where you can have animations as well. But I guess this is built specifically for narrating the storytelling parts.

[00:42:59] Stefan Hofer: Exactly.

[00:42:59] Henry Suryawirawan: Probably can also be used for Event Storming, I guess, because of the sequence of time. Or maybe not?

[00:43:05] Stefan Hofer: No. It’s just purpose-built for domain stories.

[00:43:09] Henry Suryawirawan: So I’ll make sure to put that in the show notes. Give it a try. Domain Storytelling using this tool.

[00:43:13] 3 Tech Lead Wisdom

[00:43:13] Henry Suryawirawan: So yes, Stefan, thanks so much for elaborating this Domain Storytelling technique in-depth. Unfortunately, due to time, we have to reach the end of our conversation. But before I let you go, I have one last question that I always ask all my guests, which is for you to share your three technical leadership wisdom. Doesn’t have to be really technical. Sometimes it could be just leadership. This is just an advice for you to listeners out there, maybe based on your experience. What will be your wisdom?

[00:43:40] Stefan Hofer: Okay. So I guess my wisdom is more in the area of maybe product management or requirements. But I hope it is wisdom, and it’s useful for your listeners. So I think the first point that I want to make is that building software and, in general, modeling is about making abstractions. I can say that because I’m a software developer myself, and I think in software developer training, you learn a lot to abstract. But it’s really hard to make good abstractions because you first need to understand what you’re abstracting from. And that is something that in software developer’s education is lacking a bit. So my first wisdom is first, make sure you learn about the concrete things before you make abstractions, because only then you can make good abstractions. And how do you learn about the concrete things? You learn from examples, from scenarios, from stories. So first comes the story, and then comes to the abstraction of it.

The second point is don’t just look at isolated requirements or features that you’re supposed to build. Don’t just treat them as a shopping list and first you go build this, and then build that. No. Find out about the story behind it, about the context of the requirements. Because usually, they are connected in some way, built upon each other. So, find out about the story behind the features, and also why people say they want this? What is the motivation behind it? Don’t just blindly build what your users tell you. Find out the story behind it.

The third point, and that’s maybe something that is more for business analysts, requirement engineers, product owners, people in that capacity. When analyzing requirements, don’t stand between the domain experts and the development team. So don’t be a proxy or a translator, be a facilitator, a teacher, a connector. Bring together those two. That really makes a difference, at least in areas of processes where you can do that. If it comes to tenders where you make a bid based on a document and requirement specifications, then it’s a little bit different, of course. But whenever you actually work with development teams, don’t stand in their way and bring them together with the people who have the actual domain knowledge.

[00:45:57] Henry Suryawirawan: Wow. It’s really beautifully said. This is my first time hearing such wisdom, actually. So it’s really unique. Thanks for sharing that. I really liked the last one because sometimes yeah, we have product managers. We have business analysts or maybe equivalent roles. Sometimes they just step in, making a lot of assumptions, but actually, the domain experts may know better. So thanks again for sharing that wisdom. So Stefan, for people who want to learn more about Domain Storytelling, or reaching out to you, where they can find you online?

[00:46:24] Stefan Hofer: If you go to domainstorytelling.org, you can find a contact page. There’s my Twitter handle, @hofstef, and also an email address there. Then, of course, there’s the book. It’s also linked on the webpage. And I’m also speaking frequently at conferences and meet-ups. Now, still virtual, but hopefully in the future, also again in person. So if you see me somewhere, just come up to me and say hi. We’ll talk a bit about Domain Storytelling or modeling or whatever you find interesting.

[00:46:56] Henry Suryawirawan: Cool. So, thanks again for spending your time, Stefan. I really, really enjoyed the Domain Storytelling.

[00:47:01] Stefan Hofer: Thanks again for having me. It was great to have this conversation with you. I also enjoyed it.

– End –