Ernsthaft? Wirklich? Ist das tatsächlich so? So, und dann könnte man halt eine Diskussion führen und könnte halt sagen, naja, okay, also wenn eine Reparatur angenommen wird, dann kann ich das vielleicht länger. Aber wenn ich das jetzt irgendwie abhole, muss ich ja dem Menschen das Geld abknöpfen. Dafür brauche ich halt diese Information. Aha, okay. Das heißt, ich könnte jetzt das nochmal weiter detaillieren und könnte halt sagen, okay, die Information, wie viel diese Reparatur tatsächlich gekostet hat, wenn das Fahrrad abgeholt wird, das ist sogar noch wichtiger. Das muss halt, da darf es halt höchstens zwei Minuten ausfallen oder so. Können wir jetzt auch aufschreiben, nicht spätestens nach zwei Minuten kann man den Preis einer erfolgten Reparatur wieder ermitteln. So, und jetzt habe ich wieder was fachlich über dieses System gelernt, nicht? Also Annahme von Reparaturen nicht so kritisch wie irgendwie dieses Ermitteln von dem Preis. Und eine profane Möglichkeit, das zu lösen, ist, dass ich halt an der Stelle, wo die Reparatur fertig ist, irgendwie so ein Ding ausdrücke, das halt ans Fahrrad kleben. Und da steht irgendwie dran, diese Reparatur hat übrigens zehn Euro gekostet. Dann hätte ich das halt in gewisser Weise erledigt. Oder ich habe irgendwo eine Tabelle, die fest abgelegt ist, wo das eben drauf drin steht oder weiß da drauf was. Da kann man sich halt was ausdenken, nicht? Also das kriege ich halt irgendwie hin.

