Chapter 1. Introduction

Spoken language is deeply, deeply human. Some things must be said that cannot be written.

—Avraham Poupko [Poupko 2018]

What Is Domain Storytelling?

Image

Domain Storytelling is a collaborative modeling technique that highlights how people work together. Its primary purpose is to transform domain knowledge into business software. This purpose is achieved by bringing together people from different backgrounds and allowing them to learn from each other by telling and visualizing stories.

Telling stories is a basic form of human communication. It is deeply rooted in all of us since the times our ancestors lived in caves.1 In our modern world, telling a story might seem archaic or childish. How can an activity so informal help us to build business-critical software for domains such as logistics, car manufacturing, e-commerce, and banking?

1 See The Desirability of Storytellers [Yong 2017].

We believe that conversations cannot be adequately replaced by written, formal specifications. Attempts to do so have even widened the gap between business and software development. But that is not just our personal opinion. Consider software development approaches like agile, Domain-Driven Design, or Behavior-Driven Development. These philosophies focus on feedback and stakeholder involvement. Nevertheless, making great business software is hard, but rarely is this because of technical problems. So why then? Because software developers need to understand how the day-to-day business operates. They need to become domain experts themselves—not for the whole domain but at least for the part they build software for. As Alberto Brandolini put it:

It’s developer’s (mis)understanding, not expert knowledge, that gets released in production. [Brandolini 2016]

Telling stories still works in the age of software. In our experience, telling and listening to stories helps with the following:

• Understanding a domain

• Establishing a shared language between domain experts and IT experts

• Overcoming misunderstandings

• Clarifying software requirements

• Implementing the right software

• Structuring that software

• Designing viable, software-supported business processes

Telling stories is a means for transporting domain knowledge from the heads of domain experts into the heads of developers, testers, product owners, product managers, business analysts—anyone who is involved in developing software. Of course, we do not sit around campfires in dark and damp caves anymore. We share our stories while we meet in front of a whiteboard in a workshop. The domain experts are our storytellers. We want them to tell us the true stories from the trenches—no abstract “ifs,” no hypothetical “coulds.” We want concrete and real examples of what actually happens in the domain. We want domain stories.

Note

You can learn more from a good example than from a bad abstraction.

Once, storytelling was an oral activity. Domain Storytelling is an oral and visual activity, a form of modeling: While the domain experts tell their story in spoken language, one of the workshop’s participants—the moderator—records the story as a diagram made of simple icons, arrows, and text. This way the participants get another representation of the story, which helps to uncover misunderstandings, contradictions, and plot holes. All participants see how the visual recording evolves together with the story. This makes it easy to give feedback and to contribute.

And that is Domain Storytelling.

Your First Domain Story

Matthew runs a small movie theater for arthouse films—called Metropolis—that enjoys an excellent reputation among cineastes. Local craft beer and organic snacks round off the cinema experience. One day Matthew meets his school friend Anna. When he learns that Anna has been developing apps for almost ten years, he gets an idea.

Movie theater manager Matthew: “My customers like the old-fashioned charm of my cinema. But they do not like my old-fashioned box office. Today’s moviegoers are not used to buying tickets in person at the box office anymore. Customers have been asking me to sell tickets online. Can you develop an app for me?”

App developer Anna: “You run just one cinema, and there’s only a handful of movies per week, two or three shows a day. Sounds easy.”

Matthew: “Great! But one small thing: We also show international movies in foreign languages in our program. Also, in addition to the online sales through the app, I still need the box office for less tech-savvy moviegoers. And I’d like users of the app to be able to sign up for a yearly subscription.”

Anna: “Subscriptions? Online and offline sales? Shows in foreign languages? That’s more complicated than I thought….”

The Workshop Begins

The next day they meet again in Matthew’s office. They are standing in front of a whiteboard, and Anna is holding a marker in her hand.

App developer Anna: “Yesterday you said that the app essentially has three use cases: One: selling standard tickets; two: selling special tickets for foreign-language movies; and three: signing up for a yearly subscription.”

Movie theater manager Matthew: “Uh, yes, that’s right.”

Anna: “I would like to understand how Metropolis operates today. That will help me to develop an app that meets your requirements. Could you please explain to me how you sell tickets at the box office?”

Matthew: “Sure. You sell the tickets and mark the seat in the seating plan and…”

Anna: “Wait a minute. Who sells the tickets?”

Matthew: “I have two students working for me. But sometimes I do it myself.”

Anna: “Okay, but what role do you or the students have then?”

Matthew: “Cashier.”

Anna draws a stick figure on the whiteboard and writes “cashier” underneath (see Figure 1.1).

Image

Figure 1.1 The first actor

Anna: “Who buys the tickets?”

Matthew: “A moviegoer. One without a subscription.”

Anna draws a second stick figure and calls it “moviegoer.” Next to it, she writes down that the moviegoer has no subscription (see Figure 1.2).

Image

Figure 1.2 The second actor and the first annotation

Anna: “What does a moviegoer have to do to buy a ticket?”

Matthew: “They tell the cashier which show they want to see.”

Anna: “I will draw a speech bubble as an icon for the show here, because the two of them talk to each other.”

