# Independent Service Heuristics for Business Strategy

**Podcast:** Software Architektur im Stream
**Published:** 2026-03-27

## Transcript

Hallo, ich bin Ibert Wolf.
Freitags mache ich oder Lisa Moritz ein Livestream zum Thema Software Architektur, oft zusammen mit Gästen.
Dieser Podcast is the audio des streams.
Weitere Folgen, Sketchnotes und vieles mehr findet ihr unter software-architektur.tv software.
So, dann herzlich willkommen zu einer weiteren Episode von Software Architecture and Stream.
Heute geht es um das Thema mit Independent Service Heuristics.
Warum nun ausgerechnet this thema?
This hangs zusammen, dass wir ja for kurz eine Episode gemacht hatten, unter anderem mit dem Eduardo von der Azure Meets Architecture.
Da hat er kurz über Independent Service Heuristics gesprochen.
Und ich dachte, dass es deswegen vielleicht ein spannendes Thema is.
Außerdem, this theme von Modularisierung von Systems, beispielsweise in verschiedene Services ist ja ein Thema, was wir im Stream schon häufig diskutieren haben.
Und das bedeutet, es ist irgendwie vielleicht ganz nett, dann nochmal auf so etwas wie Independent Service Heuristics einzugehen.
Das führt dann auch gleich zu der Frage Warum brauchen wir dann noch irgendetwas.
Also es gibt ja vorne Kontexte und Module and ganz viele Ansätze, wie ich halt irgendwie was unterteilen kann.
And die Gründe, also das Ganze kommt aus dem Team Topology Universum.
Ich verlinke nachher auch nochmal die Homepage, die es bei Team Topology in 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 welcher Erfahrungen die damit gemacht haben.
Und die sagen jetzt unter anderem, dass eben Domain-Jooding Design über solche Sachen wie Bowden Context oder Ubiquitous Language spricht.
Aber das wird dann irgendwann sehr kompliziert.
Es gibt sehr viele Fachbegriffs, es gibt eine komplett eigene Welt.
Und das ist insofern halt insbesondere problematisch, als dass es eben für Menschen, die halt gerade so ein Business-Hintergrund haben, tatsächlich eine fremde Welt ist.
Und das führt eben zu der Frage, kann man das nicht irgendwie noch einfacher und besser haben.
Dann is es halt so, also was sie sagen, ist, dass Independent Service Heuristics ein Zwischenschritt ist, der dabei helfen kann, die Prinzipien von Domain-Driven Design einzuführen, ohne eben diese abstrakten Begriffe zu verwenden, die oft eine Hürde darstellen.
Es soll dabei helfen, Value Streams oder Domaingrenzen zu finden, was ja mindestens ein Software-architektonischen Thema ist.
Und es sollen so einfach Daumenregeln und Hinweise sein.
Da es darum geht, Domaingrenzen zu finden, bedeutet das, dass wir auf dieser sehr grob granularen Ebene unterwegs sind.
Also auf diese Ebene, auf der man sonst vielleicht über bauen und Kontexte sprechen würde, also Dinge, die halt tatsächlich irgendwie sehr, sehr unterschiedlich sind.
Und eben eher so die Grubgranularsten Module sind, die ich halt so in einer Software-Architektur vielleicht habe.
Was ist das?
Und genau, was ist das Ziel?
Also, einmal ist das Ziel halt: Grenzen zu finden, die für den Fluss von irgendwelchen Änderungen möglichst einfach sind.
Das ist etwas, wo die Aussage, was hat Domain-Joom Design nicht wirklich löst, weil eben zu dem Zeitpunkt, als Domain-Grime Design man sich überlegt hat, eben diese Idee von dem Fluss von Änderungen durch die Softwareentwicklung noch nicht so das große Thema war.
Ich muss dazu gestehen, ich bin mir nicht sicher, ob ich das so unterschreiben würde, denn ich würde sagen, eine gute Modarisierung, die ich vielleicht mit Domain-Driven Design erzeuge, sorgt eben dafür, dass ich Endo möglichst leicht umsetzen kann, aber sei es drum.
Dann geht es halt insbesondere um diese businessfreundliche Sprache, also dass eben Menschen, die tatsächlich nicht aus dem Software-Architekturhintergrund kommen, so nicht Informatik studiert haben oder in der Softwareentwicklung arbeiten, an diesen Diskussionen sind vorteilnehmen können und was dazu beitragen können.
Dann geht es um Gruppendiskussionen und die Möglichkeit, halt dort Lernen zu unterstützen.
Und ich möchte halt schnell Ergebnisse erzielen.
Also eine Aufteilung eines Systems im mehrbauen Kontext ist eben aufwendig und schwierig.
So, und die grundlegende Idee von diesen Independent Service Juristics ist halt zu sagen, ist halt die Frage zu stellen, könnte das ein eigener SARS-Service werden?
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 relativ klar ist, insofern, als dass wir ja alle irgendwie ein Software as a Service irgendwo benutzen.
Und 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.
Und was ich mir selber noch dazu aufgeschrieben habe, das ist nichts, was die jetzt irgendwie selber gesagt haben.
Aber ich finde es halt ganz hilfreich, wenn man halt einem Modul so eine Zuständigkeit gibt, nicht bei diesen CAC-Karten-Class, Responsibility Collaboration, wo ich eben für Klassen, also auf einer ganz fein granularen Ebene, ein System unterteilt, da habe ich eben auch eine Responsibility und dort irgendwie zu sagen, ich bin halt verantwortlich für dieses Ding, diese Aufgabe, weiß ich nicht, Bestellungen entgegennehmen, Kunden, verwalten, das ist eben etwas, was hilfreich ist, um ein Modul halt zu verstehen.
Und das kriegt man hier automatisch raus, weil ich ja herausfinde, was dieser Service eben liefern soll.
Und das ist eben eine Zuständigkeit in diesem Sinne, so wie eine Responsibility bei einer CAC-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.
So, die erste Sache, die erste Frage ist natürlich die Frage, wie komme ich halt zu irgendwelchen Kandidaten?
In dem Talk haben die beiden halt erzählt, dass sie so 20 bis 40 Kandidaten typischerweise identifizieren und da unterschiedliche Möglichkeiten sehen, die halt zu identifizieren zu identifizieren.
Einmal gibt es halt diese Fracture Planes von den Team Topologies.
Das ist das, woran ich in Team Topologies Team auf Grenzen die Grenzen von Teams definiere.
Und da gibt es eben verschiedene Fracture Planes.
Eine Fracture Plane ist zum Beispiel Bound and Contexte, also fachliche Zuständigkeit für irgendwelche Fachlichkeiten.
Aber es gibt zum Beispiel auch so etwas wie Compliance, dass ja so Sachen, die halt aus irgendwelchen Compliance-Gründen eben anders sind als Sachen, die halt aus Compliance-Gründen anders sind, dass ich die halt irgendwie aufteile und damit halt Zuständigkeiten habe für Teams.
Und da ist eine Möglichkeit, Kandidaten halt zu identifizieren.
Wir hatten ja eine Folge gemacht zum Thema Team Topology.
Da ist das mit den Fracture Planes auch ein Thema.
Da kann man sich das also sozusagen nochmal angucken.
Dann halt so etwas wie User Needs, also dass ich halt als BenutzerIn 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 HIA, die im Prinzip das sehr radikal gemacht hat und gesagt hat, wir teilen unsere Unternehmen auf in viele kleine Unternehmen, viele kleine GmbHs oder was auch immer die Rechtsform ist.
Und die sind jeweils zuständig für ein Teilbereich, die haben eigene Kunden, die haben eine klare Kundenorientierung, und das sind eben dann so Microenterprises, werden die halt genannt.
Ich glaube, bei AR geht es eben darum, dadurch eine hohes Maß an Selbstorganisation hinzubekommen und eben kompetitiv am Markt zu sein.
Das wäre also auch jetzt etwas, was man sozusagen in die Intuition benutzen kann.
Und was man dann machen kann, ist man kann halt so eine Matrix machen, wo man eben sagt, ich habe die verschiedenen Kandidaten.
Ich habe mir jetzt ausgesucht, einmal ein Kandidat, um das mal ein bisschen sozusagen mit Leben zu erführen.
Das ist halt irgendwie die Buchsuche.
Es gibt so ein Beispiel, was ich in Trainingshema benutze, das ist halt eine Bibliothek, und da gibt es halt irgendwie die Buchsuche.
Und die Frage ist: Wie stellt sich halt diese Buchsuche einer Bibliothek als bezüglich der Independent Service Juristics 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 Fahrradreperatur erfasse, wo also jetzt ein Mitarbeiter, eine MitarbeiterIn irgendwie dasteht und sagt, okay, ich habe jetzt an dem Fahrrad folgendes gemacht.
Ich habe irgendwie, weiß ich nicht, die Pedale gewechselt und noch eine neue Pedale rangepackt.
Okay, da heißt, ich erfasse jetzt, ich habe eine Pedale für 20 Euro daran gebaut.
Ich habe da dran irgendwie 15 Minuten gewerkelt und darüber kriege ich dann so eine Erfassung.
So, und ich kann jetzt solche Dinge halt, ich kann eine große Matrix machen, kann ich mir sagen, okay, ich habe halt diese verschiedenen Servicekandidaten, 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 Rotus-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 halt bestimmte Dinge sozusagen relativ klar gute Services in diesem Sinne sind oder gute Aufteilung und andere Dinge dann halt irgendwie weniger gut.
Ich muss gestehen, sozusagen als Warnung, diese beiden Beispiele kommen halt aus Software-Architekturaufgaben.
Dadurch ignorieren wir sozusagen schon ein Vorteil, nämlich dass es 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 as a Service anzubieten.
Also ist es unabhängig genug, sind ja 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 halt aufgefallen ist, ist, dass sie halt von dem Ding reden.
Und das finde ich eigentlich in gewisser Weise ganz lustig, weil nicht.
Also normalerweise gibt man sich ja irgendwie Mühe und versucht ja irgendwie daraus ein Service zu machen oder eine Komponente oder so.
Aber eigentlich finde ich den Begriff das Ding ganz schön, weil also eigentlich ist eine Komponente oder ein Service häufig auch nur irgendein Ding.
Und wenn man irgendwie fragt, was ist das denn nun genau, ist das irgendwie definiert, dann kommt halt meistens raus, dass es irgendwie 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 an die Tricht nicht, also dass man eben nicht von einer Komponente spricht.
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 ein Service anbieten.
Es gibt ja sowas wie zum Beispiel die IMDB für Filme.
Sonst könnte ich für Bücher sicher auch anbieten.
Also, warum sollte das nicht was Eigenes sein?
Ist das ja etwas, was Konsumenten verstehen oder wertschätzen würden?
Kann ich mir schon vorstellen.
Es ist halt ein bisschen die Frage, was da noch der zusätzlich wäre, was der zusätzlich wert wäre, jenseits von, es gibt dieses Buch, nicht Goodreads.com, geht ja auch ein bisschen in diese Richtung.
Da gibt es dann eine Bewertung dafür.
Das ist übrigens auch ein Indikator.
Nicht, gibt es schon ein Software as a Service dafür.
Würde es die Ausführung vereinfachen?
Wahrscheinlich schon.
Also da ist das halt sozusagen einigermaßen sauber.
So, und dann, das ist also der Sinn, kommt als zweites die Marke, könnte man sich vorstellen, dieses Ding als eigene ö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 Marketingkampagne überzeugend?
Wir können Bücher suchen, weiß ich nicht genau, müsste man sich halt irgendwie nochmal drü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 halt insgesamt eine Stunde eigentlich, und ich bin alleine, das heißt, ich kann, also ich kann mit mir diskutieren, aber nur sehr begrenzt.
Im wirklichen Leben wäre es halt, glaube ich, deutlich länger und umfangreicher, sowas halt auf die Reihe zu bekommen.
Es gäbe da halt irgendwie auch größere Diskussionen.
Das heißt also, dass wir hier jetzt irgendwie eine Stunde darüber reden, ist deutlich nicht das, was in der Realität passieren würde.
Und diese Frage mit der Marketingkampagne, 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.
Also 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 Abufsair bringen, 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 diesen 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 und Lizenzen.
Ist das Ding außerhalt separat und abgekoppelt von anderen Dingen in Organisationen?
Verbucht die Organisation die Kosten separat.
Das kann ich jetzt nur beantworten und da ist, glaube ich, diese Idee von, das ist ein kollaborativer Prozess, ich habe verschiedene Ansätze da.
Das kann ich also nur beantworten, wenn ich halt eine Idee habe, so aus dem Finance-Bereich und vielleicht aus dem Betriebsbereich, die mir das also verraten können.
Also wenn ich halt sage, es gibt eine Buchsuche in der Bücherei, die Frage nach diesen Kosten kann ich nur beantworten, ist nicht so abstrakt beantwortet, sondern da hängt es eben tatsächlich davon ab, wie die Menschen halt mit diesen Kosten umgehen in diesem spezifischen Kontext, was also bedeutet, dass das in gewisser Weise eine offene Frage ist.
Diese Frage ist, glaube ich, deswegen relevant.
Also, wo wollen wir hin?
Wir wollen ja etwas haben, was irgendjemand unabhängig von anderen weiterentwickeln, umsetzen und so weiter kann.
Und dazu ist es natürlich super, wenn ich jetzt irgendwie sage, ich kann halt auch dem Betriebsaspekt, wie das Ding halt sozusagen läuft, eben habe ich eben auch unter Kontrolle, weil ich mich dann nicht mit der zentralen, dem zentralen Betrieb oder solchen Sachen halt 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, nicht, 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 sozusagen reinplacken.
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 Eingabedaten sauber, also nicht unübersichtlich?
Vermutlich schon Informationen über ein Buch sind halt nicht Autotitel und so weiter.
Das ist etwas, was man wahrscheinlich im Prinzip hinschreiben könnte.
Wenn die Daten als ein 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 wohl definierte Menge von Benutzerinnen oder Kundinnen haben, also irgendwelche Personas?
Da sind wir wieder bei dem Thema nicht, das ist halt irgendwie nicht so ganz klar, was für Menschen das halt irgendwie sind.
Entspricht das Ding, also sprich an Büchern interessiert, ist halt sehr grob.
Entsprecht das Ding bestimmten Benutzeranforderungen?
Also, ja, ich kann Qualitätsstil definieren, wie schnell das irgendwie reagieren soll.
Soll irgendwie angenehm sein, da schnell Bücher zu finden, aber jetzt so glasklar zu sein.
Also, ich würde halt mal unterstellen, dass jemand, der Bücher lesen will, um sich halt irgendwie zu entspannen, was anderes macht, als wenn jemand jetzt irgendwie Publikationen sucht zu irgendwelchen wissenschaftlichen Themen.
Kennen wir diese Benutzertypen und ihre Bedürfnisse oder können wir sie einfach nennen?
Vielleicht nicht.
Also, da wäre halt vielleicht eher so ein, 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 Float, Breite der Team, Context-Switches 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 Infrastruktur, für die Plattform überflüssig.
Ist wahrscheinlich eine Webanwendung, die ich halt irgendwie laufen lasse auf dem Standard Umgebung, würde ich halt auch sagen, das ist halt 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 halt 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 halt relativ natürlich und 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.
Also wahrscheinlich wird es irgendwie eine Aktion geben, wo ich jetzt sage, ich kann das Buch ausleihen.
Aber das ist irgendwie, also in der Büchersuche, nicht bei Goodreads oder so, gibt es ja auch Werbung und Links.
Das ist also, glaube ich, das 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 also sage, ich brauche halt eine andere Art und Weise, Webanwendungen zu deployen oder muss da halt was verbessern, dann blockiert mich das nicht.
Das macht nur meine Arbeit vielleicht irgendwie einfacher.
Wirkung, also Englisch Impact oder Wert, wäre der Umfang dieses Dings ein, würde der Umfang dieses Dings einem Team eine wirkungsvolle und spannende Herausforderung bieten?
Tatsächlich auch die Frage, ob das sozusagen langfristig motivierend wirkt.
Bin ich mir nicht sicher, Büchersuche ist vielleicht ein bisschen einfach.
Also 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.
Also 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?
Ja, also wenn ich halt in einer Bibliothek nicht nach Büchern suchen kann, ist das halt 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 einer wohl definierten Bereich des Geschäfts?
Kann das Ding, 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 also anfangen und könnte halt sagen, wie leicht, wie schnell findet ihr Bücher, wie viele Bücher findet ihr, wie gut kommt euch das alles vor.
Und das kann ich jetzt glaube ich, und die entsprechenden Entscheidungen, Verbesserungen an dem Produkt, kann ich, glaube ich, unabhängig von allen anderen durch exerzieren.
So, jetzt können wir, also was das jetzt bedeutet, ist, wenn ich mir die Buchsuche angucke, so Sinnmarke, das funktioniert, Umsatzkunden, ist die Frage, ob man damit Geld verdienen kann.
Kosten wissen wir nicht, müssen wir genauer reingucken.
Daten, ja, das kriegen wir halt 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, Schuhen relativ wichtig.
Eigene Roadmap, das wäre irgendwie auch denkbar.
Sonst können wir das andere mal nehmen.
Das ist also ein Teil des Systems in einer für eine Fahrradreparatur, wo jetzt also die Mitarbeiterin, die das Fahrrad repariert, die Zeit erfasst.
Ist es sinnvoll, das Ding as a Service anzubieten?
Ja, also 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 as a Service.
So jedenfalls meine Wahrnehmung.
Ich könnte also sowas auch as a Service anbieten.
Da gibt es aber noch die Besonderheit, dass ich ja irgendwie sagen muss, nicht, ich habe eine Pedale angebaut, also ich muss irgendwie auch neben Zeit auch Materialien erfassen.
Und ich kann mir vorstellen, dass man da eine interessante Diskussion bekommt, die eben auf die Frage halt 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 das für unwahrscheinlich, weil wenn jetzt jemand hier herkommen würde und irgendwas reparieren würde hier im Haus, wäre ja dasselbe passieren.
Also nicht, da würde halt kommen, würde Arbeitszeiten in Richtung Stellen und Materialien.
Und vielleicht ist das halt eine interessante Diskussion auch darüber, ob man es halt 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 halt die Menschen, die halt die Arbeitszeit erfassen wollen.
Vielleicht auch noch die Leute, die halt anschließend eben irgendwelche Rechnungen schreiben wollen.
Das wären irgendwie auch Menschen, die halt damit was zu tun haben.
Team, das kann ein Team sicher bauen und betreiben.
Ich wüsste nicht, warum nicht.
Abhängigkeiten.
Letztendlich ist das halt ein Helfershelfer dafür, um eine Rechnung zu schreiben.
Aber wahrscheinlich haben die Leute, die halt 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 also da eine eigene Roadmap machen?
Würde ich schon erwarten.
Also, ich kann das jetzt irgendwie sozusagen für die BenutzerInnen irgendwie attraktiver machen.
So, ich will so, und das wäre jetzt etwas, was ich halt in die Heatmap sozusagen aufnehmen kann.
Und wo ich jetzt mit grünen, gelbem und roten Post-its das halt bewerte und dann halt eine Idee davon generieren, ob das unabhängige Services sein sollen oder eben auch nicht.
Und darüber kann ich eben 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 halt tatsächlich im Betrieb ist oder jemand, der es halt irgendwie benutzt, irgendwelche Domänenexpertinnen, die hätten halt durchaus sehr, sehr spannender Input.
Eigentlich ist halt viel von dem, was ich hier irgendwie erzählt habe, sind halt irgendwelche Thesen über die Fachlichkeit, die man sinnvollerweise mit so einem Domänenexpertin nochmal durchsprechen sollte.
In dem, auf der Homepage selber stehen jetzt noch so ein paar weitere Dinge, die man damit irgendwie anfangen kann oder weitere Ideen, um halt eben die Unabhängigkeit von Services Server festzustellen.
Das ist zum Beispiel das Vokabular, also ist das Vokabular dasselbe in verschiedenen Teilen des Systems oder unterschiedlichen Business-Domainen.
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 halt 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.
Ist etwas, was so aus diesem Event Storming kommt, nicht, wo ich ja eben sage, okay, ich fange jetzt irgendwie an, and das erste, was ich halt mache, ist, dass ich halt ein Buch suche, dann leih ich halt das Buch, dann bringe ich es halt irgendwie zurück.
Das sind verschiedene Phasen und dass es eben verschiedene Phasen sind, ist eben vielleicht ein Indikator dafür, dass das halt unterschiedliche Modelle sein sollen.
Bei Eventstorming würde ich eben das, was halt jeweils passiert, nicht Buch gefunden und Buch geliehen und so weiter, halt als Events da haben und würde halt sagen, okay, hier ist halt das Ende einer bestimmten Phase, hier ist halt die nächste Phase.
Und dieser Bereich ist eben dann etwas, was tendenziell vielleicht etwas eigenes sein soll.
Das haben die halt letztendlich übernommen.
Dann haben sie aus diesen Wortlay Maps, war auch schon ein Thema bei uns im Stream, eben die Frage gestellt, kann ich das vielleicht outsourcen, die Leistung, die ich dort habe, und wird es vielleicht bald aussourzbar sein.
Dann kann ich es vielleicht, dann kann ich es tatsächlich für so eine als Vorbereitung fürs Outsourcing halt separieren.
Oder vielleicht als eigenes Produkt anbieten.
Das ist das, was Wortlay Maps an setzen, da haben sie also das sozusagen importiert.
Und dann steht auch noch das Risiko.
Also, was ist das Risiko, wenn ich diesen Service separiere, was eben die Frage stellt, ob diese Entscheidung halt irgendwie problematisch ist.
Das sind also Dinge, die, glaube ich, andere Ansätze, wie eben Eventstorming, DDD, Ubiquitus Language und so weiter damit irgendwie auch noch verheiraten.
Ich habe nicht das Gefühl, dass das so der Kern ist und das ist ja auch, glaube ich, nicht die zentrale Idee, es ist aber eine nette Ergänzung.
Und dann haben sie halt noch so auf der Detail-Ebene die Frage, lose Kopplung, ist es sinnvoll, dieses Ding in eine öffentliche 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 irgendwie 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 dann mit meinem Produkt?
Und das ist dann spätestens keine Software-Architekturfrage mehr, sondern das ist irgendwie eine Frage, wo irgendjemand aus dem Management sagen muss, also die Arbeitszeiterfassung kaufen wir halt zu, was soll's.
Daten ist dieses Ding die Quelle für wesentliche Daten.
Wir glaube ich, insbesondere bei so etwas wie dieser Zeiterfassung für die Fahrradreparatur hat sicherlich ein Ding.
Schnittstellenverträge, hat das Ding eine versionierte Schnittstelle und können neue Versionen deployed werden, ohne dass Kunden oder Clients beeinträchtigt werden.
Eher so eine Software-Architekturfrage, wo ja solche Abhängigkeiten und Schnittstellen halt eigentlich traditionell immer ein Thema sind.
Resilience, wenn Nachfragen nach dem Ding steigt, bedeutet das auch eine lineare Zunahme für neue Kapazitäten und Verfügbarkeiten, einschließlich geografischer Regionen.
Ich kann eine Buchsuche internationalisieren, beispielsweise nicht.
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, nicht also diese organisatorische Frage, sodass hier eben diese verschiedenen Perspektiven, kann ein Team, können die Menschen das irgendwie handhaben und die Business-Frage und auch die Software-Architekturfreiheit alle betrachtet werden und das ist hier mit den Skills, glaube ich, dann noch ein weiterer guter Punkt.
Dann also Anti-Pattern-Datenkopplung hat das Ding eine enge Kopplung, beispielsweise einen bestimmten Treibe eines Anbieters oder nutzt es Datenbank-Links statt einer API.
Dann ist es eben schwer separierbar und das ist wieder so eine Implementierungsfrage.
Das ist also etwas, wo TechnikerInnen was zu sagen können und wo es eben auch tatsächlich nicht um Business geht, sondern um die Umsetzung.
Und dann das Anti-Pattern-Release-Koordination braucht ein 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 aneinander gekoppelt ist, dass man es halt gemeinsam deployen muss.
So, 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 drin eine Geschichte nach Business.
Also insbesondere diese Detail-Ebene, also ist halt 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 halt feststelle, das Ding ist irgendwie deswegen so stark gekoppelt, weil es halt direkte Datenbankverbindung hat und über Tabellen mit irgendwas anderem interagiert, was typischerweise eine Separierung schwierig macht, dann könnte ich jetzt eben sagen, dass es halt lösbar in dem Sinne, dass ich jetzt eben die Software entsprechend umstrukturiere.
Wenn ich halt sage, das Ding hat halt kein 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 Fahrradreparatur.
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 Businessbereich nachdenken muss und nicht irgendwie in der Software um was anpassen sollte.
Übrigens nicht, also 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 nicht einfach kaufen?
Also, wenn man da überhaupt das selber implementieren.
Ich glaube, das ist dort irgendwie die Sache.
Frage: Warum ist das jetzt hilfreich?
Also, die Independent Service Juristics nutzen halt die Intuition und die Erfahrung von Domain-Expertinnen 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 existieren des SARS könnte halt ein Indikator dafür sein, dass das eben tatsächlich ein sinnvolles Business ist.
Diese Entkopplung 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 halt diese Produktfrage zu beantworten und darüber zu diskutieren.
Also die Frage, ist eine Buchsuche ein sinnvolles Produkt oder ist halt so eine Erfassung für die Aufwende bei einer Fahrradreparatur ein sinnvolles Produkt, ist deutlich keine Software-Architekturfrage, sondern da müsste halt sich jemand hinstellen, um zu sagen, ja, ist es halt, weil ich sehe da halt irgendwie den Markt.
Einsatzkontexte sind so etwas wie irgendwie das Validieren eines Designs.
Ich könnte jetzt also meine existierenden Services damit auf die auf die Prüf 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 halt etwas ist, was halt dazu führt, dass man so Team Topologies 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-Architekturt-Thema.
Nicht so sehr ein Thema von den Team zuständig, also von dem, was halt in Team Topologies drin ist.
Natürlich fordert Team Topologies, 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 gibt eben, oder 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 Topologies.
Und die sagen ja auch selber, dass das eben auch etwas ist, was so mit dem Ranging Design verheiratet werden kann.
Ist halt ein leicht gewichtiger Ansatz, um erstmal irgendwas auf die Reihe zu bekommen.
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.
Also, sprich, ich habe da jetzt ein neues Ding, ich plane das neue Ding, tut dieses und jenes.
Ich werde das jetzt gegen diese Kriterien halten und kriege dadurch halt eine Idee, ob das halt 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, glaube ich, daraus dadurch auch, oder ich kriege dadurch halt 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 eben Herausforderungen sind.
Also zum Beispiel ein Beispiel, was halt in dem Talk war, war, dass es dort eben ein Team gab, was halt nach Feature bezahlt wird.
Also wo irgendwie gesagt wird, okay, wir haben halt die Teams, die halt sozusagen die wirklichen Systeme bauen.
Und dann gibt es ein Team, was halt etwas zuliefert und die werden halt nur bezahlt, wenn sie etwas zuliefern können oder sollen.
Was halt bedeutet, sie haben halt eben keine Roadmap.
Also sie können jetzt nicht sagen, wir bauen das jetzt ein, sondern dass diese Entscheidung treffen, die anderen halt für sie und kaufen das sozusagen bei denen.
Und dann gibt es da halt irgendwie keine Vision.
Und dann müsste man eben dort schauen, wie man das halt 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 halt irgendwie eine Roadmap definieren kann.
Vielleicht ist das sogar sinnvoller, weil nicht halt ein Ding, was halt irgendwie nur anhand von anderer Leute Entscheidungen und Feature halt weitergebaut wird, ist vielleicht etwas, was so, also das ist 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, weil man ja diese Maßstäbe halt anlegt.
Ein Punkt, den ich nochmal loswerden wollte, ist, das war ja auch schon ein Thema bei der Episode mit dem Eduardo, also 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 zu der 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.
Es hat ja sogar Auswirkungen auf die Geschäftsstrategie.
Also, wenn ich jetzt irgendwie sage, okay, dieses Ding, also ich komme jetzt durch eine Diskussion darauf, dass halt diese Arbeitszeiterfassung, die ich halt im Rahmen der Fahrradreparatur bauen will, dass das halt ein eigenes Produkt sein könnte oder sollte, dann muss ich halt daraus ein eigenes Produkt machen.
Das hat irgendwie Konsequenzen bei Jenseits von Software-Architektur.
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 halt beeinflusst.
Und ich glaube, also wir hatten ja auch den Nick Tune hier mit seiner Software-Architekturmoderisation und ich habe auch eine Episode gemacht, wo ich über seine Paper diskutiert habe.
Und das in den Dingen verschwimmt halt die Grenze zwischen Business-Geschichte und Software-Architekturgeschichten.
Und das ist hier, glaube ich, irgendwie wieder ein ähnliches Thema.
Das ist ja auch der Grund, weswegen wir eben bei Swag Lab da breit aufgestellt sind und eben in beiden Bereichen halt beraten können.
Weil eben nicht Software-Architektur eine sozusagen Business Sinn macht, halt irgendwie kein Sinn.
Genau.
Ja.
Ich mein persönliches Fazit über die ganze Geschichte ist eigentlich.
Also, also ich finde es gut, dass diese Sachen halt dort ein Ding genannt werden und das nicht konkretisiert wird.
Dadurch und ich, also es ist 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 halt Teams und Komponenten beides irgendwie betrachtet wird, Softwarechitektur und Teams und dass Businessgründe da drin sind und ich glaube oder es ist erkennbar, dass das halt eine weitere Ergänzung zu sozusagen 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 bauen und Kontext oder Module, so wie ich ja in der Einladung sagte, das ist halt ein fundamentales Problem, dass hier ist ein weiteres Werkzeug, was man dafür nutzen kann.
Gut finde ich daran, dass es eben klare Business-Zuständigkeiten für Services halt definiert.
Das ist etwas, was sonst manchmal sozusagen unangenehm wird.
Also, ich nämlich halt die eine Geschichte während der Corona-Pandemie, wo ich halt einen Kunden hatte und der Kunde hatte halt im Prinzip ein Ding, was halt Produkte zum Kunden schicken kann, beziehungsweise 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 irgendwie bei Corona doof, weil wenn die Filialen irgendwie zu sind oder sich die Menschen halt nicht in die Filialen wagen, dann wäre es halt ganz gut, wenn man halt 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 irgendwie anbieten können?
Naja, ist eigentlich ein Logistikthema.
Und dann kriegt man, glaube ich, eher so eine Diskussion in diese Richtung, die das halt irgendwie nochmal klarer macht und irgendwie nicht solche Probleme vielleicht vermeiden würde.
Das startet sich eine Diskussion.
Also, wenn wir jetzt diese zwei zitierten fachlichen Dinge bauen würden und ich würde da halt irgendwie drin sitzen, als Techniker kann ich mir sofort vorstellen, wie die Diskussion mit den Domain-Expertinnen und den anderen Menschen halt irgendwie aussieht und es, die halt irgendwie total spannend ist, wenn ich was dabei lerne.
Und das ist ein Ansatz, der auf einer Ebene von Modularisierung ansetzt, eben auf dieser grobgranularen Ebene, wie es auch Born- und Kontext zu tun, wo Modularisierung besonders relevant ist.
Das heißt, das löst ein Problem in einer Ebene, die halt 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 das sehr, 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 grob granulare Services.
Das geht halt nicht innerhalb eines Service.
Also eine Modal, wenn ich jetzt mich also hinstelle und sage, okay, ich habe jetzt irgendwie die Buchsuche, muss ich ja innerhalb der Buchsuche das weiter unterteilen, bis sie halt immer zu Klassen und Methoden komme.
Vielleicht habe ich da irgendwie individuelle Packages noch.
Da spielt Technik vielleicht eine Rolle.
Vielleicht habe ich halt eben Packages oder bestimmte Teile des Kurs, die halt mit der Datenbank interagieren, bestimmte Teile des Kurs mit der UI interagieren.
Das muss ich also weiter dann noch ausdifferenzieren und da weitere Module bilden.
Vielleicht habe ich da ja auch weitere fachliche Sachen.
Weiß ich nicht, irgendein 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 ich das eher ein technisches Problem ist oder ein technisches Problem löst.
Dann ist halt die Frage, die ich mir halt stelle, ich baue jetzt also ein grob granularen Service.
Ich stelle fest, der ist zum Beispiel aufgrund von irgendwelchen technischen Maßnahmen, weil der halt mit dieselben Datenbanken benutzt, dieselben Datenbanktabellen benutzt, halt, habe ich halt mindestens ein rotes Postit.
Ist das jetzt dennoch wert, es einen eigenen Service zu nennen?
Und ich würde halt behaupten, das ist vielleicht so.
Also, ich werde wahrscheinlich nicht immer nur grüne Post-its haben.
Und dadurch ist für mich ein bisschen die Frage, ob vielleicht so eine unrealistische Erwartungshaltung dafür hier erzeugt wird, was wie unabhängig ein Service denn eigentlich sein sollte.
Was ich versuche zu sagen ist, insbesondere, wenn ich halt vergurktes Legacy-System habe, hängt halt alles mit einem zusammen.
Und ich kann jetzt irgendwie die Frage stellen, weil das halt irgendwie so vergurkt ist, lohnt es sich jetzt Teams unterschiedliche Aufgaben zu geben.
Und dann ist irgendwie die Frage: Ja, was soll ich denn sonst machen?
Also irgendeine Struktur brauche ich halt.
Und ich kriege hier halt raus, das ist, glaube ich, der Vorteil, dass es halt transparent ist, dass ich halt in dem Teil Probleme habe.
Wenn ich also dort eben ein Legacy-System habe, werde ich halt ja rote Post-its 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.
Also ich brauche halt irgendwelche Indikatoren nicht, wenn mir jemand sagt, okay, hier sind halt meine Domänen.
So.
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 halt eine Vollkatastrophe oder das ist irgendwie toll.
Da bin ich mir nicht sicher, ob ich halt diese zehn Sachen durchieren 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 ein Workshop habe mit dieser gemischten Aufstellung, wo ich dann irgendwie diese Diskussion haben möchte, die halt dazu führt, dass wir halt 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 gut ist oder ein schlechtes Modul ist, ist es vielleicht ein bisschen viel.
Aber es hilft ja irgendwie auch sozusagen als Intuition und ist irgendwie etwas, woraus ich dann irgendwie 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.