Abschlussprojekt

Abschlussprojekt

0:00 Willkommen zum letzten Modul. Sechs Tage lang haben wir Lotsenhaus Stück für Stück aufgebaut: Architektur und Installation, Anmeldung und Rechte, Modelle, Assistenten und Wissen, Werkzeuge und ihre Absicherung, Überwachung, Sicherung und schließlich den Weg in den Pilot. Jetzt kommt alles zusammen. Im Abschlussprojekt führen Sie die Ergebnisse zu einer Laborlösung zusammen, weisen nach, dass sie betriebsfähig ist, und lassen sie von einem anderen Team prüfen.

0:26 Am Ende steht keine Note, sondern eine Freigabeentscheidung, so wie sie auch bei Brandtner Fördertechnik fallen würde. Das ist der Moment, in dem sich zeigt, ob das Gelernte trägt.

Abschlussprojekt

0:37 Der Satz auf dieser Folie fasst das ganze Seminar in eine Haltung. Freigegeben wird nicht das Chatfenster, denn das sieht bei fast jeder Plattform gut aus. Freigegeben wird eine Plattform, deren Qualität, Zugriffsschutz und Betrieb jemand anderes nachprüfen konnte. Dieses Nachprüfen durch Fremde ist heute der Kern.

Die Ergebnisse zusammenführen

0:56 Zuerst wird gesammelt. Sechs Tage Arbeit liegen verteilt in Dateien, Notizen und Einstellungen. Daraus soll eine Lösung werden, die ein anderer verstehen kann. Der Maßstab für das Zusammenführen ist anspruchsvoller, als er klingt: Ein anderes Team soll Ihre Laborlösung ohne Erklärung nachbauen und prüfen können. Stellen Sie sich ein gutes Kochbuch vor. Es funktioniert nicht, weil der Koch daneben steht, sondern weil jede Zutat und jeder Schritt aufgeschrieben ist.

1:25 Übertragen auf Lotsenhaus heißt das: Jede Entscheidung ist begründet, jede Einstellung steht in einer Datei, und jede Berechtigung hängt an einer Gruppe statt an einzelnen Personen. Das ist mehr als Ordnungsliebe. Genau diese Eigenschaften entscheiden darüber, ob die Plattform den Weggang ihrer Erbauer übersteht. Die Schichten zeigen Lotsenhaus als Ganzes, von außen nach innen. Ganz oben der Zugang mit Reverse Proxy, dem Keycloak-Realm und den Gruppen.

1:52 Darunter die Modelle, das lokale auf inferenz-01 und ein externer Endpunkt, jeweils mit einer festen Grenze, welche Datenklassen sie sehen dürfen. Dann die beiden Assistenten, Schreibhilfe und Richtlinienlotse mit seiner Wissensbasis. Darunter die Werkzeuge, im Pilot nur lesend. Und als Fundament der Betrieb mit Datenbank, Redis, Sicherung, Monitoring und Runbooks. Jede Schicht stammt aus einem anderen Teil des Seminars.

2:18 Das Abschlussprojekt zeigt, ob sie auch zusammenpassen. Diese Tabelle übersetzt jedes Ergebnis in einen Nachweis, und das ist der eigentliche Perspektivwechsel. Es reicht nicht, dass die Architektur steht, das Zielbild und die Betriebsentscheidung müssen begründet sein. Es reicht nicht, dass die Installation läuft, sie muss sich aus dem Repository mit gepinntem Image-Tag neu aufbauen lassen.

2:41 Berechtigungen gelten erst als geprüft, wenn sie je Gruppe getestet sind, Modellzugänge erst, wenn ihre Datenklassen-Grenze belegt ist. Und der Richtlinienlotse muss den Widerspruch zwischen den beiden Fassungen der Reisekostenrichtlinie auflösen. Die Fußzeile ist streng, aber fair: Was nicht nachgewiesen ist, gilt im Review als nicht vorhanden.

3:02 Die Stolpersteine beim Zusammenführen sind alte Bekannte aus dem Seminar, die jetzt ihre Rechnung präsentieren. Wer Einstellungen nur im Admin-Bereich geändert hat, erlebt beim Neuaufbau aus dem Repository eine andere Plattform als die, die er vorführen wollte. Wer Berechtigungen mit dem Administratorkonto testet, sieht alles, denn dieses Konto umgeht die Zugriffsregeln, und der Test beweist nichts.

