Transcript

[0:00] Ich habe mir dann Gedanken gemacht, warum kriegen wir das eigentlich nicht hin, Software Requirements richtig zu erfassen und zwar so, dass es halt jeder versteht, so dass es die Fachseite versteht, so dass es Security versteht, so dass es UX versteht, jeder.
Das Modell eignet sich ganz hervorragend, wirklich ganz hervorragend für eventbasierte Systeme.
In eventbasierten Systemen kannst du das Eventmodell eins zu eins im Code abbilden.
Ich könnte dem Postboten was vom Eventmodelling erzählen. Ich rede wirklich extrem gerne über das Thema.
Also wenn das jemanden interessiert, wirklich sehr, sehr gerne melden.
Ich rede stundenlang drüber.

[0:36] Music.

[0:59] Revision 606, moderne Verwaltungsoberfläche gebaut, mit der das Arbeiten Spaß macht.
Aber jetzt mal ehrlich unter uns Nerds.
Sachen anklicken? In einem User-Interface? Muss das sein? Nein, muss es nicht.
Denn bei Midwild gibt's die M-Studio CLI. Mit der könnt ihr euer Hosting komplett über die Kommandozeile verwalten und natürlich auch entsprechend automatisieren.
Von Nerds für Nerds bringt euch Midwild die optimale Developer-Experience, wenn's ums Hosting geht.
Und deshalb jetzt auf zu midwild.de slash workingdraft.
Denn da wartet auf euch exklusiv als Hörer von WorkingDraft das Angebot, den Tarif pro Space für 30 Tage kostenlos zu nutzen.
Das war nochmal mittwald.de.
Wir danken Mittwald für die Unterstützung von dieser Revision von Working Draft.

Revision 606: Dev, Business, Design & Marketing effektiv vereint

https://workingdraft.de/606/

[2:12] Hallo und herzlich willkommen beim Working Draft. Wir sind heute zu dritt.
Vom Team habe ich mit dabei den Peter. Moin, moin.
Und als Gast haben wir einen Wiederholungsgast, und zwar den Martin Dilger, der vor kurzem schon mal bei uns bei der Revision 594 vorbeigeschaut hat, als es darum ging, vom Chaos zu Code. Gerne nachhören.
Martin, ich freue mich riesig, dass du wieder mit bei uns am Start bist, Für die ein paar Hörer, Hörerinnen, die vielleicht die 594 doch noch nicht gehört haben, magst du dich nochmal einmal kurz vorstellen, wer du so bist?
Ja, hallo. Ich freue mich auch sehr, wieder da zu sein. Ich bin der Martin Dillger.
Ich bin Geschäftsführer der Nebulit GmbH, Softwareentwickler seit mehr als 15 Jahren, mache ganz viel IT-Architektur und arbeite in letzter Zeit sehr, sehr viel im Bereich Requirements Engineering und helfe Unternehmen, die richtigen Requirements zu finden für ihre Software.

[3:14] Und damit kommst du auch zumindest mir Wege rufen, denn kürzlich erst, als wir unsere Live 600 aufgenommen haben, hatten wir ein bisschen gesprochen auch über Designsysteme und Pattern Libraries und größere Systeme und ich habe die ganze Zeit verzweifelt ein Wort gesucht, von dem ich schon mal hörte, dass da ganz viele Leute, so die ganze Firma, nicht nur Devs, nicht nur Design, quasi vor so einer Tafel steht und Striche aufzeichnet, um Dinge zu machen.
Und du hast mich bereits in der Vorbesprechung schon darüber aufgeklärt, dass das wohl Eventstorming ist und mich auch darauf vorbereitet, dass wir heute ein bisschen auch in die ungefähre Richtung von dieser Thematik gehen. Deswegen freue ich mich da natürlich sehr drauf.
Also du hast quasi meinen Hilferuf aus der 600 gehört, als ich meinte, kennt sich denn irgendjemand damit aus?
Genau so ist es. Aber jetzt überreiche ich dann gleich schon mal das Wort an dich. Womit geht es denn los?

[4:12] Die letzten sechs Monate habe ich im Prinzip über nichts anderes nachgedacht, als was ist denn eigentlich das größte Problem, was wir in der Softwareentwicklung haben?
Woran scheitert es denn? Denn wenn du dir die meisten Softwareprojekte anschaust, dann funktionieren die nicht so richtig gut.
Kannst du wahrscheinlich bestätigen. Das bestätige ich.
Genau. Ich bestätige das auch so weit, dass jedes Mal, wenn ich bei Unternehmen bin und bei deren Jobseiten sehe, irgendwas von wir verwenden die coolste Technologie oder sowas, denke ich mir schon, das glaube ich ja noch nicht.
Auf der anderen Seite, wenn ich von, auch sehr großen Firmen dann höre, die sich fast schon entschuldigen wollen, also bei uns ist ja irgendwie, da sind so komische Sachen drin, wo ich mir denke, ich kenne, egal ob Startup oder die größte Firma der Welt, ich kenne keine Codebase ohne komische Sachen.
Richtig. Das ist, genau so ist es.
Und was glaubst du denn, was ist denn das größte Problem in der Softwareentwicklung?
Was würdest du denn sagen? Woran scheitert es denn?
Also ich bin überhaupt nicht darauf vorbereitet. Ich rede jetzt einfach, was mir jetzt im Kopf kommt.
Und ein bisschen habe ich schon auch das Gefühl, dass man ja von vorher immer heutzutage nicht mehr so weiß, wo man eigentlich am Ende hinaus kommen möchte. Und...

[5:35] Und dadurch muss man ja trotzdem, auch wenn man das jetzt nicht mit Workarounds und Hotfixes macht, sondern schon noch professionell, aber man erweitert halt immer ein bestehendes Haus.
Und man hat natürlich, ich meine, es gibt unfassbar viele Software-Engineers und irgendwie machen wir alle sehr gleiche Sachen, sehr ähnliche Sachen, aber wir brauchen, trotzdem brauchen wir immer unsere eigene Special-Lösung.
Und ich glaube, dass man für diese Special-Lösungen dann immer Sachen baut, die so ein bisschen implizites Wissen da drin haben und die werden dann auch immer so ein bisschen merkwürdig und die sind halt sehr eng mit Produkt- oder Firmenkultur auch verwebt.
Deswegen denke ich, das, was für mich vielleicht auch komisch wird bei Software-Strukturen, ist das, was vielleicht auch wirklich von der Firmenkultur da so ein bisschen mit reinkommt.

[6:26] Ich habe Anfang 2024 eine Umfrage gemacht auf LinkedIn, weil ich wissen wollte, was ist denn jetzt eigentlich das größte Problem? Außer Namen finden.
Namen finden ist natürlich auch ein großes Problem, aber das größte Problem sind Requirements.
Also insgesamt einfach Requirements. Was sind die Anforderungen an die Software?
Was sind die Requirements, die du umsetzen musst?
Wie kriegst du typischerweise deine Requirements? Du kriegst eine User-Story.
Die meisten User-Stories, die ich in meiner täglichen Arbeit zu sehen bekomme, die sind meistens eine Überschrift und eine Deadline. Vielmehr steht da eigentlich oft nicht drin.
Kennst du diese Art User-Stories? Ja, ja. Ich kenne auch Notion-Tickets.

[7:08] Ja, auch das. Genau. Und ich habe mir dann Gedanken gemacht, wieso ist denn das eigentlich so?
Warum kriegen wir das eigentlich nicht hin, Software Requirements richtig zu erfassen? Und zwar so, dass es halt jeder versteht.
So, dass es die Fachseite versteht, so, dass es Security versteht, so, dass es UX versteht. Jeder. Jeder.
Und ich glaube tatsächlich, das Problem ist, was wir nie gefunden haben in dieser ganzen Softwareindustrie, in der wir alle arbeiten, ist sowas wie eine gemeinsame Sprache.
Jeder definiert im Prinzip das, was er braucht an seiner Software.
Der Datenbank-Admin definiert irgendwelche SQL-Skripte.
UX definieren irgendwelche Screens, die gemacht werden müssen.
Du hast die Entwickler, die irgendwelche UML-Diagramme zeichnen, wenn überhaupt.
Vielleicht schreiben sie auch nur Code. Du hast den Product Owner, der die User Stories schreibt.
Jeder kocht so ein bisschen seine eigene Suppe, aber wir kommen da nie so richtig gut zusammen.
Und ich glaube, das ist einer der großen Probleme, warum wir einfach keine guten Requirements an unsere Software hinbekommen.
Wir haben keine Sprache, mit der wir reden können.

[8:17] Und andere, die komplexe Sachen bauen, haben die. Also wenn ich mir jetzt irgendwie so einen fetten, keine Ahnung, so einen fetten, hier, zivilen Flieger vorstelle, würde ich ja sagen, ist ja mit so einem dicken Software-Problem ja auch ungefähr vergleichbar.
Also du hast ja irgendwie so wirtschaftliche Requirements, das soll so und so viel kosten und du hast irgendwie Anforderungen zu erfüllen, so gesetzlicherseits und hast du nicht gesehen.
Also haben die dann einfach eine gemeinsame Sprache, mit der sie das hinkriegen oder fehlt da was anderes?
Der große Unterschied zur Softwareindustrie meiner Ansicht nach ist, dass du, wenn du jetzt ein großes Flugzeug baust oder wenn du ein großes Haus baust, dann ist das alles reguliert und zwar bis ins kleinste Detail.
Du brauchst Zertifikate, es ist alles bis ins kleinste Detail reguliert.
Und deswegen greifen die meisten Gewerke da gut ineinander und es funktioniert.
In der Software ist das Ganze ein bisschen anders, denn da hast du sowas nicht.

[9:12] Ein Softwareentwickler, der bekommt eine User-Story und der versucht, diese User-Story nach Besten und Gewissen umzusetzen, aber das, was der umsetzt, ist halt nicht unbedingt das, was jetzt beispielsweise die Fachseite wirklich braucht, sondern das ist halt immer das, was er halt versteht aus dieser User-Story.
Okay, also die User-Story ist sozusagen nicht präzise genug definiert im Vergleich zu ich habe hier irgendwie was, das muss dieses Material sein und so weit müssen die Bohrlöcher auseinander sein, um jetzt in der Analogie zu bleiben.
Ganz genau. Eine User-Story ist geschriebener Text.
Ja. Meistens. Die meisten User-Stories, die du als Entwickler bekommst, ist in irgendeiner Art und Weise geschriebener Text.
Und geschriebener Text ist halt relativ ungenau.
Ist nicht vergleichbar mit so einem Bauplan von so einem Haus beispielsweise.
Um auch bei der Analogie zu bleiben, ich habe ja so diverse Erfahrungen mit Hausrenovieren letztes Jahr gesammelt.

[10:04] Dementsprechend weiß ich auch, da sind sehr viele Sachen reguliert und die Pläne, die ich selber da gesehen habe, die waren teilweise sehr genau, dass ich mir selber dachte, da kann ja gar nichts schief gehen.
Da geht auch erstaunlich viel schief, nur…, Die Sachen mussten teilweise eben so komplett ersetzt werden.
Wir hatten das Glas bestellt und da waren einfach leider die falschen Bohrlöcher drin. Das fällt natürlich sofort auf.
Und da gibt es keinen Hotfix. Also man kann halt ein Glasloch nicht mit Glas wieder zumachen.
Und dann wurden wir auch angeschaut, ist das so okay? Und ich so, es tut mir unfassbar weh für die Umwelt.
Aber nein, das ist nicht okay. Da ist ein Loch in einem Glas.
Da soll es halt nicht durchregnen.
Und das musste halt komplett nochmal gemacht werden. Und bei der Software ist mir das zumindest tatsächlich jetzt so gut wie nie, wenn ich gar nicht über den Weg gelaufen, dass man wirklich gesagt hat, ja, das stimmt so jetzt nicht.
Wir müssen das nochmal von vorne neu machen, sondern dann wurde halt dran rumgebastelt.
Ist vielleicht auch einfach in der Software so, dass man ja normalerweise Code nochmal anpassen kann, im Gegensatz zu einem fixen Glas. Was du jetzt gerade noch gemeint hast, ist, mit jeder kocht ein eigenes Süppchen.

[11:15] Kommt das aus einer Sicht heraus, dass du meinst, so wie es einem halb selber so am besten passt?
Oder soll ich das jetzt eher in die Richtung verstehen, wie das ist aber sehr unbeabsichtigt und einfach nur der Kommunikation geschuldet, dass man mit anderen Worten Sachen bespricht oder auch andere Assoziationen zu bestimmten Wörtern im Kopf hat?
Das ist mit Sicherheit ein Punkt. Und auch wenn du dir jetzt zwei Entwickler anschaust, die das gleiche Requirement umsetzen, dann wird die Umsetzung höchstwahrscheinlich nicht gleich aussehen.
Denn jeder macht es ja auf seine Art und Weise. Wenn ich Software schreibe, schreibe ich die bestimmt ein bisschen anders als du. Das ist halt nicht standardisiert.

[11:58] Es ist halt eine, nennen wir es mal eine menschliche Tätigkeit, Software zu schreiben.
Ja, aber ich meine, wenn man dir jetzt irgendwie so einen RFC-mäßigen Standard vorsetzen würde, dann würden sicherlich auch zwei unterschiedliche Implementierungen rauskommen, aber die sollten ja dann zumindest grob die gleichen Ziele verfolgen, auf ungefähr vergleichbare Weisen mit etwas kompatiblen Interfaces, die da rausfallen. Warum nicht so?
Das sollte so sein, aber so funktionieren die meisten Projekte nicht.
Wie oft bekommst du einen ausformulierten RFC in deinem Softwareprojekt?
Weiß nicht. Also ich jetzt eher nicht so. Aber ich meine, die Frage ist ja, sollte das vielleicht so sein oder könnte es so sein?
Genau. Die Frage ist, wie kommst du denn zu Requirements, die tatsächlich einfach umsetzbar sind?
Genauso wie so ein RFC. Also das, was du sagst, ist ja völlig richtig.
Ein RFC wäre genau das, was du brauchst. Ein ausformulierter RFC, der genau beschreibt, was eigentlich gemacht werden muss.
Also ich jetzt als Nerd mit meinem Softwareentwickler ruhe da auf.
Also ich weiß jetzt nicht, ob jetzt irgendwie Designer-Dieter oder irgendwelche Marketing-Leute damit viel anmachen können.
Was du bräuchtest wäre ein RFC, der von allen gemeinsam geschrieben wird.
Dann würde es funktionieren, richtig?

