Zum Stand der fachlichen Modellierung nach anderthalb Jahrzehnten DDD

Seit vielen Jahren entwickeln wir Anwendungssoftware, die Fachleute an ihren Arbeitsplätzen optimal unterstützen soll. Das ist eine fachlich anspruchsvolle Aufgabe, die nicht gelingt, wenn wir uns, wie früher üblich, Spezifikationsdokumente „über den Zaun werfen“ lassen. Agiles Vorgehen war für uns ein großer Schritt in die richtige Richtung. Gemeinsam mit allen Beteiligten Anwendungssoftware zu entwickeln – das charakterisiert agile Softwareentwicklung allgemein und auch die aktuellen Methoden der Softwareentwicklung wie Domain-Driven Design (DDD).
Doch im konkreten Projekt benötigen wir zusätzlich zu „agil“ und „DDD“ noch Techniken, um das fachliche Verständnis unter den Beteiligten einfach und schnell zu erreichen und festzuhalten. Diese Vorgehensweisen mit den dahinterstehenden Ideen und Konzepte fassen wir unter dem Etikett Collaborative Modeling (im Weiteren „CoMo“) zusammen.

Was ist Collaborative Modeling?

CoMo steht hinter vielen erfolgreichen Methoden, die traditionell unter „Anforderungsermittlung“ fallen würden. IT-Experten müssen die Domäne, also die Aufgaben und Arbeitsabläufe der AnwenderInnen, verstehen, um eine gute Anwendung entwickeln zu können. Umgekehrt sollen Fachexperten und Anwender verstehen, welche Möglichkeiten Software eröffnet und wie sich Digitalisierung auf ihre tägliche Arbeit auswirken wird. Entwickler und Fachexperten benötigen eine gemeinsame Sprache, um über die Domäne und die daraus erwachsenden Anforderungen an die Software sprechen zu können. Nur so wird die Software das widerspiegeln, was die Entwickler von den Anforderungen aus der Domäne verstanden haben und was Anwender und Fachexperten von einer Digitalisierung der fachlichen Prozesse erwarten. CoMo soll das Fachwissen aus den Köpfen der AnwenderInnen in die Köpfe von Entwicklern, Testern, Product Owners, Produktmanagern, Business-Analysten transportieren – zu jedem, der an der Softwareentwicklung beteiligt ist. Entscheidend ist hier direkte Rückkopplung zwischen allen Beteiligten. Das unterscheidet CoMo-Ansätze z.B. von einer klassischen Requirements-Technik, bei der Interviews geführt und daraus Szenarios abgeleitet werden.

CoMo ist im Domain-Driven Design (DDD) wichtig – der wohl aktuell erfolgreichsten Methode, welche die Fachlichkeit ins Zentrum der Softwareentwicklung stellt. Fachsprache, Ereignisse, Handlungen, Arbeitsmittel und Strukturen der Domäne bilden das sogenannte Domänenmodell, das die Entwickler in der Software abbilden. Ein valides Domänenmodell lässt sich nur gemeinsam von Entwicklern und Fachexperten erstellen. DDD-Experten wie Paul Rayner sehen Collaborative Modeling mittlerweile als eine Säule des DDD an (siehe Abbildung 1).

Abbildung 1: Collaborative Modeling als Säule des DDD (Quelle: Paul Rayner, Workshop auf der Explore DDD 2018. Foto: Martin Schimak)

Grundlegende Konzepte des CoMo

Wir sehen hinter den verschiedenen Techniken des CoMo folgende gemeinsame Konzepte:

  • Gruppenarbeit aller Beteiligten: Grundlegend ist, dass die verschiedenen Beteiligten auf Anwender- und Entwicklerseite gemeinsam Arbeitsprozesse und Anforderungen klären, statt dass einzelne Spezialisten auf der Basis von Interviews und Dokumentanalysen diese Themen spezifizieren. Alle Ansätze sehen gemeinsame Workshops vor; manchmal in großen Gruppen, manchmal mit wenigen Vertretern der Gruppen.
  • Geschichten erzählen: In den Workshops diskutieren die Beteiligten über konkrete Szenarien statt über abstrakte Beschreibungen. Szenarien werden wie Geschichten erzählt. Sind die Szenarien von allen verstanden, dann werden die für die Softwareentwicklung nötigen Abstraktionen und „vollständigen“ Abbildungen von Regeln und Fallunterscheidungen aufgebaut.
  • Über eine gemeinsame Sprache ein wechselseitiges Verständnis aller Beteiligter anstreben: Oft wird beklagt, dass die Fachabteilungen und die IT in ihren eigenen Welten leben und aneinander vorbeireden. Alle CoMo-Ansätze stellen dagegen die Sprache der Anwender in den Vordergrund; die verschiedenen Workshoptechniken sollen den Beteiligten helfen, sich besser zu verstehen.
  • Gemeinsame Modelle des Anwendungsbereichs erstellen: Unsere Erfahrungen mit CoMo zeigen, dass die gemeinsame Arbeit ein gegenständliches Ergebnis haben sollte. Die verschiedenen Modelle aus Zeichnungen, Karteikarten oder Post-Its sind mehr als ein Abfallprodukt. Sie zeigen allen Beteiligten den Stand der Diskussion, ihre grafische Darstellung geben eine neue Sicht auf das Thema und markieren am Ende eines Workshops ein handfestes Ergebnis, das oft in der weiteren Arbeit genutzt werden kann.

Beispiele für Ansätze des Collaborative Modeling

