super spannend direkt im Projekt drin. Ich glaube, ist so ein bisschen das, was wir auch merken. hast ja Jahre, 13 Jahre glaube ich als Freedancer gearbeitet. Aber bevor wir da reingehen, wie bist du eigentlich zur Softwareentwicklung gekommen? Was ist so dein Background?

Also eigentlich wirklich ganz, ganz klassischer Background. Ich hab mich schon früh mit Computern beschäftigt, gar nicht so sehr mit der Softwareentwicklung eigentlich, aber mit Computer, das war irgendwie immer ein Thema. Und bin dann irgendwann einfach dazu gekommen, dass ich angefangen hab, Informatik zu studieren. Hab mich dann immer tiefer in diese Softwareentwicklungswelt reingefuchst und hab irgendwann gemerkt, dass das eigentlich wirklich das ist, was ich ganz gut kann. Strukturiert denken, strukturiert arbeiten und dann schlussendlich wirklich

Probleme lösen von Kunden. Das ist einfach das, was mir Spaß gemacht hat und deswegen bin ich die letzten 20 Jahre dabei geblieben und es macht mir nach wie vor Spaß.

Die Probleme lösen, sind so die Trigger, die wir haben. wollen einfach helfen in der Softwareentwicklung. Jetzt habe ich gesehen in deinem CV, dass du 13 Jahre als Freelancer gearbeitet hast, aber seit zwei Jahren in die Gründung gegangen bist. Du hast eine eigene GmbH gegründet, du bist jetzt Geschäftsführer. Was hat dich dazu bewegt, diesen Schritt zu machen? Und wie hat sich dein Leben verändert? Was ist für dich der Unterschied? Weil Freelancer ist ja auch selbstständig.

Wie unterscheidet sich die Arbeit des Freelancers für dich versus dem Geschäftsführer von der GmbH?

Ja, also ich habe, glaube ich, so wirklich den klassischen Werdegang eines Geschäftsführers hingelegt. Also ich war erst ganz klassisch drei Jahre lang in der Anstellung, habe als Konsultant gearbeitet für eine Firma in München, bin dann irgendwann als Freelancer gestartet, weil ich gedacht habe, was ich für die Firma machen kann, das kann ich auch selber ganz gut machen und das hat auch gut funktioniert. Und dann eben vor zwei Jahren habe ich mich entschlossen, Freelancer alleine, das reicht mir irgendwie nicht mehr. Ich wollte ein bisschen mehr machen.

und hab dann eben diese GmbH gegründet. Der eigentliche Grund, warum ich mich entschlossen hab, die GmbH zu gründen, war, ich konnte diese Projekte einfach nicht mehr sehen. Es war wirklich so, ich hab in diesen Projekten gearbeitet und ein Projekt nach dem anderen hat einfach nicht funktioniert. Die Budgets wurden überschritten, die Timelines wurden überschritten, die Anforderungen haben nicht funktioniert und jedes Projekt war so. Und egal, wie sehr man sich anstrengt,

Die Projekte schienen einfach nicht zu funktionieren. Und dann habe ich mich entschlossen, das kann ich so nicht mehr machen. Ich habe es einfach nicht mehr gekonnt. Und habe dann geguckt, was kannst du anders machen? Das muss doch irgendwie besser gehen. Und bin dann irgendwann eben auf Event Modeling gestoßen und habe gedacht, das Thema ist in Deutschland quasi nicht präsent. Niemand macht das. Und warum ist das eigentlich so? Und daran muss sich was ändern. Und habe deswegen die Nebulit gegründet mit dem Ziel, dieses Thema für Kunden.

verfügbar zu machen, weil das einfach Probleme löst, denen wir uns seit Jahrzehnten rumschlagen.

Sehr schön. heißt, du hilfst uns allen weiter. Eventmodeling und Event-Sourcing beobachte ich schon eine ganze Zeit. Also das ist ja nichts Neues. trotzdem finde ich super, dass du das jetzt in Hand nimmst und dass du hier in Deutschland quasi in diese Expertise einsteigst und uns allen weiterhilfst. Du hast es ja aber nicht irgendwie einfach so gefunden. Also wie hast du damit Erfolg gehabt? Wie bist du darauf gekommen? Wie ist so der Ursprung?

Ja, also...

Wann hast du gedacht, dass es jetzt nicht einfach nur da ist, sondern Event Modeling ist wirklich richtig gut? Das will ich heute.

Witzigerweise

habe ich Event Modeling 2018 schon gefunden. Es kommt nicht von mir, ich habe das nicht erfunden, erfunden hat es quasi der Adam Dymidruk aus Kanada. Und der hat einfach diese Methode entwickelt aus der Not heraus. Er hatte eine kleine Firma, hatte wenig Entwickler und musste trotzdem in time, budget und quality liefern. Und hat sich einfach überlegt, das muss irgendwie gehen. Auch wir als kleine Firma müssen irgendwie Projekte stemmen können.

Und daraus ist im Prinzip Event Modeling entstanden. Dann hat er einen Artikel geschrieben, Event Modeling, what is it? Ist lesbar auf eventmodeling.org, das ist so die Startseite, wo man in die Welt von Event Modeling einsteigen kann. Und ich habe diesen Artikel 2018 gelesen, kurz nachdem er ihn veröffentlicht hat. Und ich habe ihn nicht verstanden. Ich habe ihn gelesen, habe gedacht, das ist ja eine ganz nette Idee, und ich habe ihn nicht verstanden und habe es dann wieder vergessen. Und bin zurück in meine Projektwelt gegangen.

und hab mich geärgert, dass all diese Projekte nicht funktionieren. Und dann irgendwann im, ich glaube, es war November 2021, bin ich wieder über diesen Artikel gestolpert, hab mir den Artikel wieder durchgelesen und dann ist mir ein Licht aufgegangen. Und dann hab ich gemerkt, das ist genau der fehlende Baustein. Genau das, was in allen Projekten fehlt. Das Puzzlestück, was Klarheit bringt und was endlich dafür sorgt, dass man Anforderungen so beschreibt, dass nicht nur die Techniker sie verstehen, sondern auch die Fachseite und im Prinzip jeder, der an einem Projekt beteiligt ist.

Und dann habe ich im Prinzip sofort angefangen, ganz, ganz tief in diese Event-Modeling-Welt eingestiegen. Ich war der im Discord, also es gibt so einen Event-Modeling-Discord. Und ich glaube, ich war der, der am meisten Fragen gestellt hat. Alle Leute da waren total genervt für mich, weil ich ständig irgendwelche Fragen gestellt habe, weil ich wissen wollte, wie funktioniert das, wie muss man das machen. Genau. Und irgendwann habe ich es halt wirklich verstanden, habe wirklich verstanden, wie das Ganze funktioniert, habe dann mit den ersten Kunden wirklich zusammengearbeitet und versucht seitdem...

eigentlich nur noch damit zu arbeiten. Das meiste, was ich mache, ist mit Kunden zusammenarbeiten, mit Event Modeling zu arbeiten und einfach versuchen, andere Firmen davon zu überzeugen, dass das der bessere Weg ist, wenn wir einfach zu viele Probleme damit lösen.

Ja, sehr schön. Hört sich spannend an. glaube, gleich werden wir auch noch mal reinschauen, was Event Modeling eigentlich ist. Vorher habe ich einige hilfreiche Links schon gehört, die werden wir in die Show Notes mit aufnehmen. Später zum Nachlesen. Vielleicht geht es dem einen oder anderen dann auch so, dass er schon mal über den Artikel gestolpert ist und jetzt ihn dann intensiver liest. Aber jetzt hilf uns noch mal, pitch uns vielleicht mal Event Modeling so in der Nutshell. Was ist das und warum sollte ich es einsetzen?

Im Prinzip ist es wirklich ganz einfach. Wie funktionieren Projekte typischerweise und woran scheitern die meisten Projekte? Die meisten Projekte scheitern in Kommunikation. Die Techniker können nicht mit der Fachseite reden, die Fachseite kann nicht mit den Technikern reden, weil die einfach nicht die gleiche Sprache sprechen. Und genau das macht Event Modeling. Im Prinzip, was machen wir? Wir setzen uns alle zusammen und wir versuchen, so ein System von Grund auf so zu modellieren, dass jeder versteht, was passiert da eigentlich. Und die größte...

Die größte Sache, die Event Modeling bringt, ist im Prinzip, wir modellieren ein System entlang einer Timeline. Das heißt, wir fangen von links an und modellieren das System genauso, wie man es auch verwenden würde. Das heißt, ich kann mich vor so ein Event Model setzen und ich kann links anfangen und kann es von links nach rechts lesen, wie so Buch. Wir arbeiten mit Screens, wir arbeiten mit Events und modellieren im Prinzip die Geschichte von unserem System. Und...

