BT

Facilitating the spread of knowledge and innovation in professional software development

Contribute

Topics

Choose your language

InfoQ Homepage Podcasts Domain Storytelling with Stefan Hofer and Henning Schwentner

Domain Storytelling with Stefan Hofer and Henning Schwentner

Bookmarks

Domain storytelling is a technique for understanding a business domain by relying on people’s natural ability to learn a new language by listening to other people speaking that language. In this episode of the podcast, Stefan Hofer and Henning Schwentner cover when to use domain storytelling, what is involved in the pictographic language, and how to have productive storytelling sessions. They go into far greater detail in their new book, Domain Storytelling.

Key Takeaways

  •  Domain storytelling is a modeling technique, and uses a pictographic language with simple icons for actors and work objects, joined by activity arrows.
  • The technique is meant to be very simple, with almost no technical requirements – a whiteboard and sticky notes could be enough. This allows a storytelling session to begin just by having the right people in the room, and not needing to learn a modeling tool or language first.
  • Not all people are natural storytellers, so it helps to have a moderator who can guide the process by asking questions. An important activity may be assumed as obvious, and might take a little effort to get captured in the story.
  • Individual stories can be categorized by three dimensions. Time: either as-is or to-be; Scope: either fine-grained or coarse-grained; and Purity: either the pure domain in business terms or the digital implementation. Each point in the categorization matrix serves a different purpose, from understanding an existing business process to describing a new feature.

Transcript

Introductions [00:16]

Thomas Betts: Hey everyone. Just to let you know, our online software development conference, QCon Plus, is back this November 1st to the 12th. You can expect curated learning on the topics that matter right now in software development. QCon Plus is a practical conference, laser focused on learning from the successes and failures of domain experts at early adopter companies. If you enjoy the conversations we have on this podcast, you'll get a lot out of QCon Plus. To learn more about the conference, head to qcon.plus.

Welcome back to another episode of the InfoQ podcast. I'm Thomas Betts, co-host of the podcast, lead editor for architecture and design at InfoQ, and a senior principal architect at Blackbaud. My guests today are Stefan Hofer and Henning Schwentner, the creators of Domain Storytelling, and authors of a new book on the subject. We'll be discussing what is Domain Storytelling, when you should use it, and how does it compare to other knowledge sharing techniques. Stefan and Henning, welcome to the InfoQ podcast.

Stefan Hofer: Thank you. Great to be here.

Henning Schwentner: Hello, Thomas.

What is Domain Storytelling? [01:13]

Thomas Betts: So let's just start off with what is Domain Storytelling and how did you start using the technique?

Stefan Hofer: Storytelling is at the heart of human communication, right? So we thought why not use storytelling and stories, listening to stories, telling stories, to have meaningful conversations about business processes and the software that supports them. So it's a technique to bring together people, stakeholders from different departments, software developers, product managers, product owners, business analysts, and, of course, the domain experts who really know how the business works. And they can all come together, and, with domain storytelling, they can get a shared understanding of a business process, and they can use it for different things like analyzing problems in these processes or designing new, better processes and how software can support them.

Henning Schwentner: What I would like to emphasize is that the idea is, of the main storytelling, like with all collaborative modeling methods, is that we want to have a very low barrier, that we want to have a notation and a format that's easy to understand by people that have no technical background. So it's a meaning for conversation between technical people and non-technical people. So we want to bring together domain experts, users on the one side and developers and all other peoples that develop software on the other side. And since you said we came up with domain storytelling, we have to be honest there, we didn't invent the method. So we learned the method at the University of Hamburg, where it was invented and had a strange, very academic, very German name, and Stefan came up with a new name which is a bit more catchy. So it's Domain Storytelling today and not exemplarische Geschäftsprozessmodellierung anymore. That really is a word, we didn't make that up.

Thomas Betts: As a native English speaker, I appreciate that. I can say Domain Storytelling, probably, has a little bit more appeal. So what is involved in telling the stories? How do you communicate them? I've seen examples, I've read the book personally, but you can describe that for our listeners.

