chap 7: Projektabschluss — Soll-Ist, Zielerreichung, Reflexion, Ausblick

chapters/closure/outlook.tex

@@ -1,6 +1,48 @@
 \section{Ausblick}
 \label{sec:outlook}
 
-% TODO: PBI 10070 (Race Conditions), Search Integration (von AU noch nicht verfügbar),
-% Dashboard-Kacheln (Security Assessments, zuletzt hinzugefügte Dokumente),
-% Abrechnungsdaten
+\subsection{Abschluss der begonnenen Arbeiten}
+
+Die nächstliegenden Schritte ergeben sich unmittelbar aus dem in Abschnitt~\ref{sec:target-comparison} beschriebenen Stand.
+
+Zusammenzuführen ist der Pull Request zur Ordnerverwaltung. Damit werden zugleich die automatische Anlage der Ordnerstruktur und der Lookup mit konstanter Aufrufzahl wirksam. Da die Lösung bestehende Ordner selbsttätig auf den kanonischen Namen umbenennt, ist kein gesonderter Migrationsschritt erforderlich — der Bestand wird durch den laufenden Betrieb überführt.
+
+Zu beheben ist ferner der aus der Abnahme hervorgegangene Fehler zur Einheitlichkeit des Suchfeldes, der für den folgenden Sprint eingeplant ist.
+
+\subsection{Absicherung des verändernden Lookup-Pfads}
+
+Die in Abschnitt~\ref{sec:race-conditions} beschriebene Nebenläufigkeit ist das inhaltlich gewichtigste offene Thema. Der zugehörige Backlog Item ist freigegeben und mit einem Zeitrahmen von vier bis sechs Stunden versehen.
+
+Welche der vorgeschlagenen Maßnahmen umgesetzt wird, hängt davon ab, ob der Speicher bedingte Schreibvorgänge unterstützt.\autocite{aws-conditional-writes} Diese Frage ist Teil derselben Rückfrage beim Betreiber, die auch den Suchdienst betrifft. Steht die Funktion zur Verfügung, ist die Absicherung mit geringem Aufwand möglich; andernfalls bleiben die Absicherung des Rücknahmeschritts und eine übergreifende Sperre.
+
+Unabhängig von dieser Entscheidung ist zu erwägen, den verändernden Anteil aus dem Anfragepfad herauszulösen. Ein eigener Vorgang, der die Ordnerbestände abgleicht, hätte den Vorteil, dass er einmalig und ohne Nebenläufigkeit ausgeführt wird. Der Lookup könnte dann auf reines Lesen zurückgeführt werden — die Selbstheilung entfiele, würde aber auch nicht mehr benötigt.
+
+\subsection{Suchdienst des Speicherherstellers}
+
+Der in Abschnitt~\ref{sec:lookup-research} betrachtete Suchdienst\autocite{storagegrid-search-integration} wurde vom Betreiber nicht bereitgestellt. Die Anfrage wurde an dessen Produktverantwortliche weitergegeben; ein Folgetermin war zum Ende des Projektzeitraums vorgeschlagen, aber noch nicht durchgeführt.
+
+Sollte der Dienst künftig verfügbar sein, eröffnet er zwei Möglichkeiten. Zum einen ließe sich der Kundenordner-Lookup unmittelbar über eine Abfrage auf das Metadatum lösen — die aufwendigere eigene Konstruktion würde damit entbehrlich, wäre aber weiterhin funktionsfähig und könnte als Rückfallebene bestehen bleiben. Zum anderen ließe sich die Dokumentensuche serverseitig ausführen, statt wie bisher sämtliche Schlüssel eines Kunden zu laden und anwendungsseitig zu filtern.
+
+Beide Verbesserungen sind Optimierungen, keine Fehlerbehebungen. Die bestehende Umsetzung funktioniert; sie skaliert lediglich schlechter, als sie es mit dem Dienst täte.
+
+\subsection{Fachliche Erweiterungen}
+
+In der Feature-Beschreibung sind zwei Erweiterungen genannt, die nicht in Backlog Items überführt wurden und damit für einen späteren Zeitpunkt offenstehen.
+
+Die erste betrifft die \textbf{Einbindung in die Übersichtsseite} des Kundenportals. Denkbar sind eine Kachel mit den zuletzt hinzugefügten Dokumenten sowie eine gesonderte Darstellung von Sicherheitsbewertungen. Für Letztere wäre allerdings zusätzliche Information nötig: Um etwa den Zeitpunkt der letzten Bewertung anzuzeigen, müssten die entsprechenden Dokumente ein auswertbares Merkmal tragen. Das ist mit der bestehenden Struktur, die den Typ ausschließlich über den Ordner ausdrückt, nicht abbildbar und würde ein Metadatum pro Dokument erfordern.
+
+Die zweite betrifft die \textbf{Bereitstellung von Abrechnungsdaten}. Hier ist zunächst fachlich zu klären, ob diese über den Dokumentenbereich oder über eine gesonderte Ansicht bereitgestellt werden sollen, da sie sich in Herkunft und Aktualisierungsrhythmus deutlich von den übrigen Dokumenttypen unterscheiden.
+
+\subsection{Bedienung durch die interne Fachseite}
+
+Die Entscheidung, die Dokumentenpflege über den bestehenden externen Dateibrowser abzuwickeln und keine eigene Verwaltungsoberfläche zu bauen, war für den Projektzeitraum richtig: Sie sparte erheblichen Aufwand und ermöglichte die Konzentration auf die Kundensicht.
+
+Sie ist jedoch bewusst als Zwischenlösung getroffen worden. Sollte sich im Betrieb zeigen, dass die Pflege häufiger erfolgt oder von einem größeren Personenkreis übernommen wird als angenommen, wäre eine Verwaltungsoberfläche innerhalb des Kundenportals neu zu bewerten. Sie hätte zudem den Vorteil, die Ordnerstruktur nicht mehr manuell einhalten zu müssen — die Zuordnung von Kunde und Typ könnte dann durch die Anwendung erzwungen werden, statt sich auf die richtige Ablage durch die pflegende Person zu verlassen.
+
+\subsection{Übertragbarkeit}
+
+Über den Dokumentenbereich hinaus hat das Projekt zwei Bausteine hervorgebracht, die auch in anderem Zusammenhang verwendbar sind.
+
+Der \textbf{Zugriff auf den Objektspeicher} ist als eigener Dienst gekapselt und nicht auf Dokumente zugeschnitten. Weitere Anwendungsfälle, die größere Dateien außerhalb der Datenbank ablegen müssen, können darauf aufsetzen.
+
+Die \textbf{Muster für Freigabelinks und Vorschaubilder} — die Kodierung des relativen Pfades, die bewusst eingeschränkte Auslieferung von Vorschaubildern auf einem nicht angemeldeten Endpunkt und die Bereitstellung in einem von Kommunikationsanwendungen unterstützten Bildformat — sind ebenfalls unabhängig vom Dokumentenbereich und lassen sich für andere teilbare Inhalte des Kundenportals wiederverwenden.