[13:09] Naja, und der halt auch die sozusagen Sprachen und, sagen wir mal, auf irgendwelchen Grundregeln basierte, die halt auch in allen diesen Kontexten Sinn ergeben.
Um jetzt wieder zum Flugzeug zurückzukommen, irgendwie so Sachen wie Kosten und Bohrlochabstand ist ja dann schon sehr universell, wohingegen so Sachen wie irgendwie muss halt gut flutschen und muss in endlich viel Zeit fertig werden und muss halt am Ende wartbar sein, das sind ja Dinge, die überhaupt gar nicht auf der gleichen Realitätsebene existieren. Exakt.
Exakt so ist es. Ich denke jetzt auch nochmal an die Flugzeuge.
Ich hatte, wenn ich gerade in solchen Teams gearbeitet habe, wo es wirklich die Designabteilung, die Produktabteilung, die Developerabteilung, die Administratorabteilung gab, schon mit guten Leuten zusammengearbeitet, die, sage ich mal, so erduldet haben, wenn die anderen Experten in ihrem Fach gerade untereinander diskutiert hatten.
So, wenn wir jetzt ganz tief mal kurz über, ganz technisch über CSS sprechen mussten im Daily, haben alle anderen brav gewartet für eine halbe Sekunde, bis es dann hieß, nehmt doch das Thema bis nach später mit.
Ansonsten kenne ich eher die Grundhaltung, wie ihr das technisch löst.
Es ist ja euch überlassen, da seid ihr ja die Experten, Expertinnen in dem Thema.

[14:20] Und wenn ich das jetzt mal so noch weiter treibe, ich habe auch generell das Gefühl, dass es halt schon oft passieren kann, dass Software getrieben wird mit dem, wie auch dieses Team entwickeln möchte.
Ich weiß da nicht, ob da immer genau die, in Anführungsstrichen, richtigen Programmiersprachen, Frameworks etc. genommen werden.
Ob das jetzt HTMX, Quick Front View React, keine Ahnung was, wenn halt das Team React macht, dann wird es bestimmt eine React-Webseite werden und keine Astro-Webseite.
Und nochmal zum Flugzeug, ich weiß nicht, ich sehe das eher fast in der Einstellung von, irgendjemand sagt, wir brauchen ein Fortbewegungsmittel, aber ob da jetzt ein Flugzeug oder ein Zug rauskommt, ist jetzt nicht so wichtig.
Also ich glaube nicht, man Man bespricht quasi bei der Software, wir brauchen ein Flugzeug, sondern einfach nur, wir müssen von A nach B und dann kann ein Flugzeug oder ein Zug rauskommen.

[15:13] Unter bestimmten Voraussetzungen. Natürlich sagst du, du brauchst ein Fahrzeug von A nach B, das muss aber mich in der und der Geschwindigkeit da hinbringen und ich muss übermorgen um 10 Uhr genau da sein.
Und das müssen aber alle machen. An dem Fahrzeug muss dann natürlich auch der Security Engineer mitreden und natürlich auch das muss richtig Design sein und da muss ja alles passen an dem Fahrzeug.
Ja, und wenn ich so drüber nachdenke, würde ich sagen, ein großer Teil der Schwierigkeit in Abgrenzung zu so einem klassischen Engineering-Ding ist ja wahrscheinlich auch, dass das komplette Grundregelwerk, also sprich die Atome und die ganzen Basisbausteine, mit denen man hantiert, ja im gleichen Moment erfunden werden, wie die Dinge, die damit gebaut werden.
Also okay, man entscheidet sich jetzt vielleicht irgendwie für ein Framework, aber trotzdem irgendwie so Sachen wie, keine Ahnung, die Pattern-Library und das Ding, das das nutzt und alles, was dazugehört und die App und die Webseite, das entsteht ja mehr oder minder alles parallel, und das ist jetzt nicht irgendwie so, dass man sagen kann, das macht man schon seit den 60er Jahren oder wir nehmen das gleiche Teil wie damals.
Das passiert halt auch, aber eher selten.
Macht sich auch nicht einfacher.

[16:18] Wenn man das alles so betrachtet, ist es gar nicht so einfach, das unter einen Hut zu kriegen. Nö.
Immer wenn du so ein komplexes Problem hast, und genau darüber drüber habe ich nachgedacht.
Immer wenn du so ein komplexes Problem hast, dann hilft es meistens, das runterzubrechen. Und zwar so lange, bis du nichts Kleines mehr findest.
Die Wadden Conquer. Jeder Softwareentwickler kennt das. Und wenn du das runterbrichst, in das kleinste Problem, dann findest du irgendwann eine Gemeinsamkeit, die alle Softwareprojekte gemeinsam haben. Alle Softwareprojekte verhalten sich so.
Und das, dieser kleinste gemeinsame Nenner, den ich gefunden habe, ist, jede Software funktioniert so, dass du sagst, du hast einen Zustand, Und dann machst du irgendwas und dann hast du einen neuen Zustand.

[17:03] Jede Software funktioniert so. Und wenn du dir mal Gedanken machst, wie du jetzt von diesem ganz kleinen Modell zu Requirements kommen kannst, dann kommst du irgendwann ganz natürlich zu einem Werkzeug, was sich Event Modeling nennt.

[17:21] Event Modeling ist im Prinzip ein Workshop-Format, was du verwenden kannst, um Requirements an Software zu definieren. Und zwar so, dass alle Beteiligten mitreden können.
Das ist nämlich genau das, was wir vorher gesagt haben, diese gemeinsame Sprache, die alle reden können, die alle verstehen.

[17:41] Darf ich da gleich mal kurz reinquetschen? Ich frage mich jetzt gerade, inwiefern hat das jetzt was mit Domain Driven Development Design zu tun?
Da geht es ja irgendwie auch so darum, dass wir eine gemeinsame Sprache finden wollen, nicht nur unter Developern, das auch, aber auch, damit wir einfach mal zum Beispiel, wenn wir einen Fachbegriff dieser Software nennen, dass dann auch Designprodukt und Developer immer von dem Gleichen reden.
Ist das irgendwie verwandt oder ganz was anderes? Das ist die gleiche Ecke.
Also Domain-Driven Design, da geht es ja im Prinzip genau darum, dass du es irgendwie schaffst, Fachseite, Business Requirements, alles irgendwie unter einen Hut zu kriegen.
Das ist genau die gleiche Baustelle. Das Problem bei Domain-Driven Design ist, dass es kaum einer versteht.
Es ist relativ komplex, da reinzukommen und wenn du jemanden fragst, was ist ein Domain-Driven Design, dann kriegst du normalerweise von jedem eine unterschiedliche Antwort.
Da fallen dann so Begriffe wie bauende Kontext und unterschiedlichste Sachen, die die meisten eigentlich gar nicht so ganz genau definieren können.
Aber du bist schon auf der richtigen Spur. Das ist genau die gleiche Baustelle.
Du versuchst immer irgendwie die Requirements und das, was deine Software tun soll, so zu formulieren und so abzubilden, dass es halt jeder irgendwie versteht.

[19:01] Dieses Event-Modeling, das ist im Prinzip ähnlich wie das, was wir in der Vorbereitung kurz besprochen haben, das Event-Storming.
Event-Storming kommt ja auch aus dem Domain-Driven-Design-Bereich und da geht es im Prinzip darum, dass du Events in deinem System sammelst und strukturiert aufbereitest.
Und Event-Modeling ist was ähnliches wie Event-Storming, nur ist es ein bisschen näher an dem eigentlichen System.

[19:32] Und ich habe die Erfahrung gemacht, mit so Event-Modeling-Workshops ist es unglaublich einfach, Requirements an Software zu definieren und zwar in kürzester Zeit.
Beispiel, ich habe kürzlich einen Workshop gemacht mit einem Startup und wir haben innerhalb von einem Tag das komplette System von Anfang bis Ende geplant, inklusive aller Requirements, sodass die im Prinzip einfach anfangen konnten, die Software umzusetzen.
Also du kriegst wirklich innerhalb von einem Tag die richtigen Requirements, sodass du es umsetzen kannst.

[20:03] Das glaube ich jetzt tatsächlich, weil mir das aus der anderen Sicht immer eher so geht, wenn ich, ich meine, ich bin ja aus Gründen auch Software-Ingenieur geworden.
Ich mag Kontrolle über Dinge haben und ich mag die definiert haben und ich mag die hundertprozentig korrekt machen. Ich funktioniere schon auch so agiler und sowas, aber das ist so mein Grund.
Und vor allem, ich bin so ein Rätsellöser. Ich habe den größten Spaß an Rätseln.
Das heißt, wenn ich immer von Problemen spreche und wir müssen dieses Problem lösen, meine ich das immer sehr, sehr positiv.
Und andere Leute, du mit deinem Problem schon wieder. wieder.
Und was mir immer und immer und immer egal, wo ich arbeite, immer wieder auffällt ist, diese Probleme, von denen ich dann spreche, die lassen sich tatsächlich in, egal ob jetzt asynchron oder synchron, aber diese Sachen lassen sich sehr oft sehr schnell klären und fest definieren und festlegen und dann kann man anfangen zu arbeiten.
Aber ich habe oft das Gefühl, das ist so eine Grundangst, dass man das jetzt ewig diskutieren muss und die Meinungen gehen nur im Pingpong hintereinander und dass es ewig lang dauern würde, dass man oft mit der Herangehensweise eher herangeht, zu sagen, wir fangen mal an und schauen mal, was es wird.
Und das habe ich jetzt nicht mit Daten bewiesen, aber rein von meinem Gefühl dauert das halt dann im Endeffekt länger und es kommt halt nicht das voraus, was man eigentlich vielleicht hätte haben wollen, wenn man das eigentlich weiß, was man eigentlich wollte.

[21:25] Man kann ja nur wissen sozusagen, was man weiß, was man will, wenn man das tatsächlich schon wissen kann.
Also ich meine, es gibt ja da auch sozusagen den explorativen Ansatz bezüglich, wir bauen mal irgendwas so in der Richtung und gucken mal, wie es wird und das ist ja auch die Idee hinter dem Agilen jedenfalls zu einem gewissen Teil, dass man halt irgendwie nicht immer von Anfang bis Ende sehen kann, das soll am Ende definitiv rauskommen, sondern man sich stattdessen einen Mechanismus überlegt, wie man sozusagen managen kann, dass man es nicht weiß.
Ja, das stimmt, aber du hast schon bei jeder agilen, bei jedem agilen Step Cycle, ist auch egal, Sprint, weißt du zumindest für diesen Bereich schon, was der feste Outcome von dem aktuellen Zyklus sein soll.
Das ist ja richtig. Das Problem ist ja natürlich immer dann, die Dinger so zu umzusetzen oder halt eben auch zu planen, dass man sich damit nicht irgendwie perspektivischen Schwierigkeiten bringt, was ja mehr oder minder ein unlösbares Problem ist, weil du ja definitionsgemäß nicht weißt, was irgendwie in drei Monaten sein wird.
Das ist ja so diese agile Sicht auf die Dinge, was ja irgendwie einerseits ein Problem löst, andererseits halt eben auch auch potenziell weitere erschafft, weil man sich irgendwie in eine Ecke hineindrängt durch gewisse Entscheidungen, wo man dann irgendwie sagt, auf lange Sicht wäre das irgendwie besser gewesen.
Aber das sind ja auch so Dinge, die man abwägen muss. Deswegen ist das wahrscheinlich alles so ein bisschen schwierig, je nachdem, wie gut man halt irgendwie wirklich sagen kann oder je nachdem, wie sehr man weiß, was man da tatsächlich fabriziert und wo man am Ende ankommen wird.

[22:53] Wobei du meiner Erfahrung nach meistens, wenn du agil arbeitest, schon weißt, was du bauen willst und wo du eigentlich hin willst.
Du kannst nur nicht so ganz genau sagen, bis wann es schlussendlich fertig ist.
Also die große Stellschraube, die du ja, wenn du mit Scrum beispielsweise arbeitest, ist, du drehst am Scope.
Sondern du sagst, du hast immer die Möglichkeit, das Backlog zu priorisieren und baust immer quasi die wichtigsten Features, die jetzt gerade wichtig sind.
Du kannst aber nicht so ganz genau sagen, wann du jetzt schlussendlich fertig bist.
Das ist eigentlich die große Stellschraube, die du mit agiler Arbeit hast.
Meistens weißt du schon, wo du hin willst. Also dass du jetzt komplett explorativ arbeitest, das hast du vielleicht mal für so ein POC oder wenn du Dinge ausprobierst, aber wenn du jetzt mal so ein größeres Projekt anschaust, ungefähr wo du hin willst, wissen die meisten.
Die meisten wissen nämlich so ganz genau, was man dafür tun muss. Ja.

[23:45] Und dass man nicht weiß, was man da tun muss und welche Schritte man genau machen möchte, dass man nur sozusagen am Horizont sieht, aha, zu dem Turm wollen wir hinlaufen. das ist dann trotzdem durch das Event-Modeling abbildbar.
Wir können uns ja mal anschauen, wie so ein typischer Event-Modeling-Workshop ausschaut und wie das abläuft und dann können wir mal überlegen, ob das dann für alle Projekte funktioniert oder nicht.
Das Erste, was du nämlich machst, ist, du sammelst erstmal alle wichtigen Leute im Raum.
Alle dürfen kommen. Ein Event-Modeling-Workshop, den kannst du mit drei Leuten machen, den kannst du aber auch mit 25 Leuten machen und wenn du willst, auch mit 50.
Das funktioniert im Prinzip mit beliebig vielen Leuten. Auch wenn ich 100 habe?

[24:23] 100 habe ich jetzt noch nicht gemacht. Ich weiß auch nicht, ob es schon jemand gemacht hat, aber wenn du einen groß genugen Raum hast, dann wird es auch mit 100 funktionieren. Okay.