Wenn man mit Event Modeling arbeitet, dann arbeitet man typischerweise in sieben Phasen. Man hat sieben Phasen, die man so typischerweise durchläuft. In so einem Workshop, da können wir vielleicht nachher auch noch bisschen drüber reden, wie so die typischen Workshops ablaufen. Aber Anfang tun wir immer mit einer ganz, ganz großen Gruppe, idealerweise. Also ich hole immer alle Leute zusammen, die zu so einem Projekt dazugehören. Und wir machen Brainstorming. Was heißt Brainstorming? Wir sammeln einfach alle Fakten, alles, was in unserem System passieren kann. Wir sagen Events dazu, aber man kann auch Fakten sagen, das ist eigentlich das Gleiche.

So ein E-Commerce-System zum Beispiel, also ein Beispiel in dem Buch, ich geschrieben habe, ist einfach so ein einfaches E-Commerce-System, so ein Cardsystem. Da könnte so ein Event einfach sein, Item Added. Wenn ein User jetzt zum Beispiel ein Item, Produkt in seinen Warenkorb legt, Item Added, Item Removed oder zum Beispiel auch Cards Submitted. Einfach Dinge, die in unserem System passieren können. Da gibt es auch gar nicht so viele Regeln, sondern die einzige Regel ist eigentlich, wir formulieren die Sachen in der Vergangenheit.

Das ist die einzige Regel. im Brainstorming sammeln wir dann einfach so viele Events wie möglich. Und da ist schon der erste große Unterschied zu den typischen Projekten. Was wir hier nämlich machen, ist, hier arbeiten wirklich alle zusammen. Die Fachabteilung, die Technik, Security, UX, manchmal sogar das CEO, sind alle in einem Raum und wir sammeln Events. Und am Ende haben wir 200 oder 300 von diesen Events und plötzlich merken wir, wir alle sprechen eine gemeinsame Sprache. Wir haben die gleichen Begriffe und plötzlich versteht jeder

Was macht denn unser System eigentlich? Ohne, dass wir über die Technik sprechen. Man sieht schon, das sind die Dinge, unser System kann. 300 Events auf einem Board und jeder sieht genau, was unser System kann. Und das nächste, was wir machen, ist, wir bringen diese Sachen einfach in eine Reihenfolge. Und sobald du diese Reihenfolge hast, wir nennen das Storyboarding, dann kannst du das System wirklich von links nach rechts lesen. Und du redest zu keiner Zeit, redest du über die Technik. Es ist einfach nur ein Sammeln der Dinge, die unser System tut.

Mhm.

Und wenn du das geschafft hast, dann bist du gar nicht so weit weg davon zu einem sauberen Systemdesign, weil das ist das Wichtigste, was du machen musst. Wir definieren ganz genau, was muss unser System eigentlich tun. Nicht das Wie. Wir definieren nicht das Wie. Wie ist die Sache der Entwickler? Die können sich später darum kümmern. Wichtig ist zu verstehen, was soll unser System eigentlich tun. Und dann im Prinzip geht es darum, dass wir einfach nur noch definieren, was sind denn die... Wie kommt die Information in unser System?

Das sind Commands, das sind die blaueste Stickynotes wie kommt Information in das System und wie kommt Information aus unserem System heraus. Es gibt nur diese beiden Richtungen. Entweder Information kommt ins System oder Information kommt aus dem System heraus. Was anderes gibt es nicht. Und tatsächlich ist es so, das ist das Einzige, was du brauchst, auch das komplexeste System zu modellieren. Was man nämlich feststellt, und das war, glaube ich, einer der großen Aha-Momente, egal wie komplex dein System ausschaut.

Alle Systeme sind eigentlich gar nicht so komplex. Komplexe Systeme haben einfach nur mehr von diesen kleinen Bausteinen. Wir zerlegen im Event-Model das System in klitzekleine Bausteine. Entweder du hast einen Baustein, Daten in das System bringt, wir nennen das State Change, oder du hast einen Baustein, Informationen aus dem System herausholt. Das nennen wir State View. Und mehr gibt es nicht. Und wenn du ganz viele dieser kleinen Bausteine aneinander reißt, merkst du plötzlich, du hast ein komplettes System modelliert und du weißt genau, wie es funktioniert. Und je komplexer das System ist,

heißt nur, du hast mehr Bausteine. Das heißt nicht, dass die einzelnen Bausteine komplexer sind, die sind immer gleich einfach, du hast einfach nur mehr von diesen Bausteinen. Und damit kannst du jedes System dieser Welt modellieren. Es funktioniert immer.

Das hört sich echt cool an. Ganz viele Fragen, die natürlich da bei mir hochkommen, ist, wenn ich mir jetzt so eine große Gruppe an Leuten aus allen möglichen Abteilungen vorstelle, wissen die denn überhaupt, wie ihr System funktioniert? Also meine These ist, die Komplexität kommt durch die Vagheit die man sich offen lässt. Also wir lassen hier Einstelloptionen, ob es eventuell links oder rechts gehen könnte und wir wissen ja noch gar nicht, wie der User es benutzt. Wie nimmst du das

Nein.

denn wahr? Also so einfach runterschreiben geht wahrscheinlich auch nicht, das werden hitzige Diskussionen sein, oder?

Tatsächlich ist der Trick dabei, wirklich so einfach wie möglich zu machen. Am schlimmsten ist es, mit Entwicklern zu modellieren. muss man wirklich sagen. Entwickler sind die schlechtesten Modellierer. Warum? Alle Entwickler neigen immer dazu, zu optimieren. Die wollen die Prozesse optimieren, die suchen die Abstraktionen und die machen das einfach viel zu kompliziert. Und ich gehöre selber dazu. Ich bin selber Entwickler und ich muss mir da wirklich an die eigene Nase fassen. Ich habe das auch jahrelang gemacht. Die Sachen einfach zu machen, ist das Schwierigste, was es gibt.

Aber wer das richtig gut kann, ist die Fachabteilung. Die wissen nämlich genau, wie ihre Prozesse funktionieren und die modellieren die Software genauso, wie sie auch ist. Die kümmern sich nicht Optimierung und das ist die beste Art und Weise, Systeme zu modellieren. Und wenn wir jetzt anfangen, ein System zu modellieren, ist meine Aufgabe in so einem Workshop eigentlich immer nur dafür zu sorgen, dass wir nicht in die eine Richtung, also in die technische Richtung abdriften oder in die fachliche Richtung, sondern dass wir uns einfach auf das fokussieren, was macht dieses System eigentlich.

Was sind die Screens, wir sehen? Was sind die Buttons, wir sehen? Wo können die User klicken? Was passiert, man auf diesen Button hier klickt? Wir machen das im Prinzip wirklich Schritt für Schritt von links nach rechts. Ganz einfach entlang einer Timeline. Am Ende hast du das komplette System modelliert und alle nicken am Ende und sagen, jawohl, das ist genau das System, was wir brauchen.

Okay.

Das ist ja spannend. Und ich denke mal, einem gewissen Punkt macht es einen Klick und die Leute fangen an, die Events zu denken. Wie sind so deine Erfahrungen? Was passiert da mit den Leuten? das ändert sich ja. Wir sind ja alle trainiert, wir haben ja alle unsere Denkmuster. Deshalb hast du wahrscheinlich gesagt, es ist viel einfacher mit der Fachabteilung zu arbeiten, weil sie ja die ganze Implementierung dahinten gar nicht...

interessiert. Sie wollen einfach nur irgendeine Prozessunterstützung haben mit der Software. Und wie kriegst du die ITler dazu, das mal fallen zu lassen und dann wirklich in Events zu denken?

Ja.

Das ist tatsächlich, das ist wirklich ein Prozess. Also das funktioniert am Anfang überhaupt nicht, speziell wenn es Entwickler sind, die schon jahrelang Erfahrung haben, die jahrelang mit Datenbanken arbeiten. Die fangen sofort an und denken, okay, wenn ich das hier habe, wie sieht die Tabelle aus, wo ich die Dinge speichern muss? Wie ist das zu optimieren? Wo sind die Fremdschlüssel? Welche Relationen brauche ich? Das interessiert alles überhaupt nicht. Das ist alles überhaupt nicht wichtig. Was wichtig ist, ist, was passiert in unserem System. Und die Fachabteilung

Die machen das ganz natürlich. Die sagen, erst passiert das, dann passiert das, dann passiert das und dann passiert das. Und am Ende ist die Order abgeschickt. Wunderbar. Es ist wirklich ein Prozess und wie gesagt, Entwickler brauchen am längsten, zu verstehen, wie das eigentlich gedacht ist.

Super.

Was sind denn so typische Missverständnisse oder Sachen, die du immer wieder begegnest, wo du sagst, ja, kannst du vielleicht den Zuhörern einen Tipp geben, sich davon zu befreien oder das erstmal nicht zu machen und was sind so die Sachen, kann ich mir vorstellen, da sind immer wieder ähnliche Dinge, die dann immer wieder auftauchen. Hast du da...

Ja. Also,

