Vom Proof of Concept in den Regelbetrieb: die technische Übergabe

01

Funktionieren ist nicht dasselbe wie Betreibbarkeit

Ein Proof of Concept beantwortet eine einzige Frage: Geht das? Mehr nicht. Er darf Abkürzungen nehmen, Zugangsdaten im Code, Tabellen von Hand geändert, eine Testumgebung, die gar nicht existiert, und all das ist erlaubt, weil es die Machbarkeit nicht berührt. Der Regelbetrieb fragt anders. Was passiert nachts, wenn der Datenträger voll läuft? Wer ändert eine Geschäftsregel, wenn die Person, die sie geschrieben hat, im Urlaub ist, und wie kommt die Anwendung überhaupt zurück, wenn der Server mitten in der Nacht ausfällt? In der Reihe Vom Prototyp zur produktionsreifen Anwendung taucht dasselbe Muster immer wieder auf: Im PoC werden solche Fragen selten gestellt, nicht aus Nachlässigkeit, sondern weil sie für die Machbarkeit unerheblich sind.

02

Welche Stationen liegen zwischen PoC und Regelbetrieb?

Der Weg führt über fünf Stationen: Machbarkeit, Pilot, Härtung, Übergabe, Regelbetrieb. Jede endet mit einer eigenen Frage. Die soll beantwortet sein, bevor die nächste Station beginnt, sonst schleppt man offene Fragen mit, die später teurer werden als am Anfang. Am besten wachsen die Übergabe-Artefakte schon ab dem Pilot mit, nicht erst am Ende der Reihe.

1. Proof of Concept

   Beweist die Machbarkeit mit wenig Struktur. Abkürzungen sind erlaubt. Notieren Sie sie trotzdem, damit später klar bleibt, welche Stellen bewusst provisorisch sind.

2. Pilot

   Echte Nutzer, oft echte Daten, ein begrenzter Kreis. Ab hier gelten Grundregeln des Betriebs: Zugangsdaten außerhalb des Codes, Schemaänderungen als Migrationen, eine Sicherung der Daten.

3. Härtung

   Berechtigungen serverseitig durchsetzen, Fehlerpfade behandeln, Protokolle ohne personenbezogene Daten schreiben, Abhängigkeiten auf einen gepflegten Stand bringen.

4. Übergabe

   Die sechs Artefakte liegen vor und wurden von jemandem gelesen, der nicht am Bau beteiligt war. Wie die IT über die Freigabe entscheidet, beschreibt Der Fachbereich hat eine App gebaut.

5. Regelbetrieb

   Überwachung, Sicherung, Aktualisierung und Zugriffskonzept laufen im Alltag weiter. Was das auf Dauer bedeutet, beschreibt Eine Anwendung im eigenen Haus betreiben.

03

Sechs Artefakte tragen die Übergabe

Architekturbeschreibung: Entscheidungen zählen mehr als Kästchen

Ein Diagramm mit Komponenten ist der leichte Teil, das zeichnet sich schnell. Wertvoller sind die Entscheidungen dahinter: warum diese Datenbank, warum das Sprachmodell lokal läuft oder über eine Schnittstelle angebunden ist, warum es eine Warteschlange gibt. Ohne Begründung werden solche Entscheidungen im Betrieb entweder nie hinterfragt oder aus Unkenntnis rückgängig gemacht. In unseren Projekten sehen wir das Muster oft: ein technisch sauberer PoC, aber keine Zeile dazu, warum eine bestimmte Komponente gewählt wurde. Ein schlankes Format hilft. Kurze Entscheidungsnotizen, eine pro Entscheidung, im Repository neben dem Code.

Betriebsdokumentation und Wiederanlaufplan: geschrieben für den schlechtesten Moment

Beide Dokumente werden gelesen, wenn etwas nicht stimmt, oft unter Zeitdruck, oft von jemandem, der die Anwendung selten anfasst, und genau deshalb sollten sie kurz sein, konkret sein, als Handlungsanweisung formuliert sein. Für die Zielwerte bietet der BSI-Standard 200-4 (BSI, 2023) zwei Begriffe: die geforderte Wiederanlaufzeit (RTO) und den maximal zulässigen Datenverlust (RPO). Ein Wiederanlaufplan ohne dokumentierten Test beschreibt eine Hoffnung. Mehr nicht. Erst eine tatsächlich durchgespielte Wiederherstellung zeigt, ob die Werte auch wirklich erreichbar sind, und genau solche Tests fordert der Baustein CON.3 im IT-Grundschutz-Kompendium (BSI, Edition 2023) ausdrücklich.