Anna continues drawing and numbers the arrow (see Figure 1.3).

Image

Figure 1.3 The first activity

Anna: “And then?”

Matthew: “Usually the cashier suggests the best seat available.”

Anna: “Ah, so the moviegoer picks a seat in advance! How does the cashier suggest seats?”

Matthew: “I take the seating plan for the show and search for available seats. In the seating plan, I can see which seats have already been sold and which are still available.”

Anna draws and explains the icons.

Anna: “Here, I’m using a film icon instead of the speech bubble to symbolize the show.”

Matthew: “The seating plan is a grid. Can you draw a grid?” (See Figure 1.4.)

Image

Figure 1.4 The second activity

Then, Anna reads back what she has understood.

Anna: “Second, the cashier gets the seating plan for the show. Third, they search for available seats. Is that OK?” (See Figure 1.5.)

Image

Figure 1.5 The third activity

Matthew nods in agreement.

Anna: “And now the cashier suggests the available seats to the moviegoer?”

Matthew: “Exactly.”

Anna: “I will move the annotation ‘does not have a subscription’ up a bit to get enough space for that fourth sentence.” (See Figure 1.6.)

Image

Figure 1.6 The fourth activity

The discussion continues….

Retelling the Story

Within a few minutes, the whiteboard is filled with a story about a moviegoer who buys tickets from a cashier at the box office. Icons and arrows are rearranged during the session. Finally, Anna retells the story from the beginning (see Figure 1.7).

Image

Figure 1.7 The whole story

Matthew: “Yes, that’s right. But I forgot about the international movies.”

Anna: “You mean the shows in a foreign language? I thought you sell special tickets for those.”

Matthew: “No, no! We usually show the movies in English. When it is a foreign movie, we also show it in its original language. We don’t sell extra tickets; you only have to point out to the moviegoers which language the movie will be shown in.”

Anna: “When does the cashier do that?”

Matthew: “Here.”

Matthew points to the arrow with the number 4. Anna amends the sentence “Cashier suggests available seats to moviegoer” with a comment “and mentions language” (see Figure 1.8).

Image

Figure 1.8 Adding another annotation

Anna: “It seems we are finished with our little ‘Going to the movies’ story. Of course, we have looked only at the best possible outcome; I call this the ‘happy path.’ I will ask you about other cases later.”

Matthew: “OK.”

Since Matthew does not have any further remarks, Anna takes a picture of the whiteboard with her smartphone and moves on.

Exploring Further

Anna: “Once a moviegoer has bought a ticket, what do they do with it?”

Matthew: “They go to the entrance of the theater where the usher is waiting and….”

Anna turns the whiteboard around, and Matthew tells her how the usher checks tickets.

After a few FINE-GRAINED Metropolis domain stories, Anna has gained a good insight into the cinema domain. She knows terms like “seating plan,” “show,” “cashier,” “to search for available seats,” and “to mark seats.” She has an initial understanding of the most important processes.

Anna realizes that it would be helpful to have an overview of the processes—a “big picture” that holds all the stories together. Anna and Matthew decide to model a COARSE-GRAINED “Going to the movies” story (see Figure 1.9).

With the knowledge about the purpose of the app and its context, she can think about how the app will work and how the processes will change.

Summary and Outlook

This section was called “Your First Domain Story”; what you have probably noticed is that this was also your first Domain Storytelling workshop.

For Anna, this was surely not the first time she applied Domain Storytelling. Why was this technique useful for Anna in this situation? First, Matthew was not able to explain to her what he wanted. He had an idea in his head but had not really thought about how to make it actionable. To start a conversation about Matthew’s idea, Anna first had to establish common ground: Which terms does Matthew use when he talks about his business, and what do they mean? Which business processes are relevant, and what are the important steps in those processes? Who is involved in those processes?

From that starting point, they will be able to discuss what’s in scope of the project and what’s not. Without Domain Storytelling, they likely would have misunderstood each other. For example, Anna initially thought that selling tickets for foreign language movies is a separate process.

Since we will refer to the Metropolis example in the following chapters, we will give the domain stories the names “Metropolis 1” (see Figure 1.9) and “Metropolis 2” (see Figure 1.10) for easier reference.

Image

Figure 1.9 Metropolis 1: Going to the movies—COARSE-GRAINED

Image

Figure 1.10 Metropolis 2: Ticket sales, happy path—FINE-GRAINED

We want to highlight a few points that came up in this first example:

• Even with just a few domain stories, you can learn a lot about a domain, its language, and its business processes.

• Domain stories use a simple pictographic language to show people, their activities, and their interactions. This helps to uncover hidden assumptions and misunderstandings.

• While a domain story is told, its picture will evolve and change accordingly.

• It’s not just about drawing a nice picture; it’s also about bringing people together.

• Domain stories can vary in granularity.

• Usually, you will model more than one story in a workshop.

• A domain story has no “ifs” and “ors.” Instead, you model only the most important alternatives—each one as a separate domain story.

• A simple whiteboard is a good enough tool for drawing domain stories.

We will cover all these points in detail in the following chapters. The first point we will discuss is the pictographic language.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
34.201.37.128