Stefan Hofer: I'd say there are at least three aspects. So you, of course, need people who tell the story and other people who listen. So we already mentioned that. And then it's not just storytelling, it's actually a modeling technique. So you need a modeling language. We call it a pictographic language because it uses simple icons to show who is doing what with whom. So who, that's the people or the software systems, those are the actors, that's how we call them. And what do they do? Those are activities. We just draw arrows for that. And what you do with those activities? You create, you change, you communicate objects, things, informations, concepts from the domain. So these things we call work objects, and we also use icons to represent either the medium, like a document or an email, or maybe we represent a physical thing. For example, we did some modeling in the port of Hamburg. And when we talk about ships and containers, then we draw little ships and containers. So that's the second thing.

And the third thing is usually a moderator who helps the storytellers to keep the story going, who asks questions, but who also takes care of the modeling and everyone, all the participants, they see the model as it evolves. So it's a whole experience. It's not just a result in the end, the finished picture, the drawing, the model. It's also the experience of being there, of sharing information, of learning from each other. That's an important aspect too.

Henning Schwentner: I wanted to say, and maybe that fits on the first part of Stefan's answer, that the idea is that we want to get rid of misunderstandings. So that's what's happening a lot when we have communication between software developers and non-software developers on the other side. So users wish for things and think, well, everything can happen and developers think of something totally else. So when they discuss with each other, then the main expert says black and the developer understands white, and that's why we have this pictographic language. That's why we draw these diagrams because with those, we can show what we have understood. We developers show, "This is what I have understood. Did I understand you right, dear domain expert?" And then the domain expert can say, "Yes, you did right. You did understand me right," or, "No, we have to change this here, or that there."

Stefan Hofer: "I forgot a step in between, or, no, the arrow is wrong, it should go in the other direction." Stuff like that. That happens constantly and it's really valuable feedback.

Thomas Betts: And so it sounds like it's a little bit more, like I said, it's a collaborative discussion. Instead, if someone says, "I think this happens, and this happens, and this happens," and you just ask, "Well, did you hear that correctly?" Someone might not fully understand it, but want to say, "Oh I did." But if you write it down, you can go back and everybody can point to the words that you said and the diagrams and say, "Yes, this is correct," or, "Change this a little bit."

People may be experts in their domain, but they're usually not expert storytellers. They need a little help and they need questions that help them articulate what they do. People are usually not used to speak about the work so many things would otherwise remain unsaid. So by asking questions like, "Where do you get this information from? How do you know that you have to do this now?" That helps keep the story going and helps the story to unfold.

Thomas Betts: As you get more experience being a moderator, you tend to learn those techniques of how to pull out the story from people?

Stefan Hofer: Yeah, but it's not only the moderator's job. So usually with listeners who want to learn something about this domain, about this business processes, as Henning said, usually those listeners are from a software development team, or business analysts, or product owners. And, of course, you can also ask questions because they know best in which direction the conversation has to go. That way, the domain knowledge gets into the heads of the development team, and then in the end into the software where it belongs.

Henning Schwentner: And another thing that's nice of having a visual representation of the process, or of the domain of what's happening, is that we can see differences. So we have the possibility to show how the process is working now, that's what we call as-is modeling, and it might also be interesting to see, okay, how will the process be in the future, what we call to-be modeling. When we see how will this process work when we have built a new software system or when the regulations will change, how does that affect the process and all that stuff? So the time is also something that comes into this idea of storytelling.

The pictographic language [07:48]

Thomas Betts: Again, it's an audio format for the podcast. It's hard to see this and I'm sure people can go to the website and see examples, but what does the pictographic language look like? Are there dozens of icons that people have to learn? Is it specific to your use case? Do you need to come up with them?

Henning Schwentner: Well, as a consultant, being a consultant, I answer, of course, it depends to this question. So it can be dozens of icons if you like to, but usually it's not a good idea. So you've asked do you have to learn a lot of icons? I think the idea is not that the pictographic language has a lot of icons. The pictographic language says, well, there are two kinds of icons. One kind of icon, those are the actors, usually stick figures, and the other kind of icons are work objects. And for those work objects, we usually use different icons. And depending on which tooling you use, you can choose the icons yourself. So a usual way to use domain storytelling is to draw out these domain stories on a whiteboard, maybe combined with sticky notes, and then it depends on your drawing skills, how to draw these stuffs.

