zurück zum Artikel

"Ich öffne die Büchse der Pandora" – Interview mit Alberto Brandolini

Know-how
"Ich öffne die Büchse der Pandora" – Interview mit Alberto Brandolini

Alberto Brandolini versteht sich als 360-Grad-Consultant, da er die Perspektive des Architekten, Mentors, Trainers, Managers oder Entwicklers in einem Projekt einnehmen möchte. Er spricht zudem auf IT-Konferenzen in ganz Europa, ist Buchautor und lehrt Domain-driven Design.

Alberto Brandolini ist der Erfinder des EventStorming – einem Workshop-Format im Kontext von Domain-driven Design, mit dem man schnell herausfinden kann, was in der Domäne einer Software passiert.

Alberto Brandolini ist Erfinder der EventStorming-Methode – einem Konzept, das die Thesen hinter Domain-driven Design (DDD) in die Praxis übersetzt. Sein Buch "Introducing EventStorming – An act of deliberate collective learning" fasst seine wesentlichen Erkenntnisse zusammen. Tobias Goeschel, Principal Consultant und Trainer beim IT-Beratungshaus codecentric, hat ihn für heise Developer zu den Hintergründen gefragt.

heise Developer: Im Buch "Domain-driven Design" (2004) stellt Eric Evans einen Ansatz vor, komplexe Softwaresysteme aus einem Geschäftsfeld heraus zu entwerfen, angefangen bei einem Domänenmodell, das eine Zusammenarbeit von Domänenexperten und Softwareentwicklern erfordert. Dazu stellt er ein Framework für Designentscheidungen sowie die entsprechende Terminologie für die Diskussion über das Design der Anwendungsdomänen zur Verfügung. Kannst du kurz erklären, warum ein gemeinsames Verständnis von der Anwendungsdomäne in unserer Branche wichtig ist?

Alberto Brandolini: Domain-driven Design zeigt einen grundlegenden Fehler in der Softwareentwicklung für Unternehmen auf: die Annahme, dass wir Software auf der Grundlage verlässlicher Anforderungen bauen können. "Bauen" ist übrigens ein furchtbares Wort, denn Software ist kein Haus.

Das ist eine Illusion, und eine gefährliche noch dazu. Gewissheit besteht zwar bei einzelnen Anforderungen wie: "Es sollte möglich sein, Dateien aus der Version 2.1 zu importieren". Aber viele Anforderungen sind nicht unumstößlich. Sie enthalten Widersprüche – das liegt in der Natur von Organisationen mit Silos und Abteilungen, in denen unterschiedliche Ansichten und Bedürfnisse herrschen, ganz zu schweigen von versteckten individuellen Zielen. Evans verlagert außerdem den Fokus auf die Sprache. Selbst ihr kann man nicht trauen: Begriffe sind nicht eindeutig.

Deshalb macht sich DDD dafür stark, Software auf eine Art und Weise zu entwickeln, die ein hohes Maß an Geschick und Kompetenz in Softwarearchitektur voraussetzt. Dadurch hat man mehrere Optionen zur Verfügung. Außerdem sollte es möglich sein, mehrere, jeweils sehr effiziente Modelle zu entwickeln, die jeweils perfekt auf die lokalen Gegebenheiten zugeschnitten sind.

"Der unsichtbare Feind ist die Vorstellung vom "großen datenzentrischen Modell", die in den letzten Jahren so weit verbreitet war. Die grundlegende Mehrdeutigkeit von Sprache wurde durch eine datenzentrierte Implementierung beseitigt, die ganze Unternehmen zwang, sich darauf zu einigen, was "Kunde" oder "Bestellung" bedeutet und wie der Datenaustausch erfolgen soll – nur um sich einige Jahre später in einer Sackgasse wiederzufinden: Jeder ist auf dieselben Daten angewiesen, sodass jede Änderung zu riskant ist. Das Vertrauen geht verloren, die Weiterentwicklung verlangsamt sich und die Arbeitsplätze verlieren an Attraktivität.

Der SoftwareArchitekTOUR-Podcast hat dem Thema Domain-driven Design gleich drei Folgen gewidmet.