Mehrere CoMo-Ansätze haben weite Verbreitung gefunden. Im Folgenden betrachten wir ausgewählte Beispiele genauer. Worin unterscheiden sie sich? Unsere Auswahl ist nicht vollständig und orientiert sich an unserer persönlichen Erfahrung.

Event Storming

Beim Event Storming [Brandolini] erarbeiten sich Entwickler und Fachleute aus verschiedenen Bereichen mit Klebezetteln und Stiften ein Bild komplexer Geschäftsprozesse. Das Bild entsteht „bottom up“ als Folge fachlicher Ereignisse (sog. Domain Events), die eine konkrete Ausprägung des betrachteten Geschäftsprozesses beschreiben. Die Klebezettel erzählen eine Geschichte. Die Beteiligten können Inkonsistenzen und Reibungspunkte schnell und zuverlässig entdecken und sehen, wie das gemeinsame Verständnis der Domäne nach und nach an der Wand entsteht. Ein guter Start für Design und Implementierung nach DDD.

Namensgebend für Event Storming ist, dass im Workshop zunächst alle Teilnehmer (wie im Brain Storming) unkoordiniert „herausstürmen“, was in der Domäne passiert. Dazu schreiben sie, ohne sich abzusprechen, Domain Events auf orange Klebezettel und kleben sie auf eine Wand (siehe Abbildung 2). Je nach Ziel des Workshops führt der Moderator schrittweise weitere Farben ein, z.B. Pink für Hot Spots (Probleme, Konflikte, Fragen) und Lila für Policies (Geschäftsregeln).

Abbildung 2: “Big Picture” EventStorming mit Events und Hot Spots

Domain Storytelling

Domain Storytelling hat sich über Jahre als graphische Modellierungsmethode von Aufgaben und Geschäftsprozessen entwickelt [Hofer]. In gemeinsamen Workshops von Vertretern der Fachabteilung und dem Entwicklungsteam unter Leitung einer Moderatorin erzählen die TeilnehmerInnen Geschichten über ausgewählte Geschäftsprozesse und halten diese in Bildern fest (siehe Abbildung 3). Normalerweise reichen wenige Domain Stories aus, um einen Geschäftsprozess zu verstehen.

Abbildung 3: Aus der Domäne “Flughafen”: Passagiere vom Gate zum Vorfeld fahren

Domain Storytelling funktioniert auch für das Design von neuen, softwaregestützten Prozessen. Veränderungen zwischen Ist- und Sollprozessen werden so anschaulich.

User Story Mapping

User Story Mapping [Patton] kommt aus der agilen Community. Eine User Story Map strukturiert Anforderungen (grob festgehalten als User Stories) in einer zusammenhängenden Geschichte aus Sicht der Benutzer einer zu entwickelnden Anwendung. Die Beteiligten stellen in kurzen Sätzen die Interaktion mit der Software aus Benutzersicht mit Klebezetteln in zeitlicher Abfolge zusammen (die horizontale Dimension der Map). In der vertikalen Dimension sind die User Stories auf der Zeitachse (siehe Abbildung 4) abgebildet.

Abbildung 4: Aus der Domain Story (Abb. 3) abgeleitete User Story Map

Story Mapping ist häufig in drei Phasen unterteilt, in denen verschiedene Aspekte mit unterschiedlichen Personen erarbeitet werden: Produktfindung, Versionsstrategie und Backlog Refinement.

Example Mapping

Auch beim Example Mapping [Wynne] sind User Stories der Ausgangspunkt, um den Problembereich genauer zu verstehen. Anhand von Beispielen sollen vor allem Vertreter der Fachabteilung, Entwickler und Tester die fachlichen Regeln oder Randbedingungen einer User Story identifizieren, um daraus Akzeptanztests abzuleiten. User Stories, Regeln mit Beispielen und offene Fragen sind jeweils auf verschiedenfarbigen Karten notiert (siehe Abbildung 5).

Abbildung 5: User Story mit Beispielen (links) und durch die Beispiele gefundene neue User Stories (rechts)

Example Mapping eignet sich gut zu Beginn eines Sprints, um User Stories auf eine implementierbare Größe zu reduzieren und offene Fragen zu identifizieren.

Auf dem Weg zu einem gemeinsamen Verständnis von CoMo

Die verschiedenen Ansätze, die wir unter CoMo bisher betrachtet haben, lassen sich aus unserer Sicht so charakterisieren:

  • Sie unterstützen Vorgehensweisen und Techniken, mit denen sich die verschiedenen Beteiligten gemeinsam über die Aufgaben, Ziele und fachlichen Randbedingungen bei der Softwareentwicklung verständigen können.
  • Sie setzen dabei jeweils ihre eigenen Schwerpunkte, unterstützen verschiedene Fragestellungen und passen zu verschiedenen Entwicklungsmethoden

Wir wollen mit diesem Beitrag einen ersten Anstoß für eine Diskussion über die grundlegenden Gemeinsamkeiten der verschiedenen Ansätze des CoMo geben. Die Diskussion könnte zeigen, in welchen Zusammenhängen und für welche Fragestellungen sich welcher Ansatz besonders gut eignet, und wo eher nicht. Weiter interessiert uns, wie wir die Ansätze in einem Projekt mit einander kombinieren können, um ohne konzeptionelle Brüche eine durchgehende Unterstützung zu erhalten.
Schließlich hoffen wir, dass sich die verschiedenen Vertreter der CoMo-Ansätze auf eine gemeinsame konzeptionelle Grundlage verständigen, damit die vielen guten Ideen noch mehr ergänzen und damit verbreiten können.

Referenzen