[24:33] Wichtig dabei ist, je mehr verschiedene Fachbereiche und Business Units mit dabei sind, desto besser. Also jeder darf da mitmachen.
Und ich bin ein großer Verfechter davon. Die zwei Personen, die mitmachen müssen eigentlich, zumindest beim initialen Workshop, ist der CTO und ist der CEO.
Die müssen da mitmachen. Das Wissen von diesen Personen braucht man.
Also du sammelst Security, du sammelst UX, UX ganz, ganz wichtig.
Du sammelst Entwickler. Alle machen mit. Datenbank-Admins.
Was hätten denn die C-Levels für ein besonderes Wissen, was sie mitbringen sollen?
Die haben die Vision. Die wissen, wo das Produkt sein soll. Die haben die Vision. Das ist das Wichtigste.
Und die haben das höchste Abstraktionsniveau? Wenn es alle verstehen müssen, müssen die es ja auch verstehen.
Die können da mitdiskutieren und der CTO unterhält sich mit dem Datenmarkt-Admin und beide verstehen sich. Ist das nicht fantastisch?

[25:32] Also das Erste, was du machst, ist, du sammelst diese ganzen Personen in einem Raum und dann überlegst du dir erstmal in der ganzen Gruppe, was sind denn eigentlich so die Ereignisse, die bei uns in der Software passieren.
Technisch heißt das Ganze Events, aber ich verzichte meistens sogar auf diese ganzen technischen Begriffe. Was kann in unserer Software passieren?
Nimm dir beispielsweise so ein ganz einfaches System. Stell dir vor, du willst Kinokarten kaufen online.
Du hast ein System, um Kinokarten zu kaufen. Was sind die Ereignisse, die bei uns im System passieren können?
Völlig unabhängig von der Technik. Technik spielt überhaupt keine Rolle.
Was kann passieren? Zum Beispiel wäre eine Sache, die passieren kann, ist, du hast deine Sitze reserviert.
Das wäre dann sowas wie Seats Reserved beispielsweise, englisch formuliert.
Also du formulierst diese Ereignisse immer in der Vergangenheitsform.
Was ist in unserem System passiert? passiert.
Sitze wurden reserviert, Karten wurden gekauft, Popcorn wurde gekauft, Bezahlvorgang wurde ausgelöst, Bezahlvorgang wurde abgeschlossen.
Du sammelst alle Ereignisse, alles was passiert.

[26:45] Und das dauert typischerweise so was, 30 Minuten, 60 Minuten, so was. Im letzten Workshop haben wir eine gute Stunde gebraucht.
Und dann sind wir so bei 104 Ereignissen rausgekommen. Für ein mittelgroßes System.
Und das sind die Sachen, die in deinem System passieren können.
Und da hast du schon auf einen Blick auf einmal alles, was dein Software-System eigentlich machen muss.
Das hast du heute eigentlich nicht. Wenn du heute eine User-Story aufmachst, dann hast du, kein Entwickler hat dieses Big Picture, kein Entwickler sieht auf einen Blick, was sollen unsere Systeme eigentlich machen, komplett.
Und da hast du jetzt, wenn du dir vorstellst, du machst das vor Ort beispielsweise, dann hast du 100, 200 Post-its an der Wand, wo einfach draufsteht, was unser System macht.

[27:35] Wo sind da die Grenzen von System? Sind die Grenzen da jetzt tatsächlich so in der User Experience, also das, was ich so als Nutzerin mit dem Ding machen kann?
Oder gehört da auch so Krempel irgendwie zu wie so rein technischer Kram, Deployment, endliche Kompilierzeiten?
Das sind ja auch, sagen wir mal, Anforderungen im allerweitesten Sinne, dass ja auch die unterschiedlichen Gewerke irgendwie, dass ich zu den Admins das rüberwerfen kann und die sagen hier, DevOps geht klar, kann ich jetzt deployen.
Also sowas betrachtest du im ersten Moment erstmal nicht.
Also sowas wie Bildzeiten oder sowas betrachtest du nicht. Wir betrachten wirklich das System.
Was soll unser System können oder beziehungsweise was soll in unserem System passiert sein? Also das System wirklich so als Benutzeroberfläche, auch wenn es jetzt nicht in Pixel untergebrochen wird, aber was kann jemand, der das nicht baut, sondern benutzt, damit anstellen?
Ganz genau. Das muss aber nicht unbedingt ein System sein, was jetzt wirklich eine Benutzeroberfläche hat. Das geht auch genauso gut für irgendwelche Batch-Prozesse.
Es muss aber ein System sein, das was tut.
Es hat ja eine Benutzeroberfläche sozusagen implizit, auch wenn ich nichts anklicken kann, aber irgendwer macht damit irgendwas.
Irgendwer ist Bediener von dem Teil. Ganz genau. Okay.

[28:50] So, jetzt hast du diese ganzen Ereignisse irgendwie an der Wand und das nächste, was du machst, ist, du clusterst diese Ereignisse.
Du brauchst erstmal Cluster mit dem schlussendlichen Ziel, dass du diese ganzen Ereignisse sortierst in eine Reihenfolge.
Du ordnest diese Ereignisse quasi eins nach dem anderen an, was passiert nacheinander in unserem System, sodass du am Ende im Prinzip eine Zeitlinie hast.
Doofe Frage. Was passiert, wenn die Reihenfolge unterschiedlich sein kann?
Ich kann ja erst das Popcorn kaufen und dann die Cola.
Ändert das was am Prozess? Nee, nee, nur wenn man jetzt, also falls jetzt man die ganze Gruppe fragt, jetzt sortiert das mal der Reihenfolge nach.
Und wenn jetzt die zwei, drei Schritte komplett egal sind, in welcher Reihenfolge die stattfinden, ist das jetzt wichtig oder spielt das jetzt keine so große Rolle? Im Prinzip spielt das überhaupt keine Rolle.
Also bei der Sortierung, da hast du schon den ersten großen Benefit, weil die Leute nämlich anfangen zu diskutieren und die diskutieren, muss das jetzt als erstes passieren?
Muss das jetzt als erstes passieren? Und plötzlich diskutiert der Security-Mensch mit dem Datenbank-Admin und jeder diskutiert miteinander und man versucht quasi rauszufinden, was ist denn jetzt eigentlich die richtige Reihenfolge?
Was soll jetzt eigentlich unser System machen?
Und du versuchst dann im Prinzip dieses, alle Ereignisse in eine Zeitleiste zu bringen.

[30:16] Und was du dann hast, ist, du hast plötzlich quasi dein System in einer Zeitleiste und jeder kann es lesen von links nach rechts.
Und zwar so, dass es jeder versteht, denn jeder kann Ereignisse lesen.
Du hast keine technischen Begriffe, da ist einfach nur aufgelistet, was macht denn eigentlich das System?
Also ein Ablaufdiagramm einer Was-passiert-dann-Maschine. Ganz genau.
Im Prinzip, was du da im Prinzip hast, das sind die Statusübergänge, die dein System abbildet. State Transitions.

[30:50] Ich muss jetzt auch nochmal bei System einhaken. Und zwar jetzt mal kurz von der Kinogeschichte-Wechsel wieder auf eine Software.
Rede ich hier gerade von dem ganzen System und im Endeffekt werde ich wahrscheinlich so ein Zehntel davon bearbeiten?
Oder kann ich das wirklich auch machen für meine kleine User Story, für mein eines Feature von dieser Webseite mit mit 500 Features.
Das, was du da machst, ist erstmal, du modellierst das ganze System.
Also die komplette Software. Das machst du nicht für deine User-Story, sondern aus diesen Ereignissen, das werden wir nachher sehen, da entsteht im Prinzip deine User-Story.
Denn ich glaube, auch im Kleinen, bei so einer kleinen User-Story wäre sowas teilweise auch schon hilfreich, weil ich halt dann noch immer den goldenen Pfad so ein bisschen, wenn überhaupt, in so einer User-Story vorfinde.
Und ich meine, ich glaube, das, wo ich immer wieder am meisten, mit reinlaufe oder quasi dann auch meine Expertise damit gut einbringen kann, sondern eben so sogenannte Edge Cases abzufangen, wobei viele davon auch gar keine Edge Cases sind, sondern eben auch einfach so Dinge, an die man sonst nicht dran denkt, während man den goldenen Pfad aufgezeichnet hat.

[32:03] Also ich glaube, ich mag die Idee auch generell wirklich so im kleinen Ticket-Bereich auch so einfach das im Hinterkopf zu behalten, wie was wird denn alles möglicherweise passieren können.
Das auf jeden Fall. Und du hast auch immer, wenn du deine Story implementierst später, hast du immer dieses große Bild im Kopf, wo auf diesem Zeitstrahl befindest du dich eigentlich gerade. Was baust du gerade und wo sind wir da gerade?
Also jeder hat im Prinzip immer diesen Zeitstrahl im Kopf und hat diesen ganzen Ablauf irgendwie im Hinterkopf und weiß genau, was passiert jetzt eigentlich nacheinander im System.
Und auch das hast du heute in einem typischen Softwareprojekt.
Das gibt es einfach nicht. Niemand macht sowas, obwohl es total einfach ist.

[32:44] Ich bin ja immer noch so ein bisschen bei der Skalierungsfrage, wo ich ja vorhin schon so halbtrollig gefragt habe, was ist, wenn ich 100 Leute habe oder so.
Also wenn ich jetzt mal aus meinem Alltag mal ein Beispiel heranziehen kann.
Ich habe es ja mehr so mit den kaputten, dysfunktionalen Molochs zu tun, wo dann halt die Feuerwehr mal dringend was austreten muss.
Aber da habe ich zum Beispiel einen so einen Verein, das ist halt eine echt große Firma, so irgendwie ihr eigenes Hochhaus ist das größte in der Stadt und so Zeug und da gibt es dann so das gallische Dorf, das ganz unten im Keller sitzt, das sind dann so die zehn Leute, die eine Software entwickeln, die nennt sich Arbeitsprozess und die heißt halt bei denen wirklich so, weil das einfach die Software ist, durch die alle Arbeitsprozesse in dem gesamten Hochhaus durchgetunnelt werden.
Also wirklich der Single Point of Failure.

[33:57] Anfangen, dieses Teil-System zu modellieren. Also du musst nicht unbedingt das komplette System modellieren, du kannst auch mit einem Teil anfangen.
Sagen wir, es ist ein Microservice.
Nimm ein Microservice aus dem System heraus und modelliere den ersten Microservice.
Oder du fängst an und modellierst das ganze System, aber nur High-Level.
Dass du quasi nur eine grobe Zeitlinie hast, wie das System funktioniert, und fängst dann an, in kleineren Systemen zu arbeiten und modellierst beispielsweise, wie hast du es genannt? Äh, Arbeitsprozess.
Arbeitsprozess, genau. Okay, also dann würde ich sozusagen einfach sagen, ich schneide hier und da jetzt ab.
Das sind dann halt irgendwelche externen Teilsysteme, da kommen dann Daten rein oder gehen Daten raus, aber die betreffen mich jetzt unmittelbar nicht in meinem Ausschnitt der Realität.
Was du machen würdest, ist, du würdest im Prinzip jedes dieser Teilsysteme ausmodellieren und dann aber die Schnittstellen zwischen diesen Systemen explizit nochmal hinzumodellieren.
Dass ganz klar ist, welche Systeme reden mit welchen Systemen über welche Ereignisse beispielsweise.

[35:04] Wenn du jetzt diese Ereignisse in deinem Zeitstrahl hast, ist das Nächste, was passiert ist, ein Freiwilliger erzählt im Prinzip die Geschichte des Systems.
Also wir wählen einen Freiwilligen aus und der erzählt im Prinzip von links nach rechts, was ist denn jetzt eigentlich die Geschichte des Systems.
Liest im Prinzip die Ereignisse vor und jeder hört zu und man überlegt, ist das, was der da gerade vorliest, stimmig? Macht das Sinn?
Auch das finde ich, also ich hatte das Wort Event Modeling, ich glaube, einmal nur vorher gehört und ich wusste nicht, dass es so etwas Offizielles gibt.
Aber auch das ist was, was ich eigentlich gerne auch in Teams mache, wenn es einfach nur um ein kleines Feature geht, ohne große Systeme.
Es ist aber auch nicht ganz trivial, weil das Team muss sich ein bisschen gut kennen, gut verstehen, damit sich jetzt auch niemand an den Pranger gestellt fühlt.
Weil ich habe selber die Erfahrung gemacht, dass ich einmal, ich war gewohnt so zu arbeiten, ein bisschen neueres Team und ich habe so plump dahergesagt, kannst du noch mal alles, kannst du mal sagen, was genau jetzt der Reihenfolge nach passiert?
Und dann war so, was, ich habe nicht aufgepasst, worum geht es?
Beziehungsweise die Person hat schon aufgepasst, aber hat sich dann so ein bisschen gefühlt, wie wahrscheinlich in der Schule vorne beim Abfragen.

[36:20] Und ich habe da auch nicht erklärt, worauf ich eigentlich hinaus wollte, weil eine Person hat es dann wiedergegeben und ich habe zugehört, so ein bisschen mitgeschrieben und dann die nächste Person gesagt, sagt, kannst du es mir jetzt auch nochmal erzählen? Was passiert denn bei deiner Version?
Also man sollte so ein bisschen die Leute darauf vorbereiten, warum man das gerade tut.
Zumindest mit ein, zwei Sätzen doch einleiten. Denn ich finde es erstaunlich, auch bei kleinen Features, welche unterschiedlichen Geschichten da schon mit menschlicher Sprache rauskommen.
Und bei wirklich so Features, wo, wenn du jetzt einfach nur die Frage stellst, ist allen klar, was zu tun gibt, dann gibt es ein allgemeines Nicken.
Aber dann fragst du du vier Leute, was kommt jetzt da raus gepostelt und vier Leute werden dir eine ungefähre andere Antwort geben. Ja.

[37:05] Was wirklich, wirklich toll ist, wenn ein Freiwilliger die Geschichte vorliest und der Beste dafür ist entweder der CEO oder der CTO, du stellst sofort fest, wenn die Geschichte nicht stimmig ist.
Du liest vor, okay, Kinokarten reserviert und dann setzt du dich hin.
Ja, da fehlt was dazwischen, das kann nicht sein, da fehlt was.
Und das passiert im Prinzip während du quasi die Geschichte erzählst ergänzt du einfach weitere Ereignisse alles was fehlt, und das wird jede Menge sein jede Menge an die niemand gedacht hat und plötzlich wird die Geschichte immer vollständiger und vollständiger und dann hast du irgendwann die komplette Geschichte von deinem System als Zeitstrahl an Bord stehen, und jeder versteht es.