Datenmodell mit Migrationshistorie: das Artefakt, das am häufigsten fehlt

In vielen Proofs of Concept wurde die Datenbank direkt verändert: eine Spalte ergänzt, ein Typ angepasst, eine Tabelle von Hand angelegt. Das funktioniert, solange es genau eine Datenbank gibt. Sobald Test und Produktion getrennt sind, weiß niemand mehr sicher, welches Schema eigentlich wo gilt, und genau an dieser Stelle kippt die Ungenauigkeit von harmlos zu riskant. Wir haben Übergaben gesehen, bei denen die Produktionsdatenbank drei Spalten mehr hatte als jede dokumentierte Version, weil eine davon nachträglich per Hand ergänzt und nie festgehalten wurde. Niemand hatte es gemerkt. Eine Migrationshistorie legt jede Änderung als Skript in der Versionsverwaltung ab, sodass sich jeder Stand reproduzieren lässt. Lässt sich die Historie nicht rekonstruieren, ist ein dokumentierter Ausgangsstand als erste Migration ein sauberer Neubeginn.

Berechtigungskonzept und Ansprechpartner: Verantwortung, die einen Personalwechsel übersteht

Im PoC haben oft alle Beteiligten volle Rechte. Das Bauen geht so schlicht schneller. Im Regelbetrieb trennt das Berechtigungskonzept die Rollen, legt fest, wer administriert, und beschreibt, wie Zugänge beim Austritt erlöschen, während der Baustein ORP.4 im IT-Grundschutz-Kompendium des BSI (Edition 2023) dafür eine fertige Gliederung liefert. Ansprechpartner werden als Rollen festgehalten, nicht als Namen. So stimmt die Liste auch nach dem nächsten Wechsel noch.

04

Warum ist ein PoC ohne diese Artefakte kein Kandidat für den Regelbetrieb?

Ohne die Artefakte liegt das Wissen über Aufbau, Betrieb und Daten ausschließlich bei den Personen, die den Proof of Concept gebaut haben, und jede Störung, jede Änderung, jede Prüfung wird so zur Rückfrage an genau diese Menschen. Das trägt eine Weile. Es trägt, solange sie verfügbar sind, und endet abrupt, wenn sie es nicht mehr sind.

Die Qualität des Codes ändert daran wenig. Auch ein sauber geschriebener PoC ohne Migrationshistorie lässt sich nicht verlässlich in eine zweite Umgebung bringen, und auch ein eleganter Aufbau ohne Wiederanlaufplan steht nach einem Ausfall einfach still, bis irgendjemand mühsam die Zusammenhänge rekonstruiert hat. In unseren Projekten hängt das selten am Code. Es hängt am fehlenden Papier drumherum.

Ein einfacher Test macht die Lage greifbar. Bitten Sie eine Person, die nicht am Bau beteiligt war, die Anwendung ganz allein anhand der vorhandenen Unterlagen in einer leeren Umgebung aufzusetzen, ohne dass jemand vom Bau-Team daneben steht. Jede Rückfrage markiert ein fehlendes oder unvollständiges Artefakt. Bei Automatisierungen und Datenskripten gilt dasselbe, dazu mehr in Vom n8n-Workflow oder Streamlit-Skript zur betreibbaren Anwendung.

05

Wie denkt man die Produktion schon während des Pilots mit?

Produktion im Pilot mitzudenken heißt nicht, den Pilot wie ein fertiges Produktivsystem zu bauen, sondern die wenigen Entscheidungen früh richtig zu treffen, die sich später nur mühsam korrigieren lassen, während der Rest bewusst provisorisch bleiben darf. Alle anderen Abkürzungen werden notiert. Dazu gehören Zugangsdaten, Migrationen, Rollen, Protokollinhalte und der Speicherort der Daten.

iiterate Technologies GmbH entwickelt KI-Anwendungen und Individualsoftware. Von der Architektur über die Umsetzung bis zum Betrieb, übergeben mit Quellcode und Dokumentation (Leistungen).