Appendix. The History of Domain Storytelling

In the early 1990s, a group of computer scientists¹ at the University of Hamburg began to research techniques for business software development. They realized that it was important for developers to understand the tasks, workflows, and domain language of the future users. For joint workshops, the developers required techniques that would support equal cooperation between the various participants. The graphical means of representation available at that time, such as flow charts and UML diagrams, proved to be unsuitable. Those reinforced the model monopoly of the computer scientists in the sense of Stein Bråten [Bråten 1973].

¹ Including Christiane Floyd, Heinz Züllighoven, and Ingrid Wetzel (later Schirmer)

Inspired by Peter Checkland’s proposal of a generally understandable diagram technique—called rich pictures [Checkland 1975]—the group developed cooperation pictures as a technique for engineering requirements. A cooperation picture shows actors and the objects that the actors work with. Actors and objects are visualized as icons and connected with arrows to show joint tasks. The earliest paper in English on this method that we know of is from Anita Krabbel, Sabine Ratuski, and Ingrid Wetzel (later Schirmer) and was published in 1996 [Krabbel et al. 1996]. Figure A.1 shows an image from that paper visualizing the admission of a patient in a hospital.

Figure A.1 An ancestor of Domain Storytelling: cooperation pictures

Cooperation pictures are an ancestor of Domain Storytelling’s pictographic language. However, cooperation pictures did not tell a story. They were created in workshops with domain experts, but after the domain experts had been interviewed and textual scenarios were written—rather than during the discussion.

The idea for using a visual language for storytelling was born in the year 2000. A car rental company hired a university spin-off that is now known as WPS—Workplace Solutions Ltd. to work out some use cases for their business. The employees were familiar with cooperation pictures and knew that visualization techniques can greatly improve workshops. In their workshops, they drew cooperation pictures on whiteboards and added something new: They labeled the arrows with numbers to express a sequence of activities. Now, the pictures had time as a dimension and told stories. After the workshop, they preserved the content of the whiteboard by redrawing the picture on the computer. For lack of a better fitting tool, they used Microsoft PowerPoint. Figure A.2 shows an example of their work.

Figure A.2 One of the first scenario-based cooperation pictures

For documentation, they wrote down the story in prose, referring to the numbers in the picture. They chose this combination of written use cases and cooperation pictures over more formal business process modeling because they had had a great experience in workshops where domain experts had no background in computer science.

The new kind of diagram was initially called cooperation picture too and was later renamed cooperation scenario. It was a perfect fit for the agile, user-centered, domain-driven style of software development that WPS had been pursuing under the name Tool and Material Approach (T&M) [Züllighoven 2004]. The founders of WPS, Heinz Züllighoven and Guido Gryczan, had also (and with others) developed that approach. T&M recommends scenarios as a means for communication between domain experts and developers.

Cooperation scenarios were used by WPS employees and others in dozens of software development projects. Many people helped with improving the technique, and by 2003 it had become an enterprise modeling approach with several model types: Cooperation scenarios were augmented with a glossary, use case diagrams, org-charts, process landscapes, and (later) IT landscapes. Enterprise modeling without a proper modeling tool is cumbersome. That’s why a modeling solution based on BOC Group’s ADONIS was built. Figure A.3 is a picture from the banking domain, created with an early version of the modeling tool.

Figure A.3 A cooperation scenario modeled with tool support

For the next few years, a method and tool were developed in a kind of co-evolution. They shared a long, German, rather academic name: exemplarische Geschäftsprozessmodellierung (eGPM), which translates to exemplary business process modeling (eBPM). eGPM was taught and researched at the University of Hamburg. One of the academic papers of that era is “Design Rationale in Exemplary Business Process Modeling” [Breitling et al. 2006].

The two of us met in 2005, when we both joined WPS. That’s also when we met eGPM, which at the time was already our colleagues’ favorite method for learning about new domains, having conversations with domain experts, and deriving domain-driven software design. In 2011, a free modeling tool for eGPM was released as part of the University of Vienna’s Open Models Initiative. Stefan was one of the developers and gradually took over product owner responsibilities.

After Stefan had finished his PhD thesis on modeling enterprise transformation [Hofer 2017], he was approached by Carola Lilienthal, now CEO of WPS. She asked Stefan to take responsibility for the (somewhat dormant) method. Stripping down and renaming the method was the first visible result of this endeavor. In the summer of 2016, Stefan suggested Domain Storytelling as a new name for eGPM’s cooperation scenario. This new name intentionally resembles Domain-Driven Design (DDD). Henning, one of WPS’s most passionate DDD practitioners, had realized that the ever-increasing DDD community would be the right environment to grow Domain Storytelling.

We started talking and writing about this technique under the name Domain Storytelling in 2016. After our talk at the Domain-Driven Design Europe conference in Amsterdam in January 2018, we realized that to become a Domain Storytelling practitioner, you might need guidance that exceeds the format of talks, blogs, and hands-on sessions. Hence, we decided to write this book, which started as a self-publishing project on Leanpub and eventually moved on to become a “real” book at Addison-Wesley.

After presenting the method on DDD eXchange, Explore DDD, and KanDDDinsky, other members of the DDD community started to use and adapt it. It became clear that the different approaches for collaborative modeling have a lot in common. From this insight, the Visual Collaboration Tools book [Baas-Schwegler/Rosa 2020] and CoMoCamp [CoMoCamp Website] were conceived. Martin Schimak incorporated Domain Storytelling into Storystorming and invented an alternative notation with sticky notes [Schimak 2019]. Nick Tune used it as an inspiration for Domain Message Flow Modelling [Tune 2021].

In 2018 the development of an open-source tool was started: Egon.io—The Domain Story Modeler [Egon.io Website].

Meanwhile, Domain Storytelling has also been adopted by the Agile, requirements engineering, and Behavior-Driven Development communities. We are looking forward to continuing to write the history of Domain Storytelling!