Jetzt würde ich ja mal…​ 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, wie ich die lösen möchte? 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 in den Text schreiben. Das heißt, wir diskutieren halt. Hier ist also die Aussage, im Shop sind keine IT-Experten beschäftigt, das System kann dann auch betrieben werden. Meine Antwort, die ich bis jetzt dazu gegeben habe, ist, ich benutze die Cloud. Und dadurch habe ich eben keinen Server, auf dem Software installiert werden muss. Ich habe also nur eine Webadresse und muss da 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. Und es kann halt auch sonst nicht. Also ich muss irgendwie Updates vielleicht installieren von irgendwelchen Dingen, weil es Security-Probleme gibt oder so. Das heißt, ich brauche schon irgendwie einen eigenen Support. 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. Jan sagt gerade noch bezüglich dieser Kassendiskussion, dass man eine 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 auch, 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 halt fragwürdig macht, ob ich das Problem überhaupt lösen kann. Jetzt sagen wir nicht so, dass ich sage, ja, kein Thema. So, jetzt lass uns mal weiterschauen. Jetzt steht hier, ein Mitarbeiter im Shop will das System zwischen 9 und 18 Uhr benutzen und es steht zu 99% zur Verfügung. Ich möchte versuchen herauszufinden, ob ich diese Probleme tatsächlich jetzt löse. Da ist jetzt tatsächlich eine Verfügbarkeitsangabe. Wenn ich jetzt erstmal profahren drübergehe, würde ich sagen, das sollte eigentlich funktionieren. 99% bedeutet zwischen 9 und 18 Uhr, das heißt also an einem Tag 9 Stunden. Ein Hundertstel von 9 Stunden sind 0,09 Stunden, das sind also 3 Minuten oder so. Das ist also, glaube ich, prinzipiell erstmal machbar. Wenn ich das jetzt wirklich ernst nehme, und ich sollte das ernst nehmen, weil das ist eines der wenigen Qualitätsszenarien, die ich habe, also offensichtlich ist das eine Anforderung, die die Kunden tatsächlich ernst meinen, die wichtig ist, dann sollte ich da mal genauer reingucken. Da gibt es einen Bereich, den ich persönlich ziemlich spannend finde, und das sind die SLAs von EC2 oder EKS. Also von den Amazon Services in Bezug auf Kubernetes und EC2. Also Disclaimer, ich erzähle hier etwas über Amazon, weil das 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 drin steht, 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 erreichen. So, jetzt ist halt die Frage, was bedeutet Verfügbarkeit? Und die Definition von Verfügbarkeit ist, dass 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 des Systems. Das steht dort drin, das ist ein juristischer Text, das steht drin. 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 gibt es 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 mehr Rechenzentren, das sind die Availability Zones. Also so ungefähr, genau genommen 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 eine 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 ich würde, 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. 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, nehmen wir halt 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 Amazon juristisch sozusagen zusichert. So, da steht halt drin, dass man halt anschließend eine Gutschrift bekommt. Das heißt also, die Zeit, die das System als ausgefallen gilt, wird nicht abgerechnet. Mit anderen Worten, also die Hoffnung wäre ja, dass dieses System mehr Wert generiert, als es im Betrieb kostet. Sonst macht das, was wir hier gerade tun, ökonomisch keinen Sinn. Das heißt also, ein Ausfall dieses Systems wird trotzdem einen ökonomischen Schaden erzeugen. So, da sind wir wieder bei diesen…​ Also, das ist eine ähnliche Diskussion, wie die Diskussion, die wir vorhin hatten, auf Basis der Rückfrage von dem guten Jan. Also, da war ja auch das Ergebnis, wir können halt jetzt mehr Geld investieren und mehr Geld in die Hand nehmen, um dafür zu sorgen, dass wir dort dazu in der Lage sind, mit höherer Wahrscheinlichkeit eine Ausfallsicherheit zu erzeugen. Und hier ist das jetzt was Ähnliches. Also, was das hier eigentlich bedeutet, ist, wenn Amazon morgen den…​ Also, nicht wenn EU West 1, die gesamte Region, aus irgendwelchen Gründen nicht mehr existiert, weil halt in Frankfurt eine große Katastrophe ist, ein großes Feuer und da ist halt irgendwie nichts mehr, dann würde das eben bedeuten, dass wir halt eine Dienstgutschrift haben und wir würden sinnvollerweise auf eine Region irgendwie ausweichen. Aber wir hätten halt dort trotzdem einen Ausfall. Das heißt, wir können das, was hier steht, eigentlich nicht wirklich garantieren. Aber ich würde sagen, es ist hinreichend unwahrscheinlich. Also, ich hätte jetzt kein Problem damit, zu sagen, wir gehen mit so einer Lösung in Produktion, weil meine Vermutung wäre, dass, wenn das System ausfällt, mehr ausfällt, als wir hier sagen oder als wir hier zusagen, dass das halt nicht ernsthaft ein wirkliches Problem ist und dass es halt hinreichend unwahrscheinlich ist. Jan fragt gerade über Datensynchronisation. Genau, dazu kommen wir gleich noch. Das ist auch noch ein Thema, was uns in Bezug auf die Technologieauswahl dann sozusagen eine Rolle spielt. So, also, was ich hier versuche zu sagen, ist, am Ende, wenn wir jetzt sagen, 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 entschuldigen. Das heißt, ich könnte jetzt sagen, ich benutze halt Google und Microsoft. 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. Wenn sozusagen mein Leben davon abhängt, dass diese 99% Verfügbarkeit auf jeden Fall immer gewährleistet sind, dann würde ich da vielleicht etwas anders vorgehen. Aber ich kann jetzt eben auch mit einer kommerziellen Person darüber noch mal diskutieren. So, und das andere, was ich hier jetzt mache, also was sich daraus ergibt, ist, dass ich jetzt auf der einen Seite die Möglichkeit habe, ich glaube, ich darüber noch mal diskutieren. So, und das andere, was ich hier jetzt mache, also was sich daraus ergibt, ist irgendwie, ich brauche halt einen eigenen Support, der jetzt zum Beispiel daraus telefoniert 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, also 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ümmern sich eben um das jetzt mit. 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 2 Uhr 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, da gibt es der RDS, das ist der Datenbank-Service von denen. Da gibt es zum Beispiel einen Oracle oder MySQL. Also ich bin da jetzt mal konservativ unterwegs. Also sprich, ich will jetzt nicht irgendwie eine NoSQL-Datenbank oder sowas aufbauen, sondern ich benutze einfach eine Relational-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 sagen, das 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. Der Jan sagt, es wäre die Abschätzung Server 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 Arc 42 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, 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, 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 in der Immersion Cloud 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 als SaaS-Lösung auf anderen Fahrradjobs angeboten werden. Die Änderung dauert höchstens zwei Monate und benötigt nicht mehr als 20 Personentage. 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. Mandantenfähigkeit ist die Fähigkeit, innerhalb des Systems verschiedene Fahrradjobs 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 denkbar. Ich bin mir aber sehr unsicher, ob ich jetzt innerhalb von zwei Monaten mit 20 Personentage ein System, das ohne Rücksicht auf Mandantenfähigkeit geschrieben wird, anbiete. Das ist wiederum etwas, über das man diskutieren kann, es führt wieder zu Kosten. Ich kann dem Kunden sagen, wir investieren jetzt mehr Geld für die initiale Entwicklung, wir bauen für die initiale Entwicklung überflüssige Flexibilität ein. Weil wir das hier vorhersehen, 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 das ist ja auch irgendwie fein, wenn dann ein Kunde oder ein 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 Änderungen vorhersehen kann und sie auch mit dem Kunden diskutiert habe. Ich würde jetzt beispielsweise nicht, wir hatten das ja vorhin mit dem Ferrari Reparaturshop, ich würde jetzt nicht das System so auslegen, dass es auch dazu in der Lage ist, die italienischen Sportwagen zu reparieren, weil das hat der Kunde nicht gesagt, dass der Kunde das will. Das macht also keinen Sinn. Das hier macht Sinn, das heißt also, ich würde nur an der Stelle Flexibilität einbauen und Dinge einbauen, wo ich die Zukunft entsprechend antizipieren kann. Und spätestens an der Stelle, wo hier ein Qualitätsszenario steht und ich das mit dem Kunden diskutiert habe, ist das glaube ich ausreichend sicher, dass ich das bei mir in der Architektur mal ernsthaft betrachten kann. Zweiter Mandant, gleich zweites Deployment. Ja, gute Frage. Das wäre wahrscheinlich auch nochmal ein Thema, das man diskutieren könnte. Also Skalierbarkeit. Können wir 2, 3, 10, 100 Fahrradshops mit dem System erschlagen? Wobei dort irgendwie meine Vermutung wäre, dass wir halt vielleicht mit 2, 3 oder 10 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 auch nochmal ein ganz wichtiges Thema ist, ist das Thema mit dem Drittsystem. Wir haben ja jetzt gerade eben gesagt, okay, mein System soll irgendwie dazu in der Lage sein, mich an das Rechnungswesen anzuschließen 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. Das ist auf jeden Fall etwas, was ich hier nochmal jetzt untersuchen sollte, könnte, müsste, muss und was sich eben auch aus den Qualitätsszenarien ableitet. 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.