die erste Sache, die Entwickler immer machen, immer, in jedem Workshop, die meisten haben das Buch gelesen von Eric Evans, Domain Driven Design, und haben dann sofort diesen Begriff Aggregate im Kopf. Aggregate ist im Prinzip, Entwickler verstehen das eigentlich als so ein...

Wie baue ich mein Modell auf? Mein Modell besteht aus Aggregates und die Entwickler fangen sofort an, in der ersten Session meistens schon, die Events in Aggregates zu strukturieren und kommen sofort in dieses technische Denken rein und das ist der größte Fehler, man machen kann. Technik hat in Event Modeling Sessions nichts zu suchen.

Okay, Technik kommt da raus. Das Glaube Buch ist natürlich allen Domain-Driven-Design-Leuten bekannt. Im Domain-Driven-Design gibt es auch eine Methode, die heißt Event Storming. Und mir persönlich ist es so gegangen, ich habe mal gesagt, hey, lass uns mal Event Modeling ausprobieren und dann, du meinst wohl Event Storming.

Ja.

Ja.

Nein, Event

Modeling. Kannst du vielleicht noch mal den Unterschied sagen. Event Storming ist auch in Europa entstanden, in Italien und wird eigentlich sehr oft im Domain für Design verwendet. Vielleicht kannst du noch mal bisschen aufklären, was das genau ist und wie es sich unterscheidet zum Event Modeling.

Genau, ich habe eingangs gesagt, Event Modeling ist gar nicht so verbreitet. Event Storming schon. Also Event Storming ist viel weiter verbreitet als Event Modeling. Die beiden Methoden sind sich sehr, ähnlich. Event Storming ist ein bisschen mehr high level als Event Modeling. Das heißt, die ersten Phasen, die sind eigentlich identisch. Wir starten immer mit einem Brain-Storming. Wir sammeln die Events, wir bringen die Events irgendwie in eine Reihenfolge, klustern die Events. Aber Event Modeling geht dann mehr in die ...

in die strukturierte Richtung, wie funktioniert mein System entlang einer Timeline. Das ist der große Unterschied. Das hast du im Event Modeling nicht. Im Event Modeling hast du die Cluster von Events und definierst dann im Prinzip so ein bisschen die Regeln, was gelten für die einzelnen Cluster, definierst deine baune Kontexte. Event Modeling ist wirklich eher, wir modellieren entlang einer Timeline und wir fokussieren uns wirklich auf unser System. Und deswegen haben wir im Event Modeling auch wirklich Screens. Wir arbeiten mit Screens, wir zeichnen einfache Screen Mockups zum Beispiel.

Damit jeder versteht, okay, hier ist dieser Screen, hier ist dieser Button, da kann der User draufklicken. Gar nicht so sehr, wie die aussehen, das ist gar nicht so wichtig, aber dass man versteht, was ist die Information, die ins System kommt, wo kann ich klicken und jeder weiß genau, wie das System funktioniert. Man kann sich es wirklich so vorstellen, als würde ich mich mit einem von der Fachabteilung an den Rechner setzen und dieses System einfach durchspielen. So kann man sich es vorstellen. Und das ist im Event Storming nicht. Im Event Storming geht es eher darum, diese Events wirklich zu finden. Was sind die wichtigsten Events?

Im Event Stomping heißt es Pivot Events. Bisschen mehr High Level und Event Modeling ist ein bisschen näher an der Implementierung. So würde ich es beschreiben.

Was ich auch spannend finde, ist, hast schon ein paar Mal erwähnt, den Faktor Zeit mit reinzubringen, eine Reihenfolge zu setzen. Event Modeling ist ja hier eine Aggregation von den Ereignissen, die ich habe, aber sagt noch nichts daraus, was folgt auf was und was für eine Rolle spielt dort Zeit. Sehr, spannend. Eingangs hatte ich es schon mal im Intro erwähnt. Du hast so ein Statement, was du sehr oft raushaust. Software hast du vorhin auch schon gesagt. Software ist nicht kompliziert. Wir machen sie nur kompliziert.

Und du gehst sogar so weit, dass man sagt, das ist Schätzerei. Ich hab dafür eine Lösung. Ich kann es zum Fixpreis anbieten. Was machen wir alle falsch? Warum kannst du das?

Also, so weit würde ich nicht gehen, dass alle was falsch machen. Ich habe einfach für mich einen Weg gefunden, der einfach funktioniert. Was wir im Event Modeling machen, ist, wir zerlegen das System, habe ich vorher schon gesagt, in diese kleinen Bausteine. nennen das Slices. Das große Problem ist, wir Menschen sind super schlecht darin, große Dinge zu schätzen. Du fängst dann an zu schätzen, hast einen kompletten baune Kontext, sollst schätzen, wie du ihn brauchst, ihn zu bauen. Und was du dann typischerweise bekommst, ist XXL, eine XXL-T-Shirt-Size.

Niemand kann damit was anfangen. Damit kannst du nichts anfangen. Die XXL kann sein, das sind zehn Tage. Kann sein, das sind 25 Tage. Typischerweise hast du dann irgendwo diesen typischen Umrechnungsfaktor Storypoint in Personentage. Die meisten Firmen wollen agil arbeiten, arbeiten dann mit Storypoints, weil wir ja Komplexität schätzen. Und in jedem Projekt gibt es irgendwo diesen Umrechnungsfaktor, der Storypoints in Personentage umrechnet. Weil am Ende des Tages das einzige, was dem Projektmanager interessiert ist,

Wann ist es fertig? Wie viele Story Points interessiert niemanden? Wann ist es fertig? Wollen die meisten wissen. Und diese großen Dinge zu schätzen, ist superschwer. Was wir aber supergut können, ist, wir können kleine Dinge schätzen. Kleine Dinge verstehen wir supergut. Und deswegen zerlegen wir im Event Modeling dieses System in kleine Slices. Und jeder Slice ist ungefähr gleich groß. Für mich ist ungefähr ein Tag Arbeit, ein Slice ist ein Tag Arbeit. Das heißt, wenn ich ein System habe mit zehn Slices,

dann kann ich das in 10 Tagen ungefähr bauen, weil ich weiß, ich brauche ungefähr einen Tag für einen Slice. Inklusive UI, inklusive Backend, alles, was dazugehört. Ein Slice kann jetzt zum Beispiel sein, ich habe eine UI, ich habe einen Button, ich klicke auf diesen Button und die Informationen werden im System gespeichert. Inklusive allem, was dazugehört. Und das könnte ich so auch dann in Produktion deployen. Wenn ich jetzt einen Tag brauche für so einen Slice und ich habe ein System, das eben vielleicht 100 Slices groß ist, dann weiß ich, dieses System hat 100 Tage Aufwand. Und weil ich genau weiß, wie lange ich für einen Slice brauche,

Mhm.

kann ich für diesen Slice auch einen Fixpreis ansetzen. Und dann funktioniert das. Der Trick ist diese kleinen Bausteine, die Größe der Arbeitspakete. ist der Trick. Je kleiner, desto besser. Und viel kleiner als ein Tag. kriegst es nicht hin, aber ein Tag ist eine super gute Messlatte.

Okay, passiert dann nicht automatisch, dass dann das Event-Model oder den Slice in den Tag gepackt wird und dass ich dann vielleicht Abstriche mache in meiner Ausführung, also damit es da reinpasst.

Nö,

tatsächlich sind die Slices, also manchmal ist natürlich ein Slice größer als ein Tag, das kann man nicht vermeiden, manchmal ist ein Slice aber auch viel kleiner als ein Tag. Und im Mittel aber, es muss nicht ein Tag sein, vielleicht sind es auch zwei Tage, aber im Mittel kommst du eigentlich immer bei einem Wert raus, das ist unsere Durchlaufzeit für einen Slice. damit lässt sich wirklich ein Projektplan erstaunlich genau machen, wirklich erstaunlich genau.

Ich weiß.

Der große Vorteil daran ist wirklich, auch wenn du jetzt ein System modellierst mit 100 Slices, dann wirst du natürlich diese 100 Slices nicht fertig bauen. Weil wenn eine Sache in Projekten sicher ist, dann ist es, dass sich Requirements ändern. Und das ist große Problem in den typischen Projektplänen. Die typischen Projektpläne, die hassen Änderungen. Die hassen Change. Aber Requirements ändern sich.

Und wenn du so kleine Arbeitspakete hast, dann bedeutet das, wenn sich Requirements ändern, nur dass sich zum Beispiel ein Slice ändert oder dass sich zwei Slices ändern oder dass vielleicht neue Slices dazukommen. Dann habe ich vielleicht am Ende mein System, nicht 100 Slices hat, sondern 110 und dann zahlt der Kunde halt 110 Slices. Aber jederzeit ist klar, wenn mir diese Requirements ändern kommen, fünf Slices hinzu und für den Kunden ist völlig transparent, dann zahle ich fünf Slices mehr. Aber ich bekomme genau das, was ich