3:24 Wer den externen Modellzugang mit vertraulichen Testdokumenten vorführt, verletzt die eigene Governance-Matrix vor Publikum. Und wer die Architekturbegründung erst beim Vortrag formuliert, merkt meist dort, dass sie Lücken hat.

Betriebsfähigkeit nachweisen

3:37 Eine Plattform, die nur im Sonnenschein funktioniert, ist nicht betriebsfähig. In diesem Kapitel zeigen Sie, was passiert, wenn etwas schiefgeht. Auffällig an dieser Tabelle ist, wie viele Nachweise aus einem Nein bestehen. Beim Störmelder zählt nicht nur, dass der Status von SM-4711 abgefragt werden kann, sondern dass ein Schreibzugriff ohne Freigabe abgewiesen wird.

4:00 Beim manipulierten Lieferantenmerkblatt LM-2 zählt, dass die versteckte Anweisung eben nicht ausgeführt wird. Und beim Zugriffsschutz zählt, dass ein Nutzer aus der IT die Ressourcen der Kommunikation nicht sieht. Dazu kommen Referenzfragen mit Quelle, überwachte Gesundheits-Endpunkte und das Protokoll der Wiederherstellungsprobe.

4:20 Die Fußzeile macht klar, was ein Nachweis ist: ein Screenshot, ein Log-Auszug oder ein Testprotokoll, keine Erinnerung. Diese Prüfliste ist bewusst kurz, sieben Zeilen, jede eine Frage, die sich mit Ja oder Nein beantworten lässt. Sie funktioniert wie die Checkliste im Cockpit vor dem Start. Piloten kennen ihr Flugzeug, und trotzdem gehen sie die Liste durch, weil gerade das Selbstverständliche im Eifer übersehen wird.

4:45 Die sieben Punkte decken die Schichten der Laborlösung ab, vom Neuaufbau über Rechte, Modelle, Wissen und Werkzeug bis zu Sicherheit und Betrieb. Die Fußzeile verrät die doppelte Funktion: Dieselbe Liste ist zugleich der Kriterienkatalog für das gegenseitige Review. Wer sie vorher ehrlich abarbeitet, erlebt dort keine Überraschungen.

5:05 Bei Vorführungen gibt es eine natürliche Versuchung, und sie ist der häufigste Fehler: nur den Erfolgsweg zu zeigen. Dabei ist der abgewiesene Schreibzugriff der eigentliche Nachweis, nicht die gelungene Abfrage. Ähnlich ist es mit der Wiederherstellung, die gern behauptet statt mit dem Protokoll belegt wird. Tückischer ist der dritte Punkt: Qualitätstests, die mit genau den Fragen bestanden werden, mit denen die Wissensbasis gebaut wurde.

5:30 Das ist wie eine Prüfung mit vorher bekannten Aufgaben. Und schließlich die Haltung, Sicherheitshinweise für die laufende Version zu ignorieren, weil es ja nur ein Labor ist. Genau diese Gewohnheit nimmt man sonst in die Produktion mit.

Die Freigabe begründen

5:43 Jetzt wechselt die Rolle. Ein fremdes Team prüft, das eigene Team begründet, und am Ende steht eine Entscheidung, die beide nachvollziehen können. Das Review ist bewusst nach dem Vier-Augen-Prinzip gebaut, wie man es aus der Buchhaltung oder vom Code-Review kennt. Jedes Team stellt sein Konzept für Pilot, Rollout und Betrieb vor und führt die Laborlösung vor. Ein anderes Team prüft gegen den vereinbarten Kriterienkatalog.

6:09 Wichtig ist der kleine Zusatz: Befunde werden ohne Diskussion notiert. Das klingt streng, schützt aber beide Seiten. Die Prüfer müssen nicht verhandeln, und die Vorführenden verlieren keine Zeit mit Rechtfertigungen. Am Ende schlägt das prüfende Team eine Freigabeentscheidung vor. So entsteht eine Beurteilung, die nicht davon abhängt, wer am überzeugendsten erzählt.