heise Developer: Das sind aber keine neuen Herausforderungen, oder?

Brandolini: Ich glaube, das ganze Problem existiert schon sehr lange, aber es fliegt uns erst jetzt um die Ohren. Zwei Faktoren sind dafür verantwortlich. Zum einen Microservices: Sie sind momentan angesagt, aber ihr Versprechen kann nur mit einer DDD-Denkweise erfüllt werden, besonders, wenn es um Bounded Contexts geht. Zum anderen der Arbeitsmarkt: Entwickler tendieren immer mehr dazu, ungesunde Arbeitsumgebungen zu verlassen, und meiner Meinung nach gibt es eine starke Korrelation zwischen bestimmten Architekturen, bei denen die Angst, etwas kaputtzumachen, vorherrscht, und der Unfähigkeit, Talente zu halten.

Ein tiefes Verständnis der Fachdomäne – wofür Domain-driven Design ja eintritt – kann die treibende Kraft für einen zielgerichteteren Ansatz in der Softwareentwicklung sein. Dabei sollte man verstehen, was richtig ist, und daraus die Software schaffen, die mit den wenigsten Kompromissen einhergeht. Das fühlt sich nicht nur gut an, sondern bringt mich auch dazu, im Unternehmen bleiben zu wollen, damit ich sehe, was am Ende dabei herauskommt.

Die Erfindung von EventStorming

heise Developer: Im Jahr 2013 hast du dein Workshop-Konzept EventStorming vorgestellt, das die DDD-Philosophie in Gruppenzusammenarbeit und eine leichtgewichtige Modellierungstechnik übersetzt. Wie bist du darauf gekommen?

Brandolini: EventStorming war keine geplante Erfindung. Das erste Mal, dass ich mit farbigen Haftnotizen auf einem Stück Papier modellierte, war während eines kleinen Treffens der italienischen DDD-Community. Mein Freund Emanuele Delbono moderierte den Workshop und beschrieb den Prozess, den er untersuchen wollte. Dann teilten wir uns in Gruppen auf.

Ich musste schnell ein paar Grundlagen festhalten, also nahm ich eine Papierrolle, fing an, mit DDD- und CQRS-Bausteinen (Command Query Responsibility Segregation) zu skizzieren, was ich verstanden hatte, und hatte innerhalb weniger Minuten etwas fertig. Währenddessen hatten die anderen Teams noch nicht einmal angefangen.

Wichtig hierfür war das Umfeld: Es war keine Business-Umgebung, ich befand mich in Gegenwart kluger Freunde. Die Kombination gab mir die größtmögliche Experimentierfreiheit: Ich konnte die Einführung überspringen und gleich ins Eingemachte gehen. Wir warten dort, um uns auszutauschen, und Mängel, die in einem Experiment auftreten würden, sprach man gleich an.

Dann fing ich an, diesen Ansatz – ursprünglich Event-Based Modeling genannt – zu verwenden, um Anfängern DDD-Bausteine zu vermitteln, ohne die traditionellen Definitionen durchzugehen. Das funktionierte und überzeugte. Der eigentliche Durchbruch geschah, als Vaugh Vernon mich als Special Guest zu seiner IDDD-Tour in Leuwen und Krakau einlud. Das war nicht nur ein Kurs, es war ein Raum mit 50 bis 70 erstaunlichen Menschen, die EventStorming liebten, es in ihren Jobs und in ihren lokalen Communitys ausprobierten und unglaublich wertvolles Feedback, Ideen und Varianten lieferten.

Alberto Brandolini bringt sein EventStorming-Konzept im Oktober und November 2019 nach Deutschland: In den beiden Workshops in Hamburg und München lernen die Teilnehmer, ihre Domäne ganzheitlich aus der Perspektive aller beteiligten fachlichen Experten zu betrachten und zu verstehen. Mehr Informationen und Tickets finden sich auf der codecentric-Website [4].

heise Developer: Du hast EventStorming schon mal mit Pizzabacken verglichen – was angesichts der Komplexität der Probleme, die gelöst werden sollen, erschreckend trivial erscheint.