Ja, super spannend. das heißt, je kleiner wir unterwegs sind, besser können wir das Ganze abschätzen und wir können auch schneller unterwegs variieren, wenn wir merken, das Projekt shiftet in eine andere Richtung, werfen wir Slices raus, fügen neue hinzu. Du hattest eingangs gesagt, der Slice ist immer eine lieferfähige Einheit, also wahre Agilität hier. Also das heißt, andere Projekte sind dann nicht so agil wie mit Hilfe dieser Methode.

Ja.

Ja.

Genau, also du bist wirklich, das ist echte, agile Entwicklung, weil du wirklich von Tag zu Tag flexibel reagieren kannst. Typischerweise, du lieferst jetzt nicht einen Slice in Produktion, das könntest du natürlich technisch, machst du aber nicht. Wir gruppieren die Slices nochmal, wir nennen das Chapter, einfach in so fachliche Einheiten. Also zum Beispiel so ein Produkt in den Wagenkorb legen. Könnten jetzt drei, vier Slices sein. Ein Slice ist, ich leg das Produkt in den Wagenkorb, ein Slice ist, ich zeig dieses Produkt dann wieder an und das ganze Paket kannst du dann dem Kunden liefern und das sind zum Beispiel drei Slices.

Und sowas kannst du dann wirklich in Produktion

Ja, spannend. Du hast es mir schon fast verkauft. Jetzt bin ich einer, der hört dir zu in dem Podcast zum Beispiel oder ich schaue mir Videos an und ich habe was gefunden. Ich will das unbedingt einführen. Bin total motiviert. Komm rein, wir machen die ersten Sessions und dann klappt das nicht so.

Natürlich nicht.

Wie das in deiner Idealwelt aussieht. Was für

Tipps hast du denn? Also dieses gefährliche Halbwissen Also ich denke, ich hab das ganz gut verstanden, wie du es gesagt hast und hab auch deine ganzen Videos gesehen. ja, was für Tipps gibst du da den Leuten? Wie kann man da...

Also,

was nicht funktioniert ist, typischerweise, einfach loslegen und einfach mal machen. Theoretisch kann das funktionieren, aber es ist einfach, es kommen dann so viele Fragen auf und dann hängt man und fragt sich, wie muss ich das jetzt modellieren? Und plötzlich ist die ganze Session ins Stocken. Die Fachabteilung interessiert sich dann nicht mehr dafür, schweifen ab und dann plötzlich funktioniert es nicht mehr. Was ich immer, immer empfehlen würde, immer, ist in den ersten paar Sessions

einen Facilitator dazuzuholen, der das einfach schon 100 Mal gemacht hat und der genau weiß, wie man so eine Session am Laufen hält. Das bietet sich wirklich an und das spart auch wirklich Zeit. Später ist es vielleicht nicht mehr notwendig, wenn die Entwickler oder die Beteiligten eine gewisse Erfahrung haben und auch wissen, wie man bestimmte Dinge modelliert, dann läuft das eigentlich ganz gut. Aber gerade am Anfang würde ich sehr empfehlen, einfach jemanden dazuzuholen, der dafür sorgt, dass die Session am Laufen bleibt. Das ist wirklich ganz wichtig.

Inhalten gibt es natürlich auch Workshops. Wenn wir jetzt einen Workshop zusammen machen, wie läuft das denn so ab? Welche Tools benutzt du dort? Nehm uns da mit auf die Reise in so einen Workshop.

Ja.

Genau, es gibt zwei Arten von Workshops. Ich mache Workshops, die wirklich das Ziel haben, Event Modeling als Methode aufzuzeigen. Das mache ich aber gar nicht so gerne, sondern am besten funktionieren die Workshops. Wir nehmen uns ein konkretes fachliches Problem und wir erarbeiten uns das im Prinzip gemeinsam. Also genauso, wie man das auch in einem Unternehmen machen würde, wenn man Problem und wir müssen es modellieren, lassen Sie es einfach mal probieren. Typischerweise sind es zwei Tage, die wir machen. genau wie ich es vorher gesagt habe, wir fangen im Prinzip an mit dem Brainstorming.

und gehen durch diese ganzen Phasen, die man im Eventmodel hat. Und wir machen das typischerweise in Miro. Also digital, auf einem Whiteboard. hab grad vorletzte Woche in München einen Workshop gemacht. Da haben wir es mit echten Sticky Notes gemacht, an einer echten Wand. Hab ich schon jahrelang nicht mehr gemacht. Und tatsächlich muss ich sagen, es funktioniert auch nicht richtig gut. ...

diese sticky notes hin und her zu schieben, das dauert einfach viel zu lang. Man verliert unglaublich viel Zeit. ich würde immer empfehlen, das Ganze digital zu machen. Mein Tool der Wahl ist Miro, funktioniert einfach völlig problemlos und man ist da auch sehr, schnell unterwegs. das ist so das, was ich verwende. Ich habe auch ein Tool geschrieben für Miro, also ein Plugin, was man Miro einfach verwenden kann. Das ist Event Modeling Toolkit, was einfach so bisschen die Event Modeling und alles, was dazugehört, direkt nach Miro bringt, mit ein bisschen Automatisierung.

bis hin zu Validierung, was man im Prinzip braucht, zu

Du hast ja erzählt, ihr habt auch so Color Codes für die Sticky Notes, die unterschiedliche Bedeutung haben für Input, Output und vielleicht auch... ja, sehr spannend.

Ganz genau.

Wenn du jetzt mal so in deiner Vergangenheit siehst, bist du irgendwann schon mal in so Projekt reingekommen, hast gedacht, oh Gott, was ist das jetzt hier? Und hast den Vorschlag gemacht, lass uns doch mal Event-Modeling machen und hast damit das Projekt gerettet. Hast du dort irgendwelche War Stories für uns?

Das kommt tatsächlich ständig vor. Das kommt wirklich ständig vor. Also ganz, ganz häufig ist es so, dass das Projekt irgendwo hängt, dass irgendwo der Knoten ist und man kommt einfach nicht so genau weiter. Man weiß nicht so genau, was ist überhaupt das Problem, woran liegt es? Ist es die Technik? Sind es die Anforderungen? Wieso kommen wir hier nicht weiter? Wieso drehen wir uns ständig im Kreis? Und ganz, ganz häufig ist es so, lass uns das mal...

Alles beiseite legen, wir modellieren mal das System und wir gucken einfach mal, was passiert. Und dann ganz häufig ist es so, dass dann der große Aha-Moment kommt und sagt, okay, das ist der Grund, warum es nicht funktioniert. Wir haben hier eine Race-Condition und das haben wir von außen gar nicht gesehen. Und jetzt sehen wir plötzlich, da gibt es diese Abhängigkeiten. Und wenn man das modelliert, dann wird plötzlich klar, so funktioniert das. Und gerade kürzlich hatte ich das in einer Plattform, die ich für Anwälte gemacht habe. Da war auch Dokumentenmanagement und es war nicht ganz klar,

Wieso ist das so kompliziert? Die Dokumente müssen hochgeladen werden, die müssen validiert werden und irgendwie alles total kompliziert. Wenn man es aber dann modelliert hat, dann war total einfach. Dann war ganz klar, das muss passieren, das muss passieren, das muss passieren und eigentlich gibt es da auch keine Parallelität und gar nichts. Das ist alles ganz, ganz einfach nacheinander. Wenn man es einmal ausmodelliert. Der Code, der schon da war, war super komplex, super kompliziert, viel komplizierter, als er hätte sein müssen.

Okay, also mit den Fachleuten sprechen die ganze Wahrheit in Form von Events und Modellierung auf den Tisch. Aber in gewissen Punkten muss natürlich so ein Slice auch umgesetzt werden in Code. Gibt es da irgendwelche Frameworks oder sagst du das sind einfach nur Funktionen, die drei Zeiler, zehn Zeiler sind und die super simpel. Also wie komme ich jetzt von der Theorie, weil ich kann mir vorstellen, es gibt ganz viele Architekturzeichnungen.

Ja.

die erstellt werden und dann ist so diese Übersetzung von der Theorie der Zeichnung des Systems hin zu Code. Wie komme ich jetzt von dem Event Model zum Code?

Das hängt immer ein bisschen davon ab, was die Zielplattform ist. Also, ich arbeite ganz viel mit Event Sourcing. Da werden wir vielleicht nachher auch noch bisschen drüber sprechen. Und speziell mit Event Sourcing ist die Übersetzung aus dem Event-Modell extrem einfach, weil es fast ein 1 zu 1 Mapping ist. Und das Schöne ist wirklich, also ich arbeite ganz viel mit Code-Generierung. Also, ich generiere mir tatsächlich den Code direkt aus dem Event-Modell und habe dann im Prinzip fast einen vollständigen Slice, den ich dann nur noch ein bisschen anpassen muss, zum Beispiel in der UI oder so.

