Risiken und technische Schulden

11.1 Risiken

Die Risiken R-001 bis R-024 stammen aus den Konsequenzen der acht ADRs. R-025 und R-026 stammen von den offenen Fragen auf dem Miro-Board zu Folge 113 (Seite 6, 10 und 11). Wahrscheinlichkeit und Auswirkung sind Team-Urteile; die Werte hier sind begründete Schätzungen. Priorität ist abgeleitet: hoch, wenn beides hoch; niedrig, wenn mindestens ein Wert niedrig ist und keiner hoch; sonst mittel. Die Tabelle ist nach Priorität sortiert.

Table 1. Risiken (Wahrscheinlichkeit und Auswirkung: inferred, vom Team zu bestätigen)
ID	Beschreibung	Quelle	Wahrsch.	Auswirkung	Priorität	Maßnahme
R-022	Betriebsmodell offen. On-premise wegen der lokalen Kasse und 99,9 % im Web ohne Betriebsteam ziehen in verschiedene Richtungen.	ADR-008	hoch	hoch	hoch	Cloud-Betrieb mit EKS/EC2-SLAs und eigenem Support (QS-Z-04, Kapitel 4); ADR zum Betriebsmodell nachziehen.
R-010	Kasse steht im Laden. Aus der Cloud muss das System die Kasse erreichen.	ADR-004	hoch	hoch	hoch	8.5 Fehlerfall "Kasse nicht erreichbar"; Spike zur Kassen-Schnittstelle vor der Cloud-Entscheidung.
R-003	Feste Kopplung an diesen Webshop steht dem SaaS-Ziel entgegen; andere Läden haben andere oder keine Webshops.	ADR-001	hoch	hoch	hoch	Login und Kundendaten hinter einer Anti-Corruption Layer kapseln; QS-A-01 als Abnahmekriterium.
R-026	Mandantenfähigkeit und Skalierbarkeit für SaaS sind offen ("?" auf dem Board). Ohne Mandantenfähigkeit steigen die Betriebskosten je Shop.	Board Seite 6	hoch	hoch	hoch	Mandantenfähigkeit im Datenmodell vorsehen; QS-A-01 (zwei Monate, 20 PT) als Grenze.
R-035	Das Rechnungswesen erfährt von einer Zahlung nur, wenn Kasse, Online-Payment oder Bezahlung sie melden. Die Zuordnung Bezahlung zu Rechnungswesen ist offen (63:16).	ADR-012	hoch	hoch	hoch	Zuordnung entscheiden; bis dahin Zahlungen in Reparatur durchführen protokollieren (8.4 Audit).
R-039	Erlaubt das Kassensystem keinen Zugriff aus der Cloud, kippt die Lösungsstrategie (26:14, "kaputt machen").	ADR-013	mittel	hoch	hoch	Kassenanbindung vor dem ersten Inkrement klären; Kassenproxy als Option (Kapitel 7, 8.5).
R-044	QS-Z-07 fordert höchstens 5 Minuten Datenverlust; kein Beleg, dass RDS das liefert.	ADR-016	mittel	hoch	hoch	RDS-Replikation und Backup-Intervall festlegen; QS-Z-07 messbar machen.
R-002	Fällt der Webshop aus, funktionieren Login und Adressabfrage nicht.	ADR-001	mittel	hoch	mittel	8.5 Fehlerfall "Webshop nicht erreichbar"; Werkstatt bleibt unabhängig vom Webshop-Login.
R-005	Umleitung vor dem Webshop: wer sie betreibt und ob das Fertigprodukt sie zulässt, ist offen.	ADR-002	mittel	hoch	mittel	Klärung mit dem Webshop-Anbieter vor der Umsetzung; 8.4 Monitoring der Umleitung.
R-011	Zahlungsstatus aus zwei Quellen (Payment Service und Kasse) ohne Vorrangregel.	ADR-004	mittel	hoch	mittel	8.2 "Bezahlstatus nur aus dem Backend"; 8.4 Audit des Zahlungsstatus; Vorrangregel im Modul Bezahlung festlegen.
R-024	5-Minuten-Ziel für Datenverlust setzt eine Persistenzstrategie voraus, die niemand entschieden hat.	ADR-008	mittel	hoch	mittel	RDS-SLAs prüfen (QS-Z-07); Replikation oder Sicherung im Minutentakt.
R-004	JWT-Cookie erreicht das System nur in derselben Domain. Geschlossen durch ADR-002.	ADR-001	niedrig	hoch	mittel	8.2 Same-Origin-Policy und Pfad `/reparatur`.
R-006	Beim SaaS-Umbau braucht jeder Laden eine eigene Umleitung unter seiner Domain.	ADR-002	hoch	mittel	mittel	Umleitung als konfigurierbaren Teil des Deployments planen; QS-A-01.
R-009	Viele Schnittstellen (Payment, Kasse, Rechnungswesen, User-DB); jede ist ein Ausfallpunkt.	ADR-003	hoch	mittel	mittel	8.5 je Schnittstelle Retry und Fallback; 8.3 Integrationstests gegen Stubs.
R-013	Beim SaaS-Umbau hat jeder Laden eine andere Kasse; die REST-Integration muss je Laden neu gebaut werden.	ADR-004	hoch	mittel	mittel	Kassen-Adapter als Anti-Corruption Layer; QS-A-01.
R-008	Zwei Bezahlvorgänge unter einer Domain verwirren Kund:innen.	ADR-003	mittel	mittel	mittel	QS-U-02 und QS-U-03 als Messung; Bezahlvorgang im Reparaturbereich klar kennzeichnen.
R-012	Fällt der Rückweg nach dem Payment-Redirect aus, bleibt eine bezahlte Reparatur unbezahlt.	ADR-004	mittel	mittel	mittel	8.5 Fehlerfall "Payment-Redirect bricht ab".
R-014	Die Statusseite wirkt wie ein Fremdkörper im Webshop.	ADR-005	mittel	mittel	mittel	QS-U-03 (4 von 5 Punkten) als Messung; Layout an den Webshop anlehnen.
R-015	Kund:innen suchen den Status im Kundenkonto des Webshops und finden ihn nicht.	ADR-005	mittel	mittel	mittel	Verweis vom Webshop auf `/reparatur`; E-Mail mit Link zur Statusseite (ADR-007).
R-018	Als SaaS trifft das System auf Läden mit eigenem Inventarsystem.	ADR-006	mittel	mittel	mittel	Materialbeschaffung als eigenes Modul halten (Kapitel 4); QS-A-01.
R-023	Lassen sich Werkstatt- und Web-Teil nicht trennen, gilt das strengere Ziel für alles.	ADR-008	mittel	mittel	mittel	8.4 Metriken getrennt je Teil; Deployment-Variante prüfen (Kapitel 7).
R-025	Rechnungswesen aus der Cloud erreichen: offene Frage auf dem Board.	Board Seite 10, 11	mittel	mittel	mittel	8.5 Fehlerfall "Rechnungswesen nicht erreichbar"; Schnittstelle vor der Cloud-Entscheidung klären.
R-031	Terminänderungen durch Eilaufträge oder Ausfall einer Mechaniker:in müssen in Terminplanung und Reparatur durchführen konsistent ankommen.	ADR-010	hoch	mittel	mittel	Informationsfluss Termin festlegen (ADR-012); 8.5 Fehlerfall.
R-032	Vier Repositories bei einem Team von drei bis vier Personen ohne IT. Pflege, Zugriffsrechte und Build-Ketten liegen bei niemandem im Shop.	ADR-011	hoch	mittel	mittel	Eigener Support (QS-U-07); Build-Kette automatisieren.
R-034	Terminplanung muss bei Reparatur durchführen nachfragen, ob die Planung noch gilt (57:50). Das läuft gegen die Abhängigkeitsrichtung.	ADR-012	hoch	mittel	mittel	Entscheidung synchron oder Messages nachholen; 8.5.
R-027	Das Protokoll enthält Einträge, die nicht kundensichtbar sein sollen (37:03). Ohne Filter erreichen sie die Statusseite.	ADR-009	mittel	mittel	mittel	Filter in Reparatur durchführen; 8.2 (T-004).
R-029	Der Schnitt entstand leichtgewichtig entlang der Stories. Komplexe Fachlogik, die Event Storming aufdecken würde, bleibt unentdeckt.	ADR-009	mittel	mittel	mittel	Domänenanalyse nachholen, sobald Fachlogik wächst; 11.2.
R-030	Wird die Terminplanung gekauft, passt das Produkt nur ungefähr (44:18). Kompromisse an der Schnittstelle zu Reparatur durchführen.	ADR-010	mittel	mittel	mittel	Spike vor Kaufentscheidung; QS-A-01 als Aufwandsgrenze.
R-033	Repository-Grenzen fixieren den Modulschnitt früh. Ein falscher Schnitt kostet Umzug von Code und Historie.	ADR-011	mittel	mittel	mittel	Schnitt vor Anlage der Repositories prüfen (R-028).
R-046	Rufbereitschaft rund um die Uhr für einen Shop mit drei bis vier Mitarbeitenden; Kosten ungenannt.	ADR-017	hoch	mittel	mittel	Kosten beziffern; nächtliches Ziel QS-Z-05 gegen Kosten prüfen.
R-047	Rufbereitschaft ohne Entwicklerin braucht Runbooks; sonst Erreichbarkeit ohne Wiederanlauf.	ADR-017	hoch	mittel	mittel	Runbooks je Fehlerfall aus 8.5; Monitoring 8.4.
R-040	Bleibt Monolith oder Microservices offen, entsteht implizit ein Monolith ohne Entscheidung.	ADR-014	hoch	mittel	mittel	Entscheidung mit dem ersten Inkrement treffen (ADR-014 Deferred).
R-045	Eine gemeinsame Datenbank für vier Module unterläuft den fachlichen Schnitt.	ADR-016	mittel	mittel	mittel	Schema je Modul trennen; Zugriff nur über das eigene Modul (ADR-009).
R-049	Der Kunde akzeptiert den Netzausfall nicht und verlangt den Cache-Server; Wartung vor Ort kehrt zurück.	ADR-018	mittel	mittel	mittel	Risiko mit dem Kunden besprechen; mobiler Router als Reserve.
R-050	Der Low-Tech-Fallback braucht aktuelle Preise auf Papier oder in einer Tabelle; niemand ist benannt.	ADR-018	mittel	mittel	mittel	Verantwortliche benennen; 8.5 Fehlerfall Netzausfall.
R-041	Die Gleichwertigkeit von Monolith und Microservices gilt nur für die vorhandenen Szenarien; Performance und Security fehlen.	ADR-014	mittel	mittel	mittel	Szenarien für Performance und Security ergänzen (Kapitel 10).
R-001	Adresse liegt in der User-Datenbank des Webshops, obwohl sie fachlich Kundeninformation ist.	ADR-001	mittel	niedrig	niedrig	8.2 HTTPS und Zugriff nur über das Backend (T-004); Grenze Nutzerdaten/Kundendaten in Kapitel 5 benennen.
R-016	Der Umfang wächst um eine Inventardomäne; die Verantwortung verwässert.	ADR-006	mittel	niedrig	niedrig	Modul Materialbeschaffung klar abgrenzen (Kapitel 5).
R-019	Benachrichtigung landet im Spam oder wird nicht gelesen.	ADR-007	mittel	niedrig	niedrig	Statusseite als zweiter Weg (ADR-005); SMS vorsehen; QS-U-03.
R-021	Benachrichtigung nicht gekapselt; SMS-Nachrüstung wird teuer.	ADR-007	mittel	niedrig	niedrig	Benachrichtigung als eigene Schnittstelle im Modul Reparatur durchführen.
R-007	Geteilter Origin mit dem Webshop: eine Schwachstelle betrifft die Cookies beider Systeme.	ADR-002	niedrig	mittel	niedrig	8.2 HTTPS, `HttpOnly`; bewusst nachrangig (Security).
R-017	Führt der Laden ein Warenwirtschaftssystem ein, entstehen zwei Bestände.	ADR-006	niedrig	mittel	niedrig	Bestandsführung hinter einer Schnittstelle, damit ein Abgleich nachrüstbar ist.
R-020	E-Mail-Dienst ist ein Cloud-Dienst; on-premise braucht einen Weg ins Internet.	ADR-007	niedrig	niedrig	niedrig	8.5 Fehlerfall "EMail-Dienst fällt aus"; entfällt bei Cloud-Betrieb.
R-028	Erweist sich das Domänenmodell der Materialbeschaffung als dünn, trägt das Modul den Aufwand eines eigenen Projekts ohne fachlichen Gewinn.	ADR-009	mittel	niedrig	niedrig	Schnitt bei Umsetzung prüfen; 11.2 Technische Schulden.
R-036	Wer die Board-Legende liest, versteht die Pfeile als Aufrufrichtung und leitet synchrone Aufrufe ab, die nie entschieden wurden.	ADR-012	mittel	niedrig	niedrig	Legende in Kapitel 5 korrigiert (Informationsfluss).
R-038	Die Wahl von AWS beruht auf der Erfahrung des Autors; ein Team ohne AWS-Erfahrung trägt Einarbeitung.	ADR-013	mittel	niedrig	niedrig	Einarbeitung einplanen; Managed Services bevorzugen.
R-043	Die SLA-Ableitung stammt aus der Lektüre im März 2022; ändert AWS die Definition, gilt sie nicht mehr.	ADR-015	niedrig	mittel	niedrig	SLA-Texte bei Umsetzung erneut prüfen.
R-048	Werkstatt-Szenarien gelten auch samstags; eine Entwicklerin zu Bürozeiten deckt das nicht.	ADR-017	mittel	niedrig	niedrig	Öffnungszeiten mit dem Support-Fenster abgleichen (QS-Z-01).
R-037	Ein Ausfall der AWS-Region trifft alle Szenarien zugleich; kein Ausweichen auf eine zweite Region geplant.	ADR-013	niedrig	hoch	niedrig	Akzeptiert; Backup außerhalb der Region prüfen (ADR-016).
R-042	Ein Ausfall der ganzen Region bleibt ungedeckt.	ADR-015	niedrig	hoch	niedrig	Wie R-037; Multi-Region nur bei SaaS-Wachstum.

Note	Offen: Die Spalten Wahrscheinlichkeit und Auswirkung sind Schätzungen. Das Team bestätigt oder korrigiert sie; die Priorität folgt dann aus der Regel oben.

11.2 Technische Schulden

Note	Offen: kein Code, keine technischen Schulden erfasst.

Kandidaten bei der Umsetzung: Die gelbe Notiz "ggf. finanziellen Aspekt separieren?" (Board Seite 9) ist eine Entwurfsschuld an den Bausteinen Reparatur durchführen und Bezahlung, falls Preisberechnung und Rechnungselemente zunächst im Baustein Reparatur durchführen bleiben. Ein zweiter Kandidat ist die Bestandsführung im Baustein Materialbeschaffung (ADR-006), falls sie als Eigenlösung ohne Abgleichschnittstelle gebaut wird (R-017).

Feedback

Was this page helpful?

Glad to hear it! Please tell us how we can improve.

Sorry to hear that. Please tell us how we can improve.