Brandolini: Ich bin Italiener und weiß, wie komplex die Herstellung einer guten Pizza wirklich ist. Ein guter Freund von mir ist im Feinschmecker-Pizza-Business, und man braucht definitiv eine Menge Wissen, um ein unvergessliches Produkt aus scheinbar einfachen Zutaten herzustellen.

Was ich mit der Pizza-Metapher sagen möchte, ist, dass kooperativ validiertes Business Storytelling eine Plattform für anspruchsvollere Überlegungen ist. Es gibt Varianten des Grundrezepts (big picture recipe), die verschiedene Workshops ermöglichen – sie haben alle dieselbe Grundlage, aber die Vorgehensweisen können sehr unterschiedlich sein.

Was mich begeistert, ist die Möglichkeit, einzelne Elemente aus den Disziplinen aller Beteiligten zu einem sehr flexiblen und leistungsfähigen Werkzeug zu kombinieren. Würde man zu orthodox mit dem Rezept umgehen, würde man vieles von dem verhindern, was auf magische Weise entsteht. Natürlich werden einige Leute schlechte Rezepte machen, aber andere werden dafür mit einem hervorragenden Rezept aufwarten.

heise Developer: Acht bis sechzehn Teilnehmer in einem Raum, die sich oft zum ersten Mal persönlich begegnen, alle mit subjektiven Ansichten und sogar Vorurteilen zur Anwendungsdomäne – wie schafft man es, in diesen geradezu chaotischen Zuständen ein kohärentes Gesamtbild zu erstellen?

Brandolini: Das ist Aufgabe der Moderation. Niemand will derjenige sein, der nur Haftnotizen an die Wand klebt und sie in einem chaotischen Raum zurücklässt. Wir können uns also darauf verlassen, dass jeder im Raum daran interessiert ist, das Chaos zu beseitigen.

Die strukturiertere Antwort ist: Schritt für Schritt. Wir fangen chaotisch an, besser gesagt, mit vereinzelt einheitlichen Ereignisclustern innerhalb eines uneinheitlichen Ganzen. Dann versuchen wir, Struktur hineinzubringen. Wir erkennen dann, dass unsere anfängliche Struktur naiv war und wenden ausgereiftere Methoden an, bis wir zu einer Ordnung gelangen, die für alle im Raum zufriedenstellend ist.

Das Chaos gemeinsam zu beseitigen ist ein Vorgang, der irgendwo zwischen Lernen und Teambuilding liegt. Aber er dient auch dazu, den Status quo in Frage zu stellen: Das anfängliche Chaos ermutigt kritische Stimmen, die nicht so leicht laut würden, wenn man mit einer aufgezwungenen Struktur anfangen würde.

Kohärenz ist nicht unbedingt mein Ziel. Besonders beim Gesamtbild muss ich den aktuellen Stand unseres Verständnisses des Geschäftsfeldes visualisieren. Wenn unser Geschäftsfeld inkohärent ist, muss ich es realistisch darstellen, nicht irgendeine geschönte Version davon. Dabei bin ich ein besonderer Freund von Hot Spots: Alle Meinungsverschiedenheiten werden visualisiert, einige können behoben werden, aber nicht alle.

heise Developer: Es gibt weitere Ansätze wie Domain Storytelling, die sich vor allem darauf konzentrieren, Empathie zwischen den Beteiligten herzustellen. Wie gehst du mit der emotionalen Seite von Teilnehmern um, die diskutieren, Meinungsverschiedenheiten, unterschiedliche Dringlichkeiten und Prozessabläufe haben?

Brandolini: Emotionen sind kontextabhängig, und Menschen sind immer wieder für eine Überraschung gut. Ein Rezept, das den Umgang mit Emotionen genau vorschreibt, halte ich also für eine schlechte Idee. Aber als Moderatoren können wir mit solchen Systemen umgehen: Eine chaotische Runde, in der Probleme und Möglichkeiten angesprochen werden, wird jedem die Gelegenheit und manchmal auch die Anonymität geben, Dissens visuell darzustellen, ohne den Chef offen herauszufordern.