[37:56] Gut. Und dann? Das Nächste, was du machst, ist, und da wird es dann richtig spannend, jetzt definierst du die Screens.
Also jetzt haben wir unsere Ereignisse an Bord stehen und jetzt definierst du die Screens. Wie sehen denn die Screens der Applikation aus, die wir da bauen?
Für jedes Ereignis brauchst du irgendeine Aktion, die ein User anklicken kann.
Du brauchst ein Screen dafür.
Ein Button oder es ist ein Batch-Prozess, der losläuft. Irgendein Screen brauchst du.
Irgendwas, wo der User draufklicken kann. Und die machst du dann ins Bord ran.
Und idealerweise ist das bereits vorbereitet. Das kannst du zum Beispiel die UX als Vorbereitung machen.
Meistens hast du irgendwelche Figma-Screens beispielsweise, die du dann schon mitbringen kannst, die schon vorbereitet sind. Und an den Screens kannst du dann rumskribbeln im Workshop.
Oder wenn du es digital machst, machen wir das typischerweise auf einem Miro-Board.
Miro ist ein ganz hervorragendes Tool für diesen Workshop.
Dann machst du diese Screens einfach direkt auf dem Miro-Board.
Weiß man das da schon so genau, mit welchen Screens? da rauspurzeln?
Du weißt es nicht ganz genau, aber du weißt es ungefähr. Wenn die UX zum Beispiel mit dabei ist, die wissen ungefähr, wie die User Experience sein soll, die wissen ungefähr, ja, hier wird der Screen kommen, da brauchen wir den Button, ungefähr.
So, dass du im Prinzip aber sehen kannst, wie sich die Applikation verhält.
Welche Buttons sind da? Man muss es erkennen können.

[39:24] Ich denke da jetzt gerade mal so ein bisschen komplizierter.
Wir haben ja auch bei uns auf der Arbeit, damit ich mal so ein ganz konkretes Beispiel nenne, ich hoffe, ich sage jetzt nichts Falsches, wenn ich mal ganz aufgeregt bin von der Arbeit erziele.

[39:35] Wir haben bei uns Feedback-Zyklen implementiert.
Und ich will nicht sagen, dass ich naiv rangegangen bin, aber ich wurde immer wieder überrumpelt, wie unglaublich kompliziert Feedback-Cycles werden können.
Man kann bei uns jetzt sozusagen den Zeitstrahl auch überwinden, Abbrechen, verschiedene Wege gehen oder sogar zurückgehen, wobei vielleicht das Zurückgehen auch einfach nur immer wieder weiter nach vorne gehen.
Konkretes Beispiel, man kann bei dem Peer-Feedback Peers auswählen, aber weil dann Situationen entstehen können, wie das die Lieblingsperson von allen hat, wurde 20 Mal als Peer nominiert und sagt, ich habe keine Zeit dafür, kann dann also wiederum Peer-Anfragen ablehnen.
Und dann kann wiederum die eigentliche Person sagen, oh, die Person hat keine Zeit, dann möchte ich jetzt einen anderen Peer wählen.
Aber damit das auch immer glatt läuft, können zum Beispiel Supervisor oder Manager das auch immer überschreiben oder sagen, oh, die Deadline zum Peer auswählen war schon rum, du warst da im Urlaub, komm, ich hab dir hier mal drei Peer schon mal ausgewählt.
Ich sehe, das läuft alles parallel, das kann alles verwirbelt sein, das können Bäumchen sein, das ist für mich schon schwer, das jetzt gerade auszuformulieren, obwohl ich mich ich monatelang damit beschäftigt habe, ich sehe dann nicht diesen einfachen Zeitstrahl.

[40:59] Was mache ich denn, wenn es so kompliziert wird mit so vielen Verzweigungen?
Tatsächlich ist auch das, was du beschreibst, ist ja nicht kompliziert.
Es sind einfach nur unterschiedliche Prozesse, die auch nachher ablaufen können.
Es ist nicht so, dass das alles parallel abläuft.

[41:11] Kompliziert ist das falsche Wort. Es ist umfangreich und ich kann es in meinem Kopf meistens nicht einfach so, ich müsste es auch geschrieben haben, um alle Punkte da aufzuschreiben.
Auch das, was du beschreibst, lässt sich auf einem Zeitstrahl abbilden.
Und ob jetzt das weiter vorne, in welcher Reihenfolge das passiert, das ist erstmal gar nicht so wichtig.
Du wählst dir quasi einen Zeitstrahl aus, wie du das System modellierst.

[41:33] Und wichtig ist nur, man kann nachvollziehen, wie das System funktioniert.
Und ob das dann hinterher weiter vorne passiert oder weiter hinten, das spielt überhaupt keine Rolle. Das ist egal. Und das funktioniert mit jeder Software.
Mit jeder Software. wäre. Gibt es so eine Wahrheit von diesem Zeitstrahl oder kann ich da mehrere alternative Universen aufzeichnen?
Also idealerweise hast du einen Zeitstrahl. Mit allen Sachen, die da sind. Also auch optionalen Schritten drin.
Da sind auch optionale Schritte drin. Natürlich kann es passieren, dass du jetzt von einem Zeitstrahl verschiedene Variationen hast.
Das versuchst du aber trotzdem in einem Zeitstrahl abzubilden.
Das Ziel ist wirklich, deine Software von links nach rechts lesbar zu machen wie ein Buch.
Es soll eine Geschichte sein.
Das ist das Ziel. Du willst eine schöne Geschichte über dein System erzählen können.
Das ist normalerweise der Schritt, der am längsten dauert, diese Screens bereitzustellen.
Deswegen, ich empfehle immer, das ein bisschen vorzubereiten.
Deswegen ist es immer fantastisch, wenn da die UX mit dabei ist.
Aber auch das geht relativ schnell. Wenn man jetzt mit Miro beispielsweise arbeitet, Wenn man da ein bisschen Übung drin hat, diese Screens zusammen zu klicken, das geht sehr, sehr schnell.
Und plötzlich hat man eine komplette Story von seinem System und man hat sogar die Screens dazu.

[42:56] Da entstehen weitere Diskussionen. Muss der Button jetzt da sein?
Braucht man diesen Button hier wirklich?
Und da werden auch nochmal neue Ereignisse entstehen, weil dann wieder auffällt, um den Button hier zu klicken, da haben wir eigentlich noch irgendwie gar nichts.
Da fehlt noch ein Ereignis.
Also diese Geschichte wird immer kompletter, je länger wir damit arbeiten.
Das dauert typischerweise so, sagen wir mal zwei bis drei Stunden.
Diese Mitvorbereitung, zwei bis drei Stunden, bis man alles zusammen hat, ist so die Hausnummer, mit der man rechnen muss.
Kann das zu komplett und zu komplex werden?

[43:36] Du meinst zu umfangreich oder was meinst du mit zu komplett?
Ja, ich meine, jetzt unabhängig von irgendwelchen physischen Constraints, aber irgendwo ist ja dann auch mal der menschliche Arbeitsspeicher erschöpft, wenn du einfach da so die Geschichte des Systems irgendwie erzählst.
Aber es ist halt einfach ein so unglaublich haariges Biest mit so vielen Sonderfällen und hier noch was und da noch was und dort, die ja vielleicht auch nicht so ohne weiteres abtrennbar sind, wie dass man einfach so Anfang und Ende von einem Microservice einfach so wegdefinieren kann.
Also was ist, wenn man sozusagen in dieser Erzählung erst merkt, hoppala, das wuchert sich aus und wir müssten das Ding eigentlich anders schneiden?
Dann hast du schon deine erste super wichtige Erkenntnis und dann hast du schon was über dein System gelernt und dann musst du dir halt überlegen, können wir so weitermachen oder macht es vielleicht erstmal Sinn, dass wir uns Gedanken machen, wie das System überhaupt aufgebaut ist, weil dann stimmt irgendwas nicht.

[44:28] Okay, Moment, warte mal. Ich bin doch gerade dabei, mir Gedanken über mein System zu machen.
Und dann stelle ich fest, das wird zu kompliziert. Und dann muss ich einen Schritt zurückgehen und mir Gedanken über das System machen. Wo bin ich da jetzt gerade vom Pfad abgewichen?
Du willst ja ein System modellieren. Jo. Genau.
Und entweder das System lässt sich so modellieren, wie du dir das vorstellst, auch wenn es größer wird.
Und dann ist es genau das, was du erreichen möchtest. Oder aber du merkst, das lässt sich so gar nicht modellieren, weil es vielleicht unterschiedliche Systeme sind, was du vorher gar nicht gesehen hast, was du gar nicht gemerkt hast.
Okay, das heißt, ich würde dann sozusagen von meinem ersten Ansatz alle in einen Raum vom obersten Chef bis zum untersten Einsteiger das dann durchspielen, merken, das haut nicht hin, das ist zu komplex, das muss aufgeteilt werden, Schritt zurückgehen, das machen, was mit meinem Arbeitsprozess-Team da der Fall war, dass wir sagen, wir definieren da Anfang und Ende und innerhalb dessen formulieren wir das aus.
Genau, man könnte zum Beispiel sagen, okay, wir machen hier einen Cut, hier hört das System auf, hier haben wir einen weiteren Bereich, das müssen wir vielleicht in einer weiteren Iteration machen, mit entweder der gleichen Mannschaft oder vielleicht auch mit einer anderen Mannschaft. Okay.

[45:40] Genau, das Nächste, was du dann machst, also jetzt haben wir schon unsere Zeitleiste, unsere Ereignisse und unsere Screens.
Jeder sieht die Software, jeder sieht, was das System tun soll.
Das Nächste, was du machst, ist, du definierst im Prinzip die Eingangsparameter.
Hm, aber das scheint mir alles gerade noch wirklich sehr aus der Frontend- und Design-Richtung fast zu sein.
Klar, das ist auch die Sicht, die ich jetzt drauf habe, aber was ich mich schon immer auch gefragt habe, zum Beispiel SystemadministratorInnen und Backendler, Müssen ja auch so im Hinterkopf, die denken ja nicht in, weiß ich vielleicht, vielleicht denken sie doch in Buttons.
Aber irgendwie habe ich das Gefühl, da müssen immer so andere unsichtbare Dinge passieren und das Frontend kriegt einfach magische Dinge.
Frontend macht einfach Button und eben für mich komplexen Fall macht Backend irgendwelche Dinge mit Kafka und Microservices und wir sagen allen was weiß ich was Bescheid.
Und dann kommt wieder was ans Frontend zurück. Aber für mich ist das immer eben klarer, die Frontend-Screens oder die UI-Screens sind aufgezeichnet.

[46:44] Gut, da müssen teilweise heutzutage auch schon sowas wie Frontend-Datenbanken, also so State-Management gemacht werden, aber mir kommt ja immer so das Backend immer so ein bisschen zu kurz.
Genau dazu kommen wir jetzt. Okay. Also bisher haben wir die Screens.
Und das Nächste, was wir machen, ist, wir definieren die Eingangsparameter.
Wie kommen denn jetzt die Daten von den Screens in unser System?
Also wir haben im Prinzip schon, wir haben die Screens und wir haben die Ereignisse, die passiert sind. Aber wir wissen, uns fehlt das Verbindungsstück im Prinzip.
Wie kommen wir von unseren Screens zu den Ereignissen? Und das Nächste, was wir machen, wir definieren die Eingangsparameter.
Nennt sich Command. Pro Ereignis oder so ganz am Anfang?
Pro Ereignis. Pro Ereignis. Genau. Du hast im Prinzip für jedes Ereignis, für jedes Ereignis, was im System passiert, hast du irgendeinen Trigger, irgendwas, was dieses Ereignis auslöst. Nennt sich Command.
Und jetzt definieren wir die Commands. Und die definieren wir so, dass wir die gleich mit den richtigen Daten anreichern.
Also stell dir vor, du hast beispielsweise, du könntest eine REST-API haben, die aufgerufen wird vom Frontend.
Und jetzt überlegst du dir, naja, welche Daten muss ich denn jetzt von meinem Frontend über die REST API in mein System geben, dass schlussendlich das Ereignis rauskommt, was ich da modelliert habe? Was brauche ich denn da für Daten?

[48:04] Und das machst du im Prinzip für jedes Ereignis. Damit definierst du im Prinzip deine API für dein System.
Für jeden Schritt. Das mache ich bei dem Workshop?
Ja. Halleluja.

[48:19] Wie lange dauert das denn? Das dauert nicht lange.
Du hast ja im Prinzip schon die richtigen Daten da. Die Daten stehen im Prinzip schon in den Ereignissen.
In den Commands definierst du nicht irgendwie, hatte die P-Post oder oder sowas, sondern es geht nur um die Daten, die du ins System gibst. Okay.
Und das machst du im Prinzip für... Sind da auch so Sonderfälle dabei, wie Rechte-Management?
Du redest auch über Security. Security ist auch ein Aspekt, der da mit rein muss.
Also zum Beispiel könnte ein Ereignis sein, Rechte zugewiesen.
User authentifiziert. Und da musst du dir überlegen, was muss denn eigentlich passieren, damit dieses Ereignis ausgelöst wird.
Der User muss sich irgendwie eingeloggt haben. Das heißt, wir brauchen irgendwie so ein Login-Command.

[49:13] Die Frage, die, glaube ich, jetzt mir gerade im Kopf rumschwirrt, kann es pro zu einem Ereignis unterschiedliche Eingangsparameter geben?
So, wenn User Rolle A hat, werden folgende Parameter gesendet?
Und sollte User eher vom Typen B sein, werden andere Daten gesendet? Das kann passieren.
Das ist möglich. Dann würdest du einfach mehrere Commands beispielsweise modellieren.
Ziel ist es eigentlich, alle Fälle in deinem Zeitstrahl abzubilden.

