Einführung und Ziele

Dieses Dokument beschreibt die Architektur des Reparatur-Systems für einen lokalen Fahrradshop. Eberhard Wolff hat das System in den Folgen 111 bis 113 von software-architektur.tv ("Wir bauen eine Software-Architektur", Februar und März 2022) live entworfen. Wir dokumentieren den Entwurf nachträglich nach arc42. Quellen sind die Transkripte der Folgen und der Endstand des Miro-Boards (11 Seiten, Stand 2022-03-25). Zeitmarken ohne Folgenangabe beziehen sich auf Folge 111.

Aufgabenstellung

Das System nimmt Reparaturen online an und organisiert die Werkstatt

Ein lokaler Fahrradshop in Kaiserslautern mit drei bis vier Mitarbeitenden will Reparaturen über das Web annehmen und die Werkstatt organisieren (16:46). Kund:innen sollen ihr Fahrrad online zur Reparatur anmelden, statt dafür in den Laden zu kommen (14:02). Der Shop betreibt bereits einen Webshop (14:25). Das Reparatur-System ergänzt ihn um Reparaturen als eigenen Bereich unter /reparatur (ADR-002, ADR-003).

Drei Geschäftsziele treiben den Entwurf:

  • Kund:innen beauftragen Reparaturen online. "Wenn Kunden damit keine Reparaturen beauftragen, dann haben wir ein Problem" (41:52).

  • Die Werkstatt organisiert Reparaturen im System: Termine, täglicher Reparaturplan, Protokoll, Bestellung von Ersatzteilen und Werkzeug.

  • Funktioniert das System gut, will der Shop es als SaaS-Lösung anderen Fahrradshops anbieten (42:13).

Drei Akteure und fünfzehn Stories bilden das Backlog

Das Backlog liegt als Stories auf Seite 1 des Miro-Boards. Es ist "mehr oder weniger gut strukturiert" und dient dem Architekten als Input (09:38). Eine fünfzehnte Story kam in Folge 112 hinzu und steht nur auf Seite 7.

Akteur Stories (Miro-Board Seite 1)

Kund:in

Fahrrad zur Reparatur anmelden; Reparaturtermin berechnen; Status der Reparatur abfragen; Repariertes Fahrrad abholen

Shop-Mitarbeiter:in

Reparatur bezahlen; Fahrrad zur Reparatur abgeben

Fahrrad-Mechaniker:in

Kunde über das Ende der Reparatur informieren; Fahrrad-Defekt aufnehmen; Voraussichtliche Kosten berechnen (seit Folge 112, 27:06; nur Board Seite 7); Reparatur einplanen; Täglichen Reparaturplan erstellen; Nächste Reparatur beginnen; Reparatur protokollieren; Ersatzteile bestellen; Werkzeuge bestellen
Note
 Die Story "Voraussichtliche Kosten berechnen" kam in Folge 112 auf einen Vorschlag aus dem Chat hinzu (27:06) und liegt im Modul Reparatur durchführen. Board Seite 7 führt sie, Seite 1 nicht; das Board ist an dieser Stelle in sich nicht konsistent. Der Akteur ist auf dem Board nicht benannt; die Zuordnung zur Mechaniker:in folgt aus dem Beispiel im Video (28:06: Schaltung ansehen, Teile und Montage kalkulieren).

Das Beispiel ist eine Architektur-Kata mit expliziten Annahmen

Eberhard entwirft das System live, ohne echten Auftraggeber. Er trifft dafür Annahmen und benennt sie:

  • Die Gespräche mit Anforderern und Fachexperten sind imaginär. "Ich dokumentiere das, was in diesem imaginären Gespräch rüberkommt" (14:47).

  • Die fachliche Detaillierung der Stories ist Aufgabe des Requirements Engineering, nicht des Architekten (09:38).

  • Der Shop hat keine IT-Abteilung. "Die haben eigentlich nicht wirklich einen Betrieb" (17:05). Der Betrieb ist deshalb kein Akteur des Systems (17:09).

  • Wo das System läuft (Cloud oder lokaler Server), ist eine Architekturentscheidung und keine Anforderung. Den Geschäftsführer zu fragen bringt "mir egal" oder "was ist die Cloud?" (10:22, 10:42).

  • Die arc42-Kapitelreihenfolge ist nicht die Vorgehensreihenfolge (11:43). Eberhard beginnt mit dem Kontextdiagramm (13:00), erhebt dann Qualitätsszenarien und denkt erst danach über eine Lösung nach.

Qualitätsziele

Eberhard erhebt die Qualitätsziele selbst und nutzt ISO 25010 als Checkliste, statt reflexhaft "wartbar und skalierbar" zu fordern (43:43). Der Fachexperte nennt Benutzerfreundlichkeit als das, was zählt (41:44). Aus dem Gespräch ergibt sich diese Rangfolge:

Rang Qualitätsziel Motivation Zeitmarke (Folge 111)

1

Benutzerfreundlichkeit (Usability) für Kund:innen und Mitarbeitende

