Der nachfolgende Text wurden mit KI erstellt und kann Fehler enthalten. Fehler gefunden? Bei GitHub editieren
So, dann herzlich willkommen zu einer weiteren Episode von Software-Architektur im Stream.
Heute geht es um das Thema mit den Independent Service Heuristics.
Warum nun ausgerechnet dieses Thema?
Das hängt einmal damit zusammen, dass wir ja vor kurzem eine Episode gemacht hatten, unter anderem mit dem Eduardo von der HMS Architecture.
Da hat er kurz über Independent Service Heuristics gesprochen und ich dachte, dass es deswegen vielleicht ein spannendes Thema ist.
Außerdem dieses Thema von Modularisierung von Systemen beispielsweise in verschiedene Services ist ja ein Thema, was wir im Stream schon häufig diskutiert haben.
Das bedeutet, es ist vielleicht ganz nett, nochmal auf so etwas wie Independent Service Heuristics einzugehen.
Das führt dann auch gleich zu der Frage, warum brauchen wir da noch irgendetwas?
Es gibt ja vorne Kontexte und Module und ganz viele Ansätze, wie ich etwas unterteilen kann.
Das Ganze kommt aus dem Team Topologies Universum.
Ich verlinke nachher auch nochmal die Homepage, die es bei Team Topologies zu den Independent Service Heuristics gibt.
Da gibt es auch eine Präsentation von dem Matthew Skelton und dem Nick Tune zu dem Thema Independent Service Heuristics und welche Erfahrungen die da mitgemacht haben.
Die sagen jetzt unter anderem, dass eben Domain-Domain Design über solche Sachen wie Embodent Context oder Ubiquitous Language spricht.
Aber das wird dann irgendwann sehr kompliziert.
Es gibt sehr viele Fachbegriffe.
Es gibt eine komplett eigene Welt.
Das ist insofern insbesondere problematisch, als dass es eben für Menschen, die gerade einen Business-Hintergrund haben, tatsächlich eine fremde Welt ist.
Das führt eben zu der Frage, können wir das nicht noch einfacher und besser haben?
Was sie sagen, ist, dass Independent Service Heuristics ein Zwischenschritt ist, der dabei helfen kann, die Prinzipien von Domain-Domain Design einzuführen, ohne diese abstrakten Begriffe zu verwenden, die oft eine Hürde darstellen.
Es soll dabei helfen, Value Streams oder Domain-Grenzen zu finden, was ja ein software-architektonisches Thema ist.
Es sollen Daumenregeln und Hinweise sein.
Da es darum geht, Domain-Grenzen zu finden, bedeutet das, dass wir auf dieser sehr grobgranularen Ebene unterwegs sind.
Auf dieser Ebene, auf der man sonst vielleicht über baune Kontexte sprechen würde, also Dinge, die tatsächlich sehr unterschiedlich sind.
Die grobgranularen Module sind, die ich in der Software-Architektur vielleicht habe.
Was ist das Ziel?
Einmal ist das Ziel, Grenzen zu finden, die für den Fluss von Änderungen möglichst einfach sind.
Das ist etwas, was Domain-Domain Design nicht wirklich löst, weil zu dem Zeitpunkt, als man sich Domain-Domain Design überlegt hat, die Idee des Flusses von Änderungen durch die Software-Entwicklung noch nicht so das große Thema war.
Ich muss dazu gestehen, ich bin mir nicht sicher, ob ich das so unterschreiben würde.
Ich würde sagen, eine gute Modularisierung, die ich vielleicht mit Domain-Domain Design erzeuge, sorgt dafür, dass ich Änderungen möglichst leicht umsetzen kann.
Aber sei es drum.
Dann geht es insbesondere um diese businessfreundliche Sprache, also dass Menschen, die nicht aus dem Software-Architektur-Hintergrund kommen, die nicht Informatik studiert haben oder in der Software-Entwicklung arbeiten, an diesen Diskussionen sinnvoll teilnehmen können und was dazu beitragen können.
Dann geht es um Gruppendiskussionen und die Möglichkeit, dort zu lernen und zu unterstützen.
Ich möchte halt schnell Ergebnisse erzielen.
Eine Aufteilung eines Systems im mehreren Kontexten ist aufwendig und schwierig.
Die grundlegende Idee von diesen Independent Service Heuristics ist, die Frage zu stellen, ob das ein eigener SaaS-Service werden könnte.
Also ein Software-as-a-Service-Service.
Also etwas, was ich in der Cloud als eigenes Produkt mit einer eigenen Firma tatsächlich anbiete.
Vorteil ist eben, dass es ein Konzept ist, das relativ klar ist.
Insofern, dass wir ja alle Software-as-a-Service irgendwo benutzen.
Das bedeutet dann eben, dass viele Menschen an dieser Diskussion teilnehmen können, dort mindestens intuitiv eine Vorstellung haben, worum es geht.
Eben auch Business-Expertinnen.
Was ich mir selber noch dazu aufgeschrieben habe, das ist nichts, was die jetzt selber gesagt haben.
Aber ich finde es ganz hilfreich, wenn man einem Modul so eine Zuständigkeit gibt.
Bei diesem CRC-Karten-Class Responsibility Collaboration, wo ich für Klassen, also auf einer ganz feinen granularen Ebene, ein System unterteile.
Da habe ich eben auch eine Responsibility und dort zu sagen, ich bin halt verantwortlich für dieses Ding, diese Aufgabe.
Bestellungen entgegennehmen, Kunden verwalten.
Das ist eben etwas, was hilfreich ist, um ein Modul zu verstehen.
Und das kriegt man hier automatisch raus, weil ich herausfinde, was dieser Service liefern soll.
Und das ist eben eine Zuständigkeit in diesem Sinne, so wie eine Responsibility bei einer CRC-Karte für eine Klasse.
Und das ist vielleicht schon hilfreich.
Ein weiteres Ziel, eine weitere Idee ist eben, dort schnell zu Ergebnissen zu kommen.
Die erste Frage ist natürlich, wie komme ich zu irgendwelchen Kandidaten?
In dem Talk haben die beiden erzählt, dass sie so 20 bis 40 Kandidaten typischerweise identifizieren und da unterschiedliche Möglichkeiten sehen, die zu identifizieren.
Einmal gibt es diese Fracture Planes von den Team Topologies.
Das ist das, woran ich in Team Topologies die Grenzen von Teams definiere.
Und da gibt es eben verschiedene Fracture Planes.
Eine Fracture Plane ist zum Beispiel, bauende Kontexte, also fachliche Zuständigkeit für irgendwelche Fachlichkeiten.
Aber es gibt zum Beispiel auch so etwas wie Compliance, dass Sachen, die aus Compliance-Gründen anders sind, dass ich die irgendwie aufteile und damit Zuständigkeiten habe für Teams.
Und da ist eine Möglichkeit, Kandidaten zu identifizieren.
Wir haben ja eine Folge gemacht zum Thema Team Topologies.
Da ist das mit den Fracture Planes auch ein Thema.
Da kann man sich das sozusagen nochmal angucken.
Dann hat so etwas wie User Needs, also dass ich als Benutzer oder irgendetwas erfüllt haben möchte.
Oder es gibt noch diese Idee von den Micro Enterprises.
Das ist ein Modell von einer Firma namens Haier, die im Prinzip das sehr radikal gemacht hat und gesagt hat, wir teilen unser Unternehmen auf in viele kleine Unternehmen, viele kleine GmbHs oder was auch immer die Rechtsform ist.
Und die sind jeweils zuständig für einen Teilbereich.
Die haben eigene Kunden, die haben eine klare Kundenorientierung und das sind eben dann so Micro Enterprises, werden die halt genannt.
Ich glaube, bei Haier geht es eben darum, dadurch ein hohes Maß an Selbstorganisationen hinzubekommen und eben kompetitiv am Markt zu sein.
Das wäre also auch etwas, was man als Intuition benutzen kann.
Was man dann machen kann, ist eine Matrix machen, wo man eben sagt, ich habe hier verschiedene Kandidaten.
Ich habe mir jetzt ausgesucht, einmal als ein Kandidat, um das mal ein bisschen mit Leben zu erfüllen.
Das ist die Buchsuche.
Es gibt so ein Beispiel, was ich im Trainingslimmer benutze.
Das ist eine Bibliothek und da gibt es die Buchsuche.
Die Frage ist, wie stellt sich diese Buchsuche einer Bibliothek bezüglich der Independent Service Heuristic dar?
Das andere Beispiel, was wir vielleicht nochmal diskutieren können, ist, ich habe diese Episode gemacht, wo ich bei einem Fahrradladen das System unterteilt habe für Reparaturen.
Und da gibt es dann eben ein Ding, das ich dort mir überlegt habe, wo ich die Fahrradreparatur erfasse.
Wo also jetzt ein Mitarbeiter, eine Mitarbeiterin irgendwie dasteht und sagt, okay, ich habe jetzt an dem Fahrrad folgendes gemacht.
Ich habe die Pedale gewechselt und neue Pedale herangepackt.
Okay, das heißt, ich erfasse jetzt, ich habe eine Pedale für 20 Euro herangebaut.
Ich habe daran irgendwie 15 Minuten gewerkelt und darüber kriege ich dann eine Erfassung.
Ich kann jetzt solche Dinge, ich kann eine große Matrix machen.
Ich kann nämlich sagen, ich habe diese verschiedenen Servicekandidaten und dann habe ich die verschiedenen Kriterien, die ich gleich diskutieren werde.
Und die Kriterien habe ich halt als Spalten.
Das sind zehn Kriterien insgesamt und dann kann ich so eine Heatmap machen.
Das heißt, ich kann da so Post-its hinhängen.
Wenn ich sage, das ist ein grünes Post-it, dann ist irgendwie dieses Kriterium erfüllt.
Wenn ich sage, es ist ein gelbes Post-it, dann ist dieses Kriterium eben teilweise erfüllt.
Wenn ich sage, das ist ein rotes Post-it, dann würde ich eben sagen, dass dieses Kriterium nicht wirklich erfüllt ist.
Dann kann ich halt visuell relativ schnell feststellen, dass bestimmte Dinge relativ klar gute Services in diesem Sinne sind oder gute Aufteilung und andere Dinge dann halt irgendwie weniger gut.
Ich muss gestehen, als Warnung, diese beiden Beispiele kommen halt aus Software-Architektur Aufgaben.
Dadurch ignorieren wir sozusagen schon einen Vorteil, dass das halt auch eine Business-Perspektive sein könnte.
Aber nicht irgendwas können wir ja mal dagegen halten.
So jetzt ist also die Frage in dieser Heatmap, was wären dort die Spalten?
Erste Spalte ist der Sinn.
Also ist es sinnvoll, dieses Ding als Service anzubieten?
Also ist es unabhängig genug?
Sind die halt die detaillierten Fragen?
Würden Konsumenten es verstehen oder wertschätzen?
Würde es die Ausführung vereinfachen?
Und das Erste, was mir dabei aufgefallen ist, ist, dass sie halt von dem Ding reden.
Und das finde ich eigentlich in gewisser Weise ganz lustig, also normalerweise gibt man sich ja irgendwie Mühe und versucht ja wieder daraus einen Service zu machen oder einen Komponent oder so.
Aber eigentlich finde ich den Begriff, das Ding, ganz schön, weil eigentlich ist ein Komponent oder ein Service häufig auch nur irgendein Ding.
Und wenn man fragt, was ist das denn genau?
Ist das irgendwie definiert?
Dann kommt meistens raus, dass es nicht so wahnsinnig klar ist.
Und deswegen finde ich es ganz gut, sich einzugestehen, dass es eben ein Ding ist, ohne das weiter zu definieren.
Und vielleicht ist das auch etwas, was eine Barriere halt erniedrigt.
Also ist man eben nicht von einer Komponente.
So, wie dem auch sei, wenn ich jetzt also die Buchsuche beispielsweise nehme, ich würde in einer Bibliothek, ist die unabhängig?
Ja, also Bücher suchen, das kann ich halt tatsächlich als einen Service anbieten.
Es gibt ja sowas wie zum Beispiel die IMDB für Filme.
Sowas könnte ich für Bücher sicher auch anbieten.
Also warum sollte das nicht was Eigenes sein?
Ist das etwas, was Konsumenten verstehen oder wertschätzen würden?
Kann ich mir schon vorstellen.
Es ist halt ein bisschen die Frage, was noch der zusätzliche Wert wäre, jenseits von, es gibt dieses Buch, gutreads.com geht ja auch ein bisschen in diese Richtung, da gibt es eine Bewertung dafür.
Das ist übrigens auch ein Indikator.
Nicht gibt es schon ein Software Service dafür.
Würde ich die Ausführung vereinfachen?
Wahrscheinlich schon.
Also da ist das halt sozusagen einigermaßen sauber.
Das ist also der Sinn.
Und als zweites, die Marke.
Könnte man sich vorstellen, dieses Ding als eigenen öffentlichen Cloud Service anzubieten?
Wäre es ein sinnvolles Business oder Mikrobusiness oder Service?
Goodreads oder sowas IMDB mäßiges?
Könnte schon sein.
Wäre es ein überzeugendes Angebot?
Würde ich jetzt behaupten, wahrscheinlich schon.
Wäre es als Marketing Kampagne überzeugend?
Wir können Bücher suchen?
Weiß ich nicht genau.
Müsste man sich halt irgendwie nochmal darüber Gedanken machen.
Das, by the way, ist auch eine von den Sachen, die ich halt sozusagen am Ende auch nochmal deutlich machen wollen würde.
Ich gehe das jetzt hier relativ schnell durch.
Wir haben insgesamt eine Stunde eigentlich und ich bin alleine.
Das heißt, ich kann mit mir diskutieren, aber nur sehr begrenzt.
Im wirklichen Leben wäre es halt, glaube ich, deutlich länger und umfangreicher, sowas auf die Reihe zu bekommen.
Es gäbe da halt irgendwie auch größere Diskussionen.
Das heißt dass wir hier jetzt eine Stunde darüber reden, ist deutlich nicht das, was in der Realität passieren würde.
Diese Frage mit der Marketing Kampagne, die müsste man dann vielleicht nochmal deutlich erklären.
Könnte das Ding ein tragfähiger Cloud Service bezüglich Umsatz und Kunden sein?
Bezahlt jemand für eine Buchsuche?
Bin ich mir nicht sicher.
BenutzerInnen wahrscheinlich nicht.
Vielleicht mit irgendwelchen Werbungen.
Da stehen jetzt tatsächlich die Fragen.
Wäre es ein tragfähiger Service als bezahltes Angebot?
Kann ich mir nicht vorstellen.
Würde es wiederkehrenden Umsatz mit Abos erbringen?
Kann ich mir eigentlich auch nicht vorstellen.
Gibt es eine klar definiertes Kundenbasis oder ein klar definiertes Kundensegment?
Menschen, die an Büchern interessiert sind, ist so medium klar.
Also auch hier, das wäre jetzt etwas, was man vielleicht nochmal weiter definieren müsste.
Kosten.
Könnte die Organisation im Moment die Kosten und das Investment in diesem Service unabhängig von anderen Dingen tracken?
Das sind also solche Fragen, wie sind die vollständigen Serverkosten transparent oder können sie ermittelt werden, inklusive Infrastruktur, Datenspeicher, Datenübertragung, Lizenzen?
Ist das Ding ausreichend separat und abgekoppelt von anderen Dingen in Organisationen?
Verbucht die Organisation die Kosten separat?
Das kann ich jetzt nur beantworten.
Das ist ein kollaborativer Prozess.
Ich habe verschiedene Ansätze.
Das kann ich also nur beantworten, wenn ich eine Idee habe aus dem Finance-Bereich und vielleicht aus dem Betriebsbereich, die mir das verraten können.
Wenn ich sage, es gibt eine Buchsuche in der Bücherei.
Die Frage nach diesen Kosten ist nicht so abstrakt beantwortbar.
Da hängt es eben tatsächlich davon ab, wie die Menschen mit diesen Kosten umgehen in diesem spezifischen Kontext.
Das bedeutet, dass das in gewisser Weise eine offene Frage ist.
Diese Frage ist deswegen relevant.
Wo wollen wir hin?
Wir wollen ja etwas haben, was irgendjemand unabhängig von anderen weiterentwickeln, umsetzen und so weiter kann.
Dazu ist es natürlich super, wenn ich sage, ich kann auch den Betriebsaspekt, wie das Ding läuft, unter Kontrolle, weil ich mich dann nicht mit dem zentralen Betrieb herumschlagen muss.
Fünfter Aspekt wäre Daten.
Ist es möglich, die Eingabedaten aus anderen Quellen zu definieren, die das Ding benötigt?
Ich brauche Informationen über Bücher, Titel, Autor, Schlagwörter, solche Geschichten.
Ist dieses Ding relativ unabhängig von anderen Datenquellen?
Vermutlich ja.
Wenn ich anzeigen will, welches Buch ausleihbar ist in meiner Bücherei, müsste ich da noch eine zusätzliche Quelle reinpacken.
Sind die Datenquellen intern unter unserer Kontrolle, nicht extern?
Vielleicht, also wenn ich die Informationen über das Buch manuell eingebe, dann sicher.
Sonst würde ich es halt irgendwie einkaufen.
Also es gibt wahrscheinlich Anbieter, die mir halt Informationen über Bücher zur Verfügung stehen können auf elektronischem Wege.
Sind die Eingaberaten sauber, also nicht unübersichtlich?
Vermutlich schon.
Informationen über ein Buch sind halt Autortitel und so weiter.
Das ist etwas, was man wahrscheinlich im Prinzip hinschreiben könnte.
Werden die Daten als einen Self-Service angeboten?
Kann das Team die Daten als Service konsumieren?
Wahrscheinlich gibt es irgendwo so einen zentralen Register über Bücher.
Das könnte dann also funktionieren.
Personas.
Kann das Ding eine kleine oder wohldefinierte Menge von BenutzerInnen oder KundInnen haben?
Also irgendwelche Personas.
Da sind wir wieder bei dem Thema, dass es nicht so ganz klar ist, was für Menschen das sind.
Entspricht das Ding, also sprich, an Büchern interessiert, ist halt sehr grob.
Entspricht das Ding bestimmten Benutzeranforderungen?
Also ja, ich kann Qualitätsziele definieren, wie schnell das irgendwie reagieren soll.
Soll irgendwie angenehm sein, da schnell Bücher zu finden.
Ich würde mal unterstellen, dass jemand, der Bücher lesen will, um sich zu entspannen, was anderes macht, als wenn jemand Publikationen sucht zu irgendwelchen wissenschaftlichen Themen.
Kennen wir diese Benutzertypen und ihre Bedürfnisse oder können wir sie einfach nennen?
Vielleicht nicht.
Das wäre vielleicht so ein bisschen gelb.
Teams.
Kann ein Team oder einige Teams einen auf diesen Dingen basierenden Service effektiv bauen und betreiben?
Was also zu der Frage führt, wäre der Cognitive Load Breite der Themen so, dass ein Team sich fokussieren kann und erfolgreich ist?
Ja, wirkt auf mich einfach machbar bei so einer Büchersuche.
Wären signifikante Abstraktionen für die Plattformen überflüssig?
Das ist wahrscheinlich eine Webanwendung, die ich irgendwie laufen lasse.
Auf der Standardumgebung würde ich auch sagen, das ist irgendwie fein.
Abhängigkeiten.
Wäre das Team dazu in der Lage, meistens relativ unabhängig von anderen Teams an seinen Zielen zu arbeiten?
Hier kommt diese Geschichte mit dem Fluss und der starken Unabhängigkeit.
Ich würde sagen, neue andere Möglichkeiten, nach Büchern zu suchen, ergeben sich relativ natürlich.
Dadurch kriege ich, oder unabhängig von anderen Anforderungen, von daher würde ich erwarten, dass das so ist.
Ist dieses Ding unabhängig von anderen Dingen?
Ja, vermutlich.
Wahrscheinlich wird es eine Aktion geben, wo ich jetzt sage, ich kann das Buch ausleihen.
Aber das ist in der Büchersuche, nicht bei Goodreads oder so, gibt es ja auch Werbung und Links.
Das ist also, glaube ich, konzeptionell dasselbe.
Kann das Team Abhängigkeiten von einer Plattform asynchron bekommen, ohne dabei blockiert zu werden?
Würde ich behaupten, ja.
Wenn ich jetzt sage, ich brauche eine andere Art und Weise, Webanwendungen zu deployen, oder muss da etwas verbessern, dann blockiert mich das nicht.
Das macht nur meine Arbeit vielleicht einfacher.
Wirkung, also englisch Impact oder Wert, würde der Umfang dieses Dings einem Team eine wirkungsvolle und spannende Herausforderung bieten?
Tatsächlich haben wir auch die Frage, ob das sozusagen langfristig motivierend wirkt.
Bin ich mir nicht sicher.
Büchersuche ist vielleicht ein bisschen einfach.
Da steht irgendwie, ist der Scope groß genug, um eine Wirkung zu haben?
Wäre der Umfang interessant für talentierte Menschen?
Auf mich wirkt es von draußen einfach.
Vielleicht unterschätze ich das.
Müsste man mal reingucken.
Das wäre jetzt auch etwas, wo vielleicht ein Dialog gut wäre mit jemandem, der fachlich tiefer drin ist.
Gibt es genügend Wert für Kunden und die Organisation, sodass der Wert klar erkennbar ist?
Wenn ich in der Bibliothek nicht nach Büchern suchen kann, ist das relativ sinnlos.
Von daher ist der Wert, glaube ich, sehr wichtig.
Produktentscheidung.
Könnte das Team, was an dem Ding arbeitet, seine eigene Produktroadmap und Richtung in der Entwicklung haben?
Bietet das Ding einen eigenen Wert in einem wohldefinierten Bereich des Geschäfts?
Kann das Team seine eigene Roadmap definieren, basierend darauf, was das Team am besten für das Produkt und seine Kunden hält?
Ist das Team also nicht durch die Requirements und Anforderungen anderer Teams getrieben?
Würde ich sehr stark unterstellen.
Ich könnte jetzt anfangen und sagen, wie leicht und schnell ihr Bücher findet.
Wie viele Bücher findet ihr?
Wie gut kommt euch das alles vor?
Die entsprechenden Entscheidungen und Verbesserungen an dem Produkt kann ich, glaube ich, unabhängig von allen anderen durchexerzieren.
Was das jetzt bedeutet ist, wenn ich mir die Buchsuche angucke.
Sinn, Marke, das funktioniert.
Umsatz, Kunden, ist die Frage, ob man damit Geld verdienen kann.
Kosten wissen wir nicht, müssen wir genauer reingucken.
Daten, ja, das kriegen wir irgendwie hin, das unabhängig zu bekommen.
Personas, nicht so klar definiert.
Team, also dass ein Team das irgendwie effektiv bauen und betreiben kann, ja, wahrscheinlich schon.
Abhängigkeiten eher weniger.
Wirkung, Impact oder Wert für die Bücherei schon relativ wichtig.
Eigene Roadmap, das wäre irgendwie auch denkbar.
Jetzt können wir das andere mal nehmen.
Das ist also das Teil des Systems für eine Fahrradreparatur, wo jetzt also die Mitarbeiterin, die das Fahrrad repariert, die Zeit erfasst.
Ist es sinnvoll, das Ding als Service anzubieten?
Tatsächlich würde ich argumentieren, vermutlich schon, weil es gibt sowas wie eine Zeiterfassung für Selbstständige.
Und die gibt es eben tatsächlich auch als Service, so jedenfalls meine Wahrnehmung.
Ich könnte also sowas auch als Service anbieten.
Da gibt es noch die Besonderheit, dass ich ja irgendwie sagen muss, ich habe eine Pedale angebaut, also ich muss neben Zeit auch Materialien erfassen.
Und ich kann mir vorstellen, dass man da eine interessante Diskussion bekommt, die eben auf die Frage hinausläuft, okay, also wie generisch ist das?
Also ist das vielleicht tatsächlich nur eine allgemeine Arbeitszeiterfassung oder ist das halt irgendwie etwas, was jetzt ganz spezifisch ist für Fahrradreparatur?
Ich halte es für unwahrscheinlich.
Also wenn jetzt jemand hierher kommen würde und etwas reparieren würde hier im Haus, würde ja dasselbe passieren.
Also nicht, da würde kommen, würde Arbeitszeit in Richtung Stellung Materialien.
Und vielleicht ist das eine interessante Diskussion auch darüber, ob man es abstrahieren kann.
Marke könnte man sich vorstellen, dieses Ding als eigenen öffentlichen Cloud-Service anzubieten?
Vielleicht, vielleicht nicht mit dem Umfang.
Umsatzkunden, könnte das Ding ein tragfähiger Cloud-Service bezüglich Umsatz und Kunden werden?
Ja, vermutlich schon.
Kosten, da ist wieder die Frage, wie betreibe ich das Ding?
Und ist das eben tatsächlich etwas, was stark unabhängig ist?
Daten sind im Wesentlichen, die ich eingebe plus die Produkte, schon irgendwie auch einigermaßen unabhängig zu sein.
Personas, die kann ich hier klar definieren.
Das sind die Menschen, die die Arbeitszeit erfassen wollen.
Vielleicht auch noch die Leute, die anschließend irgendwelche Rechnungen schreiben wollen.
Das wären auch Menschen, die damit etwas zu tun haben.
Team, das kann ein Team sicher bauen und betreiben.
Ich wüsste nicht, warum nicht.
Abhängigkeiten, letztendlich ist das ein Helfershelfer dafür, um eine Rechnung zu schreiben.
Aber wahrscheinlich haben die Leute, die die Daten benötigen, nämlich für die Rechnung, werden mir jetzt nicht vorgeben, oder das ist sozusagen eine nicht so dramatische Abhängigkeit.
Ich muss halt nur die Daten exponieren.
Wirkung, Impact, also ist das für Team eine spannende Herausforderung?
Tendenziell vielleicht eher nicht.
Produktentscheidung, kann ich da eine eigene Roadmap machen?
Würde ich schon erwarten.
Ich kann das jetzt irgendwie für die Benutzer attraktiver machen.
Das wäre jetzt etwas, was ich in die Hitmaps aufnehmen kann.
Wo ich jetzt mit grün, gelb und roten Postsitze bewerte und eine Idee davon generiere, ob das unabhängige Services sein sollen oder eben auch nicht.
Darüber kann ich so etwas leicht validieren.
Ich glaube, man hat bei der Diskussion schon gemerkt, wenn jetzt neben mir ein Product Manager sitzen würde oder jemand, der tatsächlich im Betrieb ist, oder jemand, der es benutzt, irgendwelche Domänexpertinnen, die hätten natürlich auch sehr spannenden Input.
Eigentlich ist viel von dem, was ich hier erzählt habe, sind irgendwelche Thesen über die Fachlichkeit, die man sinnvollerweise mit so einem Domänexperten nochmal durchsprechen sollte.
Auf der Homepage selber stehen jetzt noch ein paar weitere Dinge, die man damit anfangen kann oder weitere Ideen, um die Unabhängigkeit von Services festzustellen.
Da ist zum Beispiel das Vokabular.
Ist das Vokabular dasselbe in verschiedenen Teilen des Systems oder unterschiedlichen Business Domänen?
Falls nicht, wenn also beispielsweise dasselbe Wort unterschiedliche Bedeutungen in unterschiedlichen Bereichen hat, dann kann es zwei verschiedene Dienste oder Systeme sein.
Ich habe immer mal darüber diskutiert, was ist der Kunde in einem Hotel, der Kunde, der eincheckt, also nicht der Eberhard, ist vielleicht jemand anders als der Kunde, der die Rechnung bekommt.
Das wäre die Swaglab GmbH.
Das würde also bedeuten, dass diese beiden Sachen unterschiedlich sind.
Das ist ein klassisches Kriterium aus Domain Driven Design mit der Ubiquitous Language.
Wenn ich also unterschiedliche Ubiquitous Languages habe, dann ist das ein Indikator dafür, dass das unterschiedliche Dinge sind.
Das haben die letztendlich übernommen.
Ist jetzt nicht so wahnsinnig, würde ich sagen, neu.
Dann haben sie halt gesagt, bei den Phasen deckt ein Teil des Systems mit einer früheren oder späteren Bearbeitung ab.
Das könnte eine gute Grenze sein.
Das ist etwas, was aus diesem Event-Storming kommt.
Ich fange jetzt an und das Erste, was ich mache, ist, dass ich ein Buch suche.
Dann leihe ich das Buch und bringe es zurück.
Das sind verschiedene Phasen.
Dass das verschiedene Phasen sind, ist vielleicht ein Indikator dafür, dass das unterschiedliche Modelle sein sollen.
Bei Event-Storming wird das, was jeweils passiert, Buch gefunden und Buch geliehen als Events darhaben.
Ich würde sagen, hier ist das Ende einer bestimmten Phase, hier ist die nächste Phase.
Dieser Bereich ist etwas, was tendenziell etwas Eigenes sein soll.
Das haben die letztendlich übernommen.
Dann haben sie aus diesem Worldlay Maps, das war auch schon Thema bei uns im Stream, die Frage gestellt, kann ich das vielleicht outsourcen, die Leistung, die ich dort habe.
Wird das vielleicht bald outsourcbar sein?
Dann kann ich es vielleicht als Vorbereitung für das Outsourcing separieren.
Oder vielleicht als eigenes Produkt anbieten.
Das ist das, was Worldlay Maps ansetzen.
Da haben sie das importiert.
Dann steht da noch das Risiko.
Was ist das Risiko, wenn ich diesen Service separiere?
Das stellt die Frage, ob diese Entscheidung problematisch ist.
Das sind Dinge, die andere Ansätze wie Events Storming, DDD, Ubiquitous Language usw. auch noch verheiraten.
Ich habe nicht das Gefühl, dass das der Kern ist.
Das ist auch nicht die zentrale Idee, es ist aber eine nette Ergänzung.
Dann haben sie noch auf der Detail-Ebene die Frage, lose Kopplung, ist es sinnvoll, dieses Ding in einer öffentlichen Cloud alleine zu migrieren und zu deployen?
Und dann enge Kopplung.
Hat dieses Ding irgendwelche Abhängigkeiten zu einem Anbieter oder anderer Software, die skalieren, erschwert?
Das fand ich komisch, weil dieses auf Skalieren gerade zu sich zu fokussieren, das ist ja nur eine Art von Abhängigkeit, fand ich halt irgendwie erstaunlich.
Aber natürlich, die Kopplung zu betrachten, ist sicher nicht noch eine gute zusätzliche Sache.
Dann war da halt nicht kommerzielle Möglichkeiten.
Gibt es Nachfrage nach dem Ding außerhalb seines aktuellen Nutzungskontextes?
By the way, spätestens an der Stelle ist es halt so, dass wir eigentlich ganz stark in so eine Geschäftsstrategie kommen.
Also ich habe jetzt vielleicht ein Teil meines Systems, also die Büchersuche oder diese Arbeitszeiterfassung, die ich tendenziell als eigenes Ding anbieten könnte oder einkaufen könnte.
Was also zu der Frage führt, was will ich denn überhaupt selber entwickeln und was ist denn mein Produkt?
Und das ist dann spätestens keine Softwarearchitekturfrage mehr, sondern das ist eine Frage, wo irgendjemand aus Management sagen muss, also die Arbeitszeiterfassung kaufen wir zu, was soll’s.
Daten, ist dieses Ding die Quelle für wesentliche Daten?
Wäre, glaube ich, insbesondere bei so etwas wie dieser Zeiterfassung für die Fahrradreparatur hat es sicherlich ein Ding.
Schnittstellenverträge, hat das Ding eine versionierte Schnittstellung, können neue Versionen deployed werden, ohne dass Kunden oder Clients beeinträchtigt werden?
Eher so eine Softwarearchitekturfrage, wo ja solche Abhängigkeiten und Schnittstellen halt eigentlich traditionell immer ein Thema sind.
Resilience, wenn Nachfragen nach dem Ding steigen, bedeutet das auch eine lineare Zunahme für neue Kapazitäten und Verfügbarkeiten, anschließend geografische Regionen.
Ich kann eine Buchsuche internationalisieren beispielsweise, also das würde sich dann da, glaube ich, irgendwie ergeben.
Skills, betrachtet die Skills im Team, können Teams nach der Teilung jeweils ihr Ding verantworten?
Das hatten wir auch schon bei den grundlegenden Sachen, also diese organisatorische Frage, sodass hier eben diese verschiedenen Perspektiven, kann ein Team, können die Menschen das irgendwie handhaben und die Businessfrage und auch die Softwarearchitekturfrage hat alle betrachtet werden und das ist hier mit den Skills, glaube ich, dann noch ein weiter guter Punkt.
Also Antipattern, Datenkopplung, hat das Ding eine enge Kopplung, beispielsweise einem bestimmten Treibein des Anbieters oder nutzt es Datenbanklinks statt einer API, dann ist es eben schwer separierbar und das ist wieder so eine Implementierungsfrage, das ist also etwas, wo Techniker irgendwas zu sagen können und wo es eben auch tatsächlich nicht um Business geht, sondern um die Umsetzung.
Und dann das Antipattern Release Koordination, brauchen Upstream, Downstream Produzenten oder Konsumenten dein Ding, um einen Release Train zu koordinieren oder können sie unabhängig so oft deployen, wie sie wollen.
Und ich also für beides, für die Buchsuche wie auch für die Erfassung der Aufwände, würde ich halt erwarten, dass man das im Wesentlichen unabhängig hinbekommen kann, aber es könnte eben auch sein, dass das irgendwie so unglücklich, auch technisch vielleicht aneinandergekoppelt ist, dass man es halt gemeinsam deployen muss.
Und da ist also auch wieder die Frage, ist das sozusagen etwas ausreichend separierbares auf Software-Ebene mit der Architektur, mit der Umgebung, die wir jetzt irgendwie gerade haben und nicht so sehr eine Geschichte nach Business.
Also insbesondere diese Detail-Ebene ist Das ist teilweise technisch, teilweise sehr stark implementierungsgetrieben und weist dann vielleicht eher auf so technische Probleme hin, die man halt lösen muss, wenn man das wirklich unabhängig haben will.
Also wenn ich feststelle, das Ding ist deswegen so stark gekoppelt, weil es direkte Datenbankverbindungen hat und über Tabellen mit irgendwas anderem interagiert, was typischerweise eine Separierung schwierig macht, dann könnte ich jetzt eben sagen, das ist halt lösbar, in dem Sinne, dass ich jetzt eben die Software entsprechend umstrukturiere.
Wenn ich sage, das Ding hat halt keinen Markt, dann könnte ich mir überlegen, ob man den Markt irgendwie anders definiert, so wie ich das vorhin mit der Erfassung gezeigt habe für die Fahrrad-Reparatur.
Wenn ich etwas allgemeiner mache, habe ich eben tatsächlich einen größeren Markt.
Das ist irgendwie interessanter.
Das ist aber etwas, wo ich halt eben im Business-Bereich nachdenken muss und nicht irgendwie in der Software was anpassen sollte. Übrigens, diese Geschichte mit eigentlich ist das ja nur eine Zeiterfassung, so wie viele andere halt auch, führt ja zu der Frage, wollen wir das Ding einfach kaufen?
Wollen wir da überhaupt das Ding selber implementieren?
Ich glaube, das ist dort irgendwie die Sache.
Frage, warum ist das jetzt hilfreich?
Also die Independent Service Heuristics nutzen die Intuition und die Erfahrung von Domänexpertinnen und Engineers, um sinnvolle Services zu finden und nutzen da verschiedene Indikatoren.
Also nicht die Frage, ist das ein valides Produkt, gibt es bezüglich Kosten, bezüglich Kunden, bezüglich Abhängigkeiten, bezüglich Markt, das ist ja sehr stark eine Business-Perspektive, ein existierendes SaaS könnte halt ein Indikator dafür sein, dass das eben tatsächlich ein sinnvolles Business ist.
Diese Einkopplung in Bezug auf Daten ist etwas, was ich da betrachte, diese Frage nach, ist es outsourcebar, könnte ich es halt selber vielleicht benutzen, statt es halt selber zu bauen?
Und diese Business-Expertise, die ist dann insbesondere nützlich, um mal diese Produktfrage zu beantworten und darüber zu diskutieren.
Die Frage, ist eine Buchsuche ein sinnvolles Produkt oder ist eine Erfassung für die Aufwände bei einer Fahrrad-Reparatur ein sinnvolles Produkt, ist deutlich keine Software-Architektur-Frage, sondern da müsste sich jemand hinstellen und sagen, ja, ist es halt, weil ich sehe da irgendwie den Markt.
Einsatz-Kontexte sind sowas wie das Validieren eines Designs, ich könnte jetzt also meine existierenden Services damit auf den Prüfstand stellen.
Ich kriege dadurch halt auch die Möglichkeit, ein Set von Design-Prinzipien in einer Organisation zu verankern.
Also ich habe jetzt eben zehn Kategorien, ich habe irgendwie so eine Matrix, das ist zumindest etwas, was man relativ schnell hoffentlich verstehen kann.
Und es gab jetzt auch die Aussage in dem Talk insbesondere, dass es etwas ist, was halt dazu führt, dass man so Team-Turbologies in der Praxis nutzen kann.
Ich muss gestehen, dass ich das eher wahrnehme als ein getrenntes Thema, das ist halt für mich tatsächlich in erster Linie ein Software-Architektur-Thema, nicht so sehr ein Thema von den Teams zuständig, also von dem, was halt in Team-Turbologies drin ist, natürlich fordert Team-Turbologies, dass Teams relativ unabhängig an irgendwelchen Dingen arbeiten können.
Insofern ist es vielleicht tatsächlich eine Voraussetzung, aber Teams sind da nicht der einzige Punkt.
Also es wird ja nicht nur über Teams geredet, sondern eben auch über das Business und über Software-Architektur.
Deswegen würde ich das halt breiter sehen als nur ein Einstieg in Team-Turbologies und die sagen ja auch selber, dass das eben auch etwas ist, was so mit dem Design verheiratet werden kann.
Es ist ein leichtgewichtiger Ansatz, um erstmal irgendwas auf die Reihe zu bekommen.
Ein Beispiel, was in dem schon zitierten Talk nochmal diskutiert wurde, war das Teilen eines Systems, eines großen Systems, um eben in einem neuen Markt ein neues Produkt zu platzieren.
Und dann kann ich das gegen diese Kriterien halten, also sprich, ich habe da jetzt ein neues Ding, ich plane das neue Ding, tue dieses und jenes, ich werde das jetzt gegen diese Kriterien halten und kriege dadurch eine Idee, ob das eine gute Idee ist und zwar nicht nur auf Software-Seite, sondern auch auf Business-Seite.
Und dabei sind eben diese Punkte Indikatoren, das sind eben Heuristiken, das impliziert ja, dass es jetzt nicht so ganz klar ist und ich kriege dadurch auch sehr klar eine Information darüber, was halt offen oder schwierig ist.
Also ich kriege halt nicht einfach nur grüne Post-Its, sondern ich kriege eben Hinweise darauf, wo die Herausforderungen sind.
Ein Beispiel, was in dem Talk war, war, dass es dort eben ein Team gab, was nach Featuren bezahlt wird, wo gesagt wird, okay, wir haben die Teams, die die wirklichen Systeme bauen.
Und dann gibt es ein Team, was etwas zuliefert und die werden nur bezahlt, wenn sie etwas zuliefern können oder sollen.
Was bedeutet, sie haben eben keine Roadmap.
Also sie können jetzt nicht sagen, wir bauen das jetzt ein, sondern diese Entscheidung treffen die anderen für sie und kaufen das bei denen.
Und dann gibt es da irgendwie keine Vision und dann müsste man eben dort schauen, wie man das löst.
Also vielleicht ist das etwas, wo man sagt, naja, ich mache es trotzdem als eigenes Ding, als eigenes Team und ich lebe damit.
Vielleicht kommt man dahin, dass man da irgendwie eine Roadmap definieren kann.
Vielleicht ist das sogar sinnvoller, weil nicht ein Ding, was halt irgendwie nur anhand von anderen Leuten Entscheidungen und Featuren halt weitergebaut wird, ist vielleicht etwas, was dann am Ende so historisch gewachsen ist und eben nicht an der Vision und einer Idee verfolgt.
Und das kriegt man nie aber durch diese Diskussion raus, wenn man ja diese Maßstäbe halt anlegt.
Ein Punkt, den ich nochmal loswerden wollte, ist, das war ja auch schon Thema bei der Episode mit dem Eduardo und der Guru.
Das, was wir hier diskutieren, kann man jetzt tatsächlich in einer halben Stunde mal kurz durchdiskutieren, was ja irgendwie vielleicht zu dem Eindruck führt, dass man das eben auch dann in der Realität mal kurz in einer halben Stunde durchdiskutieren kann.
In der Realität dauert das halt deutlich länger und muss halt auch deutlich detaillierter sein.
Das hat ja sogar Auswirkungen auf die Geschäftsstrategie.
Wenn ich jetzt irgendwie sage, okay, dieses Ding, also ich komme jetzt durch eine Diskussion darauf, dass diese Arbeitszeiterfassung, die ich im Rahmen der Fahrradreparatur bauen will, ein eigenes Produkt sein könnte oder sollte, dann muss ich halt daraus ein eigenes Produkt machen.
Das hat irgendwie Konsequenzen weit jenseits von Softwarearchitektur.
Wenn ich umgekehrt sage, dass es das nicht wert ist, dass ich selber implementiere, sondern ich würde es irgendwie einkaufen, dann ist das auch wieder eine Sache, die halt die Aufstellung der Firma beeinflusst.
Ich glaube, wir hatten ja auch den Nick Tune mit seiner Softwarearchitektur-Modernisation und ich habe auch eine Episode gemacht, wo ich über seine Paper diskutiert habe und in den Dingen verschwimmt halt die Grenze zwischen Businessgeschichten und Softwarearchitekturgeschichten.
Und das ist hier, glaube ich, ein ähnliches Thema.
Das ist ja auch der Grund, weswegen wir eben bei SwagClub da breit aufgestellt sind und eben in beiden Bereichen beraten können, weil eben nicht Softwarearchitektur, sondern Business Sinn macht halt irgendwie keinen Sinn.
Mein persönliches Fazit über die ganze Geschichte ist eigentlich, also ich finde es gut, dass diese Sachen halt dort ein Ding genannt werden und das nicht konkretisiert wird.
Dadurch ist es für mich sofort erkennbar, dass das halt für Businessmenschen verständlich sein sollte und dadurch die Kommunikation halt vereinfacht sein sollte.
Ich finde es gut, dass Teams und Komponenten, beides irgendwie betrachtet wird, Softwarearchitektur und Teams und dass Businessgründe da drin sind und ich glaube oder es ist erkennbar, dass es eine weitere Ergänzung zu dem kanonischen DDD-Kanon ist.
Also noch ein Ding, was sich halt in diesem DDD-Kontext ganz gut einsetzen kann.
Das, was da rauskommt, sind vielleicht dann sowas ähnliches wie Baune Kontexte oder Module.
So wie ich ja in der Einleitung sagte, das ist ein fundamentales Problem, das ist ein weiteres Werkzeug, das man dafür nutzen kann.
Gut finde ich daran, dass es eben klare Businesszuständigkeiten für Services definiert.
Das ist etwas, was sonst manchmal sozusagen unangenehm wird.
Also ich erinnere mich an die eine Geschichte während der Corona-Pandemie, wo ich einen Kunden hatte und der Kunde hatte halt im Prinzip ein Ding, was halt Produkte zum Kunden schicken kann bzw. zu den Filialen.
Nur dieses Ding, was halt Produkte zu den Filialen schicken konnte, konnte eben nur Dinge zu den Filialen schicken, nicht an eine beliebige Adresse.
Und das ist bei Corona doof, weil wenn die Filialen zu sind oder sich die Menschen nicht in die Filialen wagen, dann wäre es ganz gut, wenn man das direkt irgendwo hinschicken kann.
Und das ist jetzt etwas, was man hier vielleicht klarer hinbekommt.
Dass man irgendwie klarer sagt, was machen wir denn hier?
Naja, wir schicken halt Dinge irgendwo hin.
Ist das etwas, was wir unabhängig als eigenes anbieten können?
Das ist eigentlich ein Logistik-Thema und dann kriegt man, glaube ich, eher so eine Diskussion in diese Richtung, die das halt nochmal klarer macht und nicht solche Probleme vielleicht vermeiden würde.
Das startet sicher eine Diskussion, also wenn wir jetzt diese zwei zitierten fachlichen Dinge bauen würden und ich würde da irgendwie drinsitzen als Techniker, kann ich mir sofort vorstellen, wie die Diskussion mit den Domenexpertinnen und den anderen Menschen aussieht und das total spannend ist und ich was dabei lerne.
Und das ist ein Ansatz, der auf einer Ebene von Modularisierung ansetzt, eben auf dieser grobgranularen Ebene, wie es auch bei einem Kontext zu tun, wo Modularisierung besonders relevant ist.
Das heißt, das löst ein Problem in einer Ebene, die ja tatsächlich wichtig ist.
Ich würde behaupten, dass halt sicherlich die Modularisierung in Klassen zum Beispiel auch wichtig ist, aber vielleicht nicht ganz so wichtig wie das, was wir hier diskutieren.
Es wirkt so, als würde man relativ schnell zu Ergebnissen kommen und es ist halt auch schön, dass diese Unabhängigkeit sehr weit gedacht ist, eben auch in Bezug auf Kosten, in Bezug auf Teams, in Bezug auf Infrastruktur und so weiter.
Eigentlich ist das aber, also wie soll ich sagen, das sind zehn verschiedene Möglichkeiten und dann noch ein paar mehr, die Frage zu stellen, ist dieses Ding wirklich unabhängig?
Aber eben deutlich geschickter und konkreter und das ist glaube ich der Wert.
Schlecht finde ich daran, oder etwas, was man beachten muss, ist, das geht halt nur für grobgranulare Services.
Das geht halt nicht innerhalb eines Services.
Wenn ich mich jetzt also hinstelle und sage, ich habe jetzt die Buchsuche, muss ich innerhalb der Buchsuche das weiter unterteilen, bis ich zu Klassen und Methoden komme.
Vielleicht habe ich da individuelle Packages noch.
Da spielt Technik vielleicht eine Rolle.
Vielleicht habe ich eben Packages oder bestimmte Teile des Kurses, die mit der Datenbank interagieren, bestimmte Teile des Kurses, die mit der UI interagieren.
Das muss ich also weiter ausdifferenzieren und da weitere Module bilden.
Vielleicht habe ich da ja auch weitere fachliche Sachen.
Weiß ich nicht, irgendeinen Importer, der halt Informationen über Bücher von anderen Systemen einliest oder was auch immer.
Da hilft mir halt dieser Ansatz nicht weiter.
Das ist halt ein anderes Thema.
Da muss man aber auch dazu sagen, dass vielleicht dort der Business oder die Meinung des Business nicht mehr ganz so wichtig ist, weil das eher ein technisches Problem ist oder ein technisches Problem löst.
Dann ist halt die Frage, die ich mir stelle.
Ich baue jetzt also einen grobgranularen Service.
Ich stelle fest, der ist zum Beispiel aufgrund von irgendwelchen technischen Maßnahmen, weil er die selben Datenbanken benutzt, die selben Datenbanktabellen benutzt, habe ich halt mindestens ein rotes Posted.
Ist das jetzt dennoch wert, es einen eigenen Service zu nennen?
Und ich würde halt behaupten, das ist vielleicht so nicht.
Also ich würde wahrscheinlich nicht immer nur grüne Posteds haben und dadurch ist für mich ein bisschen die Frage, ob vielleicht so eine unrealistische Erwartungshaltung dafür hier erzeugt wird, wie unabhängig ein Service denn eigentlich sein sollte.
Was ich versuche zu sagen ist, insbesondere wenn ich vergurktes Legacy-System habe, hängt alles mit allem zusammen.
Und ich kann jetzt die Frage stellen, weil das halt irgendwie so vergurkt ist, lohnt es sich jetzt Teams unterschiedliche Aufgaben zu geben?
Und dann ist die Frage, was soll ich denn sonst machen?
Also irgendeine Struktur brauche ich halt und ich kriege hier raus, das ist glaube ich der Vorteil, dass es transparent ist, dass ich in dem Teil Probleme habe.
Wenn ich also dort eben ein Legacy-System habe, werde ich halt ja rote Posteds haben in den Bereichen, wo es eben um die konkrete technische Unabhängigkeit geht und dadurch weiß ich, wo ich halt besser werden muss.
Das ist da glaube ich irgendwie hilfreich.
Ich habe mir noch aufgeschrieben, dass ich mir nicht ganz sicher bin, ob das vielleicht doch dann noch zu viel ist.
Ich brauche halt irgendwelche Indikatoren, wenn mir jemand sagt, okay, hier sind halt meine Domänen und so haben wir das halt irgendwie implementiert.
Dann brauche ich ja irgendwie eine Heuristik in so einer Beratungssituation, die mir jetzt sagt, das ist eine Vollkatastrophe oder das ist irgendwie toll.
Da bin ich mir nicht sicher, ob ich halt diese zehn Sachen durchiterieren wollen würde.
Das heißt, es ist glaube ich für den, also ich kann mir da, wo das sehr gut sicher funktioniert, ist halt, wo ich einen Workshop habe mit dieser gemischten Aufstellung, wo ich dann irgendwie diese Diskussion haben möchte, die halt dazu führt, dass wir gemeinsam das Design verabschieden.
Da finde ich das sofort irgendwie einsehbar, dass man das so macht und hiermit irgendwie umsetzt.
Aber für, jetzt sag mal, ob das ein gutes oder ein schlechtes Modul ist, ist es vielleicht ein bisschen viel.
Aber es hilft ja irgendwie auch sozusagen als Intuition und ist irgendwie etwas, worauf ich dann auch in so einer Situation schöpfen kann.
Gut, das wäre das, was ich dazu soweit sagen wollte.
Ich habe jetzt ehrlich gesagt keine Fragen gesehen.
Weder im Formular noch im Chat in den verschiedenen Plattformen.
Dann würde ich sagen, haben wir es soweit.
Ich bedanke mich für die Aufmerksamkeit.
Ich glaube, es wird nächste Woche eine Episode geben, aber ich kann das noch nicht so hundertprozentig sagen, wie es genau aussehen wird.
Also da sozusagen stay tuned, sicher nicht am Freitag.
Das wäre halt der Karfreitag, aber dann irgendwie zu einem anderen Termin.
Das seht ihr dann ja.
Ja, dann, wie gesagt, würde ich sagen, vielen Dank.
Schön, dass ihr zugehört, zugeschaut habt.
Ich hoffe, ihr habt was mitgenommen und dann sehen wir uns oder hören wir voneinander bei der nächsten Episode.
Bis dahin, vielen Dank.
Schönes Wochenende und bis dahin.