Disclaimer, Stefan and I, we are both not very talented drawers or painters and still we're able to learn a handful or two handful of useful icons there. Another possibility is to use digital tooling, which of course happened in the pandemic a lot. So there's this tool which is called bpmn.io, which is a browser based tool which you can use to draw the main stories and there's a limited set of icons that you can use for the domain stories that you're drawing. And what we both recommend is that when you draw a domain story or a couple of domain stories for one domain, that you make yourself a set of icons, which is two or three handfuls, so the people that are in the domain storytelling sessions, so storytellers and listeners, that they get used to these icons and know there's a special meaning for this document icon, or for this dollar sign and they have a typical meaning in our domain here.

Thomas Betts: And then the structure of the sentences. I think this is one of the things I picked up from the book is you're trying to not capture every possible scenario. The fact that you're showing this actor with this work object, and then the arrow you said is the activity, puts a lot of constraints on that. Is it difficult for people to express those? Is it something you get better at or does it provide good guardrails so it helps them focus their conversation and focus how they're trying to talk about and tell the story?

Stefan Hofer: Actually, I think it helps to focus. So that's why I think this technique works so well. We usually don't introduce it beforehand. We just go into the workshop before we talk about what business process and so on, what we want to model, what we don't need to teach the method beforehand. I think focusing on just one storyline really, really helps people to not drift into obscurities of the domain and not get lost in detail. So we call this also scenario-based modeling. So every picture is about one story or one scenario from beginning to end, without ifs and thens and buts. So it's just one storyline and I think that's one of the strengths of this method.

Henning Schwentner: That means also that it's typical that we are not only drawing one domain story, but that we are usually modeling several domain stories. One reason for that is that we have no conditionals in the pictographic language. As Stephan said, we are doing scenario-based modeling. Every domain story is telling one scenario. And if you want to look at a different scenario, if else you don't have case, you model another scenario. That's one reason for having several domain stories but there's also another reason for that. It's because we want to look at different aspects, what we call the scope. One example for that, we talked about that earlier, is this point in time when we see as-is versus to-be modeling that we draw different stories. And another reason is that we want to look at the scope factor that we call granularity. Are we coarse-grained from a bird's eye perspective? Are we fine-grained? Do we look onto all the details? Those are different kinds of modelings that can all be interesting depending on the situation that you are in.

Scopes and dimensions of domain stories [11:54]

Thomas Betts: Okay, so I'm going to touch on that. You said there's course-grained, fine-grained, to-be, as-is. You could model all of those, but it's up to the specific workshop that you're doing to figure out here's the problem we're trying to solve, here's the scenario, we're trying to understand, the story we're going to get to. We're not trying to capture everything all at once.

Henning Schwentner: Yeah.

Stefan Hofer: Exactly, yeah.

Henning Schwentner: And there's even a third dimension when we talk about these scope factors, which is called domain purity. So are we looking at the pure domain process, or are we looking at the story with I.T. systems, which we call pure or digitalized? Both of these dimensions can be interesting. And as you said, it depends on the purpose that you have. Do you want to learn a new domain and domain language, or do you want to draw boundaries? Do you want to implement a domain model? This has influence on which kind of scope you are going to choose. So for example, when you are going to find boundaries, then it's typically a good idea to be more coarse-grained, to look from a bird's eye perspective. When you want to implement a domain model, derive a domain model from the domain source, then it's better to be more detailed, to go into a fine-grained modeling.

Alignment with domain-driven design [13:02]

Thomas Betts: So when you said boundaries, that sounds like a DDD bounded context. I know I first got introduced to this at a DDD conference, but is this something that aligns really well with domain-driven design, thinking you're going to talk about this domain and we're going to find those boundaries?

Stefan Hofer: Yeah, exactly. So many of domain storytelling use cases that are actually within the context of domain-driven design. So if you're into this philosophy of software development, if you want to do strategic design, finding subdomains or bounded contexts within your domain that are the basis then for software architecture, or for organizing teams, that's something that we use Domain Storytelling for, but also on a more fine-grained level. So, again, we have this fine-grained. If you want to model your domain, a model on a level that is detailed enough to actually derive a software model from that, you can also use it on a more fine-grained level. So, of course, finding the ubiquitous language that is spoken within a context, the language in which you talk with your stakeholders, the language in which requirements are captured, those are all use cases of domain storytelling within DDD.

