Ist das jetzt irgendwie spannend? Also ist das eine relevante Architekturentscheidung? In Bezug auf die Qualitätsziele würde ich behaupten … … oder Qualitätsszenarien hat das keinen Einfluss. Also das eine wie das andere bekomme ich halt irgendwie genauso verfügbar. Es gibt vielleicht einen kleinen Einfluss, weil ich ja gerne wissen … … weil ja hier die Aussage ist, dass insbesondere der Preis einer folgenden Reparatur … … dass ich den wieder ermitteln kann. Das ist also besonders wichtig. Da habe ich hier den Vorteil, dass ich das irgendwie in irgendeinem dieser Container drin habe. Zum Beispiel in dem Bezahlungscontainer. Und jetzt könnte ich zum Beispiel sagen, der Bezahlungscontainer wird halt redundanter ausgelegt … … in einer höheren Menge an Redundanz als die anderen Container. Also da könnte ich versuchen, dieses Qualitätsziel zum Beispiel eher zu erreichen. Aber es ist jetzt nicht so, dass das hier diese Entscheidung wesentlich beeinflusst … … wie ich meine Qualitätsziele erreiche.

Das heißt also, ich versuche mir zu überlegen, kann ich anhand dieser Fachlichkeit irgendwie dieses System strukturieren und ich habe hier erst mal sowas wie, dass ich ein Fahrrad zur Reparatur anmelden will. Die Story nehme ich mir jetzt hier mal raus. Moment, ich muss mal kurz schauen. Genau, da habe ich tatsächlich eine Kopie gemacht. Und wenn ich das tue, so ist die Annahme, möchte ich eigentlich nur sagen, sowas wie, ich möchte gerne am 11.03. oder sagen wir mal, es ist eine längere Zeit hin, also am 18.03. eine Reparatur haben und mein Name ist Eberhard und irgendwie soll ein Fahrrad repariert werden. So, das wäre das, was ich hier hätte. Und daraus, wenn ich das halt irgendwie haben möchte, dann muss ich irgendwie dort auch, muss mal kurz schauen, den Reparaturtermin beispielsweise berechnen. Das heißt also, ich sage jetzt, ich will ein Fahrrad abgeben zur Reparatur und dann würde ich eben einen Reparaturtermin berechnen. Und was haben wir noch? Dann kann ich halt irgendwann dieses, genau, das ist sozusagen so ein bisschen Funktionalitäten, die so aus Kundenperspektive sind. Ich habe mir halt überlegt, dass ich versuche hier zu sagen, diese Sachen, die halt irgendwie oben sind, das sind so die Dinge, die halt sozusagen aus Kundenperspektive da passieren. Und jetzt kommt auf der anderen Seite, ist es jetzt so, dass wir, ja, was haben wir hier eigentlich? Ich würde behaupten, wir haben hier sowas wie eine Terminplanung. Das heißt, es geht darum zu sagen, wann ich diese Fahrräder halt eigentlich repariere. Und da habe ich letztendlich einen großen Kalender. Und diesen Teil des Systems könnte ich vielleicht sogar für meine Arbeit auch benutzen. Also ich mache ja bestimmte Dinge, ich bereite diesen Stream vor, ich berate irgendwelche Leute und ich könnte jetzt irgendwie sagen, okay, ich habe ja diese Themen. Wann fange ich an, daran zu arbeiten und wann komme ich voraussichtlich dazu, irgendein Thema zu bearbeiten? Das heißt also, dass wir hier Fahrräder haben, ist vielleicht gar nicht so wichtig. Es geht nur darum, Arbeit zu strukturieren. Und was mir so aus Sicht des Fahrradmechanikers halt dort irgendwie relevant ist, genau, den hatte ich jetzt hier sozusagen unten geplant, der würde jetzt tatsächlich sagen, okay, ich bekomme hier so einen Reparaturplan, den ich mit diesem System erstelle. Das heißt, ich sehe halt, okay, eingeplant für den am 18 ist das Fahrrad von dem Eberhardt und noch diverse andere Fahrräder. Und das wäre jetzt dieser tägliche Reparaturplan, den der sich halt überlegt. Und er würde dann halt irgendwie auch sagen, okay, ich möchte die nächste Reparatur beginnen. Also eben irgendwelche Themen, die hier eingeplant sind, auch tatsächlich umsetzen. Und ich möchte, was möchte ich denn noch? Das war es eigentlich. Genau. Dann haben wir hier so etwas, wo ich halt sage, ich möchte den Fahrrad-Defekt aufnehmen. Das heißt also, in meinem Beispiel wäre es jetzt so, dass ich sagen würde, okay, an dem Fahrrad ist die Schaltung defekt. Das würde ich jetzt dort irgendwie aufnehmen. Und also voraussichtliche Kosten berechnen. Lass uns das mal mit aufnehmen. Vielleicht ist das gar nicht schlecht. Das ist eigentlich tatsächlich ein Punkt. Fahrrad-Defekt aufnehmen. Etwas, was eher jemand macht, der so Fahrradmechaniker oder Shop-Mitarbeiter ist. Das heißt, da würde jetzt irgendwie rauskommen, okay, das hat halt einen Schaltungs-Defekt. Und das ist übrigens auch erst die Stelle, wo ich jetzt sowas wie ein, das hatte der Jan gerade gesagt, die voraussichtlichen Kosten tatsächlich berechnen könnte. Also das wäre jetzt die Stelle, wo ich sage, okay, cool, du hast eine Schaltung. Welche Art von Schaltung ist denn das? Das ist so eine Schaltung, weiß ich nicht, eine Campagnolo-Schaltung. Dann kostet das irgendwie 200 Euro, das Schaltwerk alleine, das Schaltwerk. Und dann kostet es halt irgendwie 20 Euro, das damit tatsächlich anzumontieren. Das wären also Sachen, die ich hier erst berechnen kann. Und hier wüsste ich halt andere Dinge. Hier wüsste ich zum Beispiel, dass es eben um eine Reparatur geht und dass die Schaltung kaputt ist. Und dann könnte ich hier auch noch solche Sachen machen, wie dass ich die Reparatur protokolliere. Hier könnten wir jetzt also anfangen. Also Reparaturprotokoll wäre jetzt genau so. Reparaturprotokoll, da gehört irgendwie genauso was drin, wie ich habe ein neues Schaltwerk gekauft. Ich habe das alte Schaltwerk ausgebaut. Das hat zehn Minuten gedauert und kostet halt deswegen zehn Euro. Ich habe ein neues Schaltwerk eingebaut, hat irgendwie auch zehn Minuten gedauert und hat zehn Euro gekostet. Und ich habe mir angeguckt, die Bremsklötze waren halt auch irgendwie hin. Und deswegen habe ich gleich neue Bremsklötze eingebaut und die haben 25 Euro gekostet. Und die habe ich halt auch eingebaut. Das ist halt so ein bisschen die Annahme. Ich gucke mir das Fahrrad an und schaue nochmal nach, ob bestimmte sicherheitsrelevante Themen auch noch gemacht werden müssen. Das heißt, wir haben jetzt eigentlich hier mehr gemacht, als ursprünglich geplant war. Und die Annahme ist, dass wir das halt einfach sozusagen getan haben. Das heißt, das wäre so ein bisschen so eine…​ Ich mache jetzt mal eine Legende dazu. Das hier wären so Daten, die wir da halt hätten. Und das hier wäre so der Modulname, sage ich jetzt mal. Und ich habe jetzt diesem Ding den Namen Reparatur durchführen gegeben. So, und jetzt ist halt die Frage, die der Theo Grip gerade gestellt hat, ist, was ist mit der Anmeldung der Reparatur durch den Status der Reparatur. Genau, das ist eine…​ also könnten wir jetzt hier hin tun, nicht? Das heißt, wir könnten jetzt sagen, die Reparatur ist geplant für den 18.3. Und wenn sich jetzt hier eine Änderung ergibt, weil halt irgendein hoch priorisiertes Ding reinkommt oder weil halt ein Mechaniker rauskommt, ausfällt oder sonst, oder eine Mechanikerin, dann könnte ich halt hier das sozusagen ermitteln. Aber vielleicht will ich ja auch etwas wissen darüber, wie die Reparatur durchgeführt wird gerade. Nicht? Also das heißt, was ich mir jetzt wünschen, vielleicht wünschen würde, wäre, ich gucke mir als Kunde das halt irgendwie an und ich sehe, entweder die Reparatur ist eingeplant für den 18.3. oder am 18.3. steht halt drin, wir haben übrigens jetzt deine Schaltung repariert und außerdem deine Bremsklötze und das kostet halt so und so viel Geld. Oder aber wir haben irgendwie die Schaltung erstmal nur bestellt. Solche Geschichten. Das sind Informationen, die wir jetzt hier drin haben. Und das ist jetzt für etwas…​ ich halte das für ein allgemeines Pattern sozusagen. Also das ist etwas, wo ich irgendwie in einer bestimmten Sicht Informationen habe, die ich jetzt hier irgendwie sozusagen erstmal aufgeteilt habe. Also hier ist es halt so, dass ich sage, es geht eigentlich nur um den Termin und wann ich es machen möchte. Und hier haben wir jetzt eben so etwas, wie wir in die Reparatur reingucken und schauen, was tatsächlich passiert ist. Und das hier liegt jetzt so ein bisschen quer. Und ich glaube, darauf gibt es zwei mögliche Antworten. Die eine Antwort wäre, dass man diese Funktionalität gemeinsam in diesen beiden Modulen umsetzt. Das heißt also, hier kriege ich einen Status raus, der halt irgendwie sagt, ist am 18.3. eingeplant. Und hier kriege ich einen Status raus, der halt sagt, wir haben übrigens die Schaltung jetzt ausgewechselt und irgendwelche Dinge halt getan. Aber bedauerlicherweise ist es halt so, dass die Bremsklöpse noch nicht da sind. Die müssten aber eigentlich noch eingebaut werden und deswegen dauert das noch. So, das wäre eine Möglichkeit. Und jetzt will ich ja so etwas irgendwie gemeinsam anzeigen. Also ich will eine Webseite haben, wo ich den Status der Reparatur sehen kann auf einer Seite. Und hier sind aber zwei Module. Wie gehe ich damit um? Erstmal, ich glaube, diese fachliche Aufteilung ist trotzdem sinnvoll, weil wir dadurch den Vorteil haben, dass oder weil ich denke, dass wir hier zwei unterschiedliche Informationsdichten sozusagen haben und wir hier diese Sachen eben fachlich aufteilen können. Und ein bisschen geht das in diese Richtung von bauenden Kontexten, wo ich eben sage, ich habe ein Domainmodell, was eine bestimmte Funktionalität erreicht und ich erwarte, dass ich in diesen Domainmodellen identische Dinge habe, also Dinge, die gleich benannt sind, also die Reparatur, aber unterschiedliche Informationen, die damit einhergehen. Und ich habe halt in dem linken System jetzt die Reparatur eigentlich als Termin, was also nahezu, was eigentlich bedeutet, Arbeitsplanung, was ich also auch für mich als Ebert Wolf der Berater nutzen könnte. Und rechts habe ich jetzt irgendwie das Wissen, dass eine Reparatur bedeutet, dass ich Ersatzteile habe, dass ich die einbaue, dass es Zeit kostet und so weiter. Das ist also etwas, was wirklich für mich harnikerrelevant ist. Diese beiden Systeme jetzt zusammenzupacken macht, glaube ich, keinen Sinn. Das heißt, diese Teilung ist, glaube ich, sinnvoll. Eine Möglichkeit dafür zu sorgen, dass es halt trotzdem diese Webseite gibt, ist, indem man halt sagt, diese Webseite wird gemeinsam hergestellt von diesen beiden Systemen. Das heißt also, das erste System würde halt oben sagen, die Reparatur ist am 18.03. angefangen worden. Und dann würde der untere Teil, würde halt der rechte Teil mit der Durchführung sagen. Und wir haben halt übrigens folgende Dinge gemacht. Das wäre eine Möglichkeit, dass man das sozusagen so kollaborativ darstellt. Die andere Möglichkeit wäre, dass man irgendwie sowas sagt wie, es gibt den, also wir haben hier ein neues System, das halt nur dazu da ist, den Status der Reparatur anzuzeigen. Und das ist also der Reparaturstatus. Tatsächlich fällt mir nicht an, wie ich den sonst benennen würde. Und der hat jetzt eben sozusagen die Benutzer-Sicht, die Kundensicht auf diese ganzen Geschichten. Das heißt, der kriegt jetzt von hier die Information über ein Datum. Der kriegt von hier die Information darüber, was in dieser Reparatur drin ist. Und dann können wir, das wäre halt sozusagen eine Alternative. Ich finde das in diesem Fall nicht sonderlich sinnvoll. Ich finde die andere Idee besser. Ich glaube, die baue ich jetzt irgendwie auch nochmal ein. Also diese Idee, dass ich eben sage, der Status wird eben in beiden ermittelt. Dieser Ansatz wäre zum Beispiel ein Ansatz, den ich wählen würde, wenn ich so Statistiken haben möchte oder sowas. Also einen sehr begrenzten und auch sehr anderen Blick auf diese Sachen. Wenn ich zum Beispiel in der Statistik irgendwie sagen möchte, was für mir denn ein, wie viele Schaltungen habe ich irgendwie eingebaut? Da brauche ich ja nur irgendwie plus 1, plus 1, plus 1. Das heißt eine ganze Menge an Informationen. Also zum Beispiel, wie teuer war das? Wie lange hat es gedauert? Und so weiter. Das interessiert mich alles nicht. Und ich will das vor allem irgendwie summieren. Ich will irgendwie eben eine Statistik darüber machen. Das ist, glaube ich, eine deutlich getrennte Sicht von dem Reparaturstatus selber. Und das würde für mich ein neues Domänenmodell rechtfertigen. Also es geht ja darum, dass wir Domänenmodelle haben wollen, also unterschiedliche Modelle haben wollen. Und hier würde ich eben sagen, den Status abfragen. Dafür brauche ich halt exakt diese Informationen, die hier drin stehen. Vielleicht etwas weniger, weil ich nicht ausschließen will, dass hier in diesem Protokoll Dinge drin stehen, die jetzt eben nicht kundensichtbar sein sollen. Aber die sind so identisch, dass ich eben eher dazu neigen würde, das mit dort zu implementieren und eben nicht noch ein eigenes Modul dafür zu bauen. Also schmeißen wir das mal weg. Jan sagt jetzt noch, vielleicht können wir die Terminplanung auch einkaufen, Supporting Domain. Also wir brauchen auch noch…​ Sorry, da steht halt…​ Moment, ich muss mal kurz durch die Kommentare durchgehen. Voraussichtliche Kosten berechnen. Genau, das wäre halt etwas, was ich jetzt auch hier sehen würde. Haben wir das gesagt? Ja, haben wir gesagt. Genau, das muss halt auf dieser Ebene, das muss hier halt auf dieser detaillierteren Ebene betrachten. Gehört zur Anmeldung der Reparatur auch den Status der Reparatur abfragen? Das haben wir gerade diskutiert. Zum gleichen Modul. Wir brauchen also auch die Möglichkeit, den Kunden zu kontaktieren. Zum Beispiel Gepäckträger defekt, nicht sicherheitsrelevant. Kann natürlich offline zum Beispiel Telefon erfolgen. Genau, das wäre jetzt etwas, worüber ich tatsächlich nicht…​ Ah, guter Punkt. Wir brauchen also eine Möglichkeit, den Kunden zu kontaktieren. Ist das ein Problem, das ich hier in diesem IT-System abfrischtigen würde? Ich würde behaupten, nein. Also, was hier konkret passiert, ist Folgendes. Der Mechaniker sitzt an dem Fahrrad, stellt fest, die Bremsklötze sind völlig unten. Wenn ich den jetzt irgendwie losschicke mit diesem Fahrrad, dann ist die Person halt nicht sicher. Ich will also die Bremsklötze austauschen. Nimmt das Telefon und guckt jetzt in diesem System nur die Kundeninformationen nach und ruft eben an und sagt, hey, haben wir übrigens. Das kann ich noch protokollieren. Ich könnte jetzt protokollieren, wenn ich das will, Kunde informiert. Man könnte sagen, das waren 0 Euro, weil das gehört mit zum Service oder vielleicht berechne ich es auch. Keine Ahnung. Insofern könnte das da drin sein, aber ich bin nicht sicher, ob das tatsächlich eine Funktionalität ist, weil der wesentliche Akt, nämlich dass ich das Telefon genommen habe und die Person angerufen habe, die ist ja gerade außerhalb des IT-Systems. Deswegen bin ich mir nicht sicher, ob das so richtig mit dazu gehört. Vielleicht können wir die Terminplanung auch einkaufen. Das führt zu einer wichtigen allgemeinen Geschichte. Das will ich nicht ausschließen. Das ist aber ehrlich gesagt eine Sache, wo ich festgestellt habe, dass ich persönlich so ein bisschen blind bin. Ich bin nämlich Software-Architekt. Das heißt, ich bin darauf spezialisiert, Software zu bauen. Ich finde es gut, wenn man Software nicht baut, sondern sie einkauft. Ich kann das aber nicht ernsthaft bewerten. Das heißt, das wäre etwas, wo ich andere Personen sehen würde. Vielleicht an der Stelle noch ein Hinweis. Da ist jetzt die Verwendung von diesem Begriff Supporting Domain. Das ist etwas aus Domain-Driven Design. Da gibt es eben diese Aufteilung in im Wesentlichen Generic Subdomains, Supporting Domains und Core Domains. Core Domains sind die, die mich im Geschäft differenzieren. Wenn ich die gut implementiere, dass sie dann einen Geschäftsvorteil generieren. Supporting sind die, die ich implementieren muss, um die anderen zu unterstützen. Und Generic sind die, die tatsächlich generisch sind, die für den Geschäftserfolg egal sind. Dazu würde bedeuten, dass wenn ich einkaufe, die Terminplanung eine Generic Subdomain wäre. Aus meiner Wahrnehmung heraus und aus meiner Interpretation der Begriffe. Ich finde es wichtig, die Begriffe sauber zu benutzen. Deswegen wollte ich darauf noch mal hinweisen. Das wäre vielleicht eine Option. Kann ich nicht beurteilen, müsste man sich angucken. Ich habe tatsächlich Überraschungen erlebt, was es so an spezialisierten Modulen gibt. Also auch im Bereich von Geschäftslösungen. Von daher ein guter Punkt. Aber an irgendeiner Stelle wird das sowieso alles absurd, weil wahrscheinlich gibt es eine vorgefertigte Lösung für Fahrradläden. Nehme ich mal an und Reparaturplanung. Von daher ist das sowieso die Frage, was wir uns hier geben wollen. Und vielleicht noch eine Bemerkung zum Thema Core Domain. Wie wird dieses System erfolgreich? Also eine mögliche Antwort wäre, indem wir in der Core Domain besonders gut davor sind. Was ist denn unsere Core Domain? Also Terminplanung, Reparatur durchführen? Weiß ich nicht. Ich finde dieses Beispiel, ich habe das nicht danach ausgewählt, aber ich finde dieses Beispiel ganz spannend, weil wenn man mich jetzt fragt, wie kriegen wir dieses System zum Erfolg? Dann würde ich sagen, ich kriege dieses System zum Erfolg, indem es halt besonders benutzerfreundlich ist. Weil dann finden die Benutzer das irgendwie super. Und ich habe beim letzten Mal gesagt, daraus kann nämlich auch so eine Soft-Versus-Service-Lösung werden. Dann können wir also ein Soft-Versus-Service machen. Dann können wir sagen, guck mal hier, in meinem Fahrradladen, die Leute sind alle super zufrieden damit, das wirst du bestimmt auch kaufen. Und dann haben wir einen Erfolg. Ich würde behaupten, das ist ein bisschen unabhängig von den Core Domains. Also ich würde hier behaupten, aber ich habe das System sozusagen in meinem Kopf nicht vollständig durchspezifiziert oder nicht vollständig durchdacht. Ich würde halt hier behaupten, dass uns diese Idee von sowas wie Core Domains oder Generic Subdomains, um halt zu sehen, dass wir dieses Projekt erfolgreich aus der Tür bekommen, nicht der Schlüssel ist. Sondern das, was wir dann hoffentlich von Aminata mitbekommen, das wird uns halt helfen, dieses System wirklich erfolgreich zu machen. Aus unserem Architekturenwurf kommen die Anforderungen an die eventuell einzugreifenden Produkte. Vielleicht gibt es diese ja nicht, sagt Jan gerade. Ja, also es steht glaube ich außer Frage, dass man eine Terminplanung kaufen kann. Und dann kann ich halt möglicherweise an einigen Stellen Kompromisse eingehen. Also von daher, ich glaube, das ist genau ein Teil von diesem Generic Subdomain Graffel, dass ich eben an der Stelle sage, ich will eben gerade nicht diese hochspezialisierte Exakt für mich passende Lösung haben, sondern ich will etwas haben, was ungefähr passt. Und wenn es nicht genau passt, ist es halt auffallend. Und bei der Terminplanung, vielleicht ist das halt tatsächlich ausreichend. Also kann ich mir sehr gut vorstellen. Und dann würge ich das halt irgendwie in den Rest des Systems rein. Könnte sinnvoll sein. Also ist ja auch etwas, was so ein bisschen üblich ist. Wir haben ja die, wie soll ich das jetzt sagen, die viele von den Standards Software Produkten, die man benutzt, gerade im ERP-Bereich sind halt so, wie sie sind. Und die sind da eben gerade nicht so, dass man sie anpassen wollen würde, beziehungsweise da wird es dann halt leicht teuer dafür zu Projekte abbrechen. So, zurück zu unserer weiteren Aufteilung. Wir haben jetzt hier noch Reparatur bezahlen und da würde ich halt sagen, da geht es tatsächlich nur darum einen Betrag zu bezahlen und das würde ich jetzt mal sagen ist was eigenes. Also da sage ich jetzt okay, das mache ich irgendwie und das passt irgendwie nicht zu dem was wir hier haben. Da habe ich zwar die ganzen Preise, aber ich würde es halt glaube ich tendenziell trennen. Ich kann hier irgendwie so ein Ding, wo ich als Datum eigentlich eben tatsächlich nur noch einen Geldbetrag habe. Also ich sage halt, ich bezahle jetzt 10 Euro und dann hat sich das halt. Also hier ist es glaube ich deutlich teurer, hier sind es irgendwie 150 Euro oder so. Aber ich habe hier keine Informationen mehr über die Reparatur an der Stelle und deswegen kann das eben ein sozusagen rundes, also bei mir ja eckig, aber ein rundes neues Modul sein. Und dann habe ich hier das Einplanen von der Reparatur. Das wäre auch wieder etwas in der Terminplanung und dann würde ich hier eben den Kunden über das Ende der Reparatur informieren. Das würde ich hier sehen bei der Reparatur durchführen, weil ich eben an dieser Stelle jetzt irgendwie sage, okay, alle die Sachen, die wir halt haben möchten, die sind halt jetzt erfüllt. Jan merkt gerade an, wir wollten noch die Buchhaltung und die Kasse anbinden. Genau, das wäre jetzt der nächste Schritt. Also die dritte Systeme, die haben wir anzubinden, ist noch ein Thema. Dann habe ich hier noch Fahrrad zur Reparatur abgeben. Das würde ich hiermit sehen, weil ich jetzt eben genau an der Stelle bin, wo ich sozusagen, wo das aus dem Termin eine Reparatur wird, so ein bisschen. Und dann habe ich hier noch Ersatzteile bestellen und Werkzeuge bestellen. Und da muss man ein bisschen Platz schaffen. Da wäre halt meine Aussage, dass das vielleicht auch was Eigenes ist. Und zwar eben die Materialbeschaffung, die jetzt sowas kennt wie eine Bestellung von Bestellung bei einem Großhändler. So, das wäre jetzt also so eine grobe fachliche Aufteilung. Und genau, ich habe hier, also repariertes Fahrrad abholen, wäre dann eben auch etwas, was ich hier bei diesem Reparatur-Ding irgendwie sehen würde. So, so würde also mein System aussehen.

Nach 30 Minuten soll das System wieder zur Verfügung stehen. Und wenn ich jetzt irgendwie sage, okay, ich habe einen Server untergestellt bei dieser Fahrrad-Reparatur-Werkstatt. Ich schaffe es nicht innerhalb von 30 Minuten vor Ort zu sein und dafür zu sorgen, dass das System wieder funktioniert. Das glaube ich nicht. Das heißt, das können wir eigentlich schon mal irgendwie ausschließen.

Das ist wahrscheinlich teurer. Und zum anderen bin ich mir nicht sicher, ob das wirklich eine höhere Verfügbarkeit erzeugt. Ich könnte halt beim Fahrradhändler einen Server hinstellen. Glaube ich auch nicht, dass es halt eine bessere Verfügbarkeit bringt.

So, da steht halt drin, dass man halt anschließend eine Gutschrift bekommt. Das heißt also, die Zeit, die das System als ausgefallen gilt, wird nicht abgerechnet. Mit anderen Worten, also die Hoffnung wäre ja, dass dieses System mehr Wert generiert, als es im Betrieb kostet. Sonst macht das, was wir hier gerade tun, ökonomisch keinen Sinn. Das heißt also, ein Ausfall dieses Systems wird trotzdem einen ökonomischen Schaden erzeugen. So, da sind wir wieder bei diesen…​ Also, das ist eine ähnliche Diskussion, wie die Diskussion, die wir vorhin hatten, auf Basis der Rückfrage von dem guten Jan. Also, da war ja auch das Ergebnis, wir können halt jetzt mehr Geld investieren und mehr Geld in die Hand nehmen, um dafür zu sorgen, dass wir dort dazu in der Lage sind, mit höherer Wahrscheinlichkeit eine Ausfallsicherheit zu erzeugen. Und hier ist das jetzt was Ähnliches. Also, was das hier eigentlich bedeutet, ist, wenn Amazon morgen den…​ Also, nicht wenn EU West 1, die gesamte Region, aus irgendwelchen Gründen nicht mehr existiert, weil halt in Frankfurt eine große Katastrophe ist, ein großes Feuer und da ist halt irgendwie nichts mehr, dann würde das eben bedeuten, dass wir halt eine Dienstgutschrift haben und wir würden sinnvollerweise auf eine Region irgendwie ausweichen. Aber wir hätten halt dort trotzdem einen Ausfall. Das heißt, wir können das, was hier steht, eigentlich nicht wirklich garantieren. Aber ich würde sagen, es ist hinreichend unwahrscheinlich. Also, ich hätte jetzt kein Problem damit, zu sagen, wir gehen mit so einer Lösung in Produktion, weil meine Vermutung wäre, dass, wenn das System ausfällt, mehr ausfällt, als wir hier sagen oder als wir hier zusagen, dass das halt nicht ernsthaft ein wirkliches Problem ist und dass es halt hinreichend unwahrscheinlich ist. Jan fragt gerade über Datensynchronisation.

Das heißt, das kriegt man halt auch irgendwie hin. Und was ich jetzt hier identifiziert habe als ein Thema, ist … … ich hätte hier eine Kommunikation aus der Cloud hin zu der Kasse, die bei mir im Laden steht. Und da wäre halt … ich benutze mal irgendwie gelb … … eine Frage, kann man aus der Cloud in das Rechnungswesen kommunizieren? Und die analoge Frage wäre jetzt bei der Kasse. Also da wäre halt dieselbe Frage, kann man aus der Cloud in die Kasse kommunizieren? Und ich will das gar nicht ausschließen. Also was ich ja konkret machen müsste, wäre … … der Mensch sitzt halt an meinem System, sagt, diese Rechnung, das Ding will ich jetzt irgendwie gerne bezahlen. Und daraufhin gibt es eine Kommunikation hin zur Kasse, die sagt, ich möchte jetzt gerne das 20 Euro kassiert werden … … und die das halt irgendwie auch vernünftig in die Buchhaltung bekommt und so weiter und so weiter. Und dazu müsste ich halt mit diesem Kassensystem reden, aus der Cloud. Und vielleicht ist das möglich. Also das wäre jetzt die Stelle, wo man es halt recherchieren müsste. Kassensysteme sind heutzutage im Prinzip auch PCs, sodass ich das nicht ausschließen möchte, dass das geht. Aber das wäre etwas, was wir diskutieren müssten. Und das ist jetzt tatsächlich etwas, was wir sozusagen gelernt haben. Also was ich persönlich auch bei der Vorbereitung gelernt habe, als ich eben dieses Diagramm ausgeführt habe. Das heißt, das hat mir jetzt tatsächlich etwas geholfen. Also ich habe jetzt herausgefunden, dass ich hier potenziell etwas habe, was mir meinen Ansatz kaputt machen kann. Und das ist, glaube ich, die spannendere Sache. Die würde jetzt hier unten an der Luke gelten. Also, Moment. Jetzt habe ich bedauerlicherweise die Bausteine sich dafür torpediert. Also das wäre hier eben bei dem Microservices genau das selbe Thema. Da müsste ich also exakt dieselbe Frage beantworten. Das heißt, ich kann diese beiden Post-its da auch mal rüber kopieren, weil das wäre hier auch ein Thema. Das heißt, ich habe jetzt ein Risiko identifiziert und das ist auf jeden Fall hilfreich. Das kann mir im Extremfall die Lösungsstrategie zerstören. Ich kann nicht mit der Kasse kommunizieren. Ich kann nicht mit dem Rechnungswesen kommunizieren. Dann habe ich halt irgendwie ein Problem und da muss ich vielleicht doch ein Server installieren. Oder irgendwas auf dem Kassensystem machen oder was auch immer. Das ist dann eben das, womit ich mich da beschäftigen muss.

Ist das jetzt irgendwie spannend? Also ist das eine relevante Architekturentscheidung? In Bezug auf die Qualitätsziele würde ich behaupten … … oder Qualitätsszenarien hat das keinen Einfluss. Also das eine wie das andere bekomme ich halt irgendwie genauso verfügbar. Es gibt vielleicht einen kleinen Einfluss, weil ich ja gerne wissen … … weil ja hier die Aussage ist, dass insbesondere der Preis einer folgenden Reparatur … … dass ich den wieder ermitteln kann. Das ist also besonders wichtig. Da habe ich hier den Vorteil, dass ich das irgendwie in irgendeinem dieser Container drin habe. Zum Beispiel in dem Bezahlungscontainer. Und jetzt könnte ich zum Beispiel sagen, der Bezahlungscontainer wird halt redundanter ausgelegt … … in einer höheren Menge an Redundanz als die anderen Container. Also da könnte ich versuchen, dieses Qualitätsziel zum Beispiel eher zu erreichen. Aber es ist jetzt nicht so, dass das hier diese Entscheidung wesentlich beeinflusst … … wie ich meine Qualitätsziele erreiche.

Dadurch hätte ich jetzt einen leichten Vorteil in Bezug auf die Verfügbarkeit bei der Bezahlung. Aber das hilft mir nichts bei dem Wiederanlauf, was ja eigentlich das wesentliche Kriterium ist an der Stelle. Also ich will ja eigentlich den Wiederanlauf verbessern. Und dafür hilft diese Redundanz nicht, hilft ja nur gegen Ausfallsicherheit.