Der nachfolgende Text wurden mit KI erstellt und kann Fehler enthalten. Fehler gefunden? Bei GitHub editieren
So, dann herzlich willkommen zu einer weiteren Episode von Software-Architektur im Stream.
Und heute geht es nochmal um das Thema “Wir bauen uns eine Software-Architektur.@
Und zwar ist das etwas, was uns jetzt schon zwei Episoden sozusagen verfolgt hat.
Und wir wollen jetzt hier darüber sprechen, wie wir die Qualitätsszenarien eigentlich umsetzen können.
Eigentlich war heute geplant, dass meine Kollegin, die Aminata, hier zu uns stößt.
Das hat nicht geklappt.
Das werden wir nächste Woche machen.
Und nächste Woche geht es dann um das Thema, wie bekommen wir es eigentlich hin, dass wir die Benutzerfreundlichkeit hinbekommen.
Das ist ja irgendwie eine der Hauptanforderungen, die wir jetzt gerade aktuell haben in unserem System.
Und das werden wir dann nächste Woche diskutieren.
War ursprünglich für diese Woche geplant, aber werden wir dann nächste Woche diskutieren.
Gut.
Genau.
Ein Hinweis, wenn ihr die Sketchnotes anschauen wollt, von Lisa, die gibt es parallel in einem zweiten YouTube-Stream.
Könnt ihr auch entsprechend finden.
Da unten steht ja auch Software-Architektur im Stream.
Da auf der Homepage findet man den auch entsprechend.
Ich schaffe es heute nicht, den einzublenden, weil ich irgendwie selber am Miro-Board sitze.
Und da kriege ich das halt nicht hin, gleichzeitig noch die Sketchnotes einzublenden.
So, damit sind wir jetzt eingestiegen.
Wir sind jetzt eigentlich schon beim Thema.
Das heißt also, wir können uns nochmal anschauen, was eigentlich so der Stand ist.
Gebaut hatten wir, diskutiert haben wir über ein System, wo es darum geht, Fahrradreparaturen irgendwie zu organisieren.
Und wir haben hier sowas wie, das war so der Anfang.
Wir haben halt gesagt, es gibt ein Backlog.
Und in dem Backlog ist eben die Kundin, die das Fahrrad zur Reparatur anmelden kann, das abholen kann, vielleicht einen Reparaturtermin wissen möchte, den Status der Reparatur abfragen.
Dann gibt es sowas wie die Shop-MitarbeiterIn, bei der man eben die Reparatur bezahlt und bei der man das Fahrrad zur Reparatur abgibt.
Und dann gibt es die FahrradmechanikerIn, die den Kunden über das Ende der Reparatur informieren wird, Fahrraddefekte aufnimmt und so weiter und so weiter.
Ich will das gar nicht so weit diskutieren.
Und was bisher passiert ist, ist, dass wir zum einen so einen Kontext erstellt haben, wo wir gesagt haben, in der Mitte ist das Reparatursystem.
Und drumherum sind eben ein paar Systeme, die mit dem System sprechen.
Das ist ein Kontextdiagramm.
Und das haben wir dann auch nochmal mit Protokollen irgendwie ausgeführt.
Haben wir so gesagt, wie wir das technisch integrieren wollen.
Und dann haben wir so verschiedene Qualitätsszenarien uns überlegt.
Und haben die alle hier erfasst.
Da sind halt zum einen die in Bezug auf Benutzbarkeit.
Die werden dann keine Rolle spielen.
Und dann die anderen.
Das ist im Wesentlichen Zuverlässigkeit.
Das hat sich ein bisschen herausgestellt als so das Kernthema bei der ganzen Veranstaltung.
Und wir haben beim letzten Mal das System so fachlich aufgeteilt.
Das heißt, wir haben, wie gesagt, es gibt die Terminplanung, es gibt die Durchführung der Reparaturen, die Materialbeschaffung und so weiter.
Und das ist eben die Aufteilung des Systems.
Das heißt, wir können jetzt im Prinzip das System so implementieren, wir wissen, wie wir es aufteilen wollen.
Und das, worum es heute geht, das ist also so ein bisschen der Stand.
Im Chat kommt gerade die Frage, ob ich das Beispiel ändern will auf Ferrari-Reparaturen.
Ich habe heute bei Twitter gesagt, dass ich mir einen Ferrari kaufen werde, um von dem Tankbonus zu profitieren, weil die eben besonders viel Benzin verbrauchen und man dadurch einen besonders hohen Tankbonus bekommt.
Interessanterweise ist es so, dass tatsächlich offensichtlich solche Autos auch sehr reparaturintensiv sind.
Sprich, die sind halt regelmäßig in Reparatur.
Also aus einem kommerziellen Aspekt heraus wäre das vielleicht sogar das bessere Beispiel.
Aber sei es so, wir sind eben bei Fahrrädern.
So genau, das heißt also, fachliche Aufteilung haben wir, wir haben herausgefunden, dass die Benutzerfreundlichkeit wichtig ist, und wir wollen uns jetzt an den Qualitätsszenarien orientieren.
Und das ist so ein bisschen schon das erste, was, glaube ich, wichtig ist für mich.
Ich will halt eine Lösung bauen, die halt irgendwie diese Probleme aus den Qualitätsszenarien löst.
Und das heißt, ich muss jetzt dafür irgendwie Antworten finden.
Und dazu sollten wir uns jetzt mal anschauen, was da eigentlich genau drinsteht.
Hier ist ganz viel zum Thema.
Also Benutzerfreundlichkeit, ich gehe das mal so ein bisschen durch.
Da werden wir also Aminata nächstes Mal mit sozusagen nerven.
Und hier unten steht noch etwas, das ist relevant.
Im Shop sind keine IT-Experten beschäftigt.
Das System kann dennoch betrieben werden.
Das heißt also, wir gehen davon aus, dass wir dort nicht jetzt eine Person haben.
Ich glaube, das ist eine realistische Annahme, der man irgendwie sagen kann, hey, hier ist halt ein Server, installiere auf dem Server ein Stück Software.
Wenn da ein Alarm losgeht, dann passiert da folgendes.
Das bedeutet also, dass wir darauf irgendwie eine Antwort finden müssen.
Ich würde dazu neigen, daraus abzuleiten, dass wir eigentlich nicht ernsthaft einen Server unterstellen können in dieser Fahrradreparaturwerkstatt.
Also wir müssen halt irgendwie was anderes machen, weil es hängt dann noch mit ein paar anderen Szenarien zusammen.
Also hier steht zum Beispiel so was wie, es soll 99 % Verfügbarkeit sein.
Nach 30 Minuten soll das System wieder zur Verfügung stehen.
Und wenn ich jetzt irgendwie sage, okay, ich habe halt einen Server irgendwo untergestellt bei dieser Fahrradreparaturwerkstatt.
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.
Und dann kommt irgendwie noch hinzu, dass hier unten noch diese Anforderung steht: Wir wollen daraus irgendwie auch mal perspektivisch eine Software-as-a-Service-Lösung bauen, die wir anderen Fahrradshops anbieten können oder wollen.
Und da ist halt die Aussage, die Änderung dafür dauert höchstens zwei Monate und benötigt nicht mehr, das ist noch ein Typo, und benötigt nicht mehr als 20 Personentage.
Das heißt, wir müssen halt das System so hinstellen, dass wir es relativ schnell, ohne größere Probleme auch in anderen Fahrradshops installieren können.
Das ist also auch noch mal etwas, was wir uns überlegen müssen.
Und dann sind da noch ein paar andere Themen rund um das Thema Verfügbarkeit.
Anlaufzeiten stehen hier zum Beispiel, und wie lange das, noch ein Typo, und eben Verfügbarkeiten.
Das sind, glaube ich, Dinge, die jetzt nicht so super aggressiv sind, nicht?
Also hier steht zum Beispiel, das System im Shop fällt aus, spätestens nach zwei Minuten kann man den Preis einer erfolgten Reparatur wieder ermitteln, das heißt also, das Ermitteln der Preise der Reparaturen ist besonders wichtig, das ist, glaube ich, das aggressivste Wiederanlaufkriterium, was wir irgendwie haben.
Und das ist also dort eben ein Thema.
So, der Jan fragt jetzt, wenn das System in der Cloud läuft und der Router im Laden ausfällt, ist das System aus Sicht des Kunden nicht erreichbar.
Wie adressieren wir das?
Genau, damit sind wir so zwei Schritte weiter.
Also erstmal bedeutet das, meine Lösungsstrategie wäre halt irgendwie Cloud.
Und das, was der Jan jetzt irgendwie sagt, ist ja nachvollziehbar.
Das heißt also, wenn ich jetzt sage, ich habe exakt einen Router bei diesem Fahrradladen, dann würde das eben dafür sorgen, dass, wenn der Router ausfällt, eben das gesamte System ausfällt, nicht?
Also das ist die Strategie, die mir jetzt eigentlich eingefallen ist.
Es muss ja auch nicht nur eine Cloud-Strategie sein.
Es könnte ja auch sein, dass wir in einem externen Rechenzentrum das machen.
Ich glaube auf jeden Fall.
Also ich persönlich würde jedenfalls ableiten, dass wir einen Server in dem Laden selber ausschließen können.
Dann kommen wir eben zu dem Thema, was der Jan dort zitiert hat.
So und das ist jetzt tatsächlich, finde ich, eine spannende Sache.
Eine mögliche Antwort darauf wäre, ich entwickle ja irgendwie Software, und dass es einen Router gibt, der dafür sorgt, dass mein System nicht erreichbar ist, ist nicht mein Problem, was soll’s.
Das finde ich nicht wirklich hilfreich.
Und das ist auch nicht die Art und Weise, wie ich denke, wie man diese Qualitätsszenarien interpretieren sollte.
Also das Qualitätsszenario sagt, das ist die Erwartungshaltung, die ein Kunde hat.
So, die ist da also jetzt irgendwie formuliert.
Das heißt, die Erwartungshaltung ist in diesem speziellen Fall, das System fällt aus und spätestens nach zwei Minuten kann man den Preis einer erfolgten Reparatur wieder ermitteln.
So, und jetzt gibt es halt bestimmte Szenarien, also zum Beispiel Ausfall der Netzwerkinfrastruktur.
Also zum Beispiel Ausfall eines Routers.
Aber auch zum Beispiel Ausfall des Internet-Providers und so weiter und so weiter, die mir jetzt dort wahrscheinlich ein Problem bereiten.
Und meine Strategie dagegen wäre eigentlich zu sagen, naja, wir können jetzt eine Lösung bauen, die erwartungsgemäß das üblicherweise auf die Reihe bekommt.
Ich bin da vielleicht noch etwas auf der glücklichen Seite.
Ich weiß nicht, wann ich hier das letzte Mal einen Internet-Ausfall hatte.
Und für den Notfall habe ich halt irgendwie noch einen mobilen Router.
Sowas könnte ich ja jetzt in dem Fahrradshop irgendwie auch machen.
Ich könnte also sagen, okay, es gibt einen mobilen Router, der über LTE oder über 5G oder sowas eben die Internetverbindung zur Not redundant hält.
Und ich habe dann eben einen festen Router.
Und ich gehe davon aus, dass das halt üblicherweise funktionieren sollte.
Aber an bestimmten Stellen ist es dann eben einfach vorbei.
Also wenn jetzt irgendwie beide Router ausfallen oder wenn irgendwo in dem Stadtteil das Internet insgesamt von einem Provider ausfällt, weil irgendwo ein Teil der Netzwerkinfrastruktur auf einer anderen Ebene kaputt geht, dann habe ich halt irgendwie ein Problem.
Und das wäre jetzt etwas, was ich, glaube ich, offen mit dem Kunden diskutieren würde und würde halt sagen, okay, wir haben halt dann das Risiko eines Netzwerkausfalls.
Und wir können das versuchen zu lösen.
Also wir können jetzt ein Stück Software bauen, was wir bei dir installieren in deinem Server, den du nicht hast.
Und was dann irgendwie dazu in der Lage ist, diese Preise der erfolgten Reparaturen zu cachen.
Das führt irgendwie zu einer bestimmten Menge an Aufwand und Geld, das wir investieren.
Wollen wir das tun?
So, das ist, finde ich, ein valides Feedback.
Und meine Aufgabe ist es, technisch zu bewerten, wie ich das umsetzen kann.
Und die variable Größe dabei ist eigentlich der Preis.
Das heißt also, ich kann jetzt eben durch entsprechende Entwicklungsmaßnahmen, Infrastrukturmaßnahmen versuchen, das noch unwahrscheinlicher zu machen.
Auch auf der Ebene von Dingen, die außerhalb meines Einflussbereichs sitzen.
Also ich kann jetzt sagen, okay, wir können noch einen mobilen Router daneben stellen.
Wir können eine Netzwerkinfrastruktur machen, die automatisch auf den mobilen Router kommt.
Das heißt, wenn ein Router zurückfällt, wir können, das kostet halt irgendwie einen Router und irgendwelche Netzwerktricks.
Das ist also wahrscheinlich nicht so wahnsinnig teuer.
Wir können bei dir einen Server installieren, der ein Cache ist mit den Preisen der erfolgten Reparaturen.
Das würde bedeuten, wir installieren einen Server.
Das würde bedeuten, wir müssen den irgendwie warten.
Das kriegen wir schwierig hin, weil wir müssen innerhalb von 30 Minuten da sein, sagst du.
Das kostet also deutlich mehr Geld.
Ich kann es nicht genau beziffern, aber es kostet deutlich mehr Geld.
So, und da kann man, glaube ich, dann in eine offene Diskussion gehen.
Meine Erwartungshaltung wäre, dass wir halt über einen Fahrradshop reden und wir wahrscheinlich irgendwie da landen, dass man sagt, naja, okay, dieses Risiko, dass die Verbindung zur Cloud abbricht, ist irgendwie akzeptabel.
Und vielleicht bauen wir dann noch einen mobilen Router als Fallback ein.
Das wäre etwas anderes, wenn wir, weiß ich nicht, über die Maschinensteuerung eines Atomkraftwerks reden oder sowas.
Oder über die Produktionssteuerung in einer Fabrik, wo irgendwie der Ausfall des IT-Systems dazu führt, dass wir halt massive Verluste haben.
Und das ist, glaube ich, eben das, was man da sozusagen als Feedback liefern kann.
Genau, ist also eine gute Frage an der Stelle.
Was machen wir jetzt?
Also ich will jetzt eigentlich nochmal ein zusätzliches Artefakt einführen.
Und zwar haben wir hier vom letzten Mal so eine Bausteinsicht.
Das heißt, wir haben hier irgendwie gesagt, hier ist das System mit den ganzen Umsystemen.
Und ich will jetzt eigentlich an dieser Stelle, also erstmal, was ist jetzt das entscheidende Problem, was ich lösen muss?
Irgendwie muss ich dieses Zeug auf irgendeiner Infrastruktur zum Laufen bekommen.
Und diese Infrastruktur wird mir halt dabei helfen, das Ziel mit der Verfügbarkeit zu lösen.
Das heißt also, von der Vielzahl an Zeug, die ich halt so potenziell haben kann, ich habe ja beispielsweise die arc42-Dokumentation, bin ich jetzt also irgendwo bei dieser Solution Strategy, also wie löse ich die entscheidenden Probleme.
Und eine Möglichkeit ist sowas wie Deployment View, also mal darüber zu diskutieren, wie wir es halt deployen wollen.
Also wir sind ja irgendwo bei vier oder sieben oder sowas.
Das sind also Dinge, die ich jetzt eigentlich erschlagen würde.
Und es macht jetzt vielleicht Sinn, mal ein Deployment View zu machen.
Viele von den anderen Sachen interessieren mich jetzt nicht so richtig.
Also noch tiefer reinzugreifen in, weiß ich nicht, die Building Blocks, oder irgendwelche tollen Dinge darüber zu diskutieren, wie die Building Blocks miteinander interagieren.
Ich habe das Gefühl, dass das in diesem spezifischen Fall nicht so wahnsinnig spannend ist.
Also ich habe das Gefühl, dass das von dem, was wir bei der letzten Session gesehen haben, etwas, wo ich nicht große Themen erwarte.
Das heißt, ich fokussiere mich jetzt auf die Themen, von denen ich eben erwarte, dass sie sozusagen spannend sind.
Und dazu können wir jetzt eben so ein Deployment View machen.
Das heißt, wir können sagen, dass wir irgendwie diese Dinger, diese einzelnen Bestandteile irgendwie mal umsetzen müssen und dann auch deployen müssen.
Und dazu habe ich jetzt unterschiedliche Möglichkeiten.
Eine Möglichkeit wäre, also erstmal sollte ich sagen, was ist die Semantik von meinem Deployment View?
Was ist die Semantik von meinem Zeug hier?
Ich ändere die jetzt.
Das heißt, ich sage hier beispielsweise, das sind, wobei, muss ich gar nicht.
Also das sind separierte Projekte in der Versionskontrolle oder Verzeichnisse im Source Code.
Das ist irgendwie beides noch fein.
Was ich jetzt neu habe, ist eine Deployment-Umgebung.
Das heißt, ich sage jetzt in der Legende, dass ich hier eine Umgebung haben möchte, in der ich das alles deployen kann.
Und da könnte ich jetzt irgendwie einfach sagen, das gesamte Ding wird halt monolithisch deployed als beispielsweise eine EC2-Instanz.
EC2 ist einer von diesen guten alten, einer von den ursprünglichen Amazon Web Services, also ein Cloud-Angebot von Amazon.
Und das sind letztendlich virtuelle Maschinen.
Das heißt, hier würde ich jetzt eben eine EC2-Instanz hinstellen, beziehungsweise, dazu kommen wir gleich, irgendwie mehrere, und würde jetzt eben darauf alles deployen.
Sprich, ich hätte jetzt eben da meine einzelnen, ich hätte einen Deployment-Monolithen und würde das eben komplett deployen an der Stelle.
Und das ist eben aus meiner Sicht jetzt eine Deployment-Aussage.
Hinweis dabei: Ich habe mir jetzt irgendwie meine eigene Legende geschaffen für das Diagramm.
Und ich glaube, das ist halt irgendwie auch fein.
Also da könnte ich jetzt auch noch was machen.
Also da könnte ich jetzt auch ein offizielles UML-Diagramm malen.
Ich finde das nicht so unbedingt notwendig, aber das wäre halt eine Alternative.
Also hier freestyle ich jetzt eher.
Eine andere Alternative, die ich hätte, wäre, dass ich das anders mache.
Also logisch, sonst wäre es ja keine Alternative.
Und zwar könnte ich jetzt hier zum Beispiel entscheiden, dass ich sage, ich habe jeweils Container.
Das ist vielleicht einfacher.
Das heißt, ich sage jetzt, ich habe einen Container, in dem die Terminplanung läuft.
Ich habe einen Container, in dem die Reparatur durchgeführt wird.
Ich habe einen Container, in dem die Bezahlung existiert.
Und ich habe einen Container, in dem die Materialbeschaffung funktioniert.
Und das würde jetzt implizieren, dass ich so was wie EKS benutze, also einen Kubernetes-Service oder irgendwas, was halt Container abbilden kann.
Und dann würde sich halt auch die Semantik dieser roten Dinger ändern.
Das wären dann eben Docker Images.
Also dann würde ich halt sagen, ich habe ein Docker Image für Bezahlung.
Ich habe ein Docker Image für Materialbeschaffung und so weiter.
Die laufen halt irgendwie in diesen Containern.
Und das können dann ein oder mehrere Projekte in der Versionskontrolle sein.
Das ist dann halt irgendwie egal.
Das heißt, ich hätte jetzt eben die Semantik dieser roten Dinger geändert.
Ist das jetzt irgendwie spannend?
Also ist das eine relevante Architekturentscheidung?
In Bezug auf die Qualitätsziele oder Qualitätsszenarien würde ich behaupten, hat das keinen Einfluss.
Also das eine wie das andere bekomme ich halt irgendwie genauso verfügbar.
Es gibt vielleicht einen kleinen Einfluss, weil ja hier die Aussage ist, dass insbesondere der Preis einer Reparatur wieder ermittelt werden 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 den Bezahlungscontainer.
Und jetzt könnte ich halt zum Beispiel sagen, okay, der Bezahlungscontainer, der wird halt redundanter ausgelegt, mit einer höheren Menge an Redundanz als die anderen Container.
Also da könnte ich halt versuchen, dieses Qualitätsziel zum Beispiel eher zu erreichen.
Aber es ist jetzt irgendwie nicht so, dass diese Entscheidung wesentlich beeinflusst, wie ich halt meine Qualitätsziele erreiche.
Das heißt also, die Frage Microservices oder nicht, halte ich hierfür relativ irrelevant.
Also das untere ist halt eine Microservices-Frage.
Ich kriege hier aber nochmal eine andere Information und eine andere Idee.
Und zwar sollte ich hier, ja, Jan schreibt gerade, die Latenz zwischen Containern dürfte zur Latenz zwischen Laden und Rechenzentrum zweitrangig sein.
Genau, ich würde also einen HTTP-Request hier irgendwie hinschicken.
Würde hier die Information über die Bezahlung bekommen.
Und das wäre halt der alleinige Container, der dafür verantwortlich wäre.
Das heißt, die anderen würden sich darum nicht kümmern, werden dort nicht involviert.
Und ich könnte jetzt eben von dem Bezahlungscontainer, weiß ich nicht, fünf Instanzen laufen lassen und von den anderen nur zwei.
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.
Die hilft ja nur für die Ausfallsicherheit.
So, was ich aber hier nochmal überlegen kann, ist, das ist Information, die ich hier eigentlich schon finde.
Sprich, diese Kommunikation mit den anderen Systemen.
Und das könnte ich jetzt hier mal technisch ausführen.
Das heißt, ich kann jetzt zum Beispiel sagen, also der Webshop soll irgendwie integriert sein.
Und da würde ich jetzt Links haben.
Das heißt, es würde halt ein Link von dem Webshop hin zu der Terminplanung gehen.
Es würde ein Link von dem Webshop hin zu Reparaturen durchführen gehen.
Und es würde ein Link existieren von dem Webshop hin zur Bezahlung.
Das ist alles irgendwie machbar.
Ich muss halt nur in der Cloud Zugriffe dafür realisieren.
Das ist kein Problem.
Das Rechnungswesen hatte ich irgendwie gesagt, da gibt es halt irgendwie REST als Kommunikation.
Und genau hier sollte ich also nochmal hinschreiben, dass das jetzt Protokolle sind.
Und das andere, was ich jetzt habe, ist: Also hier gibt es auch irgendeine Integration, meinetwegen mit REST.
Also die Online Payment Services werde ich sicher aus der Cloud anschließen können.
Die Kasse, damit meine ich tatsächlich das Kassensystem, will ich irgendwie auch mit REST anschließen.
So, und hier gibt es jetzt noch irgendwelche Systeme für SMS-Versand und für E-Mails.
Da könnte ich, wenn ich in der Cloud bin, also in der Amazon Cloud beispielsweise, könnte ich halt den Simple Email Service für E-Mails benutzen.
Das heißt, das kriegt man halt auch irgendwie hin.
So, 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, dass 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, so dass 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, es hat mir jetzt tatsächlich was 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 analog gelten.
Also Moment.
Jetzt habe ich bedauerlicherweise die Bausteinsicht dafür torpediert.
Also das wäre hier eben bei den Microservices genau dasselbe Thema.
Da müsste ich also exakt dieselbe Frage beantworten.
Das heißt, ich kann irgendwie diese beiden Post-its da auch mal rüberkopieren.
Weil das wäre hier halt irgendwie auch ein Thema.
Das heißt, ich habe jetzt ein Risiko identifiziert.
Und das ist halt auf jeden Fall hilfreich.
Das kann mir halt im Extremfall die Lösungsstrategie zerstören.
Ich kann halt 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 einen Server installieren oder irgendwas auf dem Kassensystem machen oder was auch immer.
Das ist dann eben das, womit ich mich da beschäftige.
So genau.
Also was ich jetzt wichtig finde, weil ich das Gefühl habe, das kommt halt sonst auch sehr leicht unter die Räder, ist die Frage: Habe ich jetzt eigentlich grob eine Idee, wie ich diese Probleme, die Herausforderungen, die ich durch die Qualitätsszenarien hier manifestiert habe, lösen möchte?
So.
Und ich fände das nicht schlecht, wenn man beispielsweise in der Lösungsstrategie das direkt adressieren würde.
Ich mache das jetzt hier mal, weil wir hier nicht irgendwie einen Text schreiben, mache ich das mal ein bisschen ad hoc.
Das heißt, wir diskutieren halt.
Hier ist also die Aussage, im Shop sind keine IT-Experten beschäftigt.
Das System kann dennoch betrieben werden.
Meine Antwort, die ich bis jetzt dazu gegeben habe, ist, ich benutze die Cloud.
So.
Und dadurch habe ich eben keinen Server, auf dem Software installiert werden muss.
Ich habe also nur eine Webadresse und muss da halt ein paar Ansätze sozusagen den Leuten beibringen.
Aber das ist etwas, wo ich davon ausgehe, dass das machbar ist.
Die Frage ist jetzt, reicht das eigentlich?
Und ich würde sagen, nee, das reicht irgendwie nicht, weil es kann sein, dass irgendwelche Dinge ausfallen.
Das ist ja trotzdem denkbar.
Also ich muss vielleicht irgendwie Updates installieren von irgendwelchen Dingen, weil es Security-Probleme gibt oder so.
Das heißt, ich brauche schon irgendwie einen eigenen Support.
So und irgendwie ist das jetzt hier noch nicht dramatisch.
Also zum Beispiel eine neue Version der Software installieren.
Das ist etwas, was man wahrscheinlich irgendwie EntwicklerInnen noch mit aufzwingen kann.
Das ist also noch nicht so ein großes Problem.
Genau, Jan sagt halt gerade noch bezüglich dieser Kassendiskussion, dass man einen Kassenproxy im Laden positionieren könnte.
Genau, das wäre jetzt eine mögliche Lösung für eben dieses Kassenproblem.
Aber ich weiß jetzt auf jeden Fall, das Ergebnis ist, ich weiß, dass ich da ein Problem habe, das ich lösen muss.
Und was halt auch tatsächlich wichtig ist, also was es halt fragwürdig macht, ob ich das Problem überhaupt lösen kann.
Das ist jetzt irgendwie nicht so, dass ich sage, ja, kein Thema.
So, jetzt lass uns mal weiter schauen.
Jetzt steht hier, ein Mitarbeiter im Shop will das System zwischen 9 und 18 Uhr benutzen und es steht zu 99 % zur Verfügung.
Da ist wieder die Frage, also nochmal, was ich jetzt gerade versuche, ist, ich möchte gerne versuchen herauszufinden, ob ich diese Probleme tatsächlich jetzt löse.
Und da ist jetzt tatsächlich eine Verfügbarkeitsangabe.
Wenn ich jetzt erstmal profan drübergehe, würde ich sagen, das sollte eigentlich funktionieren.
99 % bedeutet zwischen 9 und 18 Uhr, das heißt also an einem Tag, was sind das, 9 Stunden?
Ein Hundertstel von 9 Stunden sind 0,09 Stunden.
Das sind also, was sind das?
3 Minuten.
3 Minuten oder sowas.
Das ist also, glaube ich, prinzipiell erstmal machbar.
So, und jetzt ist es aber eigentlich so, also wenn ich das jetzt wirklich ernst nehme, und ich sollte das ernst nehmen, weil das ist eines der wenigen Qualitätsszenarien, was ich habe, also offensichtlich ist das eine Anforderung, die Kunden halt tatsächlich ernst meinen, die halt wichtig ist, dann sollte ich da mal genauer reingucken.
Und da gibt es halt einen Bereich, den ich persönlich ziemlich spannend finde, und das sind halt die SLAs von EC2 oder EKS, also von den Amazon-Services in Bezug auf Kubernetes und EC2.
Und, also Disclaimer, ich erzähle halt hier was über Amazon, weil das irgendwie die Cloud ist, über die ich am meisten weiß.
Ich nehme mal an, dass das in anderen Clouds ähnlich sein wird.
So, und was in diesen SLAs drinsteht, ist, die garantieren eine Verfügbarkeit von 99,99 % im Monat.
Das hört sich ja erstmal super an, hört sich an, als könnten wir das Ziel irgendwie erreichen.
So, jetzt ist halt die Frage, was bedeutet Verfügbarkeit?
Und die Definition von Verfügbarkeit ist, dass, wenn mehr als eine Availability-Zone in der Region ausfällt, dann ist das nicht verfügbar.
Das heißt also, ein Ausfall einer Availability-Zone ist noch kein Ausfall.
Das ist kein Ausfall des Systems, das steht dort drin, das ist ein juristischer Text.
Ein Ausfall bedeutet, dass mehr als eine Availability-Zone in der Region ausgefallen ist.
Was sind Regions und Availability-Zones?
Regions sind sowas wie EU-West-1 zum Beispiel, das ist irgendwie Frankfurt, wenn ich mich recht entsinne.
Und die Availability-Zones sind Rechenzentren.
Das heißt also, in Frankfurt gibt es jetzt irgendwie mehrere Rechenzentren.
Das sind die Availability-Zones.
Also so ungefähr, nicht genau genommen, es ist nur die Aussage, die fallen unabhängig voneinander aus.
Das heißt, die Aussage, die Amazon trifft, ist, du musst darauf vorbereitet sein, dass eine Availability-Zone ausfällt.
Erst wenn mehr als eine Availability-Zone ausfällt, dann gilt das überhaupt als ein Ausfall unseres Systems.
Das heißt also mit anderen Worten, was wir jetzt auf jeden Fall machen müssen, ist, wir müssen irgendwie unser System verteilen auf mehrere Availability-Zones.
EKS, der Kubernetes-Cluster, macht das offensichtlich automatisch.
Da müsste ich dann nur dafür sorgen, dass ich mehrere Container-Instanzen laufen habe.
Bei EC2 müsste ich so einen Elastic Load Balancer davor stecken und dafür sorgen, dass ich mindestens zwei EC2-Instanzen dementsprechend habe.
Das ist also jetzt etwas sehr Konkretes, was sich ableitet aus unserer Verfügbarkeitsanforderung.
Wenn ich also ernsthaft einigermaßen verfügbar sein will, muss ich in der Amazon Cloud diese Voraussetzung treffen.
Und Verfügbarkeit ist ein relevantes Thema.
Und daraus würde ich also jetzt für mich ableiten, dass ich mindestens diese Voraussetzung schaffen muss.
Und das ist jetzt eben etwas, was, denke ich, hilfreich ist.
Also nochmal irgendwie darauf zu schauen, was da eigentlich genau steht.
So, jetzt ist das nächste Thema.
Und genau, was steht da noch weiter?
Also für eine EC2-Instanz garantieren sie 90 % Verfügbarkeit pro Stunde.
Nicht-Verfügbarkeit bedeutet keine Konnektivität.
Das heißt also auch hier eher der Hinweis, nimm mal mindestens zwei EC2-Instanzen.
So, jetzt ist hier die andere Frage, was zum Teufel passiert denn eigentlich, wenn das System mit weniger als 99,99 % zur Verfügung steht?
Das ist ja das, was uns immer so juristisch sozusagen interessiert.
Da steht drin, dass man halt anschließend eine Dienstgutschrift bekommt.
Das heißt also, die Zeit, die das System als ausgefallen gilt, wird nicht abgerechnet.
Mit anderen Worten: 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 einer ähnlichen Diskussion wie die Diskussion, die wir vorhin hatten auf Basis der Rückfrage von dem Jan.
Da war ja auch das Ergebnis, wir können jetzt mehr Geld in die Hand nehmen, um dafür zu sorgen, dass wir dort dazu in der Lage sind, mit höherer Wahrscheinlichkeit Ausfallsicherheit zu erzeugen.
Und jetzt ist es was Ähnliches.
Also was das ja eigentlich bedeutet, ist, 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 andere Region 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, nicht?
Also ich hätte jetzt kein Problem damit zu sagen, wir gehen mit dieser Lösung in Produktion, weil meine Vermutung wäre, dass das halt nicht ernsthaft ein wirkliches Problem ist und dass es halt hinreichend unwahrscheinlich ist.
Der Jan fragt gerade über Datenreplikation, genau, dazu kommen wir gleich noch, das ist auch noch ein Thema, was in Bezug auf die Technologieauswahl dann sozusagen eine Rolle spielen wird.
So, also was ich hier versucht habe zu sagen, ist, am Ende ist das dann etwas, wo auch eine gewisse Unsicherheit bleibt, weil eben das, was uns dort Amazon garantiert, im Notfall bedeutet, dass wir auf Geld sitzen bleiben.
Und ich finde, da ist es nochmal wichtig, sich zu überlegen, also fein, ich kann mich ja jetzt gegen die Amazon Cloud entscheiden.
Das heißt, ich könnte jetzt sagen, ich benutze Google oder Microsoft, das wäre eine Alternative.
Da könnte ich jetzt nachrecherchieren, ob die halt dort irgendwie anders dastehen.
Das kann ich mir nicht vorstellen, weil ein ökonomisches Modell, wo der Anbieter der Cloud beispielsweise für Schadensersatz gerade steht, kann eigentlich nicht funktionieren.
Das wird also ähnlich sein.
Kann ich mir nicht vorstellen, also das wird wahrscheinlich nicht helfen.
Ich könnte ein eigenes Rechenzentrum hinstellen.
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 und ich glaube auch, dass es teurer ist.
Also vielleicht ist das hier tatsächlich die beste Lösung.
Und trotzdem, also wenn sozusagen mein Leben davon abhängt, dass diese 99 Prozent Verfügbarkeit halt auf jeden Fall immer gewährleistet sind, dann würde ich ja vielleicht etwas anders vorgehen.
Aber ich kann jetzt auf einer kommerziellen Ebene, glaube ich, darüber nochmal diskutieren.
So, und das andere, was ich hier jetzt irgendwie mache, also was sich daraus ergibt, ist irgendwie, ich brauche halt einen eigenen Support, der jetzt zum Beispiel angerufen werden kann.
So, das wäre jetzt auch meine Antwort auf dieses Thema hier unten.
Shop-System fällt aus.
Und die 30 Minuten sollten wir hoffentlich erreichen.
Das wäre auch meine Antwort hier, in Bezug auf die zwei Minuten, die ein System maximal ausfallen darf, um den Preis zu berechnen.
Weil ich halt denken würde, dass das in der Cloud-Lösung auch kein großes Problem darstellt.
Und das wäre auch hier die Antwort für die Verfügbarkeit im Web.
Und das wäre halt auch hier die Antwort für das Web-System.
Und für den Wiederanlauf.
So, allerdings muss ich gestehen, dass wir jetzt, spätestens an dieser Stelle, nicht?
Also hier ist es jetzt, hier ist es so, dass wir halt sagen, zwischen 9 und 18 Uhr, für die Sachen im Shop.
Das wäre also etwas, wo ich noch sagen könnte, okay, wir haben halt irgendwie eine Entwicklerin, die sich um das Thema im Wesentlichen kümmern kann.
Die kümmert sich eben um das.
Hier wird es dann schwierig, weil das ist von 7 bis 24 Uhr und von 24 bis 7 Uhr, das ist also ein 24/7-Support.
Das heißt, ich brauche jetzt hier irgendwie, spätestens an dieser Stelle, brauche ich irgendwie einen 24/7-Support.
Ich brauche jemanden, der in Rufbereitschaft ist und das bedeutet jetzt wieder ein ganz anderes Thema.
Das bedeutet nämlich, dass ich tatsächlich jemanden haben müsste, der eben nachts um zwei sich rausklingeln lässt und das wird wahrscheinlich keine Entwicklerin sein.
So, hier steht jetzt noch das Thema, dass Daten nicht verloren gehen sollen, und da würde ich jetzt als Lösung, im Amazon-Universum gibt es da RDS, das ist der Datenbank-Service von denen.
Da gibt es dann zum Beispiel ein Oracle oder MySQL, also ich bin da jetzt mal konservativ unterwegs.
Und, also sprich, ich will jetzt nicht irgendwie eine NoSQL-Datenbank oder sowas aufbauen, sondern ich benutze halt einfach eine relationale Datenbank, so wie die meisten Projekte.
Und da muss man nochmal in die RDS-SLAs reingucken.
Die sagen nach dem, was ich recherchiert hatte, was Ähnliches, also die garantieren dort auch eine entsprechende Verfügbarkeit, so dass ich erwarten würde, dass das halt einfach funktioniert.
Ich glaube aber, dass sie den Datenverlust eben tatsächlich nicht getrennt nochmal garantieren.
Genau, der Jan sagt, wäre die Abschätzung Server versus Cloud als ADR festzuhalten.
ADR sind diese Architecture Decision Records, wo ich also tatsächlich eine Entscheidung festhalte mit Alternativen.
Und sage, warum ich mich wie entschieden habe.
Das ist auch etwas, was man in arc42 beispielsweise einführen kann als eigenes Kapitel.
Ich finde das prinzipiell auch eine gute Idee.
Ich würde es hier jetzt nicht unbedingt nehmen, weil das sind so zentrale, also mein Problem, was ich mit ADRs habe, ist, dass die das Potenzial haben, einfach unstrukturiert irgendwelche Entscheidungen zu enthalten.
Und hier ist es so, dass wir über die Kernentscheidung des Systems gehen.
Das wäre für mich eher eine Solution Strategy.
Die Idee an sich, nochmal die Abwägung hinzuschreiben, das ist, glaube ich, eine sehr, sehr wichtige.
Weil, nicht, also nochmal, es ist halt fein, wenn man sagt, Cloud ist nicht die Lösung für uns.
Da muss ich eine andere Alternative finden.
Ich mit meinem jetzigen Wissen und meinem jetzigen Ansatz würde aber sagen, dass eben die Cloud die beste Lösung ist, und wenn ich das irgendwo festgehalten habe und gesagt habe, was mich zu dieser Meinung bewegt, dann kann man darüber diskutieren.
Und das ist, glaube ich, hilfreich.
Übrigens, eine Sache, die ich auch nochmal recherchiert habe, ist GDPR oder DSGVO.
Das ist auch eine Sache, die halt in der Amazon Cloud irgendwie machbar ist.
Das heißt, da ist halt auch kein Killer-Argument, sondern das kann man jetzt eben da irgendwie reinschreiben.
So.
Jetzt haben wir da unten noch die Aussage, das System soll jetzt als SaaS-Lösung anderen Fahrradshops angeboten werden.
Die Änderung dauert höchstens zwei Monate und benötigt nicht mehr als 20 Personentage.
So, und da wäre jetzt, also, wenn ich da jetzt irgendwie sage, Cloud ist halt die Lösung, das ist halt extrem profan.
Ich würde jetzt sagen, ich baue das System von vornherein mandantenfähig.
Also, Mandantenfähigkeit ist die Fähigkeit, innerhalb des Systems verschiedene Fahrradshops anzulegen.
Das brauche ich nicht für das erste System, weil da gibt es nur einen Fahrradshop.
Ich könnte also durch die Tür kommen mit einem System, das halt nur exakt einen Fahrradshop betreiben kann.
Das wäre halt denkbar.
Ich bin mir aber sehr unsicher, ob ich jetzt innerhalb von zwei Monaten mit 20 Personentagen ein System, das ohne Rücksicht auf Mandantenfähigkeit geschrieben worden ist, so umschreiben kann, dass es Mandantenfähigkeit umsetzt.
Und deswegen wäre jetzt meine Maßnahme, von vornherein Mandantenfähigkeit einzubauen.
Das ist wiederum etwas, über das man diskutieren kann.
Also es führt wieder zu Kosten.
Also ich kann jetzt dem Kunden sagen, wir investieren also jetzt mehr Geld für diese initiale Entwicklung.
Wir bauen da für die initiale Entwicklung überflüssige Flexibilität ein, weil wir das hier vorhersehen, dass eben, das ist ja das, was du gerne möchtest, diese Mandantenfähigkeit dort irgendwie drin zu haben.
Und das kann man dann auf der Basis diskutieren.
Und es ist ja auch irgendwie fein, wenn dann ein Kunde oder irgendein Entscheider sagt, dann killen wir halt diese Anforderung.
Grundsätzlich ist hier noch ein abstrakteres Konzept.
Ich baue jetzt Flexibilität in die Architektur ein, die ich nicht brauche.
Ist das in diesem Fall eine sinnvolle Entscheidung?
Ja, weil meine Aussage ist, ich schaffe es sonst nicht, dieses Qualitätsszenario umzusetzen.
Das ist aber etwas, wo ich die Änderung vorhersehen kann und sie auch mit dem Kunden auch diskutiert habe.
Ich würde jetzt beispielsweise nicht, wir hatten das ja vorhin mit dem Ferrari-Reparaturshop, ich will jetzt nicht das System so auslegen, dass es auch dazu in der Lage ist, die italienischen Sportwagen zu reparieren, weil der Kunde nicht gesagt hat, dass er das will.
Das macht also keinen Sinn.
Das hier macht Sinn.
Das heißt also, ich würde nur an der Stelle Flexibilität anbauen und Dinge halt einbauen, wo ich die Zukunft entsprechend antizipieren kann und spätestens an der Stelle, wo ein Qualitätsszenario steht und ich das mit dem Kunden diskutiert habe, ist das, glaube ich, ausreichend sicher.
Als dass ich es halt bei mir in der Architektur mal ernsthaft betrachten kann.
Zweiter Mandant gleich zweites Deployment, ja, gute Frage.
Das wäre wahrscheinlich auch nochmal was, was man diskutieren könnte.
Nicht, also Skalierbarkeit, können wir zwei, drei, zehn, hundert Fahrradshops mit dem System erschlagen.
Wobei dort irgendwie meine Vermutung wäre, dass wir halt vielleicht mit zwei, drei oder zehn noch keine Probleme haben, sodass das irgendwie nicht das Thema ist, was mich jetzt intensiv umtreibt.
Also es wäre jetzt nichts, worauf ich fokussieren würde.
Das, worauf ich halt fokussieren würde und was, glaube ich, irgendwie auch noch mal ein ganz wichtiges Thema ist, ist das Thema mit den Drittsystemen.
Wir haben ja jetzt gerade eben gesagt, okay, mein System soll irgendwie dazu in der Lage sein, sich an das Drittsystem anzuschließen, an das Rechnungswesen, und ich soll mich halt auch an die Kasse anschließen können.
Ich gehe mal davon aus, dass andere Fahrradshops andere Kassensysteme haben und andere Rechnungssysteme.
Jetzt ist halt die Frage, wie kriege ich es hin, diese Systeme dort auch zu erschlagen?
Weiß ich nicht.
Sollte man abklären und das könnte eben dazu führen, also das wird wahrscheinlich zu einer Einschränkung führen, dass man dann sagt, okay, wir können eben nur bestimmte Kassensysteme integrieren oder nur bestimmte Rechnungssysteme oder vielleicht gar keine oder weiß der Teufel was?
So, das ist auf jeden Fall etwas, was ich hier noch mal jetzt untersuchen sollte, könnte, müsste, muss und was ich eben auch aus den Qualitätsszenarien ableite.
So, ich würde jetzt eigentlich behaupten, dass wir damit die wesentlichen Dinge entschieden haben, die durch die Qualitätsszenarien auf unsere Agenda gesetzt worden sind.
Wir können jetzt darüber diskutieren.
Das, was ich hier mir überlegt habe, eine gute Lösung ist oder eine schlechte Lösung, aber wir haben halt erstmal welche und das ist etwas, was ich in vielen Architekturentwürfen sonst vermisse.
Also ich vermisse zum einen die Qualitätsszenarien und wenn die Qualitätsszenarien da sind, dann ist es so, dass ich die klaren Antworten auf diese Qualitätsszenarien vermisse.
Und das haben wir hier nicht.
Wir sind jetzt erstmal so weit, dass wir sagen können, für jedes dieser Qualitätsszenarien haben wir eine Lösung, da können wir vielleicht sogar einen Euro-Preis dran setzen, aber wir können natürlich darüber diskutieren, ob es bessere Lösungen gibt und das ist aber dann eine andere Diskussion, nicht?
Also wir laufen jetzt zumindest nicht völlig nackt in irgendein Messer rein.
Achso, der Jan fragt halt gerade.
Guter Punkt.
Statt der Mandantenfähigkeit könnte man halt auch eine zweite Instanz betreiben.
Das habe ich eigentlich für mich ausgeschlossen, weil ich glaube, dass dann die Kosten explodieren.
Aber das ist ein guter Punkt, nicht?
Also das ist eigentlich auch etwas, wo man einen Trade-off jetzt diskutieren kann, wo man nämlich irgendwie sagen kann, okay, du hast jetzt zwei Möglichkeiten.
Entweder wir bauen es halt von vornherein mandantenfähig, dann werden wir halt bei den Shops weniger Instanzen benötigen oder wir bauen eben für jeden Shop eine eigene Instanz, dann werden die halt später die Betriebskosten irgendwie hochgehen.
Was möchtest du denn gerne haben?
So, wenn man das zum Beispiel irgendwie Serverless macht, vielleicht ist das dann auch sogar kostengünstig machbar, nicht?
Weil bei Serverless bezahle ich eben nur die Instanzen, die halt zu einem bestimmten Zeitpunkt überhaupt aktiv sind.
Genau.
Also eine Alternative.
So, also wie gesagt, für mich ist halt diese Kausalkette von Qualitätsszenarien hin zu Lösungen, diese beiden Themen, habe ich Qualitätsszenarien, habe ich Lösungen für die Qualitätsszenarien, das ist für mich relevant.
Wenn wir jetzt, also wenn ich mich jetzt morgen an den Rechner setzen müsste und das System implementieren sollte, dann haben wir ja sowieso ein Problem.
Wir haben ja noch ein paar Themen, von denen wir wissen, dass wir sie vorher erklären müssen, nicht?
Drittsystem, Integration mit Kassensystemen beispielsweise.
Wir haben noch ein paar Sachen, die wir mit dem Kunden diskutieren müssen.
Nehmen wir jetzt mal an, dass wir das getan hätten.
Da müssen wir trotzdem noch entscheiden, welche Programmiersprache benutzen wir?
Welche Libraries benutzen wir?
Wie bauen wir halt irgendwie das Frontend?
Das sind aber Dinge und das sind vielleicht, also wie soll ich sagen, diese Voraussetzungen muss ich schaffen, bevor ich mich an die Tastatur setze.
Das ist sehr klar.
Aber das sind Dinge, die ich vielleicht, die ich jetzt gar nicht entscheiden muss, beziehungsweise die halt nicht so relevant sind.
Genau, jetzt können wir doch mal die Sketchnotes sehen von Lisa an der Stelle.
Wir müssen diese Sachen entscheiden, aber die sind nicht mehr so richtig spannend.
Und die hängen irgendwie auch nicht jetzt von den Qualitätsszenarien ab, sondern wenn es halt um sowas geht wie Programmiersprache oder so, hängt es zum Beispiel davon ab, welche Sachen die EntwicklerInnen gewöhnt sind.
Das heißt also, ich würde es halt wahrscheinlich mit Java machen, weil das ist irgendwie die Programmiersprache, mit der ich mich am wohlsten fühle und mit der ich irgendwie am meisten Ahnung habe.
Irgendjemand anders wird es mit irgendwas anderem machen und das wäre wahrscheinlich irgendwie auch fein.
Und analog wäre das für Cloud-Anbieter, nicht?
Also ich würde es halt mit Amazon machen, weil ich kenne irgendwie Amazon, wie man ja erkennt.
Aber wenn jemand anders halt sagt, ich mache es halt lieber mit Google, ist das halt irgendwie auch fein.
Und das bedeutet halt, als ich das vorbereitet hatte, hatte ich hier irgendwie so das, tatsächlich das Gefühl, also subjektiv, das kann eigentlich nicht eine ausreichende Architektur sein.
Und das ist es in gewisser Weise auch nicht, also insofern, als dass ich eben noch ein paar Sachen brauche, bevor ich mich an die Tastatur setzen kann.
Aber wir haben für den aktuellen Informationsstand und die aktuellen Dinge, die uns der Kunde auf den Schreibtisch gelegt hat, eine Lösungsstrategie.
Und das ist halt eine, bei der ich nicht irgendwie rot werde, wenn ich die nach draußen diskutieren muss, nicht?
Also wir wissen, dass die funktionieren sollte.
Die Anforderungen, die wir hier im Bezug auf Verfügbarkeit haben, sollte ich da mit erschlagen können.
Benutzerfreundlichkeit diskutieren wir irgendwie noch beim nächsten Mal.
Also ich glaube, damit sind wir eigentlich, stehen wir eigentlich gut da.
Und deswegen will ich eigentlich, also abgesehen von der Benutzerfreundlichkeit in der nächsten Episode, hiermit auch dieses Thema mit der Architektur für diesen speziellen Fall erstmal beschließen, weil ich glaube, wir sind an einem vernünftigen Stand.
Und ich finde es wichtiger, jetzt zu sagen, okay, wir haben halt die wichtigen Punkte identifiziert mit dem aktuellen Informationsstand, als jetzt irgendwie noch ganz viele Entscheidungen zu treffen, wie zum Beispiel Programmiersprache oder so, die eigentlich eher beliebig sind.
Und das Gefühl, dass wir keine ausreichende Architektur haben, dem würde ich eher dann mit einem iterativ inkrementellen weiteren Architekturvorgehen begegnen.
Also wenn wir jetzt dieses Projekt machen, werden wir weitere Anforderungen haben.
Und ich gehe auch davon aus, dass der Kunde irgendwie sagen wird, hey, hör mal zu, ich habe folgende Sachen nicht beachtet.
Und jetzt oder jetzt, wo es halt eine SaaS-Lösung ist, haben wir folgende andere Themen oder was auch immer.
Und dann werden wir nachsteuern müssen.
Und das ist, glaube ich, wichtiger.
Also ich weiß nicht, ob das eine gute Idee ist, aber ich glaube, das ist eine gute Idee.
Ich werde ja sicher in der nächsten Woche noch in meinem Heise-Blog einen Artikel veröffentlichen zu dem Thema, dass zukunftssichere Architekturen irgendwie ein Problem sind.
Und da steckt das ein bisschen drin.
Also wenn ich mich jetzt irgendwie hinstelle, ich glaube, es ist gefährlich, zu sagen, das ist jetzt die Architektur, so ist sie, so bleibt sie und die ist irgendwie jetzt in Stein gegossen.
Anstelle dessen finde ich es eigentlich gar nicht schlecht, wenn man sagt, okay, das ist halt, wir haben jetzt erstmal die Probleme gelöst, die sozusagen absehbar sind.
Es ist klar, dass wir halt in einem Monat oder in zwei Monaten oder so an dem Zeug irgendwie nochmal was drehen müssen.
Ich glaube, das ist deutlich besser und hilft halt auch, sozusagen Erwartungen zu managen.
Genau, Dieter hat gerade gesagt, Cloud und Multitenant wäre die effizientere beziehungsweise kostengünstigere Lösung.
Stimmt, Lambda, Azure Functions wäre eine weitere Möglichkeit.
Ich möchte dem eigentlich widersprechen, also da steht ja Cloud und Multitenant, also dass wir eben Mandantenfähigkeit haben, ist auf jeden Fall die kostengünstigere Lösung.
Ich würde behaupten, das ist ein Trade-off.
Wir werden halt mehr Entwicklungszeit reinstecken und dann dafür auf der anderen Seite Betriebskosten sparen.
Und da gibt es irgendwann ein Break-even.
Also wenn das mit dem Software as a Service nie kommt, dann ist es sinnlos, diese Entwicklungsarbeit überhaupt zu investieren, um das multitenantfähig zu machen.
Dann wäre es geschickter gewesen, zu sagen, meine Antwort darauf, dass wir ein SaaS machen, ist, dass wir mehrere Instanzen deployen, weil ich das für so unwahrscheinlich halte, dass ich jetzt keinen Bock habe, da in die Entwicklung zu investieren.
Und das wäre dann eben eine kostengünstige Lösung.
Und ich gewinne insbesondere dann, wenn eben die Anzahl der Tenants steigt.
Ich gewinne dann natürlich bei dieser Multimandantenfähigkeit, wenn die Anzahl der Mandanten irgendwie 1.000 oder so was ist.
Also wenn sie sehr hoch ist.
Aber das wissen wir nicht.
Es sind Betriebskosten versus Entwicklungskosten.
Das ist ein Trade-off und da können unterschiedliche Ergebnisse rauskommen.
So, was ist jetzt meine wesentliche Nachricht?
Also der eine Satz, den ich loswerden will, Die Architektur soll von den Kundenbedürfnissen ausgehen.
Das ist eine Trivialität.
Also das unterschreibt man sozusagen blind.
Aber was ich eigentlich sagen wollte, ist, ich sollte eben für jedes Qualitätsszenario irgendwie eine Antwort haben.
Und diese Antwort sollte so sein, dass ich sie geben kann, ohne dabei rot zu werden.
Das ist eben auch zum Beispiel der Grund, warum ich jetzt hier an dieser Stelle bei dem Thema mit der SaaS-Lösung, also wenn ich dann nur gesagt hätte, hey, wir laufen halt schon auf der Cloud und deswegen ist das mit der SaaS-Lösung kein Problem.
Wenn ich halt ehrlich zu mir bin, würde ich halt an dieser Stelle irgendwie rot werden, weil ich muss irgendwie damit umgehen, dass ich mehrere Kunden habe.
Und das hat eben zur Folge, dass die andere Drittsysteme haben.
Darauf sollte ich eine Antwort haben.
Und ich muss irgendwie damit umgehen, dass ich mehrere Kunden habe und die müssen halt auf irgendwelchen Systemen laufen.
Das ist das, was wir diskutiert haben mit Mandantenfähigkeit oder eben mehreren Deployments.
Da müssen wir halt irgendwie auch eine Antwort haben.
Das heißt, da reicht eben Cloud alleine nicht aus.
Und das ist das, was ich eigentlich meine.
Und ich glaube, dieser Sanity Check, den ich jetzt durchgeführt habe, wo ich irgendwie nochmal gesagt habe, hey, was sind eigentlich die Qualitätsszenarien?
Habe ich darauf Antworten?
Das ist, glaube ich, an der Stelle hilfreich.
Genau, Dieter gibt mir recht.
Das ist super.
Vielen Dank.
Und wie gesagt, das ist auch nicht wirklich Haarspalterei.
Ich glaube, das ist halt tatsächlich…
Also, wie gesagt, da sind Szenarien denkbar bei Mandantenfähigkeit, wo das irgendwie sinnvoll ist, und andere, wo es eben offensichtlich nicht sinnvoll ist.
Ach so, genau.
Und das ist der andere Punkt, den ich auch noch machen wollte: Es ist halt total sinnvoll, eine Flexibilität in das System einzubauen für absehbare Dinge.
Ich halte mittlerweile nichts mehr von diesem You ain’t gonna need it.
Also das ist dieser Spruch, der aus der XP-Fraktion kam, wo eben gesagt worden ist, wenn jemand sagt, das ist eine Anforderung, dann beantworte ich das grundsätzlich mit, nein, wir werden das halt nicht brauchen.
Ich halte das für nahezu Gehirnwäsche.
Ich finde es halt fein, wenn mir der Kunde, wie in diesem speziellen Fall, sagt, hey, hör mal zu, wir wollen da halt irgendwie ein SaaS draus bauen.
Und wenn ich darauf halt eine Antwort finde und dann halt irgendwie sage, okay, das bedeutet halt, du musst am Anfang mehr Geld investieren, willst du das tun?
Dann kann man halt eine Unterhaltung darüber führen und ich finde, das ist total valide.
Ich würde halt dem Kunden nie im Leben an der Stelle sagen, you ain’t gonna need it, bauen wir nicht.
Frau Bauti schreibt, wir haben das hier ja jetzt in circa drei Stunden abgearbeitet.
Wie lange würde es denn in einem echten Gespräch mit einem echten Kunden ungefähr dauern?
Naja, also das, was ich hier jetzt gemacht habe, ist kein Gespräch mit dem Kunden.
Also eigentlich war das Gespräch mit dem Kunden das, was wir ausgeblendet haben.
Das ist halt, also wir haben ja das Ergebnis hier im Rahmen dieser Qualitätsszenarien uns irgendwie angeschaut.
Und das, was wir hier gemacht haben, ist tatsächlich Architekturarbeit.
Wir haben halt angenommen, dass diese Qualitätsszenarien abgestimmt sind.
Und wir haben jetzt Architektur auf Basis dessen halt entworfen und brauchen jetzt nochmal ein Feedback mit dem Kunden.
Ich finde die Frage schwer zu beantworten und bin eigentlich geneigt dazu zu sagen, ich würde so lange mit dem Kunden sprechen, bis ich halt das Gefühl habe, dass ich es verstanden habe, was die eigentlich wollen.
Und das andere, genau, das hatte ich halt nicht erwähnt, es gibt diesen wunderschönen Qualitätsbaum, wo all diese ganzen Qualitätssachen drinstecken.
Ich muss mal kurz schauen, ob ich den hatte.
Und der hilft einem dabei, nochmal irgendwie darüber nachzusehen, ob man halt tatsächlich alles, was relevant ist, abgefragt hat.
Also da stehen halt die ganzen verschiedenen Dinge drin.
Ich muss mal kurz schauen, ob ich den, nee, das kriege ich im Moment nicht hin.
Oder doch?
Nein, im Moment nicht.
Also das ist eben, das ist dieser ISO-25010-Qualitätsbaum, der irgendwie all diese ganzen Qualitätsattribute, Security und so weiter diskutiert.
Und der hilft mir dabei herauszufinden, ob das, was ich da bauen möchte, ob ich da halt irgendwie alle wesentlichen Informationen abgefragt habe.
So, und wie lange das halt mit dem Kunden dauert, weiß ich nicht.
Es hängt eben tatsächlich sehr stark vom Kunden ab.
Und da sind manchmal, also da gibt es in meiner Wahrnehmung, in der Realität häufig unangenehme Probleme.
Ein unangenehmes Problem, was man beispielsweise haben kann, ist, dass der Kunde sich weigert, Entscheidungen zu treffen.
Dann hat man halt irgendwie ein Problem.
Oder das andere unangenehme Problem ist, der steht gar nicht zur Verfügung.
Ja, das heißt, also wie soll ich sagen, die Frage, wie lange dauert das, steht in meiner Vorstellungswelt ein bisschen zurück hinter: Sorg erstmal dafür, dass du überhaupt den Kunden hast und dass du mit dem redest und dass du halt irgendwie ausreichend ausquetscht und halt diese Informationen auf den Tisch bekommst.
Und wie lange das dauert, ist sekundär.
Insbesondere ist das eben gut investierte Zeit, weil ich dadurch vermeide, dass ich halt am tatsächlichen Ziel sozusagen vorbeiarbeite.
Genau, das vielleicht noch als abschließende Bemerkung.
Es gibt ja Software-Architektur als Beruf.
Das ist auf der Webseite software-architektur.tv, da gibt es eben Software-Architektur als Beruf.
Und da erzählen Leute so aus der Praxis, wie ihr beruflicher Werdegang da war.
Und mein Kollege, der Gernot Starke, auch ein Fellow bei der INNOQ, hat dort auf die Frage, was denn sein schlimmstes Erlebnis war, eben tatsächlich berichtet von einem Fall, wo er eine Lösung gebaut hat, die eben nicht den Ansprüchen des Kunden genügt hat, weil eben das Thema mit den Qualitäten nicht funktioniert hat.
Und das ist, glaube ich, der Grund, warum er das Thema wichtig findet.
Und ich finde das Thema ja eben auch wichtig, wie man hier sieht, weil das eben einfach sehr unterbelichtet ist in den allermeisten Fällen.
Dann würde ich sagen, vielen Dank.
Und dann wünsche ich noch ein schönes Wochenende.
Vielen Dank.
Und wir sehen uns dann nächste Woche hier zum Thema Benutzerfreundlichkeit und Software-Architektur dann mit meiner Kollegin Aminata.
Bis dahin.