[49:52] Jetzt haben wir schon sehr viel geschafft. Wir haben den Zeitstrahl, wir haben die Screens, wir haben die Ereignisse und wir haben die Eingangsparameter für unser System.
Jetzt fällt im Prinzip nur noch eine Sache.
Und zwar, wir kommen jetzt die Daten aus unserem System wieder zum nächsten Schritt. Zur nächsten UI.
Und das machst du im nächsten Schritt. Du definierst, nennt sich Read Model.
Also wie kommen die Daten jetzt aus den Ereignissen zum nächsten Schritt.
Und auch das machst du wieder mit den Beispieldaten. Und da stellst du dann fest, haben wir denn wirklich alle Daten für den nächsten Screen, den wir anzeigen sollen?
Ist denn wirklich alles da? Oder fehlt vielleicht was?
Und hier wird es ganz interessant, weil was wir hier dann erreichen, wenn wir das modellieren, ist quasi der Beweis, dass wir alles berücksichtigt haben.
Proof of Data Completeness nennt sich das. Also wenn wir das alles richtig machen, dann wissen wir, wir haben quasi alle Fälle berücksichtigt und wir wissen, alle Daten, die wir brauchen, um unser System zu bauen, sind da, wir haben an alles gedacht.

[50:59] Ja, das klingt ja gut. Jetzt gehe ich nochmal zurück zu einem Thema, was wir ja am Anfang schon mal hatten.
Da haben wir kurz über Agile und so gesprochen und wir wissen ja gar nicht, was am Ende rausputzen soll.
Du kannst bestimmt auch gleich noch weiter bei einem aktuellen Thema bleiben, aber wir gehen jetzt mal davon aus, wir haben diesen Workshop sehr gut beendet und wir haben jetzt alles mal nach vorne übersprungen und wir haben das fertig gebaut.
Das läuft jetzt. Und jetzt läuft das seit vier Wochen auf der Webseite und wir stellen fest, oh, wir haben da was vergessen, was unsere User unbedingt richtig gut gebrauchen könnten.
Und wir bräuchten jetzt bei diesen Ereignissen noch mehr Zwischenereignisse oder andere Daten, die wir noch weitergeben müssen.
Also wie robust ist das denn dann, was da rauskommt gegenüber den zukünftigen Änderungswünschen?
Das, was du da machst, ist im Prinzip, du unterteilst deine Software in die kleinstmöglichen funktionalen Blöcke, die möglich sind.
Also du hast im Prinzip immer diese Unterteilung Screen, Eingangsparameter, Ereignis und das Readmodel für den nächsten Screen.
Und das, was da im Prinzip modelliert ist, ist der kleinstmögliche Funktionsblock, den du bauen kannst.

[52:26] Und typischerweise kannst du genau diesen Funktionsblock eins zu eins in eine User-Story transportieren.
Das sind die User-Stories, die im System entstehen.
Denn jeden von diesen Blöcken kannst du eins zu eins implementieren.
Und in deinem Fall jetzt, wenn du sagst, in einem von diesen Funktionsblöcken ändert sich irgendwas, dann würdest du genau diesen einen Teil neu modellieren und würdest hier beispielsweise die Events anpassen, die Events und neue Attribute ergänzen und dann genau diesen einen Funktionsblock neu bauen.
Der große Vorteil ist, du musst nichts anderes anfassen. Du musst genau diesen einen Funktionsblock anfassen und nichts anderes. das.
Ich finde es auch schön, dass du wirklich das Wort Neumodellieren verwendet hast.
Denn was ich ja ganz am Anfang meinte, ist dieses Aufeinander draufbauen, dass ich es immer wieder und immer wieder sehe und auch selber machen möchte.
Ich sehe halt, oh, dieses Feature kam später nochmal nach.

[53:22] Und ich meine es nicht mal ausschließlich technisch und als Developer nicht jetzt irgendwie böse angesprochen fühlen.
Ich finde das im Design und im Produktflow teilweise genauso.
Da hat ja man manchmal so sein einen perfekten Flow und man möchte auch unbedingt an dem festhalten, weil der war ja damals so perfekt, aber du willst da noch ein weiteres Feature hineinbringen und manchmal fällt es wirklich auch schwer, von mir auch selber aus der Produktsicht heraus, diesen bestehenden Flow so anzupassen, dass das wieder so eine komplette Synergie ergibt.
Und ich glaube, das ist wirklich schwer, wenn man so in dem Sinne, das haben wir doch schon immer so gemacht, wenn man diese bestehenden Sachen wirklich nochmal anfassen muss.

[54:03] Tatsächlich ist dieses bestehende Sachen nochmal anfassen ein Riesenproblem.
Denn daraus entstehen die größten Aufwände in der Softwareentwicklung.
Immer wenn du Sachen anfasst, die eigentlich schon fertig sind, dann änderst du was, was eigentlich schon fertig ist. Und das willst du eigentlich nicht.
Ja, klar. Also an neuen Features zu arbeiten ist auch immer viel einfacher.
Ich kenne das, falls soll jetzt irgendwelche Produktmenschen und Manager zuhören, Ganz oft werde ich mit dem Satz konfrontiert, kann ich der Person XY die Features, ich brauche dann nur noch ein Feature auf dem bestehenden Ding drauf, weil das ist ja einfach, weil das ist ja schon fertig.
Und ich gleich immer schmunzeln muss und sage, nein, genau andersrum, gib denen mal das komplett Neue und hock mal die alten Hasen auf dieses alte Feature hier drauf. Genau so ist es.
Oder mach mal aus diesem Button hier einen Dropdown.
Müsste ja schnell gehen, dauert nur einen Tag. Mach mal einen Dropdown.
Da ist immer Hauptformal schnell verloren. Das dauert immer viermal so lange, wie erwartet.
Ich finde es übrigens großartig. Wir haben ja hier jetzt auch die Kamera am Laufen.
Und ich finde Peters Blick super, weil du schaust sehr stirnrunzelnd.
Und ich würde dich gerne fragen, was geht dir durch den Kopf?
Ich bin nur am Zuhören, Mitschreiben und gleichzeitig Nachdenken und Recherchieren.
Und das ist halt um diese Uhrzeit für diesen alten Mann schon ziemlich anstrengend.

[55:31] Nur deswegen gucke ich so gestresst. Und ich war halt eben gerade auch so bei ungefähr dem Problem am Denken mit dem Funktionsblock, wenn sich etwas ändert, wenn also was hinzugefügt werden muss, dann nehme ich den, Funktionsblock, den ich da identifiziert habe, als die kleinste mögliche Einheit, in der sozusagen diese Änderung enthalten sein kann und dann gehe ich hin und baue das in diesen Funktionsblock ein. Habe ich das richtig verstanden?
Mhm. Mhm. Okay. Und ich nehme mal an, diese Funktionsblöcke kann man auch hierarchisch strukturieren, wenn ich also jetzt den Funktionsblock als die kleinste mögliche Einheit habe und ich habe, was das berührt, zwei von den Dingern kann ich da sozusagen, zwei von denen zusammennehmen und die als ein Subsystem betrachten und darin was ändern.

[56:10] Also typischerweise betrachtest du nicht zwei als ein Subsystem, sondern jeder ist im Prinzip für sich alleinstehend erstmal.
Ja, aber ich meine, es gibt ja tatsächlich irgendwie so Dinger, ich versuche jetzt mal gerade so beim Mitdenken irgendwie so zu gucken, okay, wie mappt das auf irgendwelche Dinger, von denen ich irgendwie Ahnung habe.
Und ich habe hier gerade mal so einfach so die schlimmste dysfunktionale Webseite, die ich kenne, patreon.com aufgemacht und stoche da halt jetzt gerade so in den JSON-Responses rum, um irgendwie so nachzuvollziehen.
So, ne, einfach so den Worst Case mal irgendwie so angucken.
Und da habe ich jetzt zum Beispiel gerade in den JSON-Responsen etwas drin gefunden, so can see not safe for work. Und das ist ein Boolean, der ist true oder false.
Und wenn ich mir jetzt halt eben vorstelle, es gäbe so diesen Aspekt, ich kann eine Klasse von Content sehen oder nicht sehen und die habe ich anfangs in meinem System nicht drin und dann irgendwie in der nächsten Iteration stelle ich fest, okay, wir brauchen so einen not safe for work Filter, dann ist das ja, was das wirklich sehr viele Funktionsblöcke betrifft, irgendwie relevant sein kann, je nachdem, wie es implementiert ist.
Also taucht das einfach nicht auf oder ist das irgendwie erstaunlich ausgeblendet und ich kann es mit einem Klick einblenden.
Also wie würde ich sozusagen solche Dinge, die ja betrachtet werden kann, als im Prinzip ja nur ein Eingangsparameter, aber etwas sind, was am Ende alles andere potenziell auf links dreht, wie gehe ich damit um?
Wie würdest du denn so ein Parameter konfigurieren? Also wie kommt denn dieser Parameter ursprünglich ins System rein?

[57:30] Äh, not safe for work? Wahrscheinlich User-Checkbox.
Kann ich mir aussuchen, ob ich das sehen möchte oder nicht? Genau, also du hättest erstmal ja einen, irgendeine UI, irgendeinen Button, wo du das klickst.
Das heißt, das Erfassen dieser Information wäre erstmal wieder ein Funktionsblock von uns. Ja, klar.
Damit ist die Information im System verfügbar.
Und dann kannst du ja im Prinzip in jedem von diesen Funktionsblöcken auf diese Information zugreifen. Ja.

[58:04] Ja, aber ich muss ja auch wissen, welche Funktionsblöcke betroffen sind und welche nicht.
Das ist ja für den Login-Prozess irrelevant, aber möglicherweise für alles andere, von Zeig Medien an bis Lade Medien hoch, wo ich klassifizieren kann, ist das ja irgendwie relevant.
Also ich muss ja sozusagen, ich fange ja mit sowas Abstraktem an, wie wir brauchen einen Not Safe for Work Filter, jetzt nachträglich.
Und ich muss dann ja irgendwie rausfinden, okay, wer muss darüber irgendwie, also wer muss das mitbekommen und muss das implementieren und wie baue ich das in die Geschichte des Systems und das gesamte Big Picture, das alle zu dem Zeitpunkt haben, dann ein und wie sorge ich dann dafür, dass danach auch alle das gleiche Big Picture noch sehen.
Wenn ich jetzt wirklich so einen einzigen Boolean einfüge, aber der betrifft halt 70% von allem, was stattfindet.

[58:51] Und das passiert dann anträglich. Genau, das ist ja jederzeit möglich.
Würdest du dann diesen Filter, ich kann jetzt mit Not Safe for Work Filter nichts anfangen, wäre das ein Filter, den du einfach mit nach oben gibst?
Oder was macht der Filter?
Ich kann als Nutzer sagen, ich will das Zeug sehen oder nicht sehen.
Und wenn ich irgendwie was hochlade, kann ich sagen, das fällt in diese Kategorie, die einige rausfiltern wollen, rein.

[59:14] Ja oder nein. Das wären sozusagen die zwei Dinger. Und dann werden halt eben bestimmte Medien angezeigt oder nicht.
Oder irgendwie aufbereitet oder nicht, in der Statistik erfasst oder nicht.

[59:25] Genau, du müsstest dann im Prinzip für jeden Funktionsblock, den du hast, einfach überprüfen bei den Daten, die quasi zurück ans Frontend gegeben werden, ob der Filter greift oder nicht.
Also das kann natürlich passieren, dass du jetzt für eine Änderung mehrere von diesen Funktionsblöcken anpassen musst.
Und gegebenenfalls auch neu modellieren musst. Das kann natürlich passieren.
Ja, klar, okay. Und das muss dann sozusagen, also, Also, mir fällt halt wirklich jetzt der Prozess schwer.
Du hast jetzt ja gerade diesen Workshop mit uns durchgespielt und das war total super und ich habe genau verstanden, wie man hier von Willkommen alle in unserem Raum, da hinten steht der Kaffee, bis hin zu, wir landen dann bei konkreten Dingen wie Screens und Eingareparametern.
Ich habe komplett nachvollzogen, wie der Prozess stattfindet.
Aber der Prozess findet jetzt dergestalt statt, dass diese Idee, wir brauchen Not Safe for Work Filter, sich in der Welt manifestiert.
Und irgendwie drei Leute in der Firma wissen, so, das muss jetzt passieren.
Wie sieht jetzt der Arbeitsprozess aus? Von diese Idee wird bekannt bis hin zu, wir landen wieder bei Screens, Eingabeparametern und vor allen Dingen wieder bei dem gleichen Ding, was wir am Ende vom Workshop hatten, wo alle das gleiche Weltbild hatten.
Weil das ja im Prinzip das große Ding ist, wo wir hinterher herauskommen, alle haben das System verstanden. Aber sie müssen ja nicht nur das System verstehen, sondern sie müssen ja auch die Zustandsübergänge des Systems von Version 1 zur Version 2 nachvollziehen und auch danach noch das gleiche gemeinsame Weltbild haben.

[1:00:48] Genau. Das Erste, was du immer machst, wenn du so eine Änderung hast, das Modell ist im Prinzip immer das, was du als erstes machst.
Das heißt, du würdest erst mal das Modell anpassen, dass jeder versteht, was passiert.
Also du würdest deinen Filter jetzt im Prinzip im Modell, bevor du irgendwas machst, aktualisierst du das Modell.
Und dann entstehen im Prinzip aus den Änderungen in deinem Modell entstehen die neuen User Stories.
Noch mal wieder runtergebrochen auf so das Workshop-Szenario.
Zum Modell aktualisieren vollziehe ich welche Schritte in der echten Welt?
Das kannst du jetzt definieren. Da würdest du mit Sicherheit jetzt nicht mehr alle zusammenbringen.
Also diese große Gruppe, die brauchst du initial, um das System einmal gänzlich zu erfassen.
Später hast du dann vielleicht einzelne Leute, die für Teile des Modells zuständig sind, Teile, die nur für Teams zuständig sind. Da brauchst du nicht mehr die ganze Gruppe.
Aber bevor du irgendwas machst, aktualisierst du immer das Modell.
Das könnte der Teamlead sein, das kann das ganze Team sein, das kann man im Planning machen.
Da muss man sich einen Prozess überlegen. Wie passt die Veranstaltung mit allen, die sich davon betroffen fühlen?
So Medienanzeige im weitesten Sinne, die setzen sich zusammen und aktualisieren dann ihren jeweiligen Krempel, ja? Ganz genau. Okay.