Ich beobachte die Teilnehmer, bitte diejenigen, die sich nicht beteiligen, leise um Feedback, und verfolge die Körpersprache, um zu sehen, ob etwas schiefläuft. Einige Dinge mache ich bewusst, zum Beispiel wähle ich einen informellen Ton, sodass Hierarchien und Distanzen wenig Raum haben, und ich vermute, dass ich auch einiges unbewusst tue, um den Teilnehmern ein Gefühl von Sicherheit zu geben.

Aber ich muss sagen, dass das Ganze oft ein kleines Wunder bewirkt: Es ist schwer, sich über seine Kollegen zu ärgern, die trotz ihrer Einschränkungen eindeutig ihr Bestes geben. Ich öffne zwar schon die Büchse der Pandora – aber was herauskommt, ist mehr Versöhnung als Streit.

heise Developer: Größere Unternehmen haben oft ein einzigartiges Regelwerk, das dem freien Informationsfluss zwischen Entwicklern und Domänenexperten Abbruch tun und gemeinsame Workshops erschweren kann. Wie gehst du mit einer solchen Unternehmenspolitik um?

Brandolini: Gar nicht. Ich mache nur ihre Wirkung sichtbar. Normalerweise werde ich nicht in eine Organisation gerufen, um eine Revolution zu starten. Es gibt Einschränkungen und Vorschriften? Machen wir sie sichtbar! Lasst uns die Auswirkungen sehen. Lasst uns sehen, ob unsere Wettbewerber das gleiche Problem haben oder ob sie genau die gleichen Einschränkungen haben. Sobald diese sichtbar und Teil des Problems sind, können wir "Was-wäre-wenn" spielen.

Ich persönlich habe festgestellt, dass es oft Diskrepanzen zwischen der Einschränkung und ihrer letztlichen Umsetzung gibt. Es gab immer einfache Lösungen, die sich vorbildlich an die Regel hielten, wenn die Einschränkung einen rechtlichen Hintergrund hatte, oder mit dem Grundgedanken zu vereinbaren waren, wenn der Einschränkung eine Unternehmensvorschrift zugrunde lag.

Im Lösungsraum gibt es eine Vielzahl von Möglichkeiten, die angewendet werden können: Unscharf definierte Prozesse können dem Geist einer Regel treu bleiben, ohne in starre Mechanik zu verfallen.

heise Developer: Welches Problem löst EventStorming und wie wird das erreicht? Wann ist es nützlich und für wen?

Brandolini: EventStorming ist nicht auf ein bestimmtes Problem ausgerichtet. Es ist eine Plattform, die Rezepte bereitstellt, die für ein breiteres Spektrum an Problemen nützlich sind. Die offensichtlichsten Probleme, die es adressiert, rühren von der Zusammenarbeit zwischen mehreren Silos her, da es hier an Sichtbarkeit, Transparenz und einer gemeinsamen Sprache mangelt und gegenseitige Schuldzuweisungen üblich sind. Immer dann, wenn eine Zusammenarbeit über Abteilungsgrenzen hinweg erforderlich ist, kann die Kombination aus ereignisgesteuertem Storytelling und Visualisierung unglaublich nützlich sein. (bbo [5])

Die Fragen stellte Tobias Goeschel. Als Principal Consultant und Trainer bei der codecentric AG hilft er Kunden nicht nur dabei, ihre Produkte zu verbessern, sondern auch die Art und Weise, wie sie gebaut werden.


URL dieses Artikels:
http://www.heise.de/-4510288

Links in diesem Artikel:
[1] https://www.heise.de/developer/artikel/Episode-59-Domain-driven-Design-DDD-4300844.html
[2] https://www.heise.de/developer/artikel/Episode-64-Domain-Driven-Design-DDD-Episode-3-4491758.html
[3] https://www.heise.de/developer/artikel/Episode-61-Domain-Driven-Design-DDD-Episode-2-4366106.html
[4] https://info.codecentric.de/eventstorming-workshop-with-alberto-brandolini
[5] mailto:bbo@ix.de