Aber der grundsätzliche Code lässt sich fast komplett generieren aus dem Eventmodel. Und das Schöne ist aber, diese Slices, da die so klein sind, sehen die eigentlich immer gleich aus. Das heißt, wenn ein neuer Slice gebaut wird, dann ist es fast immer eine Kopie von einem alten Slice. Du kannst immer einen alten Slice nehmen, kopierst den einfach und passt den ein bisschen an, weil die eigentlich alle gleich aussehen. Speziell Event Sourcing und auch, wenn man mit Event Modeling arbeitet, wir arbeiten da ganz, ganz viel mit Patterns. Das ist eigentlich Patterns, die du lernst und dann...

immer und immer und immer wieder anwendest. Das ist immer das Gleiche. Nachteil davon, das Programmieren wird extrem langweilig. Programmieren ist super, super langweilig, weil du ständig das Gleiche machst. wie bei so einer Kata im Kampfsport, wenn man ständig das Gleiche macht, dann bist du irgendwann einfach super effizient, genau darin diese Dinge zu tun. Und da kommt die Geschwindigkeit.

Hört sich gut an. Event und Event Sourcing liegt nahe. Du hast eben schon angesprochen, was ist eigentlich Event Sourcing und wozu brauche ich das?

Event-Sourcing, da scheiden sich ja immer noch so bisschen die Geister. Also auch genau wie Event-Modeling, Event-Sourcing ist nach wie vor so eine kleine Nische, möchte man meinen, aber tatsächlich ist es so, ich spreche mit extrem vielen Unternehmen und tatsächlich viele Unternehmen arbeiten bereits mit Event-Sourcing. Also es ist gar nicht so eine kleine Nische, wie man vielleicht vermuten würde. Aber was ist Event-Sourcing? Im Prinzip, anstatt Dinge einfach flach in einer relationalen Tabelle zu speichern, also zum Beispiel

Zurück zu meinem Cart-Beispiel. Ich habe meinen Cart und ich habe irgendwelche Cart-Items und ich habe dann vielleicht eine Tabelle, wo ich so einen Cart einfach speichere. Und jedes Mal, wenn ich was an diesem Cart ändere, dann speichere ich den neuen meiner Tabelle. Funktioniert, aber was ich natürlich jedes Mal verliere, ist im Prinzip die Historie. Wie bin ich überhaupt zu diesem Cart gekommen? Hat der User vorher vielleicht ein Item in den Cart gelegt? Hat er ein Item entfernt? Die ganze Historie, die geht dabei eigentlich verloren. Und was wir in Events Sourcing machen, ist

Wir speichern uns die Event. im Prinzip jedes Mal, sich irgendwas im System verändert, dann speichern wir das. Wir speichern uns ein kleines Item-Added-Event, ein kleines Item-Remove-Event und haben dann im Prinzip die komplette Historie unseres Systems in einigen Event-Streams gespeichert. Der große Vorteil davon ist aber, da ich diese ganzen Daten in meinem Event-Stream habe, habe ich jetzt auch die Möglichkeit, mit diesen Daten zu arbeiten. diese Möglichkeit, die verliere ich so bisschen, wenn ich ohne Event-Sourcing habe.

Denn ich kann jetzt im Prinzip aus meinen Events beliebige Repräsentationen für mein System bereitstellen. Mir nennen es Projektion. Also ich könnte jetzt zum Beispiel eine Projektion für meinen Cart bereitstellen, indem ich einfach alle Events aus meinem Event Stream nacheinander einspiele und mir dann meinen Cart neu zusammenbaue. Wenn ich ein Item entferne und ein Item hinzufüge, habe ich hinterher ein Item im Cart. Und so kann ich im Prinzip meine Projektionen dynamisch zusammenbauen.

Jetzt kann es aber auch passieren, dass plötzlich eine ganz neue Anforderung kommt. Ich brauche sowas wie Analytics für meinen Cart. Ich möchte wissen, wie oft entfernt mir jetzt eigentlich ein User so ein bestimmtes Produkt aus dem Warenkorb. In einem CRUD-System, wo ich nur flache Cards gespeichert habe, ist es quasi unmöglich herauszufinden für historische Daten. Außer ich habe vielleicht sowas wie historisierte Tabellen oder sowas und muss mir dann mühsam aus meinem Analytics-System diese Daten oder aus dem Data Warehouse

diese Daten heraussuchen. In Event Sourcing ist das im Prinzip eingebaut. Egal welche Anforderungen ich habe, ich kann mir diese Daten so aufbereiten, wie ich sie brauche. Also im Prinzip, was wir machen ist, wir sorgen dafür, dass wir die Fragen, die morgen gestellt werden, heute beantworten.

Ja, super spannend. Gerade wenn man solche Audit-Trails sich anguckt, Standardsystem hat man ja, Feld A wurde von A nach B geändert. dem Datum, da jeder Auditor, der sowas auseinandernehmen muss und dann einen Rückschluss aufs System kriegen möchte, der wird ja verrückt. Und wir speichern sozusagen die Historie. Das klassische Beispiel, was du gedacht hast, ist natürlich der Shopping-Card ist aber auch der Bank-Account. Also wir speichern nie die Summe auf dem Bank-Account, sondern die einzelnen Transaktionen.

und am Ende des Tages gibt es dann immer eine Summe. Jetzt sind das natürlich triviale Beispiele und wir haben ja Systeme, die irgendwie dann erst interessant werden, wenn sie übergreifend Daten hin und her schieben. Wie groß oder wie klein sollte denn so ein Event Stream sein? Wie kann ich da in der Modellierung besser werden? Wir denken alle in CRUD oder die meisten zumindest, die haben dann irgendwie Master Detail oder irgendwelche normalisierten Datenstrukturen im Kopf.

Und jetzt in Event-Streams zu modellieren, wie groß darf der sein, wie muss der sein, du da vielleicht noch bisschen komplexere Beispiele, dass man das noch bisschen greifbarer machen kann.

Genau, das generisch zu beantworten, ist extrem schwer. Das hängt immer so bisschen vom Use-Case ab. Das größte Argument, was ich immer wieder höre, wenn ich mit Unternehmen, mit Kunden über Event-Sourcing spreche, ist, was passiert denn, wenn ich jetzt Millionen von Events habe und ich möchte mir meine Projektion zusammenbauen? Ich habe keine Zeit da stundenlang zu warten, bis diese ganzen Millionen von Events verarbeitet sind. Typischerweise ist es aber nicht so, dass man Millionen von Events verarbeitet. Die Event-Streams selber sind meistens

überschaubar klein. Also wir reden da von Hunderten, vielleicht ein paar Tausend Events, Millionen Events in einem Event Stream ist eher ein Anti-Pattern. Also kann natürlich mal vorkommen, kann man nicht ausschließen, aber meistens versucht man das Ganze eher so bisschen fachlich so zu modellieren, dass die Streams relativ klein sind. Also bestes Beispiel zum Beispiel, wenn du ein Kassen System modellierst, dann ist der Stream typischerweise einfach alle Zahlungseingänge, Zahlungsausgänge an einem Tag. Dein Stream ist

Du hast nicht eine Kasse, die über Monate und Jahre hinweg Events speichert, sondern du hast genau die Streams für diese eine Kasse an diesem einen Tag. Und am nächsten Tag startest du einen neuen Stream. Und damit hast du im Prinzip immer kurze Streams, mit denen du arbeiten kannst und verhinderst, dass das System so unglaublich groß wird.

Also dann habe ich jetzt für mich rausgehört, dass Pattern, wenn ich zu viele Events habe, ist es ein Indikator dafür, dass ich falsch modelliert habe. das heißt, bei überschaubaren Systems sollten die in die Millionen gehen, sondern dann habe ich eine überschaubare Anzahl an Events, die ich noch verarbeiten kann.

Nicht zwangsläufig, aber könnte sein.

Es gibt fast immer einen

fachlichen Weg, die Streams klein zu halten. Die Person, die dir das ziemlich genau sagen kann, ist die Fachabteilung. Wenn man die fragt, wann ändert sich dann so ein Abrechnungszeitraum, könnt die dir ganz genau sagen, was die Regeln sind und wie das funktioniert. Das matcht sehr häufig mit den Streams.

super spannend und ja echt echt toll das heißt wenn wir dann dort die Fachabteilung wieder mit einbeziehen dann kriegen wir die informationen die wir brauchen oft sind jetzt event ist auch ein bisschen Trend Thema geworden also wir haben irgendwie alle wollen Kafka benutzen wir haben events im ui und event zum backend

Ja.

Manche versuchen, die Events aus dem UI dann wiederzuverwerten im Backend. Wie siehst du das? Wie unterscheidet sich das, wenn ich jetzt solche UI-Frameworks habe, die auch so einen Single-Stream-Flow haben, wo quasi alles in eine Richtung nur geht, wie bei React und anderen? Was brauche ich da in meinem Kopf, das auseinanderzuhalten? Was ist deine Empfehlung?

