„Es waren zwei Königskinder…“

Wie Softwareentwickler kommunikative Brücken bauen mit Domain-Driven Design und Domain Storytelling

Als leidenschaftliche Übersetzerin zwischen IT und anderen Fachbereichen bin ich interessiert an Methoden und Rahmenwerken, die die Kommunikation zwischen zwei jeweils hoch spezialisierten Bereichen erleichtern. Eine diese Methoden ist das Domain-Driven Design.

pin

Domain-Driven Design

ist eine Methode der Software-Entwicklung, die darauf basiert, dass die Software ein System oder einen Prozess aus der realen Welt tiefgehend darstellt und widerspiegelt.

Der Begriff „Domäne“ bezeichnet dabei einen Wissens- und Tätigkeitsbereich, dessen Logik in der zu entwickelnden Software abgebildet werden soll. Mit anderen Worten, die „Domäne“ ist das, was in der Softwarewelt gemeinhin als „Geschäftslogik“ oder in der Businesssprache als „Geschäftsprozess“ bezeichnet wird.

Beim domänengetriebenen Entwurf wird die Geschäftslogik als das Herz der Software betrachtet. Je besser die realen Geschäftsprozesse durchdrungen wurden, umso höher kann die Qualität der entwickelten Software sein. Oder anders gesagt: Je besser Ihre Softwareentwickler oder allgemeiner die IT versteht um was es geht, umso besser kann die Aufnahme der Anforderungen erfolgen und umso näher am realen Bedarf kann die IT-Lösung sein.

Ich freue mich, dass mir Dr. Guido Gryczan, Geschäftsführer von WPS Workplace Solutions und Henning Schwentner, Coder – Coach und Consultant bei WPS Workplace Solutions in diesem Interview einige Fragen zu Domain-Driven Design und Domain Storytelling beantworten.

@Guido: Das „Manifest für Agile Softwareentwicklung“ wurde vor ziemlich genau 20 Jahren veröffentlicht und nur wenig später, im Jahr 2003, legte Eric Evans mit seinem Buch „Domain-Driven Design. Tackling Complexity in the Heart of Software” den Grundstein für DDD – Domain-Driven Design. Das Manifest stellt eine Art Selbstverpflichtung, quasi einen kollaborativen Ehrenkodex dar. Im Mittelpunkt stehen Qualität der eigenen Arbeit und Kundenorientierung. Von dieser Orientierung her zielt DDD in eine ähnliche Richtung.

Hat sich in dieser Zeit, vor etwa 20 Jahren, in der Herangehensweise der Softwareentwickler etwas verändert und falls ja, was war Deiner Ansicht nach der Grund dafür? Was war da los in der Zeit?

?

!

Das Manifest für Agile Softwareentwicklung und das Buch von Eric Evans waren sicherlich Meilensteine in der Entwicklung der Herangehensweise heutiger Softwareentwicklung Man kann aber noch viel früher anfangen, diese Geschichte zu erzählen.

Bereits 1984 nämlich hat Christiane Floyd, die erste Informatikprofessorin im deutschsprachigen Raum, bei der ich auch studiert habe, den Artikel „A Systematic Look at Prototyping“ in dem Buch „Approaches to Prototyping“ veröffentlicht. Die Ansätze kommen aus der skandinavischen Schule der Softwareentwicklung und sind sehr kollaborativ: Softwareentwicklung ist ein Lern- und Kommunikationsprozess. Beide, Anwender und Entwickler, lernen gemeinsam etwas über das zu lösende Problem. Das fließt ein in das Manifest und DDD.

Außerdem muss man bei der Art der Softwareentwicklung, die das Manifest und DDD im Blick haben und verbessern wollen, ausgehen von sehr großen und langwierigen Projekten. Wir sprechen hier über erste Entwicklungen in großen Zusammenhängen, für große Firmen, die erstmals in der Geschichte Abläufe „digitalisierten“.

An all diesen grundsätzlichen Problemen hat sich in den letzten Jahren nichts geändert. Geändert hat sich jedoch, dass wir nun über Methoden verfügen, unsere Arbeit besser und unser und das Leben unserer Kunden leichter zu machen. Wir haben kein Erkenntnisproblem, „nur noch“ ein Umsetzungsproblem.

Das Internet war natürlich auch ein echter Gamechanger. In den 70er-Jahren wurde begonnen, z.B. in Versicherungen, Software im großen Stil zu entwickeln. Mit dem Internet stieg die Menge an zu entwickelnder Software, viele Unternehmen öffneten sich der Nutzung von Technologie. Diese beiden Welten (Business und Softwareentwicklung) begegneten einander zum Teil erstmals und in erhöhtem Maße. Die Welt der IT hat sich drastisch verändert. Was die Technologie angeht, nicht was die grundlegenden zu lösenden Probleme angeht.