[1:02:02] Aber dann ist ja nicht mehr bei allen das gleiche Weltbild vorhanden, weil dann ja welche nicht dabei waren.
Naja, also was du ja hast, ist, das Modell ist ja für jeden zugänglich.
Und typischerweise arbeitest du ja, nimm mal ein Team.
Ein Team hat ein Microservice, der Microservice, dem gehört ein Teil des Modells.
Und das Team wird immer nur seinen Teil des Modells aktualisieren. Ja.
Und trotzdem aber haben die natürlich den Gesamtblick auf dieses komplette Modell und sehen die ganze Zeit, was passiert.
Wie ist das System aufgebaut?

[1:02:34] Okay, und das ist dann, also in dem Workshop waren das ja tatsächlich irgendwie Post-its an der Wand oder Dinge auf dem Bildschirm.
Also müsste ich dann sozusagen im Nachgang dieses Workshops auch dieses Modell irgendwie in etwas übertragen, in so eine Single Source of Truth, die dann auch modifiziert werden kann und für alle einsehbar ist?
Genau. Also ich empfehle immer Miro dafür. Auch wenn du einen physikalischen Workshop machst mit Post-its an Bord, wird es später in ein digitales Board übertragen und dann hast du dann zum Beispiel Miro.
Also das ist tatsächlich, das ist gar nicht so trivial, das Board immer auf einem aktuellen Stand zu halten und das braucht ein bisschen Übung.

[1:03:12] Aber das ist dann deine Single Source of Truth. Ja, und wie weiß ich, dass ich das sozusagen auf dem aktuellen Stand halte?
Weil ich meine, aus dem Workshop heraus ist es ja irgendwie aus sich heraus evident.
Alle sind da, alle haben es gesehen, haben den Prozess von vorne nach hinten durchgegangen, also haben die notwendigerweise ein so dermaßen synchronisiertes Weltbild, wie es eigentlich nur sein kann.
Aber sozusagen, ich muss ja sozusagen auch die Kontrolle irgendwie machen, dass wenn da jetzt einzelne Leute das System erweitern, also dass das dann irgendwie noch so verständlich ist, mit nichts anderem kollidiert, dass die nicht irgendwie was an ihrer, keine Ahnung, an ihren Daten, an ihren Inputs und Outputs so ändern, dass das nicht irgendwelchen Sachen widerspricht. Weißt du, was ich meine? Ja, natürlich.
Die Idee von Event-Modeling ist, dass du wirklich Event-Modeling first machst.
Also wirklich, du arbeitest mit dem Modell und du änderst das Modell als erstes.
Das Modell ist deine Quelle für deine User-Stories. Ja.

[1:04:09] Genau. Wenn du natürlich initial nur den Workshop machst und dann nichts mehr an diesem Modell änderst, sondern dann quasi weitermachst wie bisher, ist das auch super, weil du hast jede Menge gelernt, aber dann endet das auch da.
Also, wenn du mit Event-Modeling arbeitest, wenn du mit dem Modell arbeitest, dann musst du auch mit dem Modell arbeiten.
Es ist wirklich so gedacht, dass du Änderungen immer erst am Modell machst und dass sich das Modell im Prinzip immer weiterentwickelt und dass aus dem Modell heraus immer deine User-Stories entstehen. Okay.
Ist was anderes. Ist was anderes. Da muss man sich dran gewöhnen.
Also ich empfehle immer erst, erstmal den Workshop machen und erstmal jede Menge über das System lernen und dann kann man sich überlegen, ist das was, womit wir arbeiten können? Funktioniert das für uns?
Das funktioniert eigentlich überall, aber es ist halt was anderes.
Man muss auch bereit sein, das zu tun.
Ja, okay. Aber dann ist ja sozusagen das Outcome, das sich dann am Ende ergibt, tatsächlich dann ja doch eine Spezifikation in anderer äußerer Form.
Du kannst es Spezifikation nennen. Okay, aber es ist dann sozusagen, ja, also wir haben dann sozusagen den ganzen Ansatz als Mechanismus zur Findung der Spezifikation, zur Findung der gemeinsamen Sprache, zur Findung dessen, was normalerweise bei den RLCs immer an erster Stelle steht.
Unsere ganzen Kernbegriffe meinen dieses, jenes, solches.

[1:05:30] Okay, jetzt habe ich es verstanden.
Wir haben jetzt unseren Zeitstrahl und wir haben unsere Ereignisse und alle Definitionen und ich glaube, wir hatten davor gerade noch den Punkt genannt, oder du hattest den Punkt genannt, dass man könnte jetzt sagen, jedes so ein Arbeitspaketchen ist dann eine User-Story.
Was mir jetzt gleich aufgefallen ist, und du hast natürlich auch mehrfach Microservices genannt und ich glaube, du hast auch generell sehr viel Erfahrung mit solchen Architekturen, mit Microservices, Microfrontends und den ganzen fancy Gedöns.

[1:06:02] Übrigens, ich gehe jetzt aber auch, wenn ich das schon höre, automatisch in meinem Kopf passiert das schon, dass ich so quasi Teams pro Arbeitspaket sehe.
Soll das auch so ein Ziel davon sein, dass ich quasi solche lauter vertikalen Teams habe, dann pro Arbeitspaket? Und da kamen deswegen bei mir auch gleich diese Fragen rein.
Also was passiert denn, wenn ich jetzt eine Änderung an diesem System vornehmen möchte, das aber ganz viele von diesen Sachen betrifft.
Es ist zwar so quasi eine kleine Änderung, aber fast auf jedem Screen muss man da was anpassen. Und ich habe jetzt schon gleich diese angstvolle Befürchtung, oh Gott, muss ich jetzt 30 Teams fragen, so eine kleine Sache anzupassen?
Oder passiert es im schlimmsten Fall oder im besten Fall, keine Ahnung, dass ich jetzt lauter Vertical Teams habe, aber ich bilde jetzt wieder eine horizontale Workforce, damit man diese eine Änderung an meinen allen Arbeitspaketen durchführen kann?
Oder lässt mir das Modell das vollkommen offen und sagt, du kannst danach arbeiten in einer Teamaufstellung, wie du möchtest, egal ob vertikale Teams, horizontale Teams oder du hast Teams, die sich nicht für Richtungen entscheiden müssen.

[1:07:12] Das bringt uns ganz natürlich zum nächsten Schritt. Wir sind noch nicht ganz fertig mit unserem Workshop. Ach so, Entschuldigung. Ich passe wieder auf.
Was du nämlich machst, ist, also wir haben im Prinzip, funktional ist schon alles beschrieben, aber genau der Punkt, den du sagst, wir haben noch nicht so genau definiert, wo gehören jetzt eigentlich diese ganzen Funktionsblöcke hin.
Was du dann machst, ist, du definierst Swimlanes. Und Swimlanes sind im Prinzip, man kann es betrachten wie ein Kontext, wie ein Team, wie ein Service.
Du gruppierst im Prinzip deine Events Unterhalb vom Modell.
Und das ist eigentlich dann eine natürliche Zuordnung. Diese vertikalen Funktionsblöcke, die gehören zu diesem Team. Ja, Moment.
Jetzt komme ich aus einer wieder sehr Frontend-UI-Sicht.

[1:08:24] Und ich weiß nicht, ob ich da das immer so genau gruppiere, sondern ich komme hier immer so von den kleinen Base-UI-Components.
Und ich brauche jetzt zum Beispiel den Dropdown, brauche ich in der Order, brauche ich im Checkout, brauche ich beim Login.
Und das möchte ich ja einheitlich haben über das ganze System und hier, wie mache ich das denn jetzt?
Ich will das ja gar nicht ausblenden. Da bist du ja die Expertin, wie du das machst.
Also da hast du ja dann typischerweise irgendwie so ein Team, was sich um das Design-System kümmert und was einfach definiert, wie so ein Dropdown aussieht und wie das alles funktioniert.
Dass du aber an der Stelle einen Dropdown brauchst, das definiert wieder das Order-Team. Okay.
Wie bilde ich da so komplett cross-funktionale Geschichten wie irgendwie Security ab? Weil die kannst du ja aus nichts raushalten.
Nee, das machst du, also idealerweise, wenn du die Möglichkeit hast, modellierst du es gleich mit rein.
Also zum Beispiel ist in deinen Events dann einfach der Authorization Key mit drin oder der Bearer Token von deinem OAuth, das kannst du ja da alles mit rein modellieren.

[1:09:32] Ja, nee, aber das ist ja eine konkrete Implementierung.

[1:10:00] Der Arbeit. Aber irgendwie so, wir kümmern uns halt eben darum, dass wir wollen erreichen, dass Dinge immer ordentlich sanitized sind und dass das immer alles mit dem SQL-Query ordentlich ist.
Also, das will man ja auch, aber das kann ich ja nicht in einen Funktionsblock in eine User-Story einbauen.
Das kannst du aber im Modell abbilden, indem du beispielsweise das Passwort, gehasht anzeigst im Event, was im System gespeichert wird.
Und dann sieht auch der CTO, aha, schau mal daher, unsere Passwörter werden nicht plaintext gespeichert, sondern wir machen das gehasht, so wie sie es gehört.

[1:10:33] Und da ist es dann auch egal, ob das jetzt das Ereignis ist oder ob das die Datenbank Column ist, die du unten anzeigst.
Der CTR erkennt, dass es gehasht. Wunderbar. Ziel erreicht.
Okay, Passwort wird gehasht und der ganze andere Krempel auch.
Aber ich meine, das geht ja wirklich, wenn du jetzt zum Beispiel an so Cross-Site-Scripting-Geschichten gehst, du musst ja dann sozusagen wirklich bei allem, was irgendwie angezeigt wird, bei allem, was irgendwie eingegeben wird, irgendwie einen Filterschritt machen.
Den baust du ja nicht überall da ein, oder? Du sagst ja nicht bei jedem User-Input, das wird durch die Filter durchgezogen.
Nein, das ist, was du ja modellierst im Modell, ist im Prinzip alles, was irgendwie eine Änderung in deinem Systemstatus verursacht.
Ein Cross-Site-Scripting-Filter ändert nichts an deinem System, der ist einfach da.
Also das würde man einfach, das ist quasi dann wirklich außerhalb vom Modell.
Ja, aber wenn der nicht da ist, dann ändert das ja sehr wohl was an deinem Systemstatus. Und zwar nichts Gutes.
Ja, nicht wirklich. Du kannst festlegen, Eingaben bei uns werden über einen Cross-Site-Scripting-Filter gefiltert.
Ist einfach da. Das ist aber nichts, was du im Modell modellieren musst, weil das ist einfach quasi eine Annahme. Genauso wie du sagst, wir loggen.
Loggen würdest du nicht im Modell modellieren, weil das ändert nichts.
Das machst du einfach. Weißt du, was ich meine?
Ja, ich weiß, was du meinst, aber meine Erfahrung sagt mir, das machst du einfach, da sind sich alle drüber einig und passieren tut es dann trotzdem nicht.

[1:11:54] Das kann natürlich passieren. Wenn wir jetzt schon sagen, Softwareentwicklung läuft so mittelgut, dann ist das ja nicht nur so, dass die Entwicklerinnen und Entwickler hinterher sagen, oh meine Güte, das ist aber ein Haufen Legacy-Code, das ist gar nicht so schön, sondern ist ja tatsächlich auch irgendwie so was wie, hey Peter, was hältst du von unserem Frontend?
Und ich probiere einfach mal den offensichtlichsten Security-Kniff und bin dann sofort drin und irgendwie alles ist im Eimer.
Das ist ja auch Teil des Problems.
Was du du im letzten Schritt des Workshops machst es, du definierst Policies.
Also das sind genau im Prinzip die Fälle, die du abbilden möchtest.
Und du könntest beispielsweise eine Policy definieren, also die Policies definierst du im Prinzip unterhalb vom Modell und du schreibst ein Event hin und du könntest da ein Event hinschreiben, was einfach invalide Daten hat und du könntest dann das Command mit diesen invaliden Daten abbilden und könntest dann aber in der Policy definieren, in diesem Fall laufen wir in einen Fehler. Das darf nicht passieren.
Also du würdest nicht modellieren, wir haben einen Cross-Site-Scripting-Filter, sondern du würdest modellieren, wenn diese Daten ins System kommen, dann haben wir einen Fehler.
Und dafür könntest du beispielsweise einen Test schreiben. Für diese Policies hast du typischerweise Tests.

[1:13:11] Okay, das sind dann sozusagen konkrete Ausprägungen von dem, was ich gerade so als Werte bezeichnet habe, von wegen unser Produkt ist gefiltert. Genau.
Beispiel zum Beispiel E-Commerce, du hast einen Warenkorb und du darfst nur drei Produkte in den Warenkorb legen.
Wenn du jetzt dreimal ein Produkt in den Warenkorb gelegt Ereignis hast und du kriegst ein weiteres Command, bitte Produkt in den Warenkorb legen, hast du auch einen Fehler.
Also wirklich Business Rules, die du im System abbildest, die würdest du im Prinzip im letzten Schritt im Workshop genau so modellieren.
Und zwar unterhalb von jedem Funktionsblock.
Dann hast du einmal nämlich die Funktion selber und du hast alle Sonderfälle modelliert und im Prinzip siehst du dann genau, okay, das ist mein System, so funktioniert es. Okay.

[1:13:55] Apropos Legacy. Mal ein Schritt zur Realität jetzt hierzu.
Es ist ja jetzt vermutlich nicht der Normalfall, dass wir jetzt, wir kennen jetzt Event-Modelling und jetzt gründen wir eine Firma und machen ein neues System.
Sondern vermutlich kommt man ja irgendwann in dieses Problem, dass man sagt, oh, jetzt ist das ein bisschen groß geworden.
Jetzt brauchen wir mal einen neuen Prozess. Und dann stolpern wir über Event Modeling.
Und jetzt habe ich mein halbes System schon. Die Hälfte, wie das funktioniert, wissen nur noch die Leute, die nicht mehr da sind.
Und die andere Hälfte ist dürftig dokumentiert.
Wie mache ich denn nachträglich Event Modeling? Ich gehe jetzt einfach mal davon aus, dass das auch nachträglich irgendwie gehen muss.
Zufälligerweise habe ich heute Morgen einen Artikel veröffentlicht, der heißt Legacy-Systeme modellieren mit Event-Modelling.
Also genau, natürlich geht das und was du dann machst ist, typischerweise hast du in Bestandssystemen, nennen wir es nicht mal Legacy-Systeme, in Bestandssystemen hast du irgendwelche Tabellen, wo die Daten abgebildet sind.
Statt die Ereignisse im System zu modellieren, modellierst du einfach direkt auf die einzelnen Spalten in deiner Tabelle.