Ja.

Also

genau, die Events, mit denen man im Frontend arbeitet, das sind typischerweise nicht die Events, die relevant sind für Event-Sourcing. Was wir da haben, ist im Button-Click und eher so technische Events. Das ist gar nicht so sehr, über was wir sprechen. Event-Sourcing und auch Event-Modeling interessieren uns im Prinzip die fachlichen Events. Wann ändert sich unser System? Wir nennen das State Transition.

Wann ändert sich wirklich was signifikant in unserem System? Das sind die Events, an denen wir wirklich interessiert sind. Und die Events im Frontend, das sind wirklich zwei unterschiedliche Sachen, die würde ich auch nicht unbedingt vermischen. Was man natürlich machen kann, ist, man kann die Events aus dem Backend im Frontend verwenden, beispielsweise die Views im Frontend aufzubauen. Also Frontend Event Sourcing ist möglich und mache ich auch gelegentlich mal.

Das funktioniert, ist aber völlig was anderes als jetzt zum Beispiel so ein Klick auf den Button, was auch in React ein Event ist. Das sollte man nicht vermischen.

Okay, spannend. Das heißt, du nimmst die Technologie, du auf dem Server benutzt, auch mit in das UI rein, dort vielleicht so ein UI-Caching auch zu haben. Aber das sind dann nicht diese Click-Events und irgendwelche State-Change-Events auf UI-Ebene.

Ja.

Ja, also was

typischerweise passiert ist, du klickst in React zum Beispiel auf den Button, der Button verursacht ein Call gegen das Backend und dann auf dem backendseitig wird im Prinzip ein neues Event erzeugt, damit wir speichern, hier hat sich was verändert und das wird dann wiederum ans Frontend gegeben, die Views zu aktualisieren. Da wird dann sowas wie Server Send Events zum Beispiel verwendet, einfach die Notification ans Frontend zu geben, gibt es verschiedene Möglichkeiten, aber die beiden Eventtypen würde ich strikt trennen.

Okay, danke. Danke für die Klarstellung dort. Jetzt haben wir schon einige Punkte gehört. hast das blaue Buch Domain Driven Design erwähnt. Du hast irgendwann mal von Commands gesprochen, was schon in die Richtung CQRS geht. Wir haben Event Sourcing jetzt gehabt. Und du sagst trotzdem, es ist einfach.

Im Prinzip ist es wirklich komplett einfach. Natürlich muss man ein bisschen umdenken. Das Schwierigste bei Event Sourcing, wenn man anfängt mit Event Sourcing, ist das Aller-aller Schwierigste. Unlearning. Also die Sachen zu vergessen, die wir jetzt 10 oder 20 Jahre lang gelernt haben. Weil es ist einfach, es ist was anderes. Es ist eine andere Art zu arbeiten. Und neu zu denken und Dinge eben nicht mehr so zu machen, das ist Schwierigste. Und daran scheitern viele. Ohne Hilfe.

Okay, das geht nicht nur bei der Softwareentwicklung so, dass es auch in anderen Bereichen so das Unlearning sehr, schwierig ist. Wir sind alle Gewohnheitstiere.

Ja.

Wann passt denn Event-Sourcing nicht zu mir? Also wie sind so die Entscheidungsmuster? das was jetzt, also bei dir hört es sich so an, du setzt es sehr viel ein und sehr oft ein. Für dich ist es quasi ein Tool im Baukasten, aber es ist mit Sicherheit kein goldener Hammer. Was sind für mich so die Entscheidungskriterien, wann ich es nicht machen sollte, wann ich es auf jeden Fall machen sollte?

Also mein Denken ist hier wirklich genau andersrum, wie das Denken von den meisten Entwicklern, glaube ich. Die meisten Entwickler sagen, ich mache eigentlich immer CRUD außer ich habe einen guten Grund und dann mache ich vielleicht Event Sourcing. Bei mir ist es genau andersrum. Mein Default ist immer Event Sourcing. Immer. Nur wenn ich einen ganz, ganz guten Grund habe, dann mache ich vielleicht CRUD Aber Event Sourcing ist wirklich der Default. Und das ist auch unabhängig von der Größe des Systems. es ist nicht so, dass ich sage, für ein einfaches System lohnt sich Event Sourcing nicht.

weil es zu komplex ist oder zu kompliziert. Ganz im Gegenteil. sehe ich überhaupt nicht so. Event-Sourcing ist der einfachere Weg. Und ich würde immer Event-Sourcing machen, außer ich habe wirklich einen extrem guten Grund, das nicht zu tun. Ein extrem guter Grund könnte zum Beispiel sein, entweder ich habe wirklich ein reines CRUD-System, wo ich eine Oberfläche habe, wo ich einfach nur Daten speichere, keinerlei Fachlichkeit oder irgendwas. Dann ist auch CRUD völlig ausreichend, dann brauche ich kein Event-Sourcing. Oder ich habe irgendwelche ganz, ganz strikten Anforderungen, was

des Speichern von personenbezogenen Daten angeht, die nicht in so einem Stream gespeichert werden dürfen. Aber selbst da gibt es eigentlich in Event-Sourcing saubere Möglichkeiten, das abzubilden. Das heißt, mein Standard ist eigentlich immer Event-Sourcing, und es gibt eigentlich nur ganz, ganz wenig. Ich habe in letzten zwei Jahren kein System gebaut, das kein Event-Sourcing hat.

Okay,

wenn du von solchen CRUD Systemen sprichst, einfach nur Daten reingeklimpert wird, sollte man sich vielleicht auch fragen, brauche ich dieses System wirklich oder nehme ich vielleicht Excel oder sowas einfach?

Ja, Excel, genau. Das sage ich

wirklich ganz häufig bei so einem System, warum schreibst du da Software? Nimm doch Excel. Excel kann das. Du brauchst kein System dafür. Ja, sehe ich genauso.

Ja genau.

Ja, spannend. glaube, ein weiterer Punkt, absolut für Event-Sourcing spricht, ist natürlich der KI-Hype. Viele Leute denken jetzt, sie sprinkeln ein bisschen KI-Magic über die Applikation und quasi alles das, was ich nicht modellieren kann, macht dann die KI automatisch für mich. Aber die KI braucht auch Daten und je besser die Daten sind, mehr Informationen auf die KI zugreifen kann, umso besser kann man die Power von LLMs zum Beispiel auch in der Applikation nutzen.

Das heißt, das spricht natürlich auch dafür, wenn wir nicht nur den State einmal speichern, sondern wie kommen wir dahin, über welchen Zeitraum, hilft uns dort auch weiter, bessere Datenqualität, Historien zu bekommen und ich bekomme ein Audit Trailing for Free. Super spannend.

Die Unternehmen, vor zehn Jahren angefangen haben, mit Event Sourcing zu arbeiten, die sitzen jetzt auf einer reinen Goldmine. Die haben nämlich die komplette Historie, können die LLMs mit ihren Daten füttern und haben im Prinzip vorbereitete LLMs, die exakt verstehen, wie das Business funktioniert, die exakt verstehen, wie alles funktioniert und die können jetzt mit diesen Daten arbeiten. Es ist eine reine Goldmine. Und ich kann das nur empfehlen. ist einfach zusammen mit AI ist Event Sourcing

ein absoluter Traum. Nicht nur im Betrieb, sondern auch, was das Modellieren angeht. LLMs verstehen Event Modeling hervorragend, weil wir so kleine Kontexte haben, mit denen wir arbeiten. Das heißt, AI zu verwenden, Code zu generieren aus einem Event Model ist super einfach. Jede AI versteht Event Modeling sofort. Du kannst dir Tests generieren, die verstehen das ganz, ganz wunderbar. Das passt hervorragend zusammen.

Das heißt, du machst jetzt weniger AI-Coding, du machst mehr AI-Modeling an der Stelle.

Ja, genau.

Aktuell hast du ja den Trend Vibe-Coding, wovon ich wirklich überhaupt kein Freund bin. Das kann nicht funktionieren. Du kriegst zwar schnell irgendwie was, was läuft, aber ist halt nicht wartbar. Was ich mache, ist Vibe-Modeling. Und Vibe-Modeling funktioniert ganz hervorragend. Ich habe eine AI-Integration in einem Miro-Toolkit und ich spreche im Prinzip mit der AI und daraus entsteht das Modell. Super einfach. Und dann kannst du daraus Code generieren. Ganz hervorragend.

Genau.

Sehr schön. Auch noch mal ein interessanter Tipp, mal tiefer reinzuschauen, für das Modeling AI zu benutzen. Echt genial. Also du hast mir schon wieder ein Stück mehr verkauft, jetzt auch noch mit Event Sourcing. Das Thema, viele haben aber jetzt nicht die grüne Wiese, wo sie starten. Die haben eventuell ein CRUD System. Wie können die dann anfangen, den

Vielen