Thomas Betts: I'm assuming the ubiquitous language is the actors and the work objects that you're representing. Those icons should be very clear in this context, here's what this represents.

Stefan Hofer: Exactly, yeah. It makes it visual, and it helps you to capture the ubiquitous language.

Henning Schwentner: On the other hand, you don't have to do DDD to use Domain Storytelling. Most of the time, it's a good idea to use DDD but if you're not into domain-driven design, it still makes sense to use Domain Storytelling. For example, it's also a tool that can help you find user stories. So when you're in an agile context and you want to build your product backlog, for example, with user story mapping, then Domain Storytelling can be something that you want to do in the first place to find the backbone of the user story map. If we do a coarse-grained to medium-grained Domain Storytelling session, then you will find sentences that might be the start for coarse-grained user stories. Domain story, user story, that's kind of confusing. They sound the same, but they are not the same. Sometimes they're very close, but sometimes they're different. It's a bit like with Java and JavaScript. So they're similar names, but, well, it depends on what you're doing,

Thomas Betts: But it does seem like you're not trying to fully document everything a system's supposed to do. This is often used as an exploratory technique. Find the boundaries and then if you need to go deeper, you can do stories that flush out those specific details within your bounded context, within your subdomain. But you're not trying to write the novel, that is the full documentation of everything the system does.

Stefan Hofer: Usually a handful of examples is enough to understand even complex business processes. So it makes no sense to model or document every possible variation of a process. Usually it's the, let's say the happy path or the 80% case, that is important, and maybe one or two important error scenarios or edge cases that are relevant, that have significant impact. Those are important cases that you want to model to gain enough understanding and then for digging deeper, you might switch to other techniques. You might switch to user stories, user story mapping, example mapping, DDD style techniques. That's another thing that we learned, or let's say incorporated, in our way of using Domain Storytelling in the last couple of years. Usually in a software development project, it's not just a one size fits all modeling approach that you need. You will need several modeling approaches. You might use event storming and Domain Storytelling and example mapping in the same project, sort of different ways to combine these methods.

A comprehensive modeling tool belt [16:45]

Thomas Betts: That was actually the next thing I was going to ask about, is how does this compare to some of those other techniques? As a replacement? But it sounds like it's very much meant to be working alongside. You have these other tools in your tool belt. Here's the right one to help flesh out and something else might do something different, whatever those are.

Henning Schwentner: That's exactly what we think it is. You have a modeling tool belt and there are different tools there and there are situations where you need the hammer, but as we all know, a golden hammer is a bad tool for everything, so you also need a screwdriver, a wrench and other tools. That's also true for modeling. What's interesting, the tools in modeling are newer than those craftman tools that we were talking about earlier.

So it's pretty much clear when to use a hammer and when to use a wrench, but it's not so clear of when to use, for example, domain storytelling versus event storming. There are a lot of situations where they both can work pretty well, and there are situations where you start with one tool and then you see this is not working at all. And then you can switch to other tools and hope to get a grip on it. So that's what we want to do. This also means to be a good modeler, you have to learn different tools, which takes some time, but usually it's very rewarding in the end to be able to talk to many different people, understand what they are doing and make them happy by building great software in the end.

Stefan Hofer: I'm helping a team at a moment to build a new piece of software and the first thing we did was, together with two domain experts and the product owner, we came up with one or two domain stories that show this is the vision of how to use this product. This is the business process that this new piece of software should support, including the people who are involved, actors, and some other systems that receive data or get some data. And so that was the first thing that we did. It's in a finance domain. So the team, the development team then decided they want to use event sourcing and CQRS as architectural pattern and naturally method-like event storming on a design level fits much better to that development style. So we switched methods and said, okay, so this is the Trimble process. And now for this part of it, for this activity here and the domain story, let's model in more detail, how this would look like in a CQRS style system design, event-source design. So for system level modeling, we switched to a different method and it works together perfectly, I think.