"Insbesondere Benutzerfreundlichkeit ist wichtig. Wenn Kunden damit keine Reparaturen beauftragen, dann haben wir ein Problem. Das wird nur funktionieren, wenn das benutzerfreundlich ist." Gilt "in erster Linie für Kunden, aber auch für die Leute in der Werkstatt". Ohne Benutzerfreundlichkeit stellt sich die Frage, "warum zum Teufel entwickeln wir das überhaupt".

41:44, 41:52, 42:06, 42:56, 59:13

2

Änderbarkeit, konkret Richtung SaaS für andere Shops

"Wenn dieses System besonders gut funktioniert, dann wollen wir eine SaaS-Lösung draus machen", also "dafür sorgen, dass andere Leute das benutzen können". Änderungsszenario: Der Umbau zum SaaS dauert höchstens zwei Monate und nicht mehr als 20 Personentage. Ob das Mandantenfähigkeit oder eine Installation pro Fahrradladen bedeutet, hängt davon ab, "ob wir diese Installation pro Fahrradladen finanzieren können".

42:13, 43:52, 44:12, 57:42, 58:15

3

Verfügbarkeit, differenziert nach Nutzergruppe

Shop-System: 99 % zwischen 9 und 18 Uhr, nach Ausfall spätestens nach 30 Minuten wieder da. Web-System für Kund:innen: 99,9 % zwischen 7 und 24 Uhr, nachts 99 %. Eberhard fasst zusammen: "Wir haben eher entspannte Anforderungen bezüglich der Verfügbarkeit." Details in ADR-008.

55:07, 55:42, 56:21, 59:18

Security und Vertraulichkeit sind bewusst nachrangig. "Es wäre wahrscheinlich gut, wenn das System nicht Informationen über irgendwelche Kunden nach draußen leckt. Aber selbst wenn das passiert, das sind am Ende Fahrradreparaturdaten, ist das wirklich so kritisch? Da müssen wir mit dem Experten nochmal sprechen" (58:29 bis 58:48). Die übrigen ISO-25010-Kategorien sind "nicht so wahnsinnig wichtig" (58:22).

Die konkreten Qualitätsszenarien vom Miro-Board (Seiten 5 und 6) stehen in Qualitätsanforderungen. Wie die Architektur die drei Ziele erreicht, beschreibt Lösungsstrategie.

Stakeholder

Die Stakeholder sind Rollen der Architektur-Kata. Reale Kontaktpersonen gibt es nicht; die Spalte Kontakt nennt, wer die Rolle im Beispiel verkörpert.

Rolle Kontakt Erwartungshaltung

Kund:in

Kund:innen des Fahrradshops; im Webshop registriert

Meldet das Fahrrad online zur Reparatur an, ohne sich neu zu registrieren (Webshop-Login genügt, ADR-001). 90 % schaffen die Beauftragung in zwei Minuten (Board Seite 5). Fragt den Status ab, wird bei Fertigstellung informiert (ADR-007), zahlt online oder im Laden.

Shop-Mitarbeiter:in

Drei bis vier Personen im Laden (16:46)

Nimmt Fahrräder an und rechnet Reparaturen an der Kasse ab (ADR-004). Bedient das System nach einer Stunde Einarbeitung eigenständig. Erwartet Verfügbarkeit im Laden zwischen 9 und 18 Uhr; überbrückt 30 Minuten Ausfall "mit Zettel und Bleistift" (55:42).

Fahrrad-Mechaniker:in

Werkstatt des Shops

Nimmt Defekte auf, plant Reparaturen ein, arbeitet den täglichen Reparaturplan ab, protokolliert Positionen, bestellt Ersatzteile und Werkzeug (ADR-006). Bedient das System nach einer Stunde Einarbeitung eigenständig.

Shop-Inhaber:in

Geschäftsführer, Ansprechpartner des Architekten (10:05)

Kund:innen beauftragen Reparaturen online, sonst "haben wir ein Problem" (41:52). Das System läuft ohne eigene IT-Kenntnisse im Shop (Cloud, eigener Support; Board Seite 5). Perspektive: SaaS für andere Shops. Zum Betriebsmodell keine Meinung ("mir egal", 10:22).

Steuerberater:in / Rechnungswesen

Extern, außerhalb des Shops

Reparaturen werden "vernünftig verbucht gegenüber dem Steuerberater" (20:35). Das System liefert Rechnungselemente an das Rechnungswesen (Board Seite 9).

Webshop-Betreiber

Hersteller und Betreiber des Standard-Webshops

Der Webshop bleibt unverändert und hält keine Reparaturdaten (ADR-005). Das Reparatur-System hängt sich per URL-Umleitung von /reparatur, JWT-Cookie und REST an (ADR-001, ADR-002).
Note
 Offen: Ob der Webshop-Betreiber die URL-Umleitung und den Zugriff auf die User Database tatsächlich anbietet, wurde in Folge 111 nicht geprüft. Quelle: Transkript Folge 112/113 ausstehend.