Fußzeh ins kalte Wasser zu stecken. Was ist dort der beste Weg? Gibt es da so Übergangsszenarien? Wie macht man das? Wie komme ich jetzt von meiner Datenbank, die schön modelliert ist, die schon seit Jahren läuft und jetzt habe ich den Podcast gehört und denke, ja, das müssten wir doch mal machen. Wie komme ich von A nach B ohne Unfall?

Ich habe

heute mit einem Kunden gesprochen, die genau dieses Problem haben. Die haben eine riesengroße Landschaft, alles crud, keinerlei Event-Sourcing, gar nichts. Der wollte einfach nur wissen, ich finde das interessant, wo fange ich an, was kann ich tun? Was ich immer rate, ist, egal ob man jetzt auf der grünen Wiese anfängt oder nicht, ich würde immer das modellieren, was schon da ist. Nimm dir das System, was schon da ist und modellier es einfach. Das erste ist, du kriegst einen Überblick.

Was macht eigentlich unser System? In den meisten Unternehmen ist es so, die haben keine Ahnung, was die Systeme eigentlich tun. Die haben eine grobe Idee, aber so richtig im Detail, was passiert da eigentlich unter der Haube, das weiß keiner. Und wenn man dann anfängt und einfach mal alle Know-how-Träger im Unternehmen zusammenholt in so eine Event-Modeling-Session und vielleicht zwei Stunden in der Woche einfach modelliert und einfach mal guckt, was machen eigentlich unsere Systeme? Dann hat man vielleicht nach ein oder zwei Monaten so eine richtig schöne ...

Map, so eine Karte von unserer Systemlandschaft und man sieht genau, wo sind denn eigentlich die Zusammenhänge. Und so würde ich immer anfangen. Immer das modellieren, was schon da ist. Das ist ohne Risiko. Das ist relativ einfach und man hat einen riesen Benefit davon. Ich würde immer so anfangen.

Okay, vielleicht auch aus dem Microservice. Also wenn man in der Microservice-Umfeld ist oder in Transitionen da ist, dann operiert man natürlich nicht gleich am offenen Herzen. Dann nimmt man sich vielleicht erstmal Teile außenrum, wo man damit anfangen kann. Und du sagst, das Know-how ist das Wichtigste, dass alles offenlegen, also mit den Leuten sprechen, die im Business sind, diese große Map mal aufbauen. Und dann kann man sich ja für Slices die man dann Stück für Stück überführt.

Ja.

Ja.

Genau, kann dann einen kleinen Bereich, könnte man rausschneiden und könnte das vielleicht einfach mal testweise in ein neues System überführen. Genau, es gibt unendlich viele Möglichkeiten, aber das Wichtigste ist erstmal, das Know-how irgendwie zu strukturieren, so dass jeder damit arbeiten kann. Ist auch ein ganz hervorragendes Tool für Onboarding. Ich habe nie so schnelle Onboardings gesehen, ein System, modelliert ist. Man kann jemanden da hinsetzen, der versteht innerhalb von einer Stunde komplett, wie das System funktioniert. Wenn ich da zurückdenke, 2014,

Okay.

Ich habe in Projekten gearbeitet, da war es völlig normal, Monate oder sechs Monate Onboarding zu haben. Bis die Leute richtig produktiv waren, sechs Monate. Das ist komplett verrückt. Nimm ein Eventmodel, setzt jemanden hin, nach einem Tag kann der dir genau sagen, wie das System funktioniert.

Ja, Wahnsinn. Sechs Monate ist wirklich lang, aber nicht unrealistisch. je größer die Strukturen sind, je komplexer die Systeme. Das ich ja heute gelernt, verbaut wurden. Also, sind eigentlich einfach, Systeme. Ein guter, du hast eben gesagt, Know-how-Aufbau. Ein guter Weg, dieses Know-how auch aufzubauen, nicht nur das Organisationswissen, sondern auch, wie funktioniert Event-Sourcing und Event-Modeling ist mit Sicherheit dein Buch. Understanding Event-Sourcing.

Ja.

Ja.

Ja.

Du hast ein Buch geschrieben, was sehr erfolgreich ist. Es war, glaube ich, über mehrere Monate Best Seller. Und wie kam es denn dazu? Wann hast du dich entschieden? Jetzt schreibe ich mein Buch.

Erstaunlicherweise!

Ja.

Ich hatte überhaupt nicht den Plan, Buch zu schreiben. Überhaupt nicht. Ich hatte nicht das Verlangen, weil ich genau weiß, wie aufwendig so Buch ist. Ich habe auf LinkedIn gefragt. Also erstens, was ist passiert? Ich habe immer wieder die gleichen Fragen beantwortet. Immer wieder die gleichen Fragen in Workshops, in Discords. Immer wieder die gleichen Fragen. Und irgendwann war ich es einfach leid und habe mir gedacht, irgendwie musst du dieses Wissen mal strukturieren. Ich habe mir jetzt so viel Wissen angeeignet, irgendwie muss ich das mal strukturieren. Und dann habe ich einfach auf LinkedIn gefragt. Hey!

würde irgendjemand dieses Buch lesen. Und ich habe nicht damit gerechnet, dass ich irgendeine Art von Antwort bekomme. Und tatsächlich habe ich aber extrem viele Antworten bekommen. Also tatsächlich schien es so, als wäre da ein Interesse da. Was habe ich gemacht? Ich habe mir so ein Table of Content, so eine Inhaltsübersicht ausgedacht und habe die einfach gepostet. Würde irgendjemand dieses Buch lesen? Und super viele Leute waren daran interessiert. Und dann habe ich gedacht, okay, dann schreibe ich dieses Buch halt. Wie nennen wir es? Nennen wir es Understanding Event Sourcing. Und ...

Ich habe mir nur ein einziges Ziel gesetzt. Ich habe gesagt, ich schreibe 1000 Wörter am Tag. Mehr nicht. Ich schreibe 1000 Wörter am Tag an diesem Buch. Und das habe ich genau drei Monate gemacht und nach drei Monaten war das Buch fertig.

Wow, das ist natürlich auch eine Sache. Jeden Tag tausend Wörter rauszuhauen, über drei Monate lang da dran zu bleiben. Hattest du irgendwann mal so eine Blockade, wo du gesagt hast, ich pfeffer das Ding jetzt virtuell in die Ecke und...

Ne, tatsächlich

nicht. Ich glaube auch deswegen hat es so gut funktioniert. Ich habe einfach nur diese tausend Wörter geschrieben. Ich habe nicht darauf geachtet, ob das gute tausend Wörter sind, ob das gut strukturiert ist. Ich habe einfach nur tausend Wörter geschrieben und wenn ich am nächsten Tag die tausend Wörter vom Vortag gelöscht habe, war es auch in Ordnung. Ziel war immer nur quasi der Output, die tausend Wörter. Das war immer nur das Ziel. Und ich habe keinen einzigen Tag verpasst. Das hat ganz hervorragend funktioniert.

Ich hör da auch deine Slices wieder, so kleine Scheiben schneiden und die dann immer wieder... Sehr spannend. Das heißt, das Buch ist draußen, du hast aber auch eine Plattform dafür benutzt und du entwickelst das Buch jetzt weiter, also das heißt, das Ganze ist nicht nur agil erstanden, du postest das Inhaltsverzeichnis in die Community, lässt dir Feedback geben, habe ich da überhaupt Leser dafür?

Ja, ja, das Konzept funktioniert immer. Genau.

Ja.

Du baust jetzt auch immer noch weiter, es kommen neue Kapitel dazu, du veränderst Sachen. Wie kommt das denn bei deinen Lesern an und wie funktioniert das für Leute, die das nicht kennen?

Ja.

Also ich glaube, ist einer der Gründe, warum das Buch nach wie vor immer noch erfolgreich ist. das war ja fast drei Monate auf Platz eins bei Leanpub für eine Nische wie Event Sourcing. ist komplett verrückt. Also hat mich völlig überrascht und ist jetzt immer noch auf Platz zwölf oder sowas. wirklich sehr erfolgreich. Und ich glaube, der Grund ist, dass sich wirklich die Community da

mit einbeziehen. Also ich frage auch, ich frage regelmäßig auf LinkedIn, was soll das nächste Kapitel sein? Was interessiert euch? Das letzte Kapitel, was ich geschrieben habe, war Event Modeling in der Organisation. Also wie führst du Event Modeling ein? Weil einfach, weil so viele Leute einfach danach gefragt haben. Okay, lassen Sie einen Kapitel draus machen. Ich nenne das die Missing Chapters. Also das Buch selber ist fertig und was jetzt dazu kommt, sind im Prinzip Missing Chapters, die es einfach nicht ins echte Buch geschafft haben und die kommen jetzt einfach nach und nach dazu, aber immer auf Basis von Feedback.

aus der Community. Ich denke mir das nicht selber aus, das kommt im Prinzip, die Chapters kommen zu mir, die Fragen kommen und wenn ich merke, okay, da ist genug Bedarf da, dann schreibe ich was.

