# AI vs Human Architecture Decision Records

**Podcast:** Software Architektur im Stream
**Published:** 2026-10-14

## Transcript

So, dann herzlich willkommen zur Keynote von den Infodays und gleichzeitig einem Softwarearchitektur-Stream-Stream.
Wir wollen sprechen über den Architektur-Touring-Test.
Ich bin Ebert Wolf, genau, und Ralf ist der andere Kollege.
Ja, kurz über mich.
Ich mache irgendwie ganz viel so im Bereich Softwarearchitektur.
Ich bin ein Berater und wir machen eben gemeinsam auch Softwarearchitektur im Stream.
Wir haben da irgendwie Sachen zum Thema Softwarearchitektur und sind eingeladen worden, die Keynote zu machen und freuen uns, hier sein zu dürfen und diese Einladung.
freuen uns halt über die Einladung.
Und es geht halt darum, dass wir verschiedene Architekturentscheidungen haben und jetzt schauen wollen, ob man herausfinden kann, ob das AI oder ein Mensch ist.
Und außerdem schauen wollen, welches die bessere Entscheidung ist.
Ralf, willst du noch zwei Worte über dich sagen?
Ja, ich mache viel mit KI.
Ich mache viel zu viel mit KI.
Das ist viel zu ungesund.
Und deswegen freue ich mich, dass ich hier KI einsetzen konnte, hier bei dem Architekturing-Test.
Genau.
Genau.
Das war das andere, wir haben es gerade auf der Folie geschrieben, es sind mindestens bei Heise in den Kommentaren und auch bei LinkedIn hat der Tom Ase gesagt, dass es ja eigentlich Architekturing-Test heißen sollte und deswegen haben wir das Tour dann hier nochmal durchgestrichen.
Genau.
Dann fangen wir an, oder?
Das würde ich denken, genau.
Und mir kommt die Ehre zuteil, den Anfang zu diskutieren.
Also es geht halt, die Frage ist ja, in welchem Kontext wir jetzt diese Architekturentscheidung, das sind halt ADRs, definieren wollen.
Und dafür haben wir uns so einen Fahrradreparatur-Shop ausgedacht.
Das ist ja was, was ich im Stream tatsächlich mal benutzt habe, um eine Architektur aufzubauen.
Und dadurch gibt es da halt irgendwie schon diverse Dinge rund um die Architektur.
Und wir haben hier jetzt irgendwie drei ADRs, die das halt so ein bisschen erweitern, also Architektur Decision Records.
Und hier ist so ein KI-generiertes Bild von einem Fahrradreparaturshop.
Wenn man genau hinguckt, würde ich bei diesem Fahrradreparaturshop nicht arbeiten lassen, weil das Oberrohr von diesem Fahrrad ist irgendwie kaputt.
Ich glaube auch die zweite Pedale fehlt.
Also die müsste eigentlich sichtbar sein.
Ja, auch ein guter Punkt.
Genau.
Und Bremsen hat das Fahrrad auch nicht, braucht es auch nicht.
Ja, und kurz noch eine Meta-Sache, die habe ich vergessen.
Fragen sehr gerne hier im Chat.
Beantworten wir sehr gerne.
Vorhin in der Begrüßung hieß es ja auch, dass das eben eine Sache ist, die vorteilhaft ist.
Man kann hier also einfach so Fragen reinwerfen und die beantworten wir sehr gerne.
Das ist einer der Gründe, warum wir irgendwie dieses Stream-Format haben, um genau diese Interaktivität hinzubekommen.
Gut, dann gucken wir uns mal die nächste Folie an.
Genau, das heißt, wir haben einen relativ kleinen Shop, so mit einigen wenigen Mitarbeitenden.
Wir haben einen Webshop.
Über den Webshop kann man Sachen bestellen und irgendwie gibt es auch eine Integration Richtung Reparatursystem.
Man soll irgendwie Reparaturen mindestens bezahlen können und irgendwie auch Reparaturtermine anfragen können.
Ich habe, wie gesagt, das in drei Folgen irgendwie mal ausgewalzt, also über drei Stunden insgesamt, wie man das bauen kann.
Und wir machen jetzt halt drei weitere ADRs, die so ein bisschen offen geblieben sind.
Und diskutieren die.
Und wir sehen auf der nächsten Folie dann, wir sehen auf der nächsten Folie dann, Kontextdiagramm, das ist auch tatsächlich von der Episode sozusagen ein Screen, fast ein Screenshot.
Bei der Episode war das halt horizontal, ich habe das hier irgendwie nochmal, Quatsch, vertikal, ich habe das hier in horizontal umgemalt.
Also es gibt halt Menschen, die dieses System benutzen, die Shop-MitarbeiterInnen, die halt irgendwie, ja, Fahrräder entgegennehmen.
Das ist, glaube ich, das, was sie im Wesentlichen tun.
Dann gibt es die FahrradmechanikerInnen, die halt sich hinstellen und sagen, okay, was habe ich mit dem Fahrrad eigentlich getan?
Da wird irgendwie Zeit erfasst.
die eingebauten Ersatzteile werden erfasst und dann gibt es dann die Kundinnen, die halt gerne einen Termin haben wollen.
Das sind so im Wesentlichen die drei Akteure, die es da halt gibt.
Und dann gibt es halt an weiteren Systemen ein SMS und ein E-Mail-Versand, um halt Informationen über Termine und so etwas halt rauszuschicken.
Dann gibt es eine Integration mit der Kasse, weil man ja Dinge bezahlen möchte.
Dann gibt es eine Integration mit einem Online-Payment-System, genau genommen, wenn ich es richtig entsinne, über den Webshop.
Dann gibt es eine Integration zu dem Rechnungssystem, weil ich die Rechnung erstellen muss und die in die Buchhaltung müssen.
Integration zum Webshop habe ich schon gesagt, da kann man Termine buchen für eine Reparatur.
Und dann gibt es insbesondere, das ist auch etwas, was uns noch verfolgen wird, das ist eine Grundlage für einen der ADRs, eine Integration mit der Webshop User Datenbank.
Das heißt, an der Stelle, wo ich jetzt sage, ich möchte gerne eine Reparatur machen, kann ich sagen, ich bin übrigens der E-Bart und ich bin bei euch Kunde.
Dann gehe ich halt zu der Webshop-Userdatenbank und authentifiziere mich halt darüber.
Ich glaube, das ist ein wichtiger Punkt, diese Trennung zwischen Webshop und Reparatursystem.
Dass da zwei Systeme vorhanden sind.
Werden wir gleich noch in den ADRs merken.
Genau.
Und auf der nächsten Folie.
Also es gibt jetzt Qualitätsziele.
Architektur wird ja getrieben durch Qualitätsziele und ein wesentliches Qualitätsziel ist halt Benutzerfreundlichkeit.
Das heißt, wir wollen halt dafür sorgen, dass neue MitarbeiterInnen sich innerhalb von einer Stunde einarbeiten können und dass man innerhalb von zwei Minuten eine Reparatur beauftragen kann.
Aus meiner Sicht ist das etwas, was häufig so bei Architekturarbeit ein bisschen vernachlässigt wird, dass eigentlich Benutzerfreundlichkeit häufig sehr wichtig ist.
Ich glaube, hier ist das sehr spürbar.
Also die MitarbeiterInnen.
sind halt effizienter und effektiver, wenn dieses System vernünftig funktioniert und wir sind am Markt besser präsent, wenn wir die Kundinnen mit Benutzerfreundlichkeit überzeugen.
Dann kommt etwas, was tatsächlich eine Rolle spielen wird für einige von den Architekturentscheidungen, über die wir reden.
Ich sollte noch in Bezug auf Benutzerfreundlichkeit sagen, da gab es dann anschließend noch eine Episode mit der Aminata, wo ich dieses Thema auch nochmal diskutiert habe.
Da könnt ihr euch also mir anschauen, wie man sowas irgendwie erreicht.
Dann gibt es halt dieses Thema mit dem SaaS.
Ich sehe auch gerade, also offensichtlich ist das etwas, was andere Leute auch so sehen, dass Benutzerfreundlichkeit wichtig ist.
Danke für den Kommentar.
Und bei dieser Entwicklung Richtung SaaS ist halt die Idee, dass man halt aus diesem Angebot für diese Reparaturunterstützung auch ein Software-as-a-Service anbieten kann.
Das wird dann also vom Reparaturschropp ein Softwareanbieter werden.
Und da war die Aussage, dass wir das innerhalb von zwei Monaten mit 20 Personentagen Aufwand auf die Reihe bekommen wollen würden.
Das heißt, wenn wir etwas bauen, sollte das etwas sein, was irgendwie auch in diese Richtung erweiterbar ist.
Wir haben eine bestimmte Verfügbarkeit, dazu kommen wir später nochmal.
Das ist meiner Ansicht nach hier stark verkürzt.
Also wir differenzieren halt zwischen den Betriebszeiten im Shop tatsächlich, also wo Menschen im Shop arbeiten.
Und dann den Online-Sachen kommen wir aber noch zu.
Und genau, ich habe aufgelegt, das ist auch etwas, was noch eine Rolle spielen wird.
Also wir sind keine Bank, nicht?
Das heißt, also was wir machen ist Fahrrad reparieren.
Und das heißt, die Beträge, die wir halt irgendwie haben, sind, weiß ich nicht, Hunderte von Euros höchstens.
Und viele von den Dingen, also wie soll ich sagen, wenn ich halt jemandem ein Fahrrad rausgebe, werde ich irgendwie nochmal kontrollieren, ob die Person tatsächlich die Person ist, die sie halt vorgibt zu sein, ob ich der das halt wirklich geben kann.
Und das heißt, viele von den Dingen, die wir jetzt irgendwie in den IT-Systemen haben, werden, glaube ich, dadurch relativiert, dass wir da irgendwie noch eine zusätzliche Sicherheit haben.
Kommen wir aber noch zu.
Und dann kommen wir zu der nächsten Folie.
Achso, genau.
Das heißt, wir haben jetzt so ein blindes Experiment.
Das heißt, was wir jetzt als Format haben, ist halt erstmal die Frage, was ist denn eigentlich die Frage, über die wir diskutieren wollen?
Also was ist das der ADR?
Was soll das da beantworten?
Dann haben wir zwei...
ADRs, A und B.
Und eine ist von einem Menschen erstellt, das war ich.
Und die andere ist halt von einer AI erstellt, da hat sich Ralf drum gekümmert.
Genau, aber letztendlich eben irgendeine AI.
Ich weiß gar nicht welche.
Das war Claude Opus, ich glaube sogar 5.5.
Genau, dann stimmen wir das ab.
Es gibt zwei Dimensionen.
Es gibt halt einmal die Dimension mit, ich glaube, das ist die AI.
Und dann irgendwie die andere Dimension mit, ich glaube, das ist halt der bessere Entwurf.
Achso, und ich sollte noch sagen, da ist noch dieser Lautsprecher.
Wir haben gerungen, wie wir das irgendwie vernünftig vorstellen und sind dann, und Alf ist auf die Idee gekommen zu sagen, naja, dann lassen wir eine AI das einfach vorlesen.
Das werden wir jetzt also tun.
Dadurch haben wir also ein neutrales Ding, was jetzt irgendwie die Folien einfach vorliest.
Etwas, was man normalerweise in der Präsentation nicht machen sollte, aber hier machen wir es halt wegen der Neutralität, sonst müsste einer von uns das vorstellen und wir verraten uns möglicherweise.
Dann stimmt ihr ab und dann gibt es halt anschließend am Ende die Auflösung über alle drei ADRs.
Und damit bist du dran, Ralf.
Genau.
Und damit möchte ich noch ein bisschen erzählen, wie das Ganze entstanden ist, wie die KI damit umgegangen ist.
Eberhard hat ja schon gesagt, dass er diese drei Folgen gemacht hat, aufgenommen hat, in diesen drei Folgen genau die Architektur erklärt hat, wie er hingekommen ist.
Und das hat die KI genommen.
Und ja genau, das waren diese drei Folgen mit Sketchnotes von Lisa Maria Schäfer.
Also alles sehr gut dokumentiert.
Und die KI hat sich tatsächlich die Folgen angeguckt.
Sie hat die Videos gezogen, hat Audio von Video getrennt, hat das Ganze transkribiert und hat dann eben, diese Transkription gehabt.
Und ihr seht vielleicht rechts schon, dann kriege ich einen Jot-Token.
Also so schreibt man das nicht.
Aber das ist, was Visper verstanden hat.
Und das Faszinierende daran ist, finde ich, Visper versteht eben Wörter.
Und Claude ist dann hergegangen und hat versucht, aus dem Kontext dann die falsch verstanden Wörter eben auch zu rekonstruieren.
Unten rechts habt ihr einen QR-Code.
Da kommt ihr auf die ARC 42 Dokumentation des Webshops, den die KI ja dann daraus erstellt hat.
Und was ich da ganz cool finde, ist, da gibt es dann natürlich so Sachen, hier Qualitätskriterium.
Wo wurde das eigentlich gesagt?
Ja, und da hat die KI tatsächlich...
alle Informationen genommen und sie weiß ja, wo sie was rausgehört hat, hat das tatsächlich eingebaut.
Da gibt es Zeitmarken mit Sprüngen in diese drei MP3s.
Man kann mit dem Cursor drüber gehen, sieht den Text, man kann ihn sich nochmal vorlesen lassen, wenn man eben denkt, da wurde irgendwas falsch verstanden.
Spannend war auch aus meiner Sicht, die KI hat, ich glaube, 17 Entscheidungen rausgelesen.
Die sind aber feingranulare als das, was man jetzt in der Architektur niedergeschrieben hätte.
Aber die KI hat halt das genommen, was sie eben rausgelesen hat und damit feingranulare gearbeitet.
Genau, darf ich noch eine Sache ergänzen?
Also zum einen ist es so, dass ich, ich weiß nicht, ob du es gesagt hast, aber da unten steht halt der...
der Link, unter dem man das halt auch angucken kann im Internet.
Und die andere Sache ist, ich habe so gearbeitet, also die Episode ist glaube ich von 22, die ist älter oder 23 oder so, ist also mehrere Jahre alt.
Ich habe jetzt auf Basis der, ich habe die ADS gemacht auf der Basis von dem, was ich erinnert habe.
Und da sind so Miro-Boards mit zum Beispiel so etwas wie diesem Kontextdiagramm.
Das heißt, das, was du jetzt gerade gezeigt hast, diese ganze Dokumentation, die da entstanden ist, habe ich mir nicht angeguckt, um eben da sozusagen eine saubere Umgebung zu haben, die ja nicht AI beeinflusst ist.
Genau.
Was auch interessant ist mit den Miro-Boards, die KI kann tatsächlich damit umgehen.
Das war vor...
Zwei Jahre, sage ich mal, noch nicht so der Fall.
Sie konnte zwar Bilder erkennen, aber sie konnte halt tatsächlich nur normale Bilder erkennen.
Sie konnte mit Diagrammen nicht viel anfangen.
Mittlerweile kann sie mit den Diagrammen wirklich was anfangen.
Sie erkennt, wo welches Element ist, wo Verbindungen bestehen.
Sie kann sogar ein Bild, wenn sie merkt, da brauche ich eine bessere Auflösung, kann sie sogar reinzoomen und sich Details angucken.
Also da hat sich echt viel getan mit der KI, sodass das jetzt alles möglich ist.
Genau.
Und dann sind wir schon beim ersten Problem, was wir mit einem ADR lösen wollen.
Stellst du es kurz vor?
So hatten wir es, glaube ich, zumindest abgesprochen.
Genau, die Frage ist halt, wie sich jetzt Menschen, die ja tatsächlich im Shop arbeiten, an diesem System anmelden.
Kundinnen, da kommt auch noch irgendwie in ADR, melden sich halt im Wesentlichen bei dem Workshop an.
Und da geht es halt einmal eben um das Thema mit der Verfügbarkeit.
Das heißt, wir haben halt bestimmte Anforderungen daran, wie verfügbar das halt sein soll, weil wenn das System halt nicht da ist, kann ich halt irgendwie keine Reparaturen aufnehmen und das ist halt irgendwie doof.
Security ist so nicht ganz so wichtig.
Dann gibt es halt irgendwie genau den Webshop, über den wir ja gesprochen haben.
Das ist irgendein Shop, den die halt irgendwie gebucht haben.
Es gibt keine echte IT im Shop.
Das heißt, wir nehmen halt an, dass das eben Menschen sind, die halt keine Ahnung haben davon, wie halt IT funktioniert und sich davon halt fernhalten wollen.
Für mich nachvollziehbar.
Und es gibt halt irgendwie eine Kasse, die halt im Laden ist.
Und jetzt sind das Einflussfaktoren, die halt auf diesen Lock-in, oder die halt dazu geführt haben, dass halt der Lock-In für Kundinnen über den Webshop funktioniert.
Und jetzt ist halt die Frage, was machen wir mit den Mitarbeitern, weil die sollen sich vielleicht nicht unbedingt als Kundinnen im Webshop registrieren.
Und das heißt, wir brauchen da halt einen anderen Ansatz.
Und dann haben wir die nächste Folie.
Und bei dem Lock-In über den Webshop gibt es halt so einen JWT oder JWT-Token, der dann halt genutzt wird.
Das ist so ein Standard mit dem JSON-Format.
wo halt irgendwie sowas drinsteht, wie welcher Benutzer das halt ist und das ist signiert und so weiter.
Webshop ist wie gesagt ein Fertigprodukt.
Werkstatt und Laden arbeiten im Browser.
Kommen wir auch noch dazu, wie das technisch tatsächlich umgesetzt ist.
Und wir haben halt irgendwie wenig Mitarbeitende und niemanden, der halt jetzt in einer IT-Abteilung ist.
So, das ist also der Stand, den wir da haben.
Und jetzt können wir eigentlich...
Genau, das Audio abspielen.
Ich hoffe, mir gelingt das, dass ich dann auch die Slides entsprechend synchron weiterbringe.
Variante A.
Kontext.
KundInnen loggen sich über den Webshop ein.
Mitarbeitende müssen sich ebenfalls einloggen können.
Das System soll später auch als SAS-Lösung angeboten werden.
Das System für MitarbeiterInnen soll zwischen 9 und 18 Uhr zu 99 Prozent verfügbar sein und maximal fünf Minuten ausfallen.
Der Preis einer Reparatur soll sogar nach zwei Minuten schon wieder ermittelt werden können.
Im Shop sind keine IT-Spezialisten.
Daher läuft das System in der Cloud.
Mitarbeitende arbeiten nur im Shop mit dem System.
Optionen?
Option 1.
Login mithilfe einer Standardsoftware wie Keycloak oder Auth0 implementieren.
Das führt eine zusätzliche, nicht triviale Komponente ein.
Dafür ist die Lösung sicher.
Sie bringt eine Benutzerverwaltung mit.
Sie kann bei der späteren Implementierung des SAS mit anderen Lösungen für die Verwaltung von Benutzern integriert werden.
Option 2.
Login auch für Mitarbeitende über den Shop.
Das ist gegebenenfalls einfacher, weil diese Option bereits für die KundInnen genutzt wird.
Allerdings haben Mitarbeitende eine andere Oberfläche als KundInnen, sodass niemals dieselben Webseiten von beiden Gruppen genutzt werden.
Die Einheitlichkeit ist daher kein sehr großer Vorteil.
Außerdem müssen Mitarbeitende im Shop registriert werden, was unter anderem wegen Datenschutz problematisch sein kann.
Für ein SaaS-Angebot trägt die Lösung wohl kaum.
Option 3.
Wir implementieren ein eigenes Login mit einer eigenen Benutzerverwaltung.
Das ist nicht sicher, wenn die Implementierung fehlerhaft ist und sie wirklich sicher umzusetzen kann schwierig sein.
Die Umsetzung kann aufwendig sein, weil eine Benutzerverwaltung entwickelt werden muss, die Mitarbeitende im Shop nutzen.
Wenn für ein SAS die Integration mit einer Kundenbenutzerverwaltung notwendig ist, muss diese Implementierung entsprechend erweitert werden.
Login mithilfe einer Standardsoftware wie Keycloak oder Auth0 implementieren.
Option 1 Standardsoftware bietet hohe Sicherheit, eine hohe Geschwindigkeit bei der Implementierung und eine gute Erweiterbarkeit für die SAS-Lösung.
Eine Einarbeitung in die Standardsoftware ist allerdings notwendig.
Option 2, Webshop, bietet demgegenüber nur den Vorteil, dass keine Einarbeitung notwendig ist und überzeugt konzeptionell nicht.
Option 3, eigene Implementierung, spart ebenso die Einarbeitung in die Standardsoftware, erhöht wahrscheinlich den Aufwand spätestens bei der SAS-Lösung.
Konsequenzen?
Eine Standardsoftware muss ausgewählt werden.
Wenn die Software ein SAS ist, entstehen gegebenenfalls zusätzliche Kosten für ein Abo.
Diese können beispielsweise bei einer Übernahme des SAS-Anbieters deutlich steigen.
Wenn die Software kein SAS ist, entsteht zusätzlicher Aufwand im Betrieb.
Wenn die Software als Container ausgeliefert wird, ist das ein Grund für den Betrieb des Reparatursystems in einem Container, um so das gesamte System einheitlich zu betreiben.
Ein Framework wie Spring Security kann die Abhängigkeit des Codes zu der gewählten Lösung verringern.
Allerdings müssten bei einer Migration die Benutzerdaten migriert werden.
Es sollten Maßnahmen ergriffen werden, um den Zugriff auf den Login, die internen Anwendungen und die Benutzerverwaltung auf den Shop zu limitieren.
Ein sehr ausführlicher Architecture Decision Record, wie ich finde.
Ist alles drin, mehrere Optionen verglichen.
Mal gucken, was Option B ist.
Variante B.
Kontext.
Der Webshop verwaltet nur KundInnen.
Ihr Login liefert ein JWT-Cookie, das das Reparatursystem unter Slash Reparatur liest Architekturentscheidung 1, Architekturentscheidung 2.
Mechanikerinnen und Shop-Mitarbeitende arbeiten im Werkstattteil, doch für sie gibt es keine Anmeldung.
Der Laden hat drei bis vier Mitarbeitende und keine IT-Experten.
Qualitätsszenario Benutzbarkeit 7.
Neue Mitarbeitende bedienen das System nach einer Stunde.
Qualitätsszenario Benutzbarkeit 5.
Qualitätsszenario Benutzbarkeit 6.
Die Werkstatt soll auch laufen, wenn der Webshop ausfällt.
Risiko 2.
Der Umbau zum SaaS darf 20 Personentage nicht überschreiten.
Qualitätsszenario Änderbarkeit 1.
Risiko 3.
Security ist bewusst nachrangig.
Optionen.
Option 1.
Mitarbeitende als Webshop-KundInnen.
Jede Mitarbeiterin erhält ein KundInnenkonto im Webshop.
Das Reparatursystem führt eine Liste, welche Konten Werkstattrechte haben.
Ein Login-Mechanismus für alle.
Option 2.
Eigene Mitarbeiterkonten im Werkstattteil.
Die Inhaberin legt Konten mit der Rolle Mechanikerin oder Shop an.
Login mit E-Mail und Passwort, unabhängig vom Webshop.
Option 3.
Identitätsdienst zu kaufen.
Ein Cloud-Identitätsdienst verwaltet Mitarbeiterkonten, Passwörter und das Zurücksetzen.
Das Reparatursystem prüft nur dessen Token.
Entscheidung.
Wir führen eigene Mitarbeiterkonten im Werkstatt, Teil des Reparatursystems.
Die Inhaberin legt sie auf einer Verwaltungsseite an und vergibt eine von zwei Rollen.
Der Login läuft getrennt vom JWT-Cookie des Webshops.
Kundinnen-Login und Mitarbeiter-Login bleiben zwei Wege.
Begründung?
Mitarbeitende als Webshop-Kundinnen zu führen, missbraucht Kundinnen-Konten als Personalkonten.
Das verschärft Risiko 2, weil dann auch die Werkstatt beim Webshop-Ausfall stillsteht und Risiko 3, weil jeder weitere Shop einen Webshop mit passender Schnittstelle bräuchte.
Ein zugekaufter Identitätsdienst passt zur Linie Dienste kaufen statt betreiben.
Doch seine Verwaltungsoberfläche richtet sich an IT-Fachleute, nicht an eine Inhaberin ohne IT-Kenntnisse.
Qualitätsszenario Benutzbarkeit 7.
Eigene Mitarbeiterkonten halten die Werkstatt unabhängig vom Webshop, sind je Mandant konfigurierbar und in einer Stunde erklärt, Konto anlegen, Rolle wählen, fertig.
Gegen diese Wahl spricht, dass wir Passwortspeicherung und Zurücksetzen selbst bauen und pflegen.
Bei drei bis vier Konten und nachrangiger Security ist das tragbar.
Konsequenzen?
Die Werkstatt arbeitet weiter, wenn der Webshop ausfällt.
Risiko 2 trifft nur noch Kundinnen.
Zwei Login-Wege im selben System.
Kundinnen per Webshop, JWT, Mitarbeitende per eigenem Konto.
Das Zurücksetzen eines Passworts muss ohne IT-Experten gehen, etwa durch die Inhaberin.
Risiko?
Selbstgebaute Passwortspeicherung ist ein Einfallstor.
Wir nutzen einen erprobten Hash-Algorithmus und beachten.
Risiko 7.
Risiko?
Beim Umbau zum SAS braucht jeder Mandant eine eigene Inhaberinrolle.
Die Kontenverwaltung muss mandantenfähig sein.
Risiko 26.
Spannend.
Also ich meine, hier ist ja jetzt ein anderer Ansatz gewählt und es ist detaillierter mit den Referenzen.
Aber was davon war jetzt KI und was war Mensch?
Die erste Abstimmung, ich hoffe, sie ist gestartet.
Die erste Frage ist, welche der beiden ADRs eignet sich deiner Meinung nach besser für die Situation?
Irgendwas stimmt nicht, nicht?
Also das Voting ist nicht gestartet.
Ja, ich sehe auch gerade Verbindung wird aufgebaut.
Und jetzt müssen wir das Quiz starten.
Ich sehe ganz viele Leute angemeldet.
Und jetzt sollte es gestartet sein.
Ihr habt 60 Sekunden Zeit.
Und wir haben Lag, das ist die andere Sache, die ich gerade nicht bedankt habe.
Also sprich, wir sind etwas, da ist noch ein Stream Lag, weil der Stream halt Sachen puffert.
Und das heißt, wir sind ein paar Sekunden.
hier schneller als ihr draußen in den Geräten.
Ich sehe, dass die Zeit läuft, dass wir bei 30 Sekunden verbleibend sind.
Achso, wir sollten sagen, dass wir die ganzen Ergebnisse erst am Ende uns alle konzentriert angucken, weil wir uns überlegt haben, dass wenn man sozusagen in den Zwischenergebnissen das auflöst, da mehr Informationen sind, was irgendwie was ist und das wollten wir uns halt fürs Ende aufsparen.
Drei, zwei.
Eins.
So, das Voting ist abgeschlossen.
Und dann geht es weiter mit der zweiten Frage.
Welche der beiden ADRs ist KI generiert?
Wirst du noch die nächste Folie machen?
Guter Punkt.
Die Zeit läuft.
Ich sehe gerade noch 42 Sekunden.
Die Pause muss sich einlegen.
Genau.
Wir werden uns wieder bei noch 23 Sekunden.
Jetzt noch 23 Sekunden.
10, 9, 6, 5, 4, 3, 2, 1.
So, damit sind wir bei der Abstimmung durch.
Ich muss gerade noch gucken, dass ich das weiterklicke.
Dann sind wir bei Problem 2.
Und das stelle ich diesmal vor.
Welche Frontend-Technologie bekommt das Reparatursystem?
So.
Diesmal wieder Qualitätsziele, die Verfügbarkeit und Security nachrangig, das hatten wir gerade eben schon.
Randbedingungen, Webshop vorhanden, keine IT im Shop, Kasse im Laden.
Das ist auch so etwas, was ich eigentlich ganz gut finde, diese Abhängigkeitsbäume, die die KI generiert hat.
Wir haben den ADR01 Login über Webshop, dann haben wir den ADR02, die Fahrradreparatur und eigener Bereich.
Da hätte jetzt hier vielleicht eine längere Beschreibung gut getan.
Und jetzt haben wir die Frage der Frontend-Technologie.
Alle Nutzergruppen arbeiten im Webbrowser.
Das ist ja heutzutage üblich.
KundInnen bekommen aus dem Webshop Laden und Werkstatt arbeiten.
Was?
Ah, die KundInnen kommen aus dem Webshop Laden und Werkstatt arbeiten vor Ort.
Das heißt, sie haben ein anderes System, anderes Frontend, anderen Rechner vor sich stehen.
Das System läuft als eigener Bereich unter Slash Reparatur und vierfachliche Module, kein Betriebsteam.
Ja, dann sind wir wieder an dem Teil, wo die KI vorlesen kann.
Welche Frontend-Technologie bekommt das Reparatursystem?
Wieder ADRA und B.
Ich starte.
Variante A.
Kontext.
Alle Nutzergruppen arbeiten im Browser unter Slash-Reparatur.
Der Webshop.
Ein Fertigprodukt.
Liefert Login und JWT-Cookie Architekturentscheidung 1, Architekturentscheidung 2, Architekturentscheidung 3.
KundInnen beauftragen eine Reparatur in 2 Minuten, Qualitätsszenario Benutzbarkeit 2 und bewerten die selbst gerenderte Statusseite mit 4 von 5 Punkten, Architekturentscheidung 5, Qualitätsszenario Benutzbarkeit 3, Risiko 14, Risiko 15.
Mitarbeitende bedienen das System nach einer Stunde.
Qualitätsszenario Benutzbarkeit 5.
Qualitätsszenario Benutzbarkeit 6.
Der Shop hat keine IT-Experten.
Qualitätsszenario Benutzbarkeit 7.
Das Team pflegt vier Repositories.
Architekturentscheidung 11.
Risiko 32.
Der SAS-Umbau darf 20 Personentage nicht überschreiten.
Qualitätsszenario Änderbarkeit 1.
Risiko 3.
Risiko 6.
Eine Schichtung nach UI.
Logik und Persistenz ist verworfen.
Architekturentscheidung 9.
Monolith oder Container bleibt offen.
Architekturentscheidung 14.
Optionen?
Option 1.
Server-gerenderte Seiten je Modul.
Jedes Modul liefert seine HTML-Seiten selbst, JavaScript nur für kleine Ergänzungen.
Vorteil?
Kein eigenes Frontend-Artefakt, Cookie und Pfadpräfix laufen durch.
Nachteil?
Werkstattansichten bleiben seitenbasiert.
Option 2.
Eine Single-Page-Application für alle.
Ein JavaScript-Frontend im fünften Repository spricht REST, A, P, IS aller vier Module.
Vorteil?
Reiche Interaktion, ein Erscheinungsbild.
Nachteil?
Eine UI-Schicht quer über die Module.
Eigener Bild, eigenes Deployment.
Option 3.
Geteiltes Frontend.
Kundinnenseiten-Server gerendert, Werkstatt als Single-Page-Application.
Vorteil?
Interaktion dort, wo täglich gearbeitet wird.
Nachteil?
Zwei Technologien, zwei Bildketten.
Entscheidung?
Wir bauen servergerenderte HTML-Seiten.
Jedes der vier Module rendert seine eigenen Seiten unter Slash-Reparatur, ein gemeinsames Style-Sheet lehnt sie an den Webshop an.
JavaScript ergänzt einzelne Seiten, rendert aber keine Inhalte.
Keine Single-Page-Application, auch nicht für die Werkstatt allein.
Template, Engine und Sprache wählt das Team nach Gewohnheit.
Begründung?
Servergerenderte Seiten nutzen den Webshop-Login am einfachsten.
Der Browser schickt das JWT-Cookie mit jedem Seitenaufruf, das Auftragsformular kommt vorbelegt vom Serverqualitätsszenario Benutzbarkeit 2.
Eine Single-Page-Application müsste das Cookie an jeden API-Aufruf hängen und den Zugriff doppelt prüfen.
Das vertieft die Webshop-Kopplung, Risiko 3, und legt das Reparaturprotokoll als API offen, Risiko 27.
Ein fünftes Repository mit eigener Bildkette trifft ein Team ohne Betrieb, Qualitätsszenario Benutzbarkeit 7, Risiko 32 und führt die verworfene UI-Schicht quer über alle Module wieder eine Architekturentscheidung 9.
Je Mandant braucht das Frontend nur ein Stylesheet-Qualitätsszenario Änderbarkeit 1.
Gegen die Wahl spricht?
Tagesplan und Protokoll bleiben Formulare, verlangt die UX-Expertin mehr Interaktion, rüsten wir seitenweise nach.
Konsequenzen?
Kein Frontend-Repository, keine getrennte Frontend-Pipeline, jedes Modul enthält seine Oberfläche.
Die KI hat ein bisschen Ausspracheprobleme mit den APIs, ne?
Aber ansonsten wieder ein...
Vollständiger ADR?
Gucken wir uns den zweiten an.
Hören wir uns ihn an.
Die UIs dienen zur Eingabe und Ausgabe von Daten.
Es gibt keine komplexen Grafiken oder ähnliches wie bei einer Kartenanwendung oder einem Spiel.
Die Terminplanung hat wahrscheinlich das komplexeste UI.
Es gibt keinen Bedarf für komplexe Kompositionen von UIs.
Jede Komponente hat genau eine UI.
Gegebenenfalls muss das Bezahlsystem über eine UI-Integration angesprochen werden.
Optionen?
Option 1.
Wir benutzen das Single-Page-App-Framework, das die Entwicklerinnen kennen.
Sie können schnell loslegen und können typische Probleme schnell lösen.
Mit einem Single-Page-App-Framework wären sogar komplexere UIs umsetzbar.
Jede Komponente hat ihr eigenes Single-Page-App.
Option 2.
Wir benutzen eine andere Web-Technologie, nicht notwendigerweise ein Single-Page-App.
Gegebenenfalls ermöglicht dieser eine bessere Modularisierung und Komposition von UIs.
Entscheidung.
Wir benutzen ein Single-Page-App-Framework.
Jede Komponente hat ein eigenes Single-Page-App.
Begründung.
Integration mit Links ist mit jeder Webtechnologie möglich.
Die notwendige Benutzerfreundlichkeit hat keinen Einfluss auf die Technologieentscheidung, siehe Folge 114 zu Benutzerfreundlichkeit.
Eine komplexe Modularisierung und Komposition der UIs ist nicht notwendig.
Jede Komponente hat eine eigene UI.
Das Team ist so klein, dass auch eine Skalierung auf mehrere Teams als Motivation für eine Modularisierung nicht gegeben ist.
Durch die Vertrautheit können Entwicklerinnen schnell mit der Implementierung loslegen.
Konsequenzen?
Gegebenenfalls ist für die Terminplanung doch eine komplexere UI notwendig, die aber mit einem Single-Page-App abgebildet werden kann.
Zwischen den Single-Page-Apps für die verschiedenen Komponenten gibt es einen spürbaren Übergang, unter anderem entsteht durch den Start des Single-Page-Apps eine Wartezeit.
Das ist akzeptabel, weil solche Wechsel selten vorkommen.
Ein einheitliches UI über Single-Page-Apps hinweg muss mit Konventionen und gegebenenfalls passenden gemeinsamen Artefakten unterstützt werden.
Die Integration des Bezahlsystems muss sichergestellt werden.
Wow, ich merke wieder zwei...
Durchdachte ADRs, zwei unterschiedliche Ergebnisse.
Spannend.
Die Abstimmung.
Erstmal wieder, was ist besser für die Situation?
Die Abstimmung läuft.
Wieder 60 Sekunden, noch 55 Sekunden.
Ich bin ja echt so gespannt, was da rauskommt, in welche Richtung das geht.
Vor allem bin ich jetzt gespannt, ob...
die Zuschauer so ein paar Hinweise jetzt so rauslesen, die sie vielleicht denken, erkannt zu haben.
Aber es geht ja auch erstmal darum, welcher ADR sich besser eignet.
Auch das ist super spannend, wie da die Meinungen unterschiedlich sind.
Wobei, jeder Zuschauer kennt das System nicht so gut wie die KI oder du, Eberhard.
Wir haben noch zehn Sekunden.
Dann kommt jetzt die...
Zweite Frage, welcher der ADRs ist KI generiert?
Genau, jetzt läuft wieder die Zeit, 60 Sekunden.
Genau, du hast es gelesen, nicht?
Wir sollten auch für ALMs zu anthropomorphisieren.
Die hassen das nämlich.
Genau, die hassen das.
Ach ja, aber es ist so einfach.
So, nach 30 Sekunden, wir hätten so einen Timer, so einen Sound gebraucht, so irgendwas.
Guck mal, wir haben hier einen schnellen Herzschlag.
Ich merke gerade, ich entdecke die Sounds.
Noch 8 Sekunden, 7, 6, 5, 4, 3, 2, 1.
10 Sekunden Verzögerung, deswegen kommen die Sounds nicht so gut rüber, aber ich habe es mal gewagt.
So, damit sind wir mit der zweiten Abstimmung durch.
Drittes Problem.
Eberhard, stellst du es vor?
Genau, da ist die Frage, wie das Websystem diese hohe Verfügbarkeit hinbekommen soll, wenn Glockend-Nutzerdaten vom Webshop abhängen.
Magst du mal die nächste Folie zeigen?
Und wir haben also diesen Webshop.
Wir haben keine IT im Shop, wie wir es halt diskutiert haben.
Es gibt halt eine Kasse im Laden.
Und wichtig ist halt die Benutzbarkeit, nicht so sehr die Verfügbarkeit.
Security ist nicht ganz so wichtig.
Und das führt jetzt dazu, dass wir eben den Lock-In über den Webshop gemacht haben.
Für Flügbarkeit müssen wir uns halt eben drum kümmern.
Und jetzt ist halt die Frage, wie gehen wir mit einem Webshop Ausfall um?
Das heißt, wenn wir tatsächlich sagen, dass wir ein Lock-In machen über den Webshop, dann bedeutet das, dass wir das Reparatursystem eben auch nicht benutzen können, weil man sich eben nicht einlocken kann.
Sondern jetzt ist eben die Frage, wie kriege ich das halt hin?
Und da gibt es halt einmal den Lock-In und außerdem noch die Bezahlung.
Das ist, glaube ich, der andere Punkt.
Und jetzt ist es nochmal ausdifferenziert mit der Verfügbarkeit.
Also tagsüber halt 99,9 Prozent, nachts irgendwie 9 Prozent, 99 Prozent.
Man kann also zum Beispiel nachts tatsächlich sowas wie ein Wartungsfinster sich überlegen.
Und wir haben halt das Problem, dass bei dem Webshop nicht definiert ist, wie verfügbar der tatsächlich ist.
Das ist also eine offene Frage.
Und dann kannst du eigentlich loslegen und die, genau.
Genau.
Die zwei letzten Audio-Files.
Variante A.
Kontext.
Das Websystem soll zwischen 7 und 24 Uhr zu 99,9% und den Rest der Zeit zu 99% zur Verfügung stehen.
Der Webshop hat Links zu den Komponenten Reparaturdurchführen, Terminplanung und Bezahlung.
Die Webshop User Database bietet die Authentifizierung als einen JWT-Token als Cookie an.
Optionen.
Option 1.
Die Webshop User Database wird für einen Login direkt angesprochen.
Die Komponenten verlassen sich auf die Existenz eines JWT-Tokens.
Ein Ausfall der Webshop-User-Database führt zu einem Ausfall des Reparatursystems.
Wenn die Bezahlung im Webshop ausfällt, kann man im Shop nicht online bezahlen.
Option 2.
Falls die Webshop-User-Database ausfällt, Terminplanung ist unter Angabe einer beliebigen E-Mail-Adresse mit anschließender Bestätigung des Termins über einen Link möglich.
Kunden haben für den Reparaturstatus einen Link.
Sie können den Status ohne Authentifizierung einsehen.
Wenn der Webshop ausfällt, Bezahlung ist nur vor Ort möglich.
Option 3.
Statt der Webshop-User-Database wird eine eigene Authentifizierung genutzt, gegebenenfalls mit identischen Logindaten.
Beim Ausfall des Webshops ist eine Bezahlung nur vor Ort möglich.
Wir nutzen den Webshop, falls erfahrungsgemäß die Zuverlässigkeitsziele damit erreicht werden können.
Sonst implementieren wir die Terminvergabe mit einer E-Mail-Adresse und verwalten den Reparaturstatus über einen Link.
Online-Bezahlung ist bei Ausfall des Online-Shops nicht möglich.
Begründung?
Option 1 ist am einfachsten implementierbar.
Sie ist nur dann problematisch, wenn der Webshop die Verfügbarkeitsziele nicht erreicht.
Option 2 ist ebenfalls einfach implementierbar, aber sichert Informationen weniger gut ab.
Option 3 ist verhältnismäßig aufwendig.
Die sichere Replikation von Login-Daten bedeutet, dass Credentials repliziert werden müssen.
Das kann bezüglich Sicherheit problematisch sein.
Konsequenzen?
Option 2.
Ein Angreifer könnte den Terminkalender mit Terminen füllen.
Termine können gegebenenfalls nicht einem User im Webshop zugeordnet werden, wenn die E-Mail-Adressen unterschiedlich sind.
Der Link für den Status einer Reparatur oder eines Termins sollte nicht einfach erratbar sein, zum Beispiel UUID.
Die Informationen über den Status einer Reparatur oder einen Termin sind nicht so gut geschützt wie bei Option 1.
Den Status einer Reparatur oder einen Termin können auch andere Personen außer dem Kunden selbst einsehen.
Online-Bezahlung ist in allen Optionen nur möglich, wenn der Shop verfügbar ist.
Da das Rad abgeholt und angeliefert werden muss, ist eine Bezahlung vor Ort vermutlich akzeptabel.
Variante B.
Kontext?
Kundinnen melden sich im Webshop an, das Reparatursystem liest das JWT-Cookie und holt Adresse und Zahlungsart per Restarchitekturentscheidung 1.
Das Websystem soll zwischen 7 und 24 Uhr zu 99,9% verfügbar sein, nachts zu 99% Qualitätsszenario Zuverlässigkeit 4, Qualitätsszenario Zuverlässigkeit 5, mit Wiederanlauf in 5 Minuten Qualitätsszenario Zuverlässigkeit 6.
Der Webshop ist ein Fertigprodukt eines externen Betreibers.
Sein SLA ist unbekannt.
Fällt er aus, fallen Login- und Adressabfrage mit Risiko 2.
Der Laden hat kein Betriebsteam.
Qualitätsszenario Benutzbarkeit 7.
Die Beauftragung muss in zwei Minuten gelingen.
Qualitätsszenario Benutzbarkeit 2.
Optionen.
Option 1.
Verbundverfügbarkeit akzeptieren.
Wir fordern vom Webshop-Betreiber ein SLA und messen die 99,9% nur für die Zeit, in der der Webshop läuft.
Option 2.
Vom Webshop entkoppeln.
Das Reparatursystem prüft das JWT selbst mit dem öffentlichen Schlüssel des Webshops und hält Adresse und Zahlungsart je Kundin als Kopie.
Der Webshop wird nur beim Login gebraucht.
Option 3.
Eigener Login als Ersatzweg.
Bei Webshop-Ausfall bietet das Reparatursystem einen eigenen Login per E-Mail-Link an.
Entscheidung.
Wir entkoppeln das Reparatursystem vom laufenden Betrieb des Webshops.
Es prüft das JWT selbst, hält Adresse und Zahlungsart als Kopie und lässt KundInnen die Adresse im Formular überschreiben.
Der Webshop wird nur für die Anmeldung gebraucht.
Sein SLA klären wir vor der Umsetzung.
Begründung?
Die Verbundverfügbarkeit zu akzeptieren, misst das Ziel schön, ohne es zu erfüllen.
KundInnen merken den Ausfall trotzdem und jede Minute kostet Umsatz.
Ein eigener Login als Ersatzweg baut die zweite Nutzerverwaltung, die Architekturentscheidung 1 vermeidet und verwirrt KundInnen mit zwei Anmeldewegen.
Die Entkopplung macht den Webshop zum Ausfallpunkt nur für die Anmeldung.
Wer eingeloggt ist, beauftragt weiter.
Das JWT trägt die Identität, die Kopie trägt die Adresse.
Das schützt Qualitätsszenario Benutzbarkeit 2 und den größten Teil von Qualitätsszenario Zuverlässigkeit 4.
Gegen diese Wahl spricht Die Kopie kann veralten und die JWT-Prüfung braucht den Schlüssel eines Anbieters, den wir nicht kontrollieren.
Beides wiegt weniger als ein Ausfall.
Wer beim Webshop-Ausfall nicht eingeloggt ist, bleibt draußen.
Das nehmen wir hin.
Konsequenzen?
Eingeloggte KundInnen beauftragen auch bei Webshop-Ausfall.
Risiko 2 schrumpft auf die Anmeldung.
Das Reparatursystem hält KundInnen-Daten als Kopie.
Risiko 1 wächst.
Kopie und Quelle können auseinanderlaufen.
Der öffentliche Schlüssel des Webshops muss verfügbar sein.
Das klären wir mit dem Anbieter.
Risiko 5.
Risiko?
Läuft die Umleitung nach Slash-Reparatur über den Reverse-Proxy des Webshops?
Reißt sein Ausfall auch uns mit?
Die Umleitung braucht einen eigenen Betrieb.
Risiko 5, Risiko 22.
Risiko?
Ohne SLA des Webshops bleibt die Anmeldung unter 99,9%.
Wir messen sie getrennt.
Ja, dann kommt jetzt die letzte Abstimmung.
Die Abstimmung müsste laufen.
Läuft sie?
Läuft sie?
Läuft sie?
Ich sehe gerade nicht, ob sie läuft.
Ich hätte die Hoffnung, dass unser Backoffice sich da kümmert.
Ja, aber läuft.
Genau, läuft.
Perfekt.
Ich fand es spannend, dass der eine ADR das berücksichtigt hat, dass die Bezahlung dann nur vor Ort ist.
Der andere ADR mit dem JORT-Token des Anbieters.
Spannend.
Ich könnte jetzt inhaltlich was dazu sagen, aber das spannen wir uns, glaube ich, erst mal auf.
Genau, das machen wir gleich.
So, drei, zwei, eins.
Null.
Diese Frage ist geklärt.
Ich mache weiter.
Jetzt kommt wieder die Frage, welche der beiden ADRs ist KI generiert?
Ich bin sowas von gespannt, wie das aufgelöst wird.
Ich habe keine Ahnung.
Ich finde sie...
Beide Versionen eigentlich jeweils recht gut durchdacht.
Man könnte manche Sachen hinterfragen, wie ist dies gemeint, wie ist jenes gemeint.
Ich finde es ganz gut, die Trennung zwischen Problemstellung in der Überschrift und dann dem Kontext, was man eben für die Entscheidung alles verwendet hat an Informationen.
Das sehe ich sonst oft mehr oder weniger als Freitext.
Hier war es eigentlich ganz gut strukturiert in beiden Fällen der ADRs.
8, 7, 6, 5, 4, 3, 2, 1.
Die Abstimmung ist durch.
Und damit können wir uns die Antworten ansehen, oder?
Ja, genau, sollten wir tun.
Ich hätte hier die Slide weitermachen müssen.
So, Auflösung.
Jetzt bin ich gespannt, ob das geklappt hat.
Anmeldung.
Welche der beiden ADRs eignet sich deiner Meinung nach besser für die Situation?
A waren nur vier, B waren 18.
Welche SKI generiert?
A 19 Stimmen.
Wir hatten die Frage ziemlich eindeutig formuliert, also für die Abstimmung.
Eberhard, möchtest du auflösen, welcher war dein ADR?
Ich habe A geschrieben.
Tatsächlich, also das ist genau das, was halt offensichtlich zum einen inhaltlich schlechter angekommen ist und zum anderen auch tatsächlich irgendwie als AI generiert angesehen wird.
Ich weiß gar nicht, wie hat es auf dich gewirkt?
Also ich bin ja irgendwie super biased logischerweise.
Das heißt, ich könnte jetzt erzählen, warum A die bessere Lösung ist.
Das macht ja keinen Sinn.
Also was ist dein Gefühl?
Also mir war total aufgefallen, dass bei...
ganz viele Referenzen auf die anderen ADRs und die Risiken und Szenarien und sowas drin waren.
Das war somit detaillierter.
Und das hat man dann irgendwie bei allen ADRs gemerkt.
Die Entscheidung an sich, was sich eignet, also ich fand eigentlich beide relativ gut begründet.
Hättest du da jetzt einen Punkt, wo du sagst, B war gar nichts?
Ich überlege gerade, was war eigentlich nochmal ganz genau die erste Frage.
Das war die Authentifizierung von den BenutzerInnen.
Und tatsächlich ist es halt so, dass die beiden, und zwar von denen, die halt irgendwie im Shop sind.
Und tatsächlich ist es halt so, dass die Optionen, glaube ich, relativ ähnlich sind.
Also es sind so grob dieselben drei Optionen identifiziert worden.
Das mit den Referenzen ist mir auch aufgefallen.
Das hängt aber damit zusammen, ich weiß nicht, ob das sozusagen allgemein bekannt ist.
Ich glaube, diese ADRs sind halt Sachen, die die AI im Wesentlichen generiert hat.
Also die sind halt in den originalen Unterlagen nicht drin.
Also ich habe mich daran einfach nicht orientiert.
Von daher ist das etwas, was auffällig ist.
Ich habe subjektiv den Eindruck, also mir fehlt halt die konkrete Angabe von Technologien.
Also Key Clock ist halt da und Auth0 hatte ich halt irgendwie explizit genannt.
Und ich habe halt einfließen lassen, dass ich sehr ungern so eine Sicherheit selber bauen wollen würde.
Also das ist eigentlich trivial, weil nicht, Passwort haschen, Solter zu tun und so weiter.
Ich wäre trotzdem ein bisschen unsicher, ob ich das wirklich, wirklich sicher hinbekomme.
Da kann man jetzt argumentieren, naja, aber so wichtig ist Sicherheit nicht.
Was mir hier, ich weiß gar nicht, was die...
ist halt diese Perspektive zum SARS.
Also wenn ich halt ein SARS habe und das SARS halt irgendwie integriert wird in einer großen Fahrradkette, in irgendein, weiß ich nicht, in Active Directory, dann wäre ich halt irgendwie vorbereitet mit der Lösung, die ich halt irgendwie vorgeschlagen habe.
Und ich glaube, das ist bei der anderen nicht so richtig.
Ja, mir war jetzt vor allem auch tatsächlich...
Jetzt, wo du es nochmal erwähnst, aufgefallen, dass du Technologien tatsächlich genannt hattest, was, finde ich, ein wichtiger Punkt ist, wo die KI ausgewichen ist.
Na gut, sie wollte es ja auch selbst machen.
Und ich finde es nochmal spannend.
Ich glaube, ihr habt beide nicht darauf Bezug genommen, dass ja das Reparatur-Login, das bin ich am überlegen.
Muss der Kunde sich da auch anmelden?
Ja, er will ja einen Status sehen, ne?
Nee, nee, der würde halt über den Webshop kommen.
Und das ist halt das, was der dritte ADR diskutiert.
Das heißt, wir haben tatsächlich ein getrenntes System.
Es gibt noch diese Geschichte, über die man tatsächlich diskutieren kann.
Ich habe halt das Gefühl, wenn ich halt Keygroup benutze oder Auth0, dann habe ich eine Benutzerverwaltung und die ist halt irgendwie da.
Und das AI-System hat gesagt, diese...
Benutzerverwaltung wäre halt schwer nutzbar für Expertinnen.
Weiß ich nicht, ob ich das kaufen würde, aber nicht, sei es drum.
Aber wenn es nur intern ist, dann kann man ja in Sachen Security auch sagen, okay, kann man nicht von außen einfach angreifen, haben wir erstmal eine Firewall quasi dazwischen oder zumindest ein Reverse-Proxy.
Wollen wir weitergehen?
Ja, finde ich gut.
Oh, das war jetzt schwieriger.
Ist natürlich jetzt auch die Frage, ob vielleicht ein paar User aufgrund der Formulierung dann umgeschwenkt sind, ein paar Zuschauer.
Hier ging es um die Frontend-Technologie.
Was eignet sich besser?
Eberhard, möchtest du auflösen?
Welchen ADR hattest du?
Ich war B.
Genau.
Du hattest tatsächlich einen Single-Page-Application-Framework.
Die KI hatte gesagt, komm...
Wir rendern es einfach auf dem Server, da ist es dann egal, dann brauchen wir kein JavaScript.
Ich hatte schon so ein bisschen geschmunzelt, weil es ging so ein bisschen in Richtung Self-Contained Systems, hatte ich das Gefühl, dein ADR.
Wenn man da so jeden Bereich mit einer eigenen Single-Page-Application versieht, dann hat man so vertikale Slices.
Ja, aber...
Also danke, dass du das Thema ansprichst.
Wir werden ja auch in, ich glaube, zwei oder drei Wochen eine alte Episode haben zu dem Thema.
Ich würde halt unterstellen, dass das eher etwas ist, was die AI-Lösung vielleicht noch ein bisschen besser unterstützt.
Also Server-Seite-Gerenderte, Radio-Mail-Seiten sind halt eigentlich so das, was ich in erster Linie mit Self-Content Systems in Verbindung bringe, weil ich ja eine einfache Modularisierung habe.
Im Kern sagt meine Entscheidung, wenn das Team halt mit irgendetwas erfahren ist, das ist ja meine...
die kennen halt irgendetwas, dann benutze ich halt das.
Und eine exzessive Modularisierung, was halt ein Nachteil von Single-Page-Apps-Frameworks wäre, brauche ich halt nicht.
Ich kann halt einfach modularisieren, indem ich halt unterschiedlich Single-Page-Apps habe, was in gewisser Weise eine Domänenaussage ist.
Also ich habe tatsächlich mir das halt angeguckt und habe halt für mich gesagt, okay, wenn ich halt Werkstatt-Mitarbeiterin bin, dann stehe ich halt da und arbeite die ganze Zeit und erfasse halt Reparaturen.
Das ist halt eine Single-Page-App.
Und wenn ich halt Kundin bin, dann versuche ich halt einen Termin zu bekommen.
Das ist eine Single-Page-App.
Das heißt, Übergänge zwischen diesen Single-Page-Apps gibt es so gut wie nicht.
Also komme ich damit durch die Tür.
Und eigentlich sagt der ADR damit, wenn ich halt irgendwie Menschen vor mir habe, die halt irgendwas können, dann benutzen wir das.
Weil der Vorteil, dass ich damit halt schnell in Produktion gehen kann und dass das halt schnell umgesetzt wird, dominiert halt alles andere.
Wir haben halt nicht eine komplizierte Anwendung mit ganz viel Modularisierung und so weiter.
Also gehen wir halt in diese Richtung.
Das ist so das, was ich irgendwie sagen würde.
Ich bin jetzt, das kann ich was das, ja, also die zwingende Sache, HTML-Seiten und das Thema PageRabs überhaupt gegeneinander abzuwägen von dem ADRA, wie gesagt, ich würde mich halt irgendwie an dem Team orientieren, wäre mein erster Ansatz.
Ja, ich denke, das ist auch meistens so der Ansatz, der gefahren wird.
Man hat ein technisches Umsetzungsteam und wenn das eine bestimmte Technologie beherrscht, dann nimmt man die.
Somit ist eigentlich eine Constraint, die man hat.
Also ich wäre zu einem anderen Ergebnis gekommen, wenn man gesagt hätte, wir brauchen eine große, komplizierte Anwendung mit Seiten, wo ich nicht eine Produktdetailseite habe und die Produktdetailseite hat einen Preis und da ist irgendwie oben ein Login.
Und all diese ganzen Geschichten, weil dann habe ich ein Modularisierungsthema und ich habe mehrere Teams, wenn das ein komplexes System ist, die für verschiedene Teile dieser Seite zuständig sind.
Es gibt einen Preisberechen, das ist ein Team.
Ich habe ein Team, was sich um Benutzerlocken und solche Sachen kümmert.
Da muss ich das vernünftig auf die Reihe bekommen, das alles zu integrieren.
Da müsste man halt was sagen zum Thema Modularisierung.
Das brauche ich hier nicht.
Und vielleicht ist das etwas, ich glaube, das ist beim nächsten ADR noch ein bisschen krasser.
Ich habe...
bei den ADRs auch nochmal was über die Domäne gelernt.
Also das ist halt so ein bisschen, wie unterschiedlich getrennt sind denn diese Funktionalitäten?
Das sind eben sehr stark getrennte Funktionalitäten.
Das ist eigentlich eine Aussage über die Domäne.
Und vielleicht noch eine Sache, die wollte ich eigentlich ganz am Anfang loswerden.
Ein Problem, was halt diese Episode hat, so wie auch andere Episoden, wo wir halt irgendwie über AI und Architekturunterstützung gesprochen haben, ist halt, das stellt sozusagen in Abrede, dass das ein kollaborativer Prozess ist.
Also im wirklichen Leben würde ich halt unterstellen, dass wir ein Team hätten.
Wir müssen mit mehreren Leuten reden, wir müssen mit Stakeholdern reden, wir müssen mit Entwicklern reden, wir müssen eine Armee verschiedenen Meinungen einholen, wir müssen uns ein Buy-in einholen von Entwicklern, von Stakeholdern und auch von vielleicht anderen Architekten.
Und das ist hier halt irgendwie komplett ausgeblendet.
Das heißt, ich würde halt unterstellen, Beide Ansätze, also ich schließe mich ins Kämmerchen ein und entscheide das mal kurz, respektive wir haben eine AI, die das halt mal kurz entscheidet, ist im wirklichen Leben eine bedingt gute Idee, weil ich eigentlich gerne das kommunizieren wollen würde und muss.
Das vergisst man halt, glaube ich, häufig und das ist aber eigentlich ein ganz wichtiger Punkt.
Ja, ist tatsächlich ein wichtiger Punkt.
Da wollte ich auch gleich nochmal drauf eingehen, aber jetzt gehen wir noch zum dritten ADR.
Dritte Runde.
Ach guck mal, da hat sich noch mal einiges geändert.
Da war es die Verfügbarkeit.
ADR A eignet sich besser nach Abstimmung unserer Zuschauer, Zuhörer.
Und KI generiert ist ADR B.
Eberhard, löst auf.
Tatsächlich ist es so, ich muss mal kurz schauen.
Genau, ich habe A geschrieben.
Und inhaltlich ist es so, das ist der ADR, wo ich tatsächlich am meisten nochmal für mich über die Domäne gelernt habe.
Also ich habe in den Folgen, da habe ich halt irgendwie gesagt, die Kundinnen müssen sich irgendwie einloggen und wir benutzen halt irgendwie den Webshop dafür und damit hat sich das halt.
Und ich habe eben jetzt in diesem Raum mir nochmal das halt überlegt und habe halt für mich gesagt, eigentlich, wenn ich halt einen Reparaturstatus habe, und ich habe dort eine schwer erratbare URL, ist das sogar vorteilhaft, weil ich diese URL jemand anders geben kann, dem ich zum Beispiel sagen kann, hey, wenn das Fahrrad fertig ist, dann holst du halt ab, hier ist die URL, wo du es dir halt angucken kannst.
Und das hängt damit zusammen, dass der Reparaturstatus meiner Ansicht nach nicht ernsthaft schützenswert ist.
Genau genommen sollte man das nochmal überprüfen.
Da ist die Frage, was passiert, wenn der Reparaturstatus rausleckt.
Ich würde erwarten, dass das nicht ernsthaft ein Problem ist, aber das wäre dort der Punkt.
Das Thema mit der Terminvergabe ist ein ähnliches.
Wenn ich also einen Termin vergeben kann, ohne dass ich als Benutzer registriert bin, verringere ich die Barriere, um einen Termin zu bekommen.
Das heißt, es ist einfacher, neue Nutzerinnen zu gewinnen und neue Kundinnen zu gewinnen.
Ist das nicht eigentlich der bessere Weg?
Sondern dann kommt man dahin, dass halt eigentlich nur noch das Bezahlen übrig ist.
Und da ist halt die Geschichte, wenn ich sowieso mich zu dem Shop bewege, weil ich ja das Fahrrad hinbringe oder abhole, kann ich aber auch gleich vor Ort bezahlen.
Und ich würde aufgrund dessen, dass ich also diese Dinge halt über die Domäne gelernt habe, wahrscheinlich die Integration in den Webshop einfach killen.
Also kann man darüber diskutieren.
steht ja auch in dem ADR drin.
Ich kriege halt nicht raus, welche Benutzer irgendwas repariert hat.
Also wenn ich da nicht den User-Account habe, habe ich da sozusagen Disconnect und kriege halt nicht raus, dass der Benutzer, der Kunde Eberhard dieses Ding repariert hat.
Aber das ist vielleicht verschmerzbar, keine Ahnung.
Und eigentlich wäre das jetzt eine Geschichte, wo ich halt nochmal mit Domänexpertinnen darüber reden wollen würde, um halt herauszufinden, wo wir eigentlich hinwollen.
Und das hätte ich halt, bevor ich das durchdacht habe auf dieser Granularitätsebene, habe ich halt einfach gesagt, wir benutzen einen Login.
Natürlich brauchen wir einen Login und wir benutzen den Login vom Webshop, weil, also nicht, ist halt so.
Und ja, wie gesagt, das würde ich jetzt halt irgendwie hinterfragen.
Was ich jetzt spannend finde, ist, wir haben ja hier den Architekturing-Test gemacht.
Und ich habe gerade eben nochmal nachgeguckt.
Einmal dachten unsere Zuhörer, Genau falsch.
Architektur ist, also KI ist der Mensch und zweimal lagen sie richtig.
Das heißt, die KI hat den Architekturring-Test jetzt nicht bestanden.
Aber was ich spannend finde, ist, dass es doch ziemlich ausgeglichen ist, dass, ja.
fast die Hälfte der Zuhörer, die KI besser findet, die andere Hälfte den menschlichen ADR.
Und das zeigt ja eigentlich auch, dass man die KI wahrscheinlich ganz gut als unterstützendes Instrument nutzen kann.
Die KI kennt die ganzen anderen ADRs in- und auswendig, die Qualitätsszenarien.
Und wenn man mit der KI etwas durchdiskutiert, dann kriegt man vielleicht noch mal ein paar andere...
Gedanken und die KI kann auch nochmal gegentreten und sagen, du, das Qualitätskriterium widerspricht deiner Idee, aber wir haben es ja auch mit Trade-offs zu tun bei allen Entscheidungen, sodass wir dann eben gucken müssen, welches Qualitätskriterium wiegt mehr als das andere.
Also insofern ist das, finde ich, eigentlich jetzt ein Erfolg, was wir hier zu verbuchen haben.
Wir haben so oder so einen Erkenntniserfolg.
Wir haben irgendwas gelernt durch dieses Experiment, so hoffe ich.
Es scheint keine Kommentare im Chat zu geben.
Also gerne, wenn ihr Kommentare noch habt, da könnt ihr euch gerne auch nochmal äußern dazu.
Ich muss halt gestehen, der dritte ADR hat für mich diese Frage erzeugt, welche dieser Dinge sind wie schützenswert.
Das will ich nicht missen, darüber nachzudenken.
Und ich bin nicht sicher, ob ich mit einer AI-Unterstützung in diese Richtung gegangen wäre.
Also die Frage ist halt, was ist denn das, was ich eigentlich schütze?
Wie ist das Risiko?
Und das nochmal zu durchdenken war ein wichtiger Prozess.
Bei dem zweiten, bei der Frontend-Technologie, ist halt mein Gefühl, naja, benutzt halt was passt.
Das ist ja nicht so wahnsinnig relevant.
Also ich habe nicht das Gefühl, dass man hier etwas hat, was mit irgendeiner Frontend-Technologie nicht zu erschlagen ist.
Und bei dem ersten ADR wäre, finde ich, es überraschend, wenn man aufgrund der SARS-Perspektive nicht zu dem Ergebnis kommt, dass man eigentlich etwas haben möchte, was halt jetzt erstmal wie Overkill wirkt.
Also sowas wie KeyCluck oder Auth0 kann man eigentlich für dieses System nicht wirklich rechtfertigen.
Aber durch die zusätzliche Security und durch die Erweiterbarkeit halte ich das eigentlich für die richtige Entscheidung.
Keine Ahnung, also nicht offensichtlich bin ich da, also die Mehrheit sieht das halt irgendwie anders.
Was ich auch für mich nochmal gelernt habe, ist, ich bin halt nicht ganz sicher, ob meine Darstellung wirklich gut ist.
Aber, also sprich, das könnte man wahrscheinlich nochmal jemandem zum Durchlesen geben, der dann irgendwie Feedback gibt, ob das wirklich leicht verstehbar ist und das irgendwie durchdiskutiert.
Das habe ich jetzt irgendwie nicht getan.
Das wäre halt etwas, was ich ja tun würde.
Genau, hier ist der Kommentar, interessantes Experiment.
Lieben Dank dafür, sehr gute Idee, erst am Ende aufzulösen.
Danke für das Feedback.
Wir sind so ein bisschen am Ende der Zeit.
Wir haben jetzt zwei Minuten überzogen.
Ich werde der KI gleich noch den Auftrag geben, die ADRs nachzudokumentieren in der großen ARC 42 Dokumentation mit der Dokumentation des Experiments.
Ja, und damit sind wir am Ende, oder?
Ja, vielen Dank.
Vielen Dank an alle Beteiligten.
Also eine Sache, die auch ganz wichtig ist, die ich leider vergessen habe, zu erwähnen ist, dass Lisa es heute leider nicht geschafft hat.
Die ist halt ausgefahren, sonst wären wir ja zu dritt gewesen.
Und ich möchte mich bei einem Beteiligten bedanken, also bei den Menschen von den Infodays natürlich, bei dir, Ralf, bei Lisa und bei Martina.
Und ja, also für mich war das halt ein spannendes Experiment.
Und ich erinnere ehrlich gesagt nicht, ich habe mich heute Morgen noch gefragt, wer eigentlich irgendwie ursprünglich auf die Idee gekommen ist und ich weiß das nicht mehr genau.
Das bedeutet, dass es eben tatsächlich aus meiner Sicht ein Team erforderbar und verschiedene Leute haben verschiedene Dinge halt herbeigetragen.
Das fand ich halt irgendwie auch super.
Hier ist noch der letzte Kommentar von Marc G.
Danke für das Experiment, dass solche Entscheidungen im Austausch mit vielen getroffen werden sollten.
Wie du ja gesagt hast, ergibt sich der Review auf Verständlichkeit automatisch.
Genau.
Und das ist halt so ein bisschen mein Punkt.
Ich bin halt nicht sicher, ob ich mich schriftlich immer sauber ausgedrückt habe.
Wahrscheinlich wäre das halt der Tipp nicht.
Macht es nicht so wie ich.
Nehmt jemanden und gebt ihm nochmal den ADR zum Lesen und schaut halt, ob der verständlich ist.
Das ist auf jeden Fall gut.
Und eben in der gemeinsamen Diskussion den ADR zu erstellen, ist auch eine gute Idee.
Dann noch viel Spaß auf den Infodays, oder?
Genau.
Vielen Dank und einen schönen Tag noch.
Und genau.
Vielen Dank für...
die Chance, die Keynote halten zu dürfen, in dieser Art und Weise.
Bis dahin.
Genau.
Danke.
Ciao.
Tschüss.