Virtual domain storytelling workshops [19:13]

Thomas Betts: I know event storming gets talked about as a really great technique. Very collaborative. People go up, and sticky notes go on the wall. But I know it has struggled to be done remotely. In fact, I know Alberto said, "No, you can't do it remotely." And that was back in 2019 before you didn't have an option. Do you find that this works well, or okay, remotely with teams, because you can use the tool and just have a easier conversation? You're not trying to put sticky notes everywhere?

Henning Schwentner: What I learned in the pandemic is that even event storming can work out very well in a remote setting, if you have the right tooling. So you need the right virtual whiteboard, you need people that are somewhat used to that tooling, and it's also working. And what all collaborative modeling techniques suffer from, of course, is that you can't get very close to your collaborators. You can't smell them. You don't see their body language. You don't see when somebody's rolling eyes when they don't want you to. All those factors are, of course, interesting in collaborative modeling because they show problems and all the details that are around these sessions.

Having said that, when you have the right tooling, like bpmn.io that we were talking about earlier, then domain storytelling works very well in distributed situations. So, Stefan, we've both done many sessions in the pandemic and before that, over Zoom and Teams and all the video platforms, and that works out well. And I think for some parts, it even may be better because you're not as limited as you are on a whiteboard or on a wall in the virtual space. You don't have the boundaries. You can go everywhere. That's one thing that can be even better. Nonetheless, of course, I'm looking forward to having real world conversations and real world modeling sessions, as the standard, sometime in the future again.

Thomas Betts: So earlier you said that when you're doing a workshop, you didn't have to do a whole lot of training beforehand, of here's how we're going to do domain storytelling. People are able to just walk in. You tell them ahead of time this is the story that we're going to be describing. And seems like that lends itself to what you were describing about working remotely. You don't have to get people familiar with the virtual whiteboard before you can be successful. If you have the moderator, whoever's documenting it is the person in the room who knows how to use it, they can really help guide the conversation.

Stefan Hofer: I think that's true. Can be helpful to lower the barrier. But then on the other hand, if the people don't model themselves, some people might not be that engaged. So I found that when doing it remotely, it's even more important to ask questions and to check almost continuously, is this right? Did I understand it correctly? And retell this story from time to time from beginning to wherever you are right now so that everyone is still engaged and keeps telling the story.

More resources [22:18]

Thomas Betts: I think we're coming up close to the end. The book I saw is available for download now as an ebook, and if people want a physical copy, because it's fun to read, that'll be available for pre-order now, and by the time this podcast comes out, it may show up. Where can people go to find out more about Domain Storytelling?

Stefan Hofer: The best place to find out more is domainstorytelling.org. That's our website where we have links to the book, obviously to training, but also to a list of resources, videos, podcasts, articles. That's the place to go.

Henning Schwentner: If you've listened to this podcast and thought, yeah, well that sounds nice, but I have to see that, then probably one of those videos is the next step to go. That can be found on YouTube and the like.

Thomas Betts: I'd have to agree. It's saying that when you experience it or see it demonstrated, it makes a little more sense and I hope that the listeners will take the time to go and follow up and find some place that they can use this in their work day. I've already used it with my teams and it's been very helpful. So I want to say a final thank you to Stefan Hofer and Henning Schwentner for joining me today on the InfoQ podcast.

Stefan Hofer: It's been our pleasure. Thank you very much for having us.

Henning Schwentner: Thanks, Thomas, and see you soon.

Mentioned

Learn how to solve complex software engineering and leadership challenges. Attend in-person at QCon London, (April 4-6) or attend online at QCon Plus (May 10-20).

QCon brings together the world's most innovative senior software engineers across multiple domains to share their real-world implementation of emerging trends and practices. Find practical inspiration (not product pitches) from software leaders deep in the trenches creating software, scaling architectures and fine-tuning their technical leadership to help you make the right decisions. Save your spot now!

More about our podcasts

You can keep up-to-date with the podcasts via our RSS Feed, and they are available via SoundCloud, Apple Podcasts, Spotify, Overcast and the Google Podcast. From this page you also have access to our recorded show notes. They all have clickable links that will take you directly to that part of the audio.

Previous podcasts

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT