Der nachfolgende Text wurden mit KI erstellt und kann Fehler enthalten. Fehler gefunden? Bei GitHub editieren
Dann herzlich willkommen zu einer weiteren Episode von Software-Architektur im Stream.
Heute will ich mal was anderes zeigen, und zwar wie man eigentlich überhaupt so eine Softwarearchitektur bauen kann.
Das ist also heute so ein bisschen Thema, ein bisschen eine Zusammenfassung von dem, was wir, glaube ich, schon an vielen Stellen im Stream diskutiert haben, aber ich glaube, dass es da noch ein paar ganz interessante weitere Aspekte gibt.
Organisatorisch zum Überblick: Wir werden nächste Woche hier im Livestream keine Episode haben.
Ich bin dort dabei und kümmere mich um einen Kunden.
Was wir aber machen werden, ist, dass wir eine weitere Episode von Softwarearchitektur als Beruf live stellen werden, und da gibt es halt auch schon weitere Episoden, die sozusagen geplant sind, und das ist sozusagen so ein bisschen das, was da auf uns zukommt.
So, wir wollen also eine Softwarearchitektur erstellen.
Ich habe erst überlegt, die iSAQB-Standard-, die iSAQB-Beispielaufgabe zu nehmen und die zu lösen, habe mich dann aber dagegen entschieden und habe mir ein anderes Beispiel überlegt.
Bedeutet aber nicht, dass wir nicht irgendwann mal auch diese Beispielaufgabe vom iSAQB lösen wollen würden.
Und jetzt ist natürlich die Frage: Was nehme ich als Input an?
Und dazu habe ich mir überlegt, nehme ich mal an, dass mir irgendjemand so ein bisschen, so so ein paar fachliche Sachen schon mal zur Verfügung gestellt hat.
Also das, was ich hier jetzt habe, könnte halt ein mehr oder weniger gut strukturiertes Backlog sein, in dem irgendwelche Sachen stehen, die zu implementieren sind.
Also sprich, wir haben jetzt einen fachlichen Überblick über die ganze Geschichte.
So, und worum es halt grob geht, ist: Wir wollen ein System bauen, das uns dabei hilft, in einem Fahrradladen Fahrradreparaturen zu erledigen.
Und dieses Backlog, oder wie auch immer man es halt nennen will, ist nicht so richtig stark strukturiert, aber hier sind so verschiedene Rollen, und wir fangen hier an mit dem Kunden.
Ich werde übrigens das, das ist Miro-Board, ich werde das Miro-Board irgendwie auch nochmal als PDF exportieren und dann zum Download anbieten.
Also es gibt den Kunden und, ja genau, Jan fragt gerade: iSAQB BigSpender.
Genau, das ist die Beispielaufgabe, die es halt beim iSAQB zum Runterladen gibt und wie gesagt.
So, also wir haben hier erst mal die Aufgabe, also wir haben die Aufgabe, ein System zu bauen, was einen Fahrradladen dabei unterstützen soll, Fahrräder zu reparieren zu lassen.
Und wir haben jetzt hier so verschiedene Perspektiven und Nutzer oder vielleicht, wenn man auch Personas das nennt.
Also wir haben zum einen den Kunden und der Kunde will halt ein Fahrrad zur Reparatur anmelden.
Und das, was uns jetzt der Auftraggeber gesagt hat, ist, dass das halt zum Beispiel online passieren kann oder auch Ja, indem die Person in den Shop kommt und das halt direkt dort irgendwie anmeldet.
Dann ist es so, dass das Fahrrad zur Reparatur abgegeben wird.
Da ist jetzt der Shop-Mitarbeiter oder die Shop-Mitarbeiterin, die ist halt, eigentlich ist das etwas, was der Kunde, die Kundin, die Shop-Mitarbeiterin und der Mensch hier, der Fahrradmechaniker, was die irgendwie zusammen tun.
Also da wird jetzt irgendwie gesagt, hey, an meinem Fahrrad ist die Schaltung kaputt, das muss irgendwie repariert werden.
Und das wird irgendwie die Kundin, die Shop-Mitarbeiterin sagen oder der Fahrradmechanikerin, je nachdem, wer sozusagen gerade da ist.
Das heißt, da existiert dann so ein Ding, wo irgendwie drinsteht, okay, Schaltung ist kaputt oder sowas.
Wenn die Kundin das Fahrrad abgeben will, wird ein Reparaturtermin berechnet.
Also das ist ja so eine typische Frage: Hey, ich will halt mein Fahrrad vorbeibringen, könnt ihr irgendwie sagen, wann es voraussichtlich fertig ist?
Ja, dauert 14 Tage.
Das ist das, was dahinter steckt.
Wenn dann das Fahrrad abgegeben worden ist, dann möchte ich gerne den Status der Reparatur abfragen.
Fahrrad ist noch nicht repariert, wir haben die Reparatur angefangen und es gibt dann noch ein paar weitere Sachen, die ergeben sich dann, sehen wir gleich in der Kollaboration mit der Fahrradmechanikerin.
Und dann will ich halt das reparierte Fahrrad abholen.
Wenn ich das reparierte Fahrrad abhole, will ich das Ding auch bezahlen.
Das ist etwas, was typischerweise eine Shop-Mitarbeiterin macht oder auch eine Fahrradmechanikerin oder das kann ich auch sonst online machen.
Das ist also dann noch eine weitere Möglichkeit.
Und dann haben wir halt die Fahrradmechanikerin.
Die wird den Kunden über das Ende der Reparatur informieren, also wird sagen: Fahrrad jetzt irgendwie fertig.
Diesem Fahrrad defekt aufnehmen, also feststellen, Anderschaltung ist jetzt folgendes kaputt und außerdem sind mir vielleicht noch folgende weitere Dinge eingefallen.
Wird die Reparatur irgendwann einplanen und so einen Reparaturplan erstellen.
Das ist das, was die Person macht, wenn sie halt morgens in den Fahrradladen kommt, dann sagt sie halt: Hey, was mache ich denn eigentlich heute?
Und das ist so der tägliche Reparaturplan.
Vielleicht sollte ich hier auch schreiben: der tägliche Reparaturplan.
Und dann irgendwann beginnt diese Person mit der nächsten Reparatur.
Das heißt also, nimmt sich das Fahrrad, guckt nochmal nach: Ah, Schaltung ist kaputt, alles klar.
Das ist also das, was ich jetzt hier reparieren muss, und protokolliert dann die Reparatur.
Das heißt also, ich habe die alte Schaltung rausgebaut, ich habe eine neue Schaltung eingebaut, die Schaltung kostet fünf Euro, meine Arbeitszeit kostet irgendwie zehn Euro und ich habe im Übrigen gemerkt, dass auch was mit den Pedalen nicht in Ordnung ist, habe die irgendwie auch ausgetauscht, Pedalen kosten so und so viel, dass man also anschließend eigentlich mit dem Ziel, die Arbeitszeit zu erfassen, damit die abgerechnet werden können, und die Ersatzteile zu erfassen, damit die abgerechnet werden können.
Ersatzteile muss ich möglicherweise bestellen.
Oh, die Schaltung haben wir nicht auf Lager, muss ich bestellen.
Und ich hatte tatsächlich einen Fall, wo ich mein Fahrrad abgegeben habe und die mussten halt ein Werkzeug bestellen.
Das wäre also diese weitere Sache.
So, das ist das System, was wir also vorhaben im grobgranularen fachlichen Durchlauf.
Geht hier jetzt nicht darum, dieses System fachlich detailliert zu verstehen.
Und wir haben jetzt hier diese drei Rollen mit ihren jeweiligen Verantwortlichkeiten.
Und jetzt ist halt die Frage: Ja, was tun?
Was ist jetzt der erste Schritt?
Ich weiß nicht, ob irgendjemand im Chat dazu eine Idee hat.
Also wie kriege ich das jetzt hin?
Was ist das Erste, was ich jetzt tue, um herauszufinden, was ich hier in dieser Reparatur mache oder was ich für dieses System bauen soll, wie ich also eine Architektur dort aufsetze?
Noch ein Hinweis packe ich auch noch mal in die Links.
Also es gibt dieses wunderschöne arc42.
Das ist von meinem Kollegen, dem Gernot Starke, sehr stark beeinflusst.
Das ist eine gute Möglichkeit, um Architekturen zu dokumentieren.
Und viel von dem Zeug, was ich hier jetzt irgendwie präsentiere, ist dadurch zumindest inspiriert.
Gleichzeitig ist es aber auch so, dass eine ganz wichtige Aussage, glaube ich, hier ist, dass man jetzt nicht irgendwie einfach blind so ein arc42-Template ausfüllen sollte, sondern irgendwie muss man da anders vorgehen.
Und damit habe ich möglicherweise schon Teil sozusagen der Lösung von mir gegeben, aber irgendwie müssen wir da was machen.
Also irgendeine Idee, irgendeine Idee, was wir jetzt als Artefakt zuerst bauen wollen würden oder wie wir da überhaupt an das Problem rangehen.
Was ist das, was wir jetzt hier bei dieser Architektur machen wollen?
Anforderungen dokumentieren.
Ah, genau.
Theo Gripp sagt: Anforderungen dokumentieren.
Guter Punkt, und das war etwas, was ich eigentlich explizit sagen wollte.
Die Anforderungen, die wir jetzt hier haben, die sind ja so ein bisschen schwach.
Also das ist halt irgendwie eine nette Idee mit irgendwelchen … Mit irgendwelchen Dingen, die halt in dem Backlog stehen.
Ich würde mich als Architekt jetzt nicht hinstellen und diese Sachen genau dokumentieren, weil ich die Hoffnung hätte, dass es dafür Requirements Engineers oder andere Leute gibt, die das halt irgendwie genauer aufnehmen.
Das nehme ich eher als Input an und ich würde eigentlich auch erwarten, dass das, also nicht, dass hier jetzt ein Artefakt, von dem ich erwarte, dass es da ist, in irgendeiner Art und Weise, Backlog oder wie auch immer.
So, Anforderungen dokumentieren, das also nicht, das nehme ich an, ist ein Input, wenn wir zumindest über diese Art von Anforderungen reden.
Wo soll die Anwendung laufen?
Cloud, lokaler Server.
Können wir ja mal probieren.
Das heißt also, wir können jetzt mal, ich könnte jetzt also zu dem Experten gehen, der in dem Shop mein Ansprechpartner ist, also ein Geschäftsführer, und könnte den fragen: Soll das in der Cloud laufen oder auf dem lokalen Server?
Und ich würde vermuten, dass die Person entweder sagt: Mir egal, oder die Person sagt: Was ist die Cloud und was ist ein lokaler Server?, kannst du mir das erklären?
Oder die Person sagt: Das soll in der Cloud laufen, und dann habe ich potenziell auch ein Problem, weil das vielleicht keine gute Idee ist.
Das heißt, ich würde behaupten, die Frage, wo soll die Anwendung laufen, ist eine Architekturentscheidung, die müssen wir treffen.
Es wäre nicht die erste Entscheidung, die ich treffen würde, und es ist für mich auch keine Anforderung, sondern es gibt Anforderungen und die sorgen dafür, dass wir es halt in der Cloud laufen lassen wollen, also zum Beispiel Verfügbarkeit oder Datenschutz oder was auch immer.
Der Jendrik sagt: Qualitätsszenarien formulieren.
Genau, guter Punkt.
Dazu kommen wir auch tatsächlich gleich.
Bei INNOQ einen Berater anfragen, sagt Frau Bauti.
Ja, das hilft sicher, aber ich hätte ja, also wir reden ja gerade drüber, weil ich eben glaube, dass es so ein paar fundamentale Sachen gibt und die sind ja auch, glaube ich, schon an vielen Stellen publiziert.
Jan sagt nochmal, A42 soll gar nicht blind ausgeführt werden.
Wenn ich Infos habe, dann so ablegen.
Genau.
Und ich muss auch gestehen, dass vielleicht eine von den Learnings, aber darüber können wir diskutieren, die man da vielleicht ableiten kann, ist, dass vielleicht auch die Reihenfolge der Kapitel nicht die Reihenfolge ist, die ich vorgehen würde.
So, von den Vorschlägen finde ich besonders gut das von dem Jendrik mit den Qualitätsszenarien formulieren.
Das ist auch tatsächlich das, was ich erst gedacht habe, was ich wahrscheinlich tun würde.
Ich habe mich trotzdem für was anderes entschieden.
Ich erzähle gleich nochmal was.
Und was ich jetzt insbesondere gut finde, ist, eigentlich hätte ich die Antwort erwartet.
Naja, wir nehmen jetzt mal die Anforderungen und strukturieren die irgendwie und kommen dann mit einer Architektur mit Boxen und Pfeilen raus.
Also das wäre ja das, was man jetzt gerade erwarten könnte, wenn man so aus dem Domain-Driven Design kommt.
Dann würde ich jetzt irgendwie anfangen und würde halt sagen, okay, ich habe halt Reparatur einplanen und ich habe Reparaturplan, lass uns mal schauen, wie wir halt die Software strukturieren, damit sie halt diese Sachen irgendwie abdeckt.
Und das ist ein Teil der Architektur, das ist auch wichtig, aber das ist nicht das, womit ich jetzt anfangen würde.
Womit fange ich also an?
Ich habe mich dazu entschieden zu sagen, ich baue mal ein … Systemkontextdiagramm.
Und ein Teil davon fällt mir halt sozusagen schon in den Schoß, weil die Shop-Mitarbeiterin, die Fahrradmechanikerin und die Kunden, die werden alle irgendwie mit diesem Reparatursystem interagieren.
Also das Kontextdiagramm sagt, in welchem Kontext bewegt sich dieses System, also welche anderen Systeme interagieren damit und welche Nutzer interagieren damit.
Und wie gesagt, diese drei Nutzerkategorien, die habe ich ja jetzt schon durch die Anforderungen sozusagen geliefert bekommen.
Das heißt, die habe ich hier einfach eingemalt.
Das war jetzt nicht so super spannend.
Wir können jetzt mal darüber reden, was wir hier an Anforderungen haben.
Lass uns also nochmal irgendwie zurückgehen.
Also irgendwie der Kunde soll das Fahrrad zur Reparatur anmelden und wir haben gesagt, das war so ein Detail, dass das irgendwie auch online möglich sein soll.
Also ich möchte jetzt irgendwie zur Webseite gehen und dort in der Webseite sagen können als Kunde, ich möchte gerne dieses Fahrrad zur Reparatur anmelden.
Und es ist tatsächlich so, dass dieser Fahrradladen bereits einen Webshop hat und weitere Diskussionen mit dem Anforderer, das ist so das, was ich jetzt ausspare.
Also eigentlich sind wir halt an der Stelle, wo wir nochmal mit Anforderern und Experten sprechen müssen, um herauszufinden, was eigentlich sozusagen Phase ist.
Und ich dokumentiere sozusagen das, was in diesem imaginären Gespräch irgendwie rüberkommt, so in eine von den Aussagen.
Also das heißt, wir gucken uns jetzt eben diese Anforderungen, die hier ja ein bisschen armselig dargestellt sind, nochmal genauer an und versuchen herauszufinden, wie wir das Ding, wie wir dort arbeiten wollen.
Also zum Beispiel eben die Frage: Wie gehen wir da vor bei dem Fahrrad zur Reparatur anmelden?
Und es stellt sich halt heraus, dass wir irgendwie da den Webshop haben und der spielt da irgendwie eine Rolle.
Gut, das heißt also, wir haben jetzt als weiteres zusätzliches System den Webshop, mit dem wir irgendwie interagieren müssen.
Irgendwie ist es halt so, dass wir dort eine Integration hinbekommen müssen.
Und dann, genau, und was sich halt außerdem dabei noch herausstellt, ist, es wäre total super, wenn wir in dem Webshop, wenn sich dort jemand registriert hat, auch die Möglichkeit haben, dass diese Personen gleich Reparaturen beauftragen.
Das heißt, irgendwie müssen wir auch mit dieser Datenbank von dem Webshop interagieren.
Das ist irgendwie die User-Datenbank, das ist irgendwie ein Teil davon.
Und da können wir zum Beispiel nachfragen, welche Adresse diese Person hat, auch beispielsweise, ob das ein Fahrrad, was der, genau, und wie der typischerweise bezahlt und solche Geschichten.
Das ist eine weitere Integration.
So, der Jan schreibt jetzt weitere Akteure, zum Beispiel den Betrieb.
Das ist eine gute Frage.
Also da sind jetzt zwei Sachen.
Für diesen speziellen Fall würde ich jetzt erst mal unterstellen, dass der Betrieb, also der Fahrradshop, den ich halt irgendwie sozusagen vor Augen habe, ist eben tatsächlich ein lokaler Fahrradshop hier in Kaiserslautern.
Und da sind so, weiß ich nicht, drei, vier Leute, die halt dort arbeiten.
Und es ist irgendwie so, dass ich jetzt mal unterstelle, ich weiß es nicht, ich habe mit denen nicht geredet, dass die halt keine echte Ahnung haben von IT.
Das heißt also, die haben eigentlich nicht wirklich einen Betrieb.
Deswegen würde ich diesen Akteur dort nicht identifizieren.
Ob ich ihn sonst identifizieren würde, weiß ich nicht genau.
Sprich, ich bin mir nicht sicher, ob wir auf dieser Ebene Leute von Betrieb überhaupt mit Systemen interagieren werden, sondern ob die das nicht einfach als Blackbox sehen, als irgendwie etwas, was irgendwo läuft.
Aber das wäre, also könnte möglicherweise sein.
Es wären jetzt nicht die Ersten, die mir einfallen würden.
Ich würde halt eher Kunden sehen und Leute, die sozusagen Anforderungen haben in erster Linie.
So, dann sagt der Jan weiter: Bezahlung über den Webshop, genau.
Und das hat auch eine Spezialität, und zwar ist, also der Webshop ist halt ein standardisierter Webshop, in dem ich im Wesentlichen Räder und Sachen halt irgendwie kaufen kann und dann halt irgendwie anschließend abholen kann.
Und das ist halt ein Fertigprodukt.
Und die Diskussion mit der Anfordererin hat ergeben, dass wir jetzt nicht eine Reparatur als ein Produkt im Webshop haben wollen, weil das ja irgendwie auch unnatürlich ist.
Also das ist etwas anderes, über das wir hier reden.
Und deswegen wollen wir hier anders vorgehen.
Wir wollen so vorgehen, und deswegen brauchen wir auch die Integration in diese User-Datenbank, dass tatsächlich ich einen eigenen Teil der Webseite habe, also sozusagen neben dem Webshop, in dem ich sagen kann: Ich möchte dieses Fahrrad reparieren, und da soll es dann einen eigenen Bezahlvorgang geben.
Das heißt also, wir werden nicht in den Webshop uns integrieren in dem Sinne, dass wir ein Produkt haben, das wir jetzt in dem Webshop bezahlen können, sondern wir werden dort etwas Eigenes haben.
So, das bedeutet, dass wir tatsächlich irgendwie so einen Payment-Service brauchen.
Und also ich denke da halt ehrlich gesagt in erster Linie so an PayPal, das heißt, wir werden irgend so einen Button haben, wo wir halt sagen: Bezahlen wir jetzt mit PayPal, und da kann ich halt entweder mein PayPal-Konto eingeben oder meine Kreditkarte.
Das wäre also ein weiteres Ding, was wir benötigen.
Dann kommt: Benötigt der Webshop Live-Daten aus dem Reparatursystem oder reicht ein regelmäßiger Datenabgleich?
Genau, das ist jetzt, das ist also, das ist eine Frage, die wir auf dieser Granularitätsebene eigentlich nicht betrachten müssen, weil wir ja erst mal nur versuchen herauszufinden, in welchem System wir überhaupt integrieren.
Und trotzdem ist es so, dass sich aus unseren Angaben, die wir bis jetzt haben, oder den Ideen, die wir bis jetzt ausgetauscht haben, sich darauf eine Antwort ergibt, und zwar ist die Antwort: Der Webshop hat keine Daten aus dem Reparatursystem, sondern wir würden eine Webseite haben, wo ich irgendwie hingehe, ich sage, ich bin Eberhard Wolff, hallo, und dann sagt das Ding halt: Das Fahrrad, was du halt abgeliefert hast, ist immer noch nicht fertig.
Es wäre also eine Webseite, die wir selber rendern.
Deswegen müssen wir die Daten nicht austauschen.
Integration mit dem Rechnungswesen?
Ja, guter Punkt, sollten wir aufnehmen, ist tatsächlich etwas, was ich irgendwie vergessen habe.
Da sieht man, das ist also möglicherweise relevant, das heißt, ich schreibe hier mal mein Rechnungswesen hin.
Also wir müssen das ja irgendwie vernünftig verbuchen gegenüber dem Buchhalter, Quatsch, gegenüber dem Steuerberater.
Das heißt, wir brauchen irgendwie das Rechnungswesen.
Und ich habe es gerade eben schon kurz gezeigt, was wir halt außerdem brauchen, ist eine Integration mit der Kasse.
Also es gibt ein Kassensystem, das ist letztendlich so eine Art PC.
Und dieser PC ist halt ein weiteres System, mit dem wir uns integrieren müssen.
Das ist halt die Alternative.
Also wir werden nicht nur Online-Payments machen, sondern wir werden uns halt auch irgendwie mit der Kasse integrieren müssen.
So, Online Payment Service.
Kann ich die Kamera etwas mehr in die Ecke schieben?
Dann lass mich mal kurz schauen.
Mir ist das auch aufgefallen, dass es halt bedauerlicherweise … ich fix das mal kurz.
Das Bild im Bild ist halt ein bisschen sehr groß.
Und ich bin ja … genau.
Gut.
So, danke für den Hinweis, Frau Bauti.
Dann haben wir … ach so, da ist noch ein guter Hinweis: Inventursystem für Teile des Rades.
Und das ist tatsächlich jetzt auch noch mal eine spannende Frage.
Also wollen wir sowas, haben wir dort ein System?
Und die Annahme ist, dass wir tatsächlich in dem System, was halt die Reparaturen macht, selber Buch für Ersatzteile.
Das heißt, da steht halt irgendwie drin, ich habe hier noch eine Schaltung, ich weiß nicht, irgendeine Shimano, also ein Schaltwerk.
Und dieses Schaltwerk ist eben noch da und kostet halt so und so viel Euro.
Das wollen wir halt im Reparatursystem selber drin haben.
So, und das ist übrigens einer der Gründe, warum ich das jetzt mit diesem Kontextdiagramm spannend finde, weil wir jetzt gerade definiert haben, dass wir eine bestimmte Verantwortung haben.
Also wir müssen eben die Ersatzteile tracken und wir müssen uns eben nicht integrieren mit irgendeinem anderen System.
Das ist halt irgendwie eine Entscheidung, die wir jetzt getroffen haben, und deswegen ist eben dieses Systemkontextdiagramm, glaube ich, ganz wertvoll.
Was habe ich mir denn noch aufgeschrieben?
Muss mal kurz schauen.
Irgendwie vermisse ich gerade ein Browserfenster.
Ah, da.
Ach so, wir wollen noch den Kunden darüber informieren, dass die Reparatur fertig ist, und dazu schicken wir eine E-Mail.
Thinking about it, man müsste, damit stellen wir eine Abrede, dass wir halt SMS machen, was vielleicht nicht so super smart ist.
Also ich bin da halt eher oldschoolig, das heißt, mich erreicht man tatsächlich über E-Mail, aber vielleicht sollten wir da halt irgendwie auch noch eine SMS-Integration vorsehen.
So.
Also haben wir jetzt hier ein Systemkontextdiagramm.
Wir wissen, dass wir diese drei Personen haben, die mit uns interagieren würden, und wir haben halt jetzt eine Vielzahl von Systemen, mit denen wir reden müssen.
Jan fragt, sollten wir die Verantwortung, dass wir die Ersatzteile selber tracken, hier notieren?
Nö, das ist das Systemkontextdiagramm, ne.
Und da wollen wir ja nur sehen, dass dieses System, was wir jetzt bauen, also der Reparaturservice, sich im Kontext befindet mit einigen anderen Systemen.
Und da die Frage: Tracken wir die Ersatzteile? ist eigentlich etwas, so eine fachliche Frage.
Die müsste halt hier irgendwo stehen.
Und eigentlich, also das hier weist so ein bisschen darauf hin, dass wir halt Ersatzteile hier bestellen können und dass wir irgendwie auch Reparaturen protokollieren, impliziert ja, dass wir zumindest zum Teil diese Sachen halt irgendwie tracken.
Und wir haben das jetzt eben nochmal konkretisiert.
Und eigentlich ist das eben eine fachliche Sache.
Das hier ist eine technische Aussage.
Also diese technische Aussage sagt jetzt eben, unser System wird mit einer Vielzahl an anderen Systemen irgendwelche Schnittstellen haben.
Und das ist eben tatsächlich eine technische Aussage, also tatsächlich unser Architekturthema.
Und es wäre jetzt nichts, was ich erwarten würde, dass jemand, der sonst fachliche Anforderungen erhebt, mir das halt irgendwie zuliefert.
Also das werde ich tatsächlich selber wahrscheinlich machen müssen.
Gut, Fragen erstmal noch dazu, irgendwelche Kommentare?
Wie bewertet ihr das?
Also ich fand es halt, ich habe, wie gesagt, ja das nun vorbereitet und habe mich halt dazu entschieden, als Erstes das Systemkontextdiagramm zu machen.
Und was ich dabei halt hilfreich fand, ist, dass ich dadurch tatsächlich ein besseres Bild bekommen habe über das, was ich bauen soll und mit wem ich interagieren muss.
Und das ist ja irgendwie auf der höchsten Ebene eine spannende Sache.
Also insbesondere kriege ich darüber raus, welche Verantwortung ich sozusagen habe.
Und ich kriege eben auch, wie gesagt, Schnittstellen raus.
Also ich fand das als ersten Schritt ehrlich gesagt … Besser als Qualitätsszenarien, das wäre das Nächste, was halt eigentlich kommen würde.
Und das andere, genau, das ist vielleicht in der Diskussion jetzt gar nicht so klar rausgekommen.
Also zum Beispiel, dass man dem Rechnungswesen, das man dem Rechnungswesen hatte ich halt vorher nicht betrachtet.
Also das heißt, da ist auch tatsächlich bei diesem Spielbeispiel habe ich hier mindestens eine Sache übersehen.
Das heißt also, das ist tatsächlich relevant.
Beinhaltet der Webshop auch einen User-Account?
Hat er, ne?
Also da gibt es diese Webshop-User-Datenbank und das ist genau das, was jetzt sozusagen eine Rolle spielt.
Das heißt also, wenn ich Eberhard Wolff bin, dann möchte ich halt gerne mich in den Webshop einloggen und dann weiß das System schon mal, dass ich ich bin und kann dann eben dafür sorgen, dass Dinge auch übernommen werden, also zum Beispiel meine Adresse oder sowas.
Gut.
Das hier ist jetzt so ein Systemkontextdiagramm, das so auf Business-Ebene das kommuniziert.
Das heißt, ich sehe das hier abstrakt, ohne konkrete technische Sachen.
Was wir jetzt noch mal machen können, ist, wir können insbesondere hier den linken Bereich duplizieren und wir können daraus, wir können jetzt einfach noch mal, oder einfach, also wir können jetzt noch mal mehr Informationen sammeln, und zwar … über die technische Umsetzung dieser Schnittstellen.
So, und eine von den technischen Entscheidungen oder eine von den Sachen, die wir hier jetzt irgendwie haben, ist: Wir haben uns dazu …
Also hier ist es so, ich logge mich ein bei dem Webshop, dann kriege ich ein JWT-Token als Cookie.
JWT-Token ist ein Standard, mit dem ich halt zum Beispiel in einem Cookie Informationen hinterlassen kann, wie zum Beispiel meinen Namen, meinen Benutzernamen, solche Geschichten.
Und darüber würde ich jetzt diese Informationen in mein Reparatursystem bekommen.
Das heißt also, mein Reparatursystem bekommt ein Cookie, da steht drin, dass eben gerade der Eberhard Wolff am Werkeln ist, und darüber kann ich dort diese Benutzerinformationen austauschen.
Und außerdem nehmen wir jetzt mal an, gibt es halt irgendwie so eine REST-Schnittstelle, die es mir halt erlaubt beispielsweise die Adresse des jeweiligen Nutzers herauszufinden.
Wobei das so ein bisschen borderline ist, also in der User-Datenbank die Adresse zu haben, eigentlich ist das ja eher eine Kundeninformation.
So, die Integration mit dem Webshop haben wir diskutiert, das können wir hier auch nochmal irgendwie genauer festhalten, funktioniert halt darüber, dass wir bestimmte URLs umleiten an unser Reparatursystem.
Also innerhalb von meintollerfahrradshop.de gibt es halt /reparatur und /reparatur ist unsere Verantwortung.
So, und dann müssten wir jetzt hier die restlichen Protokolle noch definieren.
Mir war das jetzt ehrlich gesagt, wie soll ich sagen, zu doof, ne?
Also da steht halt irgendwas dann drin, also meinetwegen REST oder irgendwas anderes, gRPC oder so, und dann hätten wir halt diese Informationen da drin.
Das wäre jetzt für das Rechnungswesen auch, glaube ich, gar nicht so spannend.
Spannend ist vielleicht noch die Geschichte mit dem Payment Service, und da ist es so, dass wir halt auf der einen Seite eine Integration hätten über REST, worüber ich eben abfragen kann, ob das wirklich funktioniert hat und ein paar Informationen bekomme über die Buchung, und eine UI-Integration, sprich ich habe so einen Button, mit dem ich halt sage, bezahle per PayPal, und der leitet um zu PayPal, und dann komme ich anschließend zu meinem System zurück.
Das heißt, im Backend würde jetzt die Information ausgetauscht werden über die Bezahlung und im Frontend gäbe es eine Integration über so einen Button.
Das führt dazu, dass solche Sachen halt häufig einfach zu integrieren sind.
Und hier hätten wir jetzt auch irgendwelche Protokolle, also wir hätten zum Beispiel ein REST-Protokoll Richtung Kasse, zu dem E-Mail-System, weiß ich nicht, wenn das halt, das sind zum Beispiel Sachen, die man halt bei AWS kaufen kann.
Das heißt, man könnte jetzt, also Simple Email Service, den könnte man also entsprechend hier über eine Schnittstelle aufrufen, meinetwegen auch eine REST-Schnittstelle, und meinetwegen ist das hier auch eine REST-Schnittstelle.
Also hier würden halt technische Informationen stehen, da wir das System nicht bauen, ist das, glaube ich, nicht so super spannend.
Genau, Jan sagt, bei dem Cookie die Same-Origin-Policy beachten.
Genau, das würde also bedeuten, dass eben unser Rechnungs-, da geht es darum, dass Cookies nur ausgetauscht werden können, wenn sie halt in derselben Domäne sozusagen registriert sind.
Und das ist also auch eben einer der Gründe, weswegen wir bestimmte URLs Umleiten wollen, nicht?
Also meintollerFahrradshop.de/reparatur, und da würden dann eben die Cookies von meintollerFahrradshop, also eben genau der mit JWT-Token, der würde da halt übertragen werden.
So, damit hätten wir jetzt eine gute Übersicht darüber, welche Schnittstellen wir haben und wie wir das System integrieren wollen.
Ich muss gestehen, ich finde es halt spannend, dass wir bei diesem Spielbeispiel schon diese Vielzahl an Schnittstellen haben, aber das ist halt sozusagen das Typische.
Und wie gesagt, also wenn ihr mich jetzt sozusagen fragt, ich würde behaupten, in der Bewertung des Systems und von dem, was wir halt vorhaben, sind wir jetzt deutlich einen Schritt weitergekommen.
Also bei mir ist jetzt das mentale Bild von diesem System sozusagen besser.
Hat dieses Diagramm auch einen speziellen Namen?
Ja, das ist ein Systemkontextdiagramm.
Also, lass mal kurz schauen.
Bin nicht sicher, ob ich das …
Moment.
Genau, lass mich kurz schauen.
Das hier ist arc42 und … also ich kann es tatsächlich mal zeigen, da muss ich nur kurz das umschalten, genau hierhin, und dann sollte ich das hier machen.
Genau, also das ist die URL, die ich vorhin gezeigt hatte, und da, also sprich, das ist die arc42-Dokumentation, und da gibt es halt genau dieses Kapitel 3, da sind wir jetzt.
Und in diesem Kapitel, nein, also da sind wir gerade nicht, sondern was ich halt sagen wollte, ist, es gibt eben hier verschiedene Kapitel und ich bin jetzt hier reingesprungen ins Kapitel 3, weil ich das eben besonders spannend fand.
Und da gibt es eben genau diese Kontextdiagramme, also einmal den Business-Kontext und zum anderen den Technical-Kontext und das ist das, was wir hier gebaut haben.
Das heißt also, der Business-Kontext zum Beispiel von diesem HTML Sanity Checker, der sagt jetzt, welche Benutzer es da gibt und wie das halt mit anderen Systemen sich integriert.
Und hier ist der technische Kontext und dann haben wir jetzt zum Beispiel bei dem HTML Sanity Checker haben wir jetzt hier eben genau so ein, was steht da, Internet HTTPS oder Internet HTTPS.
Das heißt, wir haben da eben genau diese zusätzlichen technischen Informationen, die Akteure sind halt weg.
Genau, und Frau Bauti fragt halt: Ich dachte, das Systemkontextdiagramm zeigt keine Technologien.
Genau, deswegen gibt es ja gerade diese zwei Varianten.
Also es gibt halt einmal diese Variante hier mit dem Business-Kontext und dann gibt es eben diese Variante mit dem technischen Kontext und im technischen Kontext kommen eben diese Protokolle vor.
Ich muss gestehen, wenn wir uns das jetzt hier wieder anschauen, ich bin mir ehrlich gesagt unsicher, wie viel zusätzliche Informationen man hier halt gewinnt.
Also das hier ist halt … Glaube ich sehr wertvoll.
Das hier, da finde ich halt dieses Thema wertvoll, nicht?
Also die Frage, wie komme ich mit dem Webshop irgendwie zurande?
Und darüber haben wir ja auch diskutiert.
Das ist also tatsächlich, glaube ich, ein spannender Constraint.
Der Jendrik Ottmann fragt: Würde dann neben den Protokollen noch die Hosting-Environments fehlen für unsere Systeme?
Für unsere Systeme, also für das Webshop-Reparatursystem, ist eine Architekturentscheidung, wie wir das Ding hosten wollen.
Und das müssen wir halt erst mal entscheiden.
Das kann nicht, das hier ist ein Input, das hier ist halt die Aussage, es gibt folgende Systeme, mit denen ich mich integrieren muss.
Und irgendwie ist jetzt, behaupte ich mal, könnten wir diese Informationen erfassen, wo dieser Webshop ist, wo die User-Datenbank ist, finde ich auf dieser Granularitätsebene jetzt nicht so super spannend, nicht?
Also es interessiert mich nicht, dass das jetzt mein toller Webshop ist und dass der halt irgendwo gehostet wird, sondern ich will irgendwie grob granular erst mal wissen, wie gehen wir dort technisch vor.
Und ja, wenn irgendeine Entwicklerin sich darum kümmern muss, dann werden wir mehr Informationen brauchen, aber für meine aktuelle Flughöhe ist das ausreichend.
Also Jendrik fragt: Bei den externen Systemen.
Genau, bei den externen Systemen finde ich, hilft mir das im Moment nicht.
Also ich will ja eine Lösung bauen, ich will das System noch nicht programmieren.
Wenn ich es programmiere, dann brauche ich sicher noch viel mehr Informationen.
Im Moment finde ich das halt so ausreichend.
Ich will ja so ein paar technische Ideen mir überlegen.
Gut, so, das heißt, wir haben jetzt eine Idee darüber, wie sich unser System sozusagen in den Rest der Welt integriert.
So, und jetzt kommt das, was … Wer hat es denn vorhin gesagt?
Das fand ich halt so schön, weil genau der Jendrik hat es gesagt.
Jetzt kommt das mit den Qualitätsszenarien.
Und was ich jetzt erst mal machen würde, ist, ich würde, oder was ich hier erst mal mehr runterkopiert habe, ist ein Überblick über den ISO 25010.
Und der sagt jetzt, also nein, nochmal abstrakter und vielleicht allgemeiner gesprochen: Wir wissen jetzt also, wie sich dieses System integriert in die anderen Systeme drumherum.
Wir können auf Basis dessen jetzt ein paar Entscheidungen bezüglich der Schnittstellen treffen.
Das andere ist, wir müssen uns jetzt überlegen, welche technischen Probleme wir überhaupt lösen müssen.
Und dafür fehlt als Input eine Aussage über die technischen Herausforderungen, die wir eigentlich haben.
Also wenn ich dieses System baue, kann ich dieses System mit unterschiedlichen technischen Qualitäten bauen.
Ich kann es zum Beispiel wahnsinnig einfach wartbar machen.
Ich kann es wahnsinnig benutzerfreundlich machen.
Ich kann es wahnsinnig verfügbar machen.
Ich kann es wahnsinnig schnell machen, wahnsinnig sicher.
Ich muss mir jetzt überlegen, welcher dieser Aspekte ist tatsächlich wichtig.
Und wir reden hier über ein Fahrradreparatursystem.
Das heißt also, wir müssen uns mal Gedanken darüber machen, hier auch wieder eine Kommunikation mit dem Experten, der Expertin, was denn nun tatsächlich unsere technischen Herausforderungen sind.
Da gibt es, wie soll ich sagen, ich glaube, es gibt da so ein bisschen zwei Meinungen.
Und die eine Meinung ist, na ja, als Architekt sollte ich mich darum eigentlich nicht kümmern müssen.
Ich will ja eine Lösung finden, ich will nicht die Anforderungen erheben.
Das mag halt sein.
Das Problem ist, dass ich behaupten würde, dass das, was wir hier sehen, ist, glaube ich, gar nicht so weit entfernt von dem, was wir in einem Projekt tatsächlich sehen würden.
Also wir würden jetzt in einem Projekt einen Backlog sehen und da wären solche fachlichen Stories drin, wenn es gut läuft.
So, sagt mir das jetzt etwas darüber, ob das System sicher sein soll?
Sagt mir das etwas darüber, ob das System skalierbar sein soll?
Nö, tut es halt irgendwie nicht.
Das heißt also, wenn ich mich hinstelle und sage, eigentlich müssten da jetzt irgendwie Anforderungen stehen in diesem Bereich, stehen sie nicht.
Sorry, so kann ich nicht arbeiten, das hilft mir nicht.
Irgendjemand muss sich kümmern, also werde ich mich möglicherweise selber kümmern müssen als Architektin.
Und dafür finde ich jetzt dieses hier hilfreich.
Das heißt, ich kann jetzt hier bei der Qualität schauen, was ist eigentlich meine Herausforderung bei der Qualität?
Und hier haben wir jetzt eben sowas wie Zuverlässigkeit, Performance, Benutzbarkeit, Sicherheit, Kompatibilität, Wartbarkeit oder Übertragbarkeit.
Und das ist eben die Stelle, wo nach meinem Empfinden zu häufig Architekt:innen sagen, na ja, das ist klar, wir wollen eine vernünftige Architektur bauen.
Offensichtlich muss das System wartbar sein und skalierbar.
Und na ja, das sollten wir jetzt mal hinterfragen.
Das heißt also, wir würden jetzt mit dem Fachexperten sprechen.
Und wenn wir jetzt mit dem Fachexperten sprechen, wird er halt sagen, dass sowas wie Genauigkeit beispielsweise sicher relevant ist.
Also es wäre jetzt komisch, wenn da Rechnungsbeträge rauskommen, die halt völlig falsch sind.
Aber, und das könnten wir jetzt alles dokumentieren.
Also wir können jetzt irgendwie hinschreiben, ja, Rechnungsbeträge sollen irgendwie korrekt sein.
Das Ding soll in einigermaßen vernünftiger Zeit antworten.
Aber was ist denn jetzt eigentlich der Kern der ganzen Geschichte?
Also was ist das, was halt tatsächlich wichtig ist?
Was ist das, die technischen Eigenschaften, die sozusagen dazu führen, dass das System halt, wenn sie nicht eingehalten werden, gekillt werden, uns killen?
So, und da ist das, was uns jetzt der Experte gesagt hat.
Der hat uns gesagt, insbesondere Benutzerfreundlichkeit ist wichtig.
Wenn wir mit diesem System nicht arbeiten können, insbesondere wenn Kunden damit keine Reparaturen beauftragen, dann haben wir halt ein echtes Problem.
Und das wird halt nur funktionieren, wenn das halt benutzerfreundlich ist.
Das heißt also, wir wollen gerne ein benutzerfreundliches System haben, in erster Linie für Kunden, aber auch für die Leute in der Werkstatt.
Und da gibt es noch eine andere Story.
Und die andere Story ist, wenn dieses System halt besonders gut funktioniert, dann wollen wir halt eine SaaS-Lösung draus machen.
Also dann wollen wir halt irgendwie dieses System anbieten in diesem Internet und dann wollen wir halt dafür sorgen, dass andere Leute das benutzen können.
Das heißt, von den Themen, die wir hier haben, haben wir in erster Linie etwas in Bezug auf Benutzbarkeit.
So, und das ist, finde ich jetzt erstmal eine spannende Aussage und vielleicht auch keine atypische.
Also ich finde halt, dass Benutzerfreundlichkeit, oder ich vermute, dass Benutzerfreundlichkeit in vielen Kontexten ein sehr wichtiger Punkt ist, weil ohne Benutzerfreundlichkeit will eben niemand das System benutzen und dann stellt sich irgendwie die Frage, warum zum Teufel entwickeln wir das überhaupt.
So, und jetzt ist die nächste Frage: Wie kriegen wir das, also über Benutzerfreundlichkeit insbesondere darüber können wir jetzt diskutieren.
Und, nicht, also da gibt es ja auch sehr stark ideologische Diskussionen, wer jetzt was irgendwie wie benutzerfreundlich findet.
Und da ist irgendwie die Frage, wie können wir das eigentlich tatsächlich konkretisieren?
Also dass wir aus dieser Diskussion jetzt mitnehmen ist, von dem, worüber wir hier reden, ist halt offensichtlich sowas wie Benutzerfreundlichkeit, Benutzbarkeit ein wichtiger Punkt.
Da müssen wir uns halt irgendwie mal ernsthaft mit beschäftigen.
Die anderen Punkte, na ja, wir sollten es halt zumindest mal abklappern, weil gerade sowas wie Verfügbarkeit ist halt auch vielleicht wichtig.
Und wir sollten halt irgendwie auch uns überlegen, wie wir dieses System dann später mal zu einem SaaS-System umbauen können.
Jan fragt: Mandantenfähigkeit bedeutet SaaS-Mandantenfähigkeit und Installation pro Fahrradladen.
Das wäre dann beispielsweise etwas, was wir bei den Fach- genau, das wäre halt auch etwas, worüber wir nochmal bei den Qualitätsszenarien sozusagen reden könnten.
Also wie, das hängt dann ja eben davon ab, ob wir zum Beispiel diese Installation pro Fahrradladen finanzieren können.
So was zum Beispiel.
So, also wir müssen diese Sachen halt irgendwie mal verifizierbar bekommen und dafür helfen diese Qualitätsszenarien.
Qualitätsszenarien sind so, dass ich entweder dieses System irgendetwas aussetze, also einer Benutzung, einer Änderung oder einem Ausfall, und das System soll dann in irgendeiner Art und Weise mit einer definierten Metrik antworten.
So, und das können wir jetzt mal versuchen, also beziehungsweise das werden wir jetzt mal tun.
Und zwar fangen wir mal an mit dem Thema Benutzerfreundlichkeit, Überraschung.
Und ein Szenario, was mir da zum Beispiel einfällt, ist: Ein neuer Kunde will das System nutzen und er kann sich innerhalb von einer Minute registrieren.
Das ist halt eine Aussage über Benutzerfreundlichkeit, irgendwie auch über Performance, weil wenn die Performance jetzt schlecht ist, schafft er es halt irgendwie nicht.
Aber es muss jetzt irgendwie möglich sein, dass ich mich so schnell registriere.
Und dass es tatsächlich schnell bedeutet wahrscheinlich, dass man nicht viel mehr machen kann, als Benutzernamen und Passwort irgendwie abfragen und das irgendwie auch sehr einfach halten muss an der Stelle.
Jetzt bin ich mir nicht sicher, ob irgendjemand mit meinem Problem auffällt.
Ich habe tatsächlich das Szenario irgendwie formuliert und habe dann festgestellt, das ist ein Szenario, was wir gar nicht erfüllen können.
Denn das bedeutet, dass wir uns irgendwie in der Benutzerdatenbank registrieren und das ist hier.
Also das heißt, der Registrierungsprozess ist wahrscheinlich im Webshop, sodass das hier wahrscheinlich gar nicht ernsthaft machbar ist.
Das fand ich halt interessant, weil, also schon bei diesem Spielbeispiel ist es dann irgendwie so, dass man über das Systemkontextdiagramm bestimmte Dinge ausschließen kann.
Jan hat es auch gerade gesagt.
Also das heißt … Szenario nicht erfüllbar, weil Registrierung im Webshop.
Der Felix sagt gerade, dass das Szenario schlecht messbar ist.
Das finde ich interessant.
Ich hätte nämlich jetzt eigentlich argumentiert, dass dieses Szenario super messbar ist, weil ich kann jetzt jemanden an den Rechner setzen, ich nehme die Stoppuhr und sage ihm: Registrier dich bitte auf der Webseite.
Und wenn er oder sie sich nach einer Minute nicht registriert hat, habe ich das Szenario gerissen.
Und das ist, finde ich, eigentlich eine gute Möglichkeit, um Benutzerfreundlichkeit messbar zu machen.
Also wenn das jetzt irgendwie so verwirrend ist, dass das eben nicht möglich ist, innerhalb einer Minute sich zu registrieren, dann habe ich halt ein benutzerunfreundliches System.
So wäre meine Aussage, aber vielleicht hat Felix da eine andere Meinung.
Dann haben wir hier das nächste: Ein frisch registrierter Kunde, der also noch nie irgendwas gemacht hat, will eine Reparatur beauftragen.
Er kann das innerhalb von zwei Minuten tun.
Das ist also auch wieder etwas, was, glaube ich, Benutzerfreundlichkeit messbar macht und was leicht verifizierbar ist und, glaube ich, auch tatsächlich sehr relevant ist.
Also es gibt so bestimmte Dinge, also es gibt einen Webshop im Internet, wir … Genau, es gibt einen Webshop im Internet, wo ich halt immer wieder, wenn ich sozusagen nicht hellwach bin, kriege ich es halt nicht hin, Sachen da zu kaufen.
Felix fragt, Felix sagt noch: Wo fängst du an zu messen, im Flow und im Live-System müssen wir über Perzentile reden.
Guter Punkt.
Also ja, das müssten wir jetzt irgendwie noch mal weiter runterbrechen.
Wir müssen also jetzt sagen, was bedeutet das nun exakt.
Ich muss halt gestehen, dass ich als mentales Bild dahinter habe, dass es halt im Wesentlichen ein Formular ist.
Und dann, also nicht, das ist halt tatsächlich, und da wäre jetzt die Frage, wie kompliziert ist dieses Formular, wie viele Fragen beantworte ich da drin?
Oder vielleicht ist es eben auch so, dass es mehr als ein Formular ist und dann reiße ich halt die Zeit.
Das mit den Perzentilen ist ein guter Punkt.
Also sagen wir mal, 90 Prozent der Benutzer:innen können das innerhalb von zwei Minuten tun.
Gute Ergänzung.
So, der Theo Grip fragt jetzt: Wie schafft man es, immer neue Testkunden zu bekommen, um diese Messungen zu machen?
Und das weist für mich auf ein anderes Thema hin, deswegen finde ich die Frage gut.
Und zwar hört sich das ja ein bisschen an wie ein Akzeptanzkriterium beziehungsweise ein Test, den ich mache.
Quatsch, also Akzeptanzkriterium ist es.
Es ist eben das, womit der Kunde jetzt sagen würde, ja, die Software ist halt irgendwie fein.
Aber es ist halt die Frage, ob das jetzt in einem Test mündet.
So, und das ist halt nicht die Aussage.
Also die Aussage ist: Ich habe das System live gestellt.
Und 90 Prozent der Benutzer:innen können innerhalb von zwei Minuten ein Fahrrad reparieren lassen.
Das heißt also, ich könnte das jetzt in dem Live-System überprüfen und ich weiß dann, dass ich eben diese Sache gerissen habe, wenn das eben nicht so ist.
Und in dem Live-System kann ich es halt tatsächlich, also nicht wenn ich es eingeführt habe, dann werde ich halt herausfinden, ob das halt funktioniert oder nicht.
So, und das impliziert nicht unbedingt, dass das ein Test ist.
Also es bedeutet, was damit kommuniziert ist, ist, dass der Kunde an der Stelle, wo das eben nicht eintritt, mir anschließend sagen wird: Hör mal zu, das war nicht die Lösung, die ich eigentlich haben wollte.
Das ist die Aussage.
So, und der Theo führt jetzt noch weiter an: Naja, nicht alle Nutzer sind gleichmaßen technikaffin.
Genau, guter Punkt.
Das bedeutet also, vielleicht ist die Aussage, naja, kriegen wir halt nicht hin, weil wir haben es halt mit Leuten zu tun, die einfach nicht technikaffin sind.
Und das ist halt unrealistisch anzunehmen, dass die auch ein einfaches Webformular ausfüllen können innerhalb von zwei Minuten, und dann reißen wir das halt.
Und dann können wir sozusagen nichts dafür, aber wir wissen zumindest im Vorhinein, dass wir halt dort dann ein Problem haben werden.
Was ich also versuche zu sagen, ist: Wir kriegen hiermit raus, was der Auftraggeber eigentlich von uns will, was wir in Produktion beobachten.
Und ja, das ist eine schlaue Idee, darauf basierend beispielsweise Tests zu machen.
Und ich glaube, es ist klar, wie wir das machen können.
Aber es ist jetzt nicht so, dass das unbedingt Testszenarien sind, und den Anspruch würde ich daran auch nicht erheben, weil ich will ja jetzt nicht, dass mir der Auftraggeber sozusagen Testszenarien nennt, sondern ich möchte wissen, wann ich für den Auftraggeber etwas Erfolgreiches gebaut habe.
Und darum geht es halt hier an dieser Stelle.
Es ist aber tatsächlich eine Diskussion, die hier mehrmals auftritt, und vielleicht gibt es auch andere Leute, die da eine andere Meinung haben, aber das wäre meine Meinung.
Also ich möchte gerne wissen, wann ich den Kunden zufriedengestellt habe oder den Auftraggeber.
Das wäre eben in dem Fall, wo ich das hier erreiche, und das kann möglicherweise durch Tests nicht gelöst werden.
So, jetzt muss ich mal sehen.
Hier sind noch andere Sachen, die ich mir überlegt habe.
Kunde bewertet das System, vergibt im Schnitt vier von fünf Punkten.
Dann ein Mitarbeiter des Shops würde das System sehr wahrscheinlich anderen empfehlen.
Also Frage: Würdest du dieses System jemand anders empfehlen?
Ja, nein oder nicht, sehr wahrscheinlich, wahrscheinlich, weniger wahrscheinlich.
Hier trifft sicherlich auch wieder das zu, was Felix sagt, dass man da wahrscheinlich eher so, 85 Prozent der Mitarbeiter:innen des Shops würden das System sehr wahrscheinlich weiterempfehlen, sowas in dem Dreh.
Also diese Prozentangaben bräuchte man wahrscheinlich irgendwie überall.
Und dann wäre hier: Ein neuer Mitarbeiter des Shops wird in das System eingearbeitet.
Nach einer Stunde kann er das System eigenständig bedienen.
Das ist also auch, das ist so Erlernbarkeit.
Und das gibt es hier jetzt auch für Fahrradmechaniker:innen.
Und hier ist noch eine Aussage, die ich hier noch habe, ist: Wir haben hier keine IT-Experten.
Das System kann dennoch betrieben werden.
Was auch immer das jetzt bedeutet.
Also wir hatten ja jetzt die Frage über die Ablaufumgebung, und das hier kann jetzt zum Beispiel dadurch gelöst werden, dass man sagt, ihr betreibt es halt gar nicht, sondern es gibt jemand anders, der sich damit beschäftigt.
Oder vielleicht ist es halt super einfach, umzubetreiben.
Brauchen wir ein Bewertungssystem oder sind das Kommentare in anderen Portalen, Foren, Kundenumfragen?
Wäre dann halt, also das ist nicht definiert.
Wir wollen ja sagen, wenn der Kunde befragt werden würde, dann würde er Folgendes sagen.
Ob wir ihn tatsächlich befragen, ist eben noch mal eine andere Sache.
Also das müssen wir jetzt nicht unbedingt einbauen, könnten wir natürlich, wäre vielleicht gar nicht so schlecht.
Ich komme ein bisschen über die Zeit raus.
Ich habe mir noch aufgeschrieben, so als andere Knackpunkte, das ist jetzt so Verfügbarkeit.
Ein Mitarbeiter im Shop will das System zwischen 9 und 18 Uhr benutzen und es steht zu 99 Prozent zur Verfügung.
Und das ist das andere, was ich aufgeschrieben habe: Das System im Shop fällt aus, es steht spätestens nach 30 Minuten wieder zur Verfügung.
Und für das Websystem habe ich dort gesagt, das soll verfügbarer sein.
Quatsch, das war nicht das, was ich kopieren wollte.
Also nicht.
Das Websystem soll zu 99,9 Prozent zur Verfügung stehen und da soll eben die Aus- zwischen 8 und 24 Uhr.
Und zwischen 24 und, sorry, da sollte eigentlich 7 Uhr stehen, also zwischen 7 und 24 Uhr steht es zu 99 Prozent, 99,9 Prozent zur Verfügung.
Und nachts haben wir nicht so viele Kunden, da ist es weniger akzeptabel, aber das System soll schneller wieder anlaufen.
So, das heißt, worauf ich hier einfach hinweisen möchte, ist: Wir haben hier also, also Hintergrund ist, der Shop macht halt um 9 Uhr auf und macht um 18 Uhr zu.
Zu dieser Zeit soll das System irgendwie zur Verfügung stehen.
Wenn es dann um 18 Uhr eine Minute ausfällt, ist es egal, so sagt der Auftraggeber.
Und es ist akzeptabel, wenn es 30 Minuten ausfällt, weil man kann sich 30 Minuten lang irgendwie mit Zettel und Bleistift über Wasser halten in dem Shop, so die Aussage der Person dort.
Und das ist natürlich im Internet irgendwie anders.
Und dort ist eben die Aussage nicht: Jede Minute, die wir halt irgendwie nicht haben, die führt halt irgendwie zu einem Umsatzausfall, also müssen wir da besser sein.
Und ich habe mir noch aufgeschrieben, dass Daten nicht verloren gehen sollen.
Daten, die, also das System fällt aus und wenn die Daten schon vor fünf Minuten erfasst worden sind, dann sollen sie halt praktisch sicher den Ausfall überstehen, damit nicht plötzlich ein Reparaturauftrag irgendwie weg ist.
Das wäre halt einfach unschön.
Und ich habe mir noch als weiteres aufgeschrieben, also wir wissen ja, dass das mit diesem SaaS-System ansteht.
Das heißt, ich habe jetzt aufgeschrieben, das soll nach spätestens zwei Monaten gemacht werden und nicht mehr als 20 Personentage dauern.
Irgendwelche Werte habe ich mir da aufgeschrieben.
So, das sind jetzt so Szenarien.
Und was hier halt für mich wichtig ist, sind eigentlich zwei Dinge.
Die eine Sache ist: Von diesem Gesamtüberblick haben wir im Wesentlichen jetzt also ganz viel im Bereich Usability.
Wir haben so ein paar Sachen im Bereich Reliability und noch diese eine Geschichte in Bezug auf, dass das System eben änderbar sein soll als SaaS-System.
Und die meisten anderen Dinge sind nicht so wahnsinnig wichtig.
Also wir sollten jetzt, wir könnten wahrscheinlich noch weiter graben.
Also zum Beispiel wäre es wahrscheinlich gut, wenn das System nicht Informationen über irgendwelche Kunden nach draußen leckt.
Das ist halt etwas, was hier in Security drin ist mit Confidentiality.
Aber selbst wenn das passiert, es sind halt am Ende Fahrradreparaturdaten.
Ist das wirklich so kritisch?
Da müssen wir also mit dem Experten noch mal sprechen, wenn wir jetzt so ein bisschen diese Hauptpunkte rausgearbeitet.
Und vielleicht zu dem, was das jetzt für mich bedeutet oder wo ich so jetzt sozusagen stehe.
Ich habe jetzt, also ich weiß nicht, wie es euch geht, ich habe jetzt ein besseres Bild von dem System und von dem, was jetzt tatsächlich relevant ist.
Also offensichtlich ist Benutzerfreundlichkeit ein ganz wichtiges Thema.
Es gibt ein Änderungsszenario, was so ein bisschen in der Luft schwebt, und wir haben eher entspannte Anforderungen in Bezug auf Verfügbarkeit.
So, und bei mir ist es jetzt nicht so, dass ich jetzt sagen könnte, das ist die Lösung, die ich bauen würde.
Also da war ja die Frage mit Cloud oder machen wir irgendwas on-premise.
Das ist zum Beispiel eine Geschichte, die wir jetzt diskutieren könnten.
Also auf der einen Seite ist es eben so, dass wir Integrationen haben mit so ein paar lokalen Systemen, zum Beispiel mit der Kasse.
Ist vielleicht in der Cloud schwierig oder vielleicht auch nicht.
Müssen wir mal drüber reden.
Müssen wir mal schauen, wie man das genau hinbekommt.
Auf der anderen Seite haben wir jetzt hier irgendwelche Anforderungen an Verfügbarkeit und eben das Problem, dass es keine IT-Experten gibt.
Das heißt also, diese Constraints würden jetzt beispielsweise genau dieses Betriebsmodell beeinflussen.
Aber es ist jetzt nicht für mich so, dass sich das direkt hier daraus ergibt, welches Betriebsmodell nun tatsächlich angeraten ist, sondern es ist eher so, dass ich irgendwie dastehe und sage: Ich habe besser verstanden, was der Kunde, was der Auftraggeber eigentlich von mir will.
So, und das sind halt auch alles Dinge, die hier oben, wenn ich halt nur die Fachlichen Anforderungen irgendwie sehe, glaube ich überhaupt nicht offensichtlich wären.
Und das ist so der Stand, in dem ich jetzt bin.
Das heißt also, ich habe den Kunden besser verstanden.
Das ist das, was ich, glaube ich, erreicht habe.
Ich habe besser verstanden, was die Constraints sind.
Über eine Lösung würde ich jetzt erst nachdenken.
Das ist der nächste Schritt.
Sind soweit erst mal noch Fragen?
Das scheint nicht der Fall zu sein.
Dann würde ich sagen, erst mal vielen Dank für die Aufmerksamkeit.
Wie gesagt, nächste Woche gibt es ein neues Video bei Softwarearchitektur als Beruf.
Das ist in einer anderen YouTube-Playlist und es ist in einem anderen Podcast.
Also es gibt den Podcast Softwarearchitektur als Beruf, da sind die ganzen Folgen drin.
Und ja, übernächste Woche würde es dann weitergehen.
Vielleicht mache ich noch eine Episode zu Architektur, vielleicht ein anderes Thema, da müsste ich noch mal sehen.
Und da bin ich halt auch auf Feedback gespannt beziehungsweise dafür dankbar.
Und ich gucke noch mal, ob irgendwelche Themen hier sind, die ich nicht …
Ich habe irgendwie so diverse Kanäle, auf denen man sich melden kann, aber da sind keine weiteren Themen.
Dann würde ich sagen, vielen Dank.
Vielen Dank für die Aufmerksamkeit.
Vielen Dank für die Fragen und die Diskussion.
Das war, glaube ich, sehr spannend.
Und ich hoffe, dass wir uns dann in diesem Stream an irgendeinem Zeitpunkt wiedersehen und wünsche ein schönes Wochenende.
Bis dahin.