Warum also scheitern Softwareprojekte denn in der Regel? Nun ja, es ist nun einmal eine echte Beziehungsfrage mit 2 beteiligten Parteien. Man hat wechselseitige Erwartungshaltungen an das Ergebnis. Manche der Erwartungen sind ausgesprochen, manche unausgesprochen, andere entwickeln sich über die Zeit. Eine langfristig erfolgreiche Beziehung lebt davon, dass man die Grundlagen der Beziehung ständig erneuert. Benutzer und Entwickler müssen also zunächst eine Grundlage zur wechselseitigen Beziehung schaffen. Die Begegnung muss in jedem Fall auf Augenhöhe sein. Sonst kann das Potenzial der Beziehung nicht gehoben werden.

@Henning: Du hast mit Deinem Kollegen Stefan Hofer zusammen das so genannte „Domain Storytelling“ in der Softwareentwicklerszene etabliert und einen regelrechten Hype ausgelöst. Es handelt sich dabei um eine Methode, gezielt und ganz konkret einen Wissenstransfer zu ermöglichen. Also Wissenstransfer von denen, die Anforderungen an Software oder IT haben zu denen, die es letztlich realisieren sollen.

pin

Domain Storytelling

ist eine Technik, mit deren Hilfe erfasst und visualisiert, wie Menschen zusammenarbeiten. Konkret geht es um die Menschen, deren „Domäne“ dann in Geschäftssoftware oder IT-Lösung umgewandelt werden soll. Um dieses Ziel zu erreichen, werden Menschen mit unterschiedlichem Hintergrund zusammengebracht. In einem moderierten Prozess im Rahmen eines oder mehrerer Workshops werden Abläufe und Aktivitäten erzählt, gesammelt und visualisiert. Es entstehen so echte Geschichten, die im wahrsten Sinne des Wortes das Wissen der Domäne erzählen.

megafon

Wer lieber liest, kann sich entweder gleich Euer Buch kaufen „Domain Storytelling. A Collaborative Modeling Method“, die Website besuchen: domainstorytelling.org oder sich hier einen Eindruck von der Vorgehensweise verschaffen: „How Domain Storytelling reveils the secrets of your domain – Henning Schwentner, Stefan Hofer“.

Nun meine Frage: Nach wie vor werden fehlende Kommunikation und mangelnde Begleitung von Veränderungen als wesentliche Punkte für das Scheitern von IT-Projekten genannt. In wieweit kann Domain Storytelling dazu beitragen, das Verständnis für die Anforderungen an IT zu verbessern und die Qualität der Ergebnisse zu erhöhen?

?

!

Die Idee des Domain Storytelling ist, dass Anwenderinnen und Anwender eine echte Geschichte darüber erzählen, wie sie die Dinge im eigenen Arbeitsbereich tun. Das wird dann eine echte Bildergeschichte

Dabei kommt es nicht vor allem auf Vollständigkeit an, sondern das die Geschichte so erzählt ist, dass ich als IT-ler sie verstehen kann. Es muss vor allem eine typische Geschichte sein. Stell Dir vor, jemand schreibt einen Text über die eigene Tätigkeit. Davon abgesehen, dass das niemand will, wird es eine echt lange Geschichte, die eigentlich niemand lesen will. Stattdessen stellen wir mit Domain Storytelling eine Dialogsituation her, in der alle Leute zusammengebracht werden, die an der Geschichte oder dem Prozess beteiligt sind.

So einen Workshop zu moderieren muss übrigens Spaß machen und der Moderator/die Moderatorin muss über gewisse Fähigkeiten und Fertigkeiten verfügen. Wir achten bei WPS natürlich darauf, dass die Leute, die solche Workshops durchführen, das auch können.

Kommunikation ist uns insgesamt wichtig. Anders als das Stereotyp vom Programmierer im dunklen Keller mit Stapeln von leeren Pizzakartons suggeriert, arbeiten wir meist in großen Teams. Daher muss man nicht nur mit Anwendern, sondern auch miteinander reden können. Seitenhieb auf Informatikuntereicht in der Schule: genuin männliche Angelegenheit. Wilfried Brauer, ein weiterer Pionier der deutschen Informatik, brachte es einmal auf den Punkt: die männliche Perspektive auf Softwareentwicklung ist geprägt von Performance. Wie schnell ist ein Prozessor? wie viel Kapazität hat ein Computer? Die weibliche Perspektive ist Relevanz: Wozu ist das gut, was ich mache? Wie kann ich es besser machen? Aus unserer Perspektive müssen beide Aspekte zusammen gedacht werden (m/w/d). Wir achten daher sehr darauf, in gemischten Teams zu arbeiten, denn sie sorgen für Gleichgewicht. und Kommunikation.

Die Verwendung von Ubiquituos Language, meist übersetzt mit „allgegenwärtiger Sprache“, ist ein Grundprinzip von DDD. Die Domain Stories werden in dieser Sprache verfasst. Was ist an dieser Verwendung einer gemeinsamen Terminologie so wichtig? Was ist der Unterschied zu „Umgangssprache“? Gibt es dann nach einem Workshop ein Glossar für SoftwareentwicklerInnen/ IT und den DomänenexpertInnen? Soll Fachsprache oder auch unternehmensspezifische Sprache vermieden werden oder schließt sich das nicht aus?