[1:15:10] Also du hast immer noch deine Screens, du hast immer noch deine Commands, statt aber die Ereignisse zu modellieren, nimmst du einfach deine Tabellen, so wie sie sind und modellierst einfach, wie kommen die Daten aus deiner UI dann jetzt schlussendlich in deine Tabellen rein?
Und wie kommen die Daten aus der Tabelle zum nächsten Screen?
Mache ich das erstmal einfach nur mit Ist-Zustand? Du würdest den Ist-Zustand modellieren, genau. Das ist im Prinzip, was du da machst, ist erstmal die Dokumentation für dein System.
Super wertvoll, also allein das ist super wertvoll. Und dann kannst du das natürlich verwenden, um die Weiterentwicklung zu steuern.
Was sind die Funktionsblöcke, die wir haben? Brauchen wir neue Funktionsblöcke?
Was ändert sich? Wo muss man was anpassen?
Funktioniert ganz wunderbar.
Jetzt so mal aus dem Startup rausgetrieben. Ich glaube, eine Sorge, die dabei herrschen würde, ich glaube dir zwar, und da bin ich ja immer auf deiner Seite, ich denke, das ist weniger Zeit, was sowas kostet, als vor allem im Hinblick, was da ja für Nutzen dabei rauskommen kann.
Aber das Argument, das mir jetzt sofort schon im Kopf schwirrt, ist, wenn ich jetzt vor allem mit Screens arbeite, das ist ja alles änderbar, das Design wird oft angepasst, weil sich die Features so schnell weiterentwickeln.
Lohnt sich das denn überhaupt, das zu dokumentieren, wenn wir in zwei Wochen später das sowieso schon wieder einen ganz anderen Screen haben, der anders aussieht?

[1:16:32] Ich stelle die Frage mal andersrum. Was ist denn die Alternative dazu?
Durchwurschteln. Läuft schon.
Du kannst es durchwurschteln. Das ist auch völlig okay. Das Problem ist nur, früher oder später wirst du das System wegschmeißen müssen. Das passiert immer.

[1:16:50] Durchwurschteln ist völlig in Ordnung. Und wenn du sagst, du bist noch in dieser Phase, wo Wurschteln dein Ziel ist, ist das auch völlig okay.
Da würde ich nicht mehr die Event-Modeling arbeiten.
Wenn du wirklich wurschteln willst. willst, aber meistens ist es halt doch meistens eine gute Idee, weil du hast eigentlich keinen Zeitaufwand oder wenig Zeitaufwand und du modellierst dein System so, dass du es hinterher halt nicht mehr wegwirfst.
Ja, ich habe meistens, ich habe ja, wie gesagt, ich bin normalerweise nicht die Person, die das argumentiert, weil ich genau schon immer, wenn ich das höre, wie in zwei Wochen schaut es bestimmt eh schon wieder anders aus, entspricht normalerweise wirklich nicht meiner Realität. geht.
Das werde ich auch bei jedem Merch beziehungsweise Pull-Request immer anmerken, wenn ich da schon im Code lese, so, ja, da ist jetzt so ein To-Do, aber in zwei Wochen wollen wir das nochmal anfassen, sage ich, nee, das passiert doch sowieso nicht, das ist für das nächste Jahr, es bleibt das, der gleiche Screen, weil wir haben sowieso neue Features am Arbeiten.
Von daher zumindest in meiner Realität ist es immer so ein Mythos, dass sich die Sachen wirklich so schnell anpassen, dass man sie nicht dokumentieren müsste, weil es so viel mehr Aufwand wäre.

[1:17:58] Aber gut, ich habe jetzt mein Bestandssystem und damit ich das eben nicht wegschmeißen muss, irgendwann mal gehe ich da mit Event-Modeling her und mache meinen Ist-Zustand.
Was passiert denn jetzt, wenn ich dabei auch, ich habe ja irgendein Ziel, das ich jetzt verfolge, was ist denn das Ziel jetzt bei dem Bestandssystem, das zu haben, außer dass ich die Dokumentation über den Ist-Zustand habe?
Ist es einerseits, möchte ich zum Beispiel Lücken haben, die ich zum Beispiel im Bestandssystem habe, um die dann aufzufüllen?
Oder ist es auch einfach nur, weil ich es eben mit Features erweitern möchte?
Also erstmal ist es Dokumentation, die du haben möchtest. Denn ich weiß nicht, wie es dir geht, aber ich habe bisher selten Software-Systeme gesehen, die gut dokumentiert sind.
Und mit so einem Event-Modell hast du natürlich eine perfekte Dokumentation.
Das ist für ein Onboarding das Beste, was du jemandem geben kannst.
Du willst wissen, wie unser System funktioniert, fang links an und hör rechts auf und du hast alles gesehen. Was Besseres gibt es nicht.
Gute Zwischenfrage. Du hast Miro jetzt hin und wieder erwähnt.
Ist Miro dann für dich da auch so ein gutes Tool oder ist das so ein Zwischenstuhl, um das dann in einen, wie heißt das, Conference oder sowas, dieses große Tier-Ding?
Also tatsächlich, wir arbeiten Miro first und wir arbeiten auch quasi an Tools, um beispielsweise Code aus Miro heraus zu generieren. Also Miro ist das Tool, mit dem wir arbeiten.

[1:19:23] Aber da sind die Screens mit drin. Ja. Wie veraltet dürfen die denn sein?
Denn was sich vielleicht nicht so wirklich oft updatet, meiner eigenen Meinung nach, ist wirklich die UI und es dauert eh alles viel zu lange zu implementieren mit der ganzen UI.
Aber Texte und sowas können sich ja schon wirklich häufig updaten. Genau.
Texte würde ich im Miro-Board jetzt nicht eins zu eins schreiben.
Ich würde einen Text so schreiben, dass man erkennt, was gemeint ist, aber jetzt nicht wortwörtlich, weil das kriegst du im Miro nicht abgebildet.
Also es muss nicht so genau sein. Man muss ja erkennen, was das Text ist.
Die du in Miro hast, dann was für Screens meinst du denn dabei?
Ich habe jetzt gerade fast an Screenshots gedacht bei dem Bestandssystem, dass sie einfach ein Screenshot von der Webseite nehmen.
Auch das ist natürlich möglich, dass du Screenshots nimmst oder du nimmst eben, wie gesagt, Figma-Screens oder du zeichnest einfach Screens selber mit dem Budget-Tool in Miro.

[1:20:15] Es ist wirklich da nicht so genau, aber jetzt gerade Bestandssysteme, wenn du Screenshots hast, wunderbar.
Jetzt haben wir immer ganz viele Fragen zwischen reingestellt.
Wir haben doch bestimmt noch solche abschließenden Punkte, die wir jetzt gerade übersprungen haben.
Tatsächlich sind wir jetzt am Ende von unserem Workshop angekommen.
Also wenn wir das alles gemacht haben, wir haben die Events definiert, wir haben die Commands definiert, wir haben die Screens definiert, wir haben die Read Models definiert, wir haben alles in die richtige Reihenfolge gebracht, Wir haben die Policies definiert und im Prinzip haben wir jetzt unser System in der Reihenfolge, in der die Dinge passieren.
Das ist der Outcome von unserem Workshop. Und wie du dann quasi mit dem Modell in die Implementierung gehst, das ist dann nochmal eine andere Geschichte.
Das Modell eignet sich ganz hervorragend, wirklich ganz hervorragend für eventbasierte Systeme.
In eventbasierten Systemen kannst du das Eventmodell eins zu eins im Code abbilden.
Aber auch für normale CRUD-Systeme funktioniert das.
Also das ist dann wirklich, da muss man dann mit den Teams einfach quasi nach dem Workshop sich hinsetzen und sich überlegen, okay, wie macht man denn von hier aus weiter? Wie wollt ihr damit arbeiten?

[1:21:29] Dieses System kann ja jetzt sehr groß sein. Und wir haben ja schon häufiger das Wort agil verwendet.
Komme ich denn von meinem Zeitstrahl, den ich da jetzt hingezeichnet habe, komme ich da dann auch zu kleineren Zeitstrählen, die ich jetzt nacheinander implementieren kann?
Weil zum Beispiel unser Feedback-Zyklus, da wissen wir ganz genau, da gibt es ein Peer-Feedback und die Peers müssen sich nominieren und wieder abnominieren können und Manager müssen dazustimmen und nicht zustimmen.
Aber wenn wir das alles auf einmal implementieren, dann sind wir ein halbes Jahr, sind wir alle in unserem Zimmerchen und dann sieht man uns wieder.
Ja, so funktioniert es ja in der Realität nicht so oft, sondern ich möchte ja eigentlich immer so das Minimum-Value-Product-Dingsbums-MVP, MVC, naja, keine Ahnung, wird spät, an die User shippen und schon mal auch Feedback generieren, weil jeder Value ist ja besser als kein Value erstmal und vor allem so kleine Produktideen sind dann auch bugfrei, was vielleicht besser ist als die Eier legende Wollmilchsau am Anfang schon zu deliveren.

[1:22:29] So, aber ich weiß quasi, ich brauche auch ein Peer-Feedback, aber ich möchte damit nicht anfangen. Ich möchte erst was Kleineres rausbringen.
Erlaubt es das System soweit denn? Ist es überhaupt dafür da? Klar. Du.
Also erst mal, was du hier machst, ist, du modellierst das komplette System nach Möglichkeit.
Aber das heißt ja noch lange nicht, dass du alles umsetzen musst.
Du kannst ja genau diese vertikalen Funktionsblöcke rauspicken, die den meisten Value für deine User liefert.
Ich muss quasi immer nur schauen, dass ich die richtigen Werte dann auch zur Verfügung habe. Das weißt du aber.
Du weißt genau, welche vertikalen Funktionsblöcke du bauen kannst und welche quasi die Vorbedingungen sind, weil du genau an den Daten erkennst, was brauchst du. Weißt du, 100%.

[1:23:18] Okay, ich hätte noch eine Frage für das gesamte Erstaufziehen des Systems.
Und zwar, die meisten Systeme sind ja tatsächlich so ereignisbasiert.
Ist ja gerade bei so Frontend-Krempel ganz klar.
Ich klicke Button, Dinge passieren. Oder ich will Dinge erreichen, Dinge passieren.
Wie baue ich da in mein eventbasiertes System irgendwelche Constraints ein, die nicht eventbasiert sind?
Politikmäßiges Zeug zum Beispiel. Das ist die, keine Ahnung, du bist die Bahn-Webseite und die versuchen dir bei jeder Gelegenheit noch einen Mietwagen überzuhelfen, obwohl das das Letzte ist, was du möchtest.
Aber das tun die ja und das wollen die ja. Und du hast ja in diesem Laden Mächte am Werk, die das auch so umgesetzt sehen wollen.
Und du musst das ja immer irgendwie berücksichtigen, dass halt dieses permanente Upselling irgendwie passiert. Weil wenn du das nicht berücksichtigst, hast du halt irgendwie nicht die Leute an Bord.
Also das ist ja was, das muss ja auch irgendwie da drin sein, aber das ist ja nicht irgendwie jetzt, streng genommen ereignisbedingt, Es sei denn, du baust halt einfach so ein, ich komme auf die Webseite und ich kriege halt einfach in meiner User-Story in Anführungszeichen jederzeit dieses Upselling irgendwie noch reingewirkt.
Wäre das so der Ansatz?
Alles ist ereignisbasiert. Die Frage ist, was triggert denn denn Upselling?
Irgendwas muss das ja triggern. Ist das nur der Page-Load oder wann passiert das?
Es muss halt auch wieder überall drin sein. Also ich muss ja in jedem Screen irgendwie drin haben und wenn du noch einen Mietwagen haben willst, da ist einer.

[1:24:45] Und das ist aber nicht Teil des Systems in deinem Szenario?
Es ist ja Teil des Systems, aber es ist ja tatsächlich nur sozusagen eine, sagen wir mal, Komplikation, die wieder so ähnlich wie mein Not-Safe-for-Work-Filter in allem irgendwie drin ist.
Und ja im Prinzip einfach überall immer so mit gemeint werden muss, dass du sozusagen nicht nur die Gewerke hast, von wegen Design hier, Technik da, sondern halt irgendwie sozusagen auch noch die, ja, in so einem Konzern wäre das halt wirklich ein Geschäftsbereich oder so.
So, dass halt irgendwie die Mietwagenabteilung sich halt eben auch da überall drin wiederfinden will.
Also ich komme, glaube ich, immer zu so einem Skalierungsding zurück, weißt du, wo ich halt irgendwie so denke, so 50, 100 Leute in einem Raum, das ist ja super, aber was ist, wenn du wirklich der Konzern bist und du bist die Konzernwebseite und alle müssen da irgendwie mit rein und so ein Ding, wie halt eben eine Bahnreise buchen wird, halt durch so Dinge wie irgendwie, es geht über die Grenze und du fährst irgendwie von Paris über Deutschland nach Wien und am Ende kriegst du noch einen Mietwagen übergehörfen und die Hälfte von deinem Ticket bezahlst du mit, Bonuspunkten, aber du hast halt nur eine Rabattkarte für Österreich.

[1:25:49] Aber das sind ja alles Constraints, die du im System abbilden kannst.
Also auch ein Upselling ist ja immer irgendetwas, was du entweder als User akzeptieren musst oder nicht oder du ignorierst es einfach, aber es ist ja immer irgendwie im System abgebildet und kann deswegen natürlich auch modelliert werden.
Ja klar, aber ist die Wand groß genug? Habe ich genug Post-its dafür?
Das ist die Frage. Also das System kann natürlich beliebig groß werden und dann würde man mit einem Teil des Systems halt anfangen.
Du würdest jetzt nicht die Bahn-Webseite auf eine Wand malen.
Das funktioniert nicht. Ja, aber vielleicht die Startseite.