Sehr schön. Und der Prozess ist wesentlich dynamischer, weil wir nicht auf eine Auflage warten müssen, es nicht, hast du es auch gedruckt, gibt es das auch in Papier oder?

Es gibt es auch gedruckt, man kann es auf Amazon kaufen, aber nur, weil die Nachfrage so groß war. Die Missing Chapter gibt es nur im E-Book, weil das viel einfacher ist zu arbeiten.

Ja, hört sich richtig gut an. Also an alle eine Empfehlung. werden das natürlich in den Show Notes mit aufnehmen. jetzt ist die Frage, wann gibt es das nächste Buch? Oder gibt es überhaupt eins?

Ich hab

nicht geplant, neues Buch zu schreiben. Also, der Aufwand ist nicht zu unterschätzen. Also, tausend Wörter am Tag zu schreiben, das ist zwar nicht so aufwendig, aber dann insgesamt alles Korrektur lesen und so. ich hab nicht geplant, ein neues Buch zu schreiben. Also, ich arbeite viel mit der Community. Mein Ziel ist es, Event Modeling bekannt zu machen. Und das Buch ist ein wichtiger Teil davon. Es gibt den Kurs zum Buch. Das ist auch ein wichtiger Teil davon.

Das Ganze ist ein Big Picture. Das Ziel ist insgesamt einfach Event Modeling und diese Art zu arbeiten, speziell in Deutschland bekannt zu machen, auch über Deutschland hinaus. Aber speziell in Deutschland ist mein Ziel und daran arbeite ich. Und das ist so das Ziel für die nächsten ein, zwei Jahre.

Okay, also das heißt, die Mission ist erst mal dort erfüllt, alles ist runtergeschrieben und wenn nicht gibt es ein zusätzliches Missing Chapter, aber keine Tendenzen, neue Bücher. Man sieht sich, du bist sehr viel aktiv auf LinkedIn, wenn du jetzt vielleicht eine Empfehlung für andere Leute hast, die starten, wie wichtig ist denn das, ein Buch zu schreiben, immer wieder zu posten, eine Community aufzubauen, wie hast du das gemacht?

Also für mich ist das wirklich, das ist mein einziger Akquisekanal. Also über LinkedIn bekomme ich neue Kunden, komme ich mit Kunden ins Gespräch. Das ist mein kompletter Akquisekanal. Das ist der Grund, warum ich viel poste und natürlich, weil ich merke, das hilft wirklich. Also da ist ein Interesse da, die Leute interessieren sich dafür. Im Prinzip, was ich immer empfehlen würde, ist, wenn jemand anfängt und versucht, sich was aufzubauen, das Wichtigste ist, sich ein Thema herauszusuchen und in diesem einen Thema Weltklasse zu sein.

nicht der Beste zu sein, sondern wirklich Weltklasse. Ich hab das schon mehrfach gemacht. hab das 2013 mit Git gemacht, als ich angefangen hab, Git-Schulungen zu geben und mit Git zu arbeiten. Ich war einer der bekanntesten Entwickler in Deutschland, die mit Git gearbeitet haben. Warum? Weil ich nichts anderes gemacht hab. Git war mein großes Thema. Und jetzt ist mein großes Thema eben Event Modeling und Event Sourcing. Das heißt, ich hab immer ein Thema und dieses eine Thema treib ich weiter, soweit ich kann. Und ich kann das nur empfehlen.

Es ist eigentlich egal, welches Thema man sich da raussucht. Wenn man Weltklasse in diesem Thema ist, dann findet sich immer ein Markt dafür.

Das heißt eine Nische besetzen und die richtig bearbeiten sozusagen. Aber es ist natürlich auch aufwendig, wieder Inhalte zu finden. Wie sieht dein Kreativprozess aus? hast du da so einen Marketingplan, wo du sagst, sind die Themen, kommt das einfach jetzt morgens unter der Dusche und dann schreibst du was? Wie organisiert man sich dort?

Nee, nee.

Das ist alles, mein kompletter Content ist komplett strukturiert. Also, ich habe einen ganz kleinen Plan, wann schreibe ich über was. Die Themen sind für die nächsten Wochen schon geplant, mehr oder weniger. Also, ist nichts Spontanes. Das ist wirklich alles geplant und strukturiert. Ich habe einen ganz kleinen Contentplan. Ich kann dir genau sagen, welches Thema kommt nächsten Mittwoch, welcher Post kommt nächsten Mittwoch und über was spreche ich da.

Ja, perfekt. heißt, Social Media ist auch ein Business. Das muss strukturiert werden. Da muss ein Plan dahinter. Das ist nicht einfach mal aus dem Gefühl was raus posten. Das geht natürlich auch und macht es vielleicht hier und da mal persönlicher. Aber wichtig ist, dass eine Struktur dahinter ist. Ja, sehr cool.

Ja,

genau, es ist auch so, ich gucke mir jeden Monat meine Posts an, ich gucke mir an, welche Posts haben funktioniert, was sind die Themen, die funktioniert haben und das ist dann auch der Fokus für den nächsten Monat. Also das ist wirklich alles mit Struktur.

Ja super. Dann teil doch vielleicht kurz, wo bist du in den sozialen Medien unterwegs? Du hast einen LinkedIn-Kanal, ein Profil, YouTube vielleicht auch. Teil mal.

Ja, genau.

Der Hauptkanal ist definitiv LinkedIn. Also, wer mit mir in Kontakt treten möchte, ist definitiv LinkedIn, weil da bin ich am meisten unterwegs. Da mache ich auch am meisten. Es gibt einen YouTube-Kanal, der ist aber, also da ist kein Fokus drauf. Ich poste hin und wieder mal ein Video, wenn ich was Interessantes habe. Aber der primäre Kanal ist wirklich LinkedIn. Und wer möchte, der Newsletter. Ich habe einen Newsletter, den ich einmal die Woche heraus schicke. Einfach auch über Event Modeling und Event Sourcing. Da sind manchmal so

Geschichten aus der Praxis mit dabei, Dinge, interessant sind. Genau, das sind so die zwei Sachen, ich.

Super. Dann jetzt kurz bevor wir zum Ende kommen. LinkedIn ist ein Hauptmedium, mit dem du unterwegs bist. Du hast einen Kurs, den du gerade veröffentlicht hast oder noch dabei bist. Vielleicht kannst du da noch mal drauf hinweisen. Es gibt das Buch und es wird in München eine Event Modeling Konferenz geben. Vielleicht für Leute, die das hier spannend finden, ist es auch ein guter Einstieg, da in die Szene einzutauchen. Wie sieht die Konferenz aus? Was passiert da?

Ja.

Ja.

Genau, also der Kurs ist im Prinzip eine Erweiterung vom Buch. Also der Kurs ist ganz genau wie das Buch. Nur, dass man mir im Prinzip zuschauen kann, wie modelliere ich jeden einzelnen Teil. Das heißt, wenn es einen Kapitel im Buch gibt, dann gibt es eine Lektion im Kurs dazu. Das heißt, man kann ständig zwischen dem Buch und dem Kurs hin und her springen und hat im Prinzip dann so eine interaktive Möglichkeit, die Sachen einfach zu lernen und auch auszuprobieren. Das ist im Prinzip die Idee dahinter.

Und die Event Modeling Konferenz, da freue ich mich persönlich riesig drauf. Die wird Anfang Oktober in München sein. Adam Dymitruk wird aus Kanada anreisen, das heißt, er wird auch vor Ort sein. Zwei Tage wird es sein. Das wird mit Sicherheit super, super spannend.

Und was erwartet uns dort? Vorträge oder wirklich auch Modeling Sessions? Wie läuft das ab?

Höchstwahrscheinlich wird es eine Art von Unconference sein. Es wird definitiv Workshops geben. wird vielleicht auch ein, zwei Vorträge geben. Aber größtenteils wird es so eine Art Unconference sein. Das heißt, wir werden am Anfang so einen Marktplatz eröffnen, wo man einfach Dot-Voting machen kann auf bestimmte Themen. Und dann machen wir diese Themen einfach. Irgendwie noch nicht ganz klar. Irgendwie sowas wird es sein.

Ja.

Hört sich sehr spannend an. Martin, vielen Dank, dass du da warst bei Beyond Code. Wir haben einiges versprochen. finde, definitiv für mich hast du das Thema Event Modeling nochmal ganz neu auf den Bildschirm gebracht. Ich werde da nochmal tiefer eintauchen. Ich werde auch nochmal das Event Sourcing Thema mir genauer anschauen. Es war ein tolles Gespräch mit dir. Vielen Dank.

Ansteckend.

Vielen Dank für die

Einladung. Hat sehr viel Spaß gemacht.

Und alle anderen, bitte teilt diesen Podcast gerne mit eurer Community. Liked, subscribete und abonniert ihn, damit die Community von Beyond Code größer wird. dann bis zum nächsten Mal. Ciao.

Ciao!