?

!

Unser Lieblingsbeispiel entspringt einem Projekt für den Hamburger Hafen, an dem wir gearbeitet haben. (Die ganze Geschichte kann man sich auch als Youtube-Video ansehen.) Etwas verkürzt: Um zu verstehen, wovon unsere Partner sprechen, sind wir mitgefahren und haben uns angesehen, wie die die „Tiefenzahl“ messen. Warum? Weil sie in ihrer Geschichte den Begriff Tiefenzahl verwendeten und wir verstehen wollten, warum das wichtig ist und wie oder an welcher Stelle der Aktivitätenkette die Messung der Flusstiefe wichtig ist.

Der gleiche Begriff, den man sich gemeinsam erarbeitet, wird in anderer Abteilung übrigens möglicherweise anders verwendet. Was tun, wenn wir als Auftragnehmer aber trotz dieser unterschiedlichen Verwendung der gleichen Vokabel für beide Abteilungen Software entwickeln sollen? In diesem Fall reicht uns der so genannte „bounded context“ einer Abteilung oder eines Arbeitsbereiches für gemeinsames Verständnis zunächst aus. Untereinander haben die Bereiche ja offenbar bereits einen Modus operandi mit ihren Schnittstellen gefunden, der kein Problem darstellt. Wir jedoch brauchen ein jeweils zugeschnittenes Verständnis für das Umfeld, in dem wir entwickeln. Das Begriffsverständnis wird geschärft: wer tut was womit wozu? Ubiquitous Language baut daher vor allem was Verwendbares, abstrahiert, generalisiert. Spezifisch und ganz nah dran an dem, was der Kunde braucht. Und ja, wir erarbeiten ein gemeinsames Glossar.

Sollte es doch einmal zu unüberwindbaren Missverständnissen in der Begriffsverwendung kommen, können wir dann immer noch zur Entscheidung bringen, wie man die Begriffe verwendet. Wir haben dann ein Problemverständnis erreicht. Denn der Zweck agiler Entwicklungsmethoden ist es, zum frühestmöglichen Zeitpunkt festzustellen, dass WIR ein Problem haben.

@Guido + Henning: Eure eigene „Domäne“ ist ja auch lediglich ein Ausschnitt eines Gesamtvorhabens, z.B. Softwareentwicklung in einem Projekt zur Produktentwicklung. Andere Spezialisten nutzen ähnliche Techniken. So beschreibt beispielsweise Kim Godwin in „Designing for the Digital Age“ Kapitel 5 „Understanding the Business“ ihre Herangehensweise, um möglichst kundenorientierte Produkte und Dienstleistungen zu entwickeln. Es treffen also möglicherweise in ein und demselben Projekt verschiedene kreative und kollaborative Methoden aufeinander. Könnt Ihr aus der Praxis schildern, wie diese Ansätze voneinander profitieren können?

?

!

Im Vordergrund steht doch die Frage: Welche Mittel stehen uns zur Verfügung, um an die Lösung heranzukommen? Domain Storytelling ist eines der verfügbaren Mittel mit der Konzentration sich auf die Frage, wie die Akteure miteinander umgehen. Es gibt auch andere Mittel, wie z.B. Event Storming oder Collaborative Modelling.

Letztendlich ist es gut, eine Methodenvielfalt zu beherrschen und nutzen zu können. Man sieht ja auch wenige Handwerker, die nur mit einem Hammer oder nur mit einem Messer arbeiten. Ein guter Anforderungsermittler braucht einen Werkzeugkasten. Der schlechteste Fall ist ein Anforderungsermittler der keinerlei Möglichkeit oder Fähigkeit hat, das Wissen des Anforderers zu erschließen. Domain Storytelling kann diesen guten Beitrag leisten, zu lernen und (die richtigen) Fragen zu stellen.

Und damit sind wir eigentlich wieder bei der Frage zu Beginn des Interviews. Es hat sich vieles, aber auch wieder nichts geändert in den letzten 20 Jahren. Wir wissen nun aber, wie wir miteinander umgehen und DDD hat seinen Anteil daran.

Wie fange ich denn mit DDD am besten an, wenn es in meinem Unternehmen damit noch keine Erfahrung gibt? Wer sollte zum Beispiel in einem Workshop für Domain Storytelling teilnehmen?

?

!

Wie immer: Es kommt drauf an. Wenn beispielsweise das Ziel ist, monolithische Software-Systeme in beherrschbare kleinere Teile aufspalten, ist es sinnvoll zunächst die „bounded contexte“ festzustellen und diese dann Schritt für Schritt aufzuarbeiten. Alle betroffenen Akteure müssen sich gemeinsam das Bild der Lage erarbeiten.

Der Dreh und Angelpunkt jedoch ist die Beteiligung der Fachabteilungen und die explizite Unterstützung des Top-Managements, ohne die man dieses Unterfangen in großen Organisationen nicht durchsetzen kann.

Vielen Dank für das spannende Interview, Guido und Henning!

Ähnliche Beiträge