[1:26:26] Also du kannst es probieren, aber du kannst nur das modellieren, was halt auch funktioniert.
Also du kannst nicht beliebig große Systeme so modellieren. Nee, nee, klar.
Aber du hast halt eben Systeme von Systemen und Subsystemen und hast die nicht gesehen.
Und die sind dann wieder miteinander verbunden irgendwie.
Okay, aber hast du dann nicht eine zweite Codebase geschaffen?
Du kannst ja, also wenn du sagst, du modellierst ein System, heißt das ja nicht, dass das eine Codebase ist. Auf gar keinen Fall.
Nee, nee, nee, das meine ich auch gar nicht. Sondern ich meine jetzt mehr so, ich baue ein kompliziertes Ding, wie zum Beispiel den Buchungsprozess für einer Bahn.
Und das irgendwie in Code zu gießen, ist halt unglaublich kompliziert und schwierig und deswegen baue ich das System mit dem Event-Modeling, spiele das Ganze durch, pflege die Systeme weiter, wie wir das alles besprochen haben.
Aber sozusagen, dann ist es ja mehr oder minder eine Spezifikation.
Eine Spezifikation ist ja auch nichts weiter als in Prosa gegossene, letztlich Abfolgen von Zeug, also Quasicode.
Habe ich dann nicht mein System zweimal gebaut?

[1:27:33] Du meinst halt, dass du einmal im Modell hast und einmal im Code.
Ja, und ich halt eben das Ding mal zwei habe, plus halt eben dafür sorgen muss, dass die beiden halt eben synchronisiert sind. Richtig.
Und halt eben mehr oder minder halt eben auch sozusagen global, jetzt nicht permanent, aber halt irgendwie effektiv es ja für jeden jederzeit möglich sein muss, im Prinzip die, keine Ahnung, CTO-Perspektive einzunehmen und ganz raus zu zoomen oder halt eben auch die Security-Nerd-Perspektive einzunehmen und ganz runter zu zoomen. Natürlich.

[1:28:04] Das ist auch so. Aber das hast du heute auch. Du hast es heute auch zwar...
Das ist ja in Figma und auf der Webseite heute eh schon so.
Das ist auch sowas, mit dem ich oft konfrontiert werde, wie muss man das jetzt auf Figma updaten, weil auf der Webseite ist es hier eh schon die Single Source of Truth und die Webseite muss ja die Single Source of Truth sein, weil nur das ist ja das, was die User im Endeffekt bekommen.
Allerdings ist für mich halt die geschriebene Codebase eben nicht dieses Storytelling, das ich brauche, um das Produkt zu verstehen.
Ich glaube, das wird teilweise auch ganz schön überschätzt, was wir im Code alles teilweise rauslesen können.
Ich kann im Code nicht rauslesen so genau, keine Ahnung, Beispiel, wie die Feature-Switches genau miteinander funktionieren, wenn es zum Beispiel so übergreifende Feature-Switches gibt, die mehrere Sachen auf einmal an- und austockeln oder ähnliches.
Da ist natürlich im Endeffekt, was die User bekommen werden, ist in der Codebase drin und nicht auf Figma.
Aber es ist im Code nicht einfach lesbar. Das brauche ich irgendwo modelliert.
Ja, stell dir vor, du hast einfach einen Flag an deinem Kunden. Prospect, true, false.
Aus dem Code liest du nicht raus, was macht dieses Flag, wo kommt es her?
Im Event-Modell siehst du genau, okay, das wird 17 Schritte weiter vorne wird das gesetzt und es kommt aus diesem System. Aha.

[1:29:22] Und du hast es auch heute. Du hast heute auch alles doppelt, nur hast du das in hunderte User-Stories aufgeteilt, in geschriebenem Text.
Das ist genau das Gleiche.

[1:29:34] Also ein bisschen kam ja auch daher meine Frage vorher, lohnt sich das überhaupt mit den Screens, die sich hier doch immer wieder ändern?
Das ist wahrscheinlich eine Frage, die die gesamte Dokumentation dieser Welt betrifft.
Lohnt sich das, das da nebenbei aufzuschreiben? Weil es könnte sich ja ändern.
Ja, also das Ding ist halt eben, es ist ja am Ende Dokumentation, was wir betreiben. sozusagen mit einer Befindungsphase.

[1:30:04] Ja, bloß die Dokumentation, die wir da machen, ist halt quasi ein Treiber für die Implementierung.
Normalerweise machst du die Dokumentation nach dem Code.
In dem Fall machst du die Dokumentation vorher und der Code basiert auf der Dokumentation. Okay, also es ist eine Spezifikation und nicht eine Dokumentation.

[1:30:22] Haben wir denn jetzt was noch nicht besprochen? Ich hätte noch eine letzte, eine allerletzte Frage. Schieß los.
Und zwar, Martin, was ist dein Verhältnis zu Conways Law? Was sagst du?
Zu Conway's Law? Wo kommt diese Frage her?
Das war das allererste, woran ich gedacht habe, als du gesagt hast, wir holen alle in einen Raum, damit alle das gleiche Weltbild haben und produzieren was, wo alle irgendwie letztlich sich drin wiederfinden.
Conway's Law ist quasi ein Naturgesetz, daran kommst du nicht vorbei.
Naja, er hat halt irgendein Heini gesagt, also ich meine, ob das jetzt ein Naturgesetz ist, weiß ich nicht, aber ich wollte sozusagen nur sozusagen, dein Verhältnis einfach so wissen, wenn du jetzt, ich meine, die Aussage, das ist ein Naturgesetz, ist ja im Prinzip was ich hören wollte, nämlich wie dein Verhältnis dazu ist, ist super.
Ich glaube, es ist so, also das Conway's Law gilt und da kommst du auch nicht dran vorbei, glaube ich.
Da fest eine Überzeugung. Wollt ihr mal kurz beschreiben, was das Conway's Law ist?
Convice-Law ist, du hast eine Organisation, die produziert etwas, was immer sie produziert, ist ein Abbild der Organisationsstruktur, der produzierenden Entität.

[1:31:38] Also im Prinzip, wenn du drei Abteilungen hast, wirst du nach Convice-Law mit drei Microservices rauskommen. Ja.
Du hast vier Teams, die am Compiler arbeiten, also wird es vier Passes über den Code geben. Ich könnte noch ein neues Frontend-Framework schreiben.
Und das kann man so oder so sehen und wenn man das als Naturgesetz hinnimmt, dann kann ich das verstehen.

[1:32:04] Also ich glaube, es lohnt sich wirklich, sich, wenn auch nur vielleicht mal an einem Tag damit zu beschäftigen, einfach mal das Team zusammenzurufen und einfach mal aus Jux und Dollerei so ein Eventmodell aufzuzeichnen. Einfach mal gucken, wo man dabei rauskommt.
Der Aufwand ist nämlich tatsächlich nicht wirklich groß und wir haben das nicht explizit gesagt, also Eventmodelling ist nichts, was ich mir ausgedacht habe, nichts, was meine Firma sich ausgedacht hat, sondern das ist im Prinzip eine Bewegung, die seit 2018 da ist und die quasi jetzt gerade richtig Fahrt aufnimmt.
Erfunden hat es der Adam Dimitruk aus Kanada und das ist einfach im Prinzip was, was man einfach ausprobieren muss. Und da gibt es auch jede Menge Informationen dazu.
Wenn man einfach Event-Modeling googelt, dann kommt man entweder bei meiner Webseite raus oder bei anderen Webseiten.
Es gibt jede Menge Informationen dazu und ich kann wirklich nur empfehlen, das einfach mal auszuprobieren und gucken, ob es funktioniert oder nicht.
Und meine Erfahrung damit ist sehr, sehr gut und die Unternehmen, mit denen ich es bisher gemacht habe, waren alle mehr als begeistert.

[1:33:12] Ich glaube, ich möchte da heute auch quasi nur so extra streng sein für die Nachhaltigkeit davon.
Ich war ja auch als Teilnehmerin bei verschiedensten Workshops bisher in meinem Leben dabei.
Und bei manchen hatte ich das Gefühl, man, das war heute so ein netter Tag, aber nachhaltig war da nichts mehr.
Am nächsten Tag sind wir halt alle wieder vor unsere Laptops und haben weitergearbeitet wie davor. vor.
Und das könnte, ich meine, hier hat man ja zumindest noch so Action-Items, die man danach machen kann.
Dann hat man das erledigt und daraus können wir dann schöne Arbeitspaketchen schnüren.
Aber sonst wäre halt die Sorge so, ja, cool, wir haben jetzt drüber gesprochen, aber jetzt geändert hat sich nichts oder dokumentiert haben wir nichts.
Also ich meine, selbst wenn du nur das Diagramm machst, hast du schon mal einen Mehrwert für das Modell geschaffen.
Auch wenn du nichts weiter machst, hast du schon mal eine super Dokumentation für dein Projekt und das dauert einen Tag.
Du kannst das Modell in einem Tag für ein mittelgroßes Projekt machen. Ja, das glaube ich.

[1:34:20] Ist es dir schon mal, das ist heute alles, was wir besprochen haben.
Ich kann nicht mal sagen, dass es aus einer Produktsicht heraus ist.
Aber dennoch hast du ja auch gesagt, im besten Fall sind Screens auch schon vorbereitet.
Ich habe jetzt auch teilweise Projekte schon mal gehabt, die überhaupt nicht designgetrieben waren, sondern wirklich sehr, sehr, sehr, sehr technisch getrieben.
Obwohl ich im Endeffekt auch gar nicht so genau weiß, was es genau bedeutet.
Im Endeffekt waren dann halt auch einfach Developer dabei, die auch sehr gut im Designen sind.
Oder es gab auch einfach schon fertige UI-Bibliotheken, die man für so ein internes Tool mal verwenden kann.
Aber jetzt aus der Sicht heraus, ich möchte vielleicht gar nichts so für die menschlichen End-User bauen, sondern ich will mir selber eine Admin-Interface bauen.
Ich will mir jetzt selber ein Ticketsystem bauen, sowas.

[1:35:17] Ähm, da habe ich auch schon oft gehört, ist jetzt auch nicht so wichtig, wie die Screens aussehen, mach einfach das, was technisch am leichtesten funktioniert.
Und ich denke jetzt, dass so eine Herangehensweise mit Event Modeling auch sofort schon kaputt gemacht wird, beziehungsweise gar nicht erst entstehen kann oder es gar nicht erst diese Ausrede geben kann, wie ist an dieser Stelle nicht so wichtig, mach einfach das, was technisch am leichtesten ist, weil auch im Endeffekt ist ja das wahrscheinlich auch schon dann eine Entscheidung.
Gut, dann machen wir halt einfach ein natives Formular mit einem nativen Submit Button und fertig. Genau, ist ja völlig okay.
Aber das Wichtige ist, du arbeitest mit den richtigen Daten.
Es kann ja nicht passieren, dass du Daten vergisst oder dass du annimmst, dass Daten da sind, die aber gar nicht da sind, weil das Eventmodell das gar nicht hergibt.
Ja, gut.

[1:36:19] Ich habe keine Fragen mehr. Peter, du hast vorher gemeint, das ist eine allerletzte Frage, aber du darfst natürlich trotzdem noch eine fragen.
Nur für mich fällt einfach keine mehr ein. Ich muss das jetzt halt ausprobieren.
Nein, also das Letzte, was ich jetzt natürlich noch fragen würde, wäre, Martin, wo findet man dich im Internet und wo kann man dich für einen solchen Workshop anheuern?
Genau, am besten einfach auf meine Webseite gehen, nebulit.de und einfach anschreiben.
Oder man findet mich auch auf LinkedIn. Ich poste fast jeden Tag über dieses Thema.
Man darf mich jederzeit anschreiben, man darf jederzeit anrufen.
Ich rede sehr, sehr gerne über das Thema.
Viele können es schon gar nicht mehr hören, die öfter mit mir zu tun haben.
Ich bin wirklich der Überzeugung, dieses Thema wird die Softwareindustrie in den nächsten 24 Monaten revolutionieren.
Jetzt warte ich noch drauf. Kannst du mal an meiner Tür klopfen und sagen, hallo, hätten Sie fünf Minuten, um mit mir über Event-Modeling zu sprechen?
Ich könnte dem Postboten was vom Event-Modeling erzählen. Ich rede wirklich extrem gerne über das Thema.
Also wenn das jemanden interessiert, wirklich sehr, sehr gerne melden.
Ich rede stundenlang drüber.
Dann meine letzte Frage. Woher kommt der Name Nebulit?

[1:37:26] Nebulit, ursprünglich war die Firma quasi für Cloud-Themen verantwortlich.
Nebul ist Nebel, Cloud und daher kommt der Name.
Das ist cool. Aber ursprünglich ist jetzt keine Cloud mehr.
Wir arbeiten natürlich immer noch mit Clouds, spezialisiert auf AWS, aber Fokus ist jetzt tatsächlich auf Entwicklung von eventbasierten Systemen mit Event Modeling.
Alles klar. Martin, hast du noch eine Sache, die du noch nicht loswerden konntest, während wir dich ja die ganze Zeit mit Fragen unterbrochen haben?
Ich habe ja wirklich sehr, sehr viel geredet und es hat genauso viel Spaß gemacht wie letztes Mal. Also ich bin sehr froh, dass ich heute da sein durfte.
Wie gesagt, einfach mal ausprobieren. Ist ein super spannendes Thema und wer Fragen hat, darf sich immer gerne melden. Das klingt großartig.

[1:38:45] Und ich glaube, mir hat diese Reihenfolge jetzt sehr gut gefallen, weil das wäre so ein bisschen das Verständliche für alle.
Und bei Domain-Driven Development, da gab es dann sofort Fachbegriffe, die einfach sehr viel technischer klingen und dadurch sehr viel abstrakter waren.
Aber ich glaube, diese Sachen lassen sich sehr gut dann miteinander verbinden als quasi aufeinanderfolgend.
Dann bleibt mir an der Stelle nur noch vielen, vielen lieben Dank zu sagen.
Ich hatte sehr viel Spaß. Auch Chapeau, wie du unserem Kreuzverhör hier standgehalten hast.
Willkommen bei zwei deutschen Skeptikern. Mir hat es sehr viel Spaß gemacht.
Vielen lieben Dank euch beiden. Und dann hören wir uns wieder nächste Woche mit einem diesmal wieder sehr frontatlastigen, einfachen, einfachen Thema von so ein bisschen Nux.js und Un.js, da gehen wir wieder in die JavaScript-Richtung.
Vielen Dank fürs Zuhören und bis zum nächsten Mal.
Ciao, ciao. Tschüssi. Ciao.

[1:39:54] Music.

[1:40:10] Bis zum nächsten Mal.