6:31 Diese Folie erklärt, warum ein beeindruckender Chat im Review fast nichts zählt. Eine gute Antwort zeigt die Leistung des Modells, nicht die der Plattform darum herum. Die eigentlichen Risiken liegen woanders: in Rechten, in Datenwegen, in Werkzeugen und im Betrieb. Eine Freigabe muss außerdem tragen, wenn das Projektteam längst weitergezogen ist, und das gelingt nur mit nachprüfbaren Grundlagen. Besonders wertvoll ist der letzte Gedanke.

6:57 Offene Punkte, die ein Team selbst benennt, sind ein Ergebnis und zeugen von Überblick. Verschwiegene Punkte dagegen sind ein Risiko, das später teurer wird. Die Bewertungsbögen machen sichtbar, worauf es bei einer Unternehmensplattform wirklich ankommt. Drei Kriterien sind hoch gewichtet: Qualität, Zugriffsschutz und Betriebsfähigkeit.

7:18 Das sind die Bereiche, in denen ein Fehler Menschen falsch informiert, Daten in falsche Hände bringt oder die Plattform lahmlegt. Konzept und Nachvollziehbarkeit sind nicht unwichtig, aber eine Lücke dort lässt sich leichter nachholen. Achten Sie auf die Fußzeile, denn sie verhindert ein bekanntes Spiel: Die Gewichte werden vor dem Review gemeinsam festgelegt, nicht danach.

7:39 Sonst passt man die Regeln dem Ergebnis an, das man ohnehin haben wollte. Die vier Entscheidungen sind abgestuft, und das ist realistisch. Eine glatte Freigabe gibt es, wenn alle hoch gewichteten Kriterien erfüllt und nur nachrangige Punkte offen sind. Häufiger ist die Freigabe mit Auflagen, und die ist nur so gut wie ihre Auflagen: jede mit Termin und Verantwortlichem, sonst ist sie ein Wunsch.

8:02 Nacharbeit heißt, ein wichtiges Kriterium ist verfehlt und muss erneut geprüft werden. Und keine Freigabe gibt es in zwei klaren Fällen: wenn der Zugriffsschutz verletzt ist oder die Wiederherstellung nicht belegt. Das sind die beiden Punkte, bei denen ein Unternehmen keine Kompromisse eingehen sollte.

Übung

8:19 Zum letzten Mal im Seminar wird es praktisch. Vorführen, fremd prüfen lassen und gemeinsam entscheiden. Diese Übung trainiert zwei Fähigkeiten zugleich. Sie vertreten Ihre eigene Plattform anhand belegter Kriterien, und Sie beurteilen die Lösung eines anderen Teams so, dass Ihr Urteil nachvollziehbar ist. Beides brauchen Sie im Unternehmen, denn Sie werden mal in der einen, mal in der anderen Rolle sitzen.

8:43 Erfolgreich ist die Übung, wenn Ihre Lösung samt Fehlerfällen vorgeführt ist, das fremde Review schriftlich vorliegt und die Entscheidung Begründung und Auflagen nennt. Eine Spielregel ist wichtig: Die Entscheidung trifft das prüfende Team. Als vorführendes Team beantworten Sie nur Rückfragen, und das ist manchmal die schwerste Übung von allen.

9:03 Zwei Stunden, ein klarer Ablauf. Zuerst arbeiten Sie die Prüfliste ab und reichen fehlende Belege nach. Dann folgt die Vorführung, vom Konzept bis zur Wiederherstellung. Das fremde Team prüft, notiert Befunde und schlägt eine Entscheidung mit Auflagen vor. Zum Schluss halten Sie gemeinsam die offenen Punkte fest, und die werden der erste Eintrag im Backlog des Regelbetriebs. Damit schließt sich der Kreis dieses Seminars.

9:27 Begonnen haben wir mit Steckbriefen und einer Governance-Matrix für ein Unternehmen, in dem jedes Team seinen eigenen Assistenten nutzte. Jetzt steht eine geprüfte Plattform mit Regeln, Verantwortlichen und einem Weg in den Betrieb. Vielen Dank fürs Mitmachen, und viel Erfolg mit Ihrem eigenen Lotsenhaus.