Die Methode, die das alte System nie anrührt

Der Artikel nennt ohne Beschönigung, worauf die Unternehmenswelt tatsächlich läuft: SAP ERP, Oracle-Datenbanken, gealtertes Microsoft Dynamics, Eigenentwicklungen auf Java EE, COBOL-Großrechner. All das wurde vor fünfzehn bis zwanzig Jahren entworfen, hält Petabytes, verarbeitet Milliarden von Transaktionen und bietet weder REST noch GraphQL.

Dann kommen die beiden Zahlen, zwischen denen man wählt. Eine vollständige Migration eines Monolithen auf Microservices dauert drei bis fünf Jahre und kostet Dutzende Millionen Dollar bei hohem Risiko des Scheiterns; ein altes ERP gegen etwas wie SAP S/4HANA zu tauschen, kostet ein Unternehmen zwei bis zehn Millionen und legt ganze Abteilungen für Jahre still. Die angebotene Alternative soll drastisch billiger sein und in Monaten statt Jahren gemessen werden.

Als Erstes übersetzt es. Alte Systeme sprechen SOAP, XML-RPC oder flache Dateien über FTP; der Agent denkt in JSON und ruft Funktionen auf. Das Gateway nimmt das JSON, entfaltet es zu einer sperrigen SOAP-Anfrage, zerlegt das zurückkommende XML und reicht dem Agenten eine saubere Struktur. Der Agent erfährt nie, dass am anderen Ende der Leitung das Jahr 2005 saß.

Als Zweites bremst es das Tempo. Tausend gleichzeitige Fragen zum Bestellstatus würden zu tausend synchronen Aufrufen, und die Datenbank würde umfallen. Deshalb sitzt zwischen Agent und Monolith ein Broker — RabbitMQ, Apache Kafka, Redis Streams —, und das Gateway lässt die Warteschlange in dem Tempo durch, das das System verträgt, im durchgerechneten Beispiel zehn Anfragen pro Sekunde. Währenddessen sieht der Nutzer eine Zeile über die laufende Analyse.

Als Drittes fragt es gar nicht erst. Stammdaten, Kataloge, Preise, Filiallisten werden in Redis aggressiv zwischengespeichert und asynchron aufgefrischt. Die Entlastung der Hauptdatenbank wird mit bis zu 90 Prozent angegeben, und daneben steht ein Hinweis, den man behalten sollte: Das ist die Schätzung der Autoren für typische Szenarien, keine Messung.

Der Agent bekommt nie direktes SQL. Er erhält einen eng begrenzten Satz von Funktionen — den Status eines Kunden abfragen, ein Support-Ticket eröffnen —, und das Gateway prüft die Parameter streng. Eine in eine Kennung eingeschmuggelte Injektion, die ein Prompt-Injection-Angriff theoretisch erreichen könnte, wird abgewiesen, bevor die Anfrage das interne Netz berührt.

Das Dienstkonto folgt dem Prinzip der geringsten Rechte: auf den meisten Tabellen nur lesend. Schreibrechte werden chirurgisch vergeben und nur dort, wo wenig auf dem Spiel steht — Protokolle und Tickets —, und nur über gespeicherte Prozeduren. Jedes Byte des Austauschs landet in unveränderlichem Speicher, einer Blockchain oder WORM-Laufwerken, damit sich die Gedankenkette des Agenten Sekunde für Sekunde nachvollziehen lässt.

Selbst erzeugtes SQL läuft woanders

Ein eigenes Elend ist ein Schema, in dem eine Tabelle T_DOC_435 heißt und hundertfünfzig undokumentierte Spalten trägt. Dafür wird eine semantische Metadatenschicht gebaut: eine Beschreibung der Struktur in klarer Sprache, der ein Modell folgen kann. Ein Text-to-SQL-Agent verfasst seine Abfrage anhand dieser Beschreibung, das Gateway prüft sie auf löschende und ändernde Befehle, und die Abfrage läuft gegen eine Replik statt gegen das Original.

Das Logistikbeispiel ist im Detail durchgerechnet. Ein Unternehmen mit einer Flotte von fünfhundert Lastwagen lebt auf einem stark angepassten alten ERP und Dutzenden riesiger Tabellen. Eine frei formulierte Anfrage — zwanzig Paletten Ziegel, von einer Stadt in eine andere, morgen früh, ein Lastwagen mit Hebebühne — wird in Entitäten zerlegt; über das Gateway fragt der Agent verfügbare Fahrzeuge im Umkreis von fünfzig Kilometern ab, bekommt drei, wägt Bewertungen und Freigaben der Fahrer ab, schreibt dem Fahrer und gibt nach dessen Zustimmung den Befehl für einen Frachtbrief.

Der angebotene Vergleich lautet drei Disponenten und vierzig Minuten gegen fünfzehn Sekunden, rund um die Uhr, bei zehnfach beschleunigtem Geschäft und unverändertem Kern-ERP. Bemerkenswert ist, was der Artikel nicht ausdrücklich sagt: In dieser ganzen Kette wird genau eine Sache in das alte System geschrieben, der Frachtbrief. Das Lesen, das Gespräch und die Entscheidung sind alle nach außen verlagert.

Das Bankbeispiel hat dieselbe Gestalt, formalisiert als CQRS-Muster. Kontostände und Verlauf werden asynchron in schnellen Arbeitsspeicher wie Redis oder Apache Ignite repliziert, und eine Frage nach den Kaffeeausgaben des Monats wird in hundert Millisekunden aus dem Zwischenspeicher beantwortet. Eine Überweisung von 150 $ an den Ehepartner geht einen ganz anderen Weg: Prüfung der Absicht, ein Zwei-Faktor-Code, eine Kafka-Warteschlange und ein Adapter, der den Vorgang in den Kern einfügt, als wäre es eine klassische Überweisung.

Schriftverkehr und Reparaturhistorien werden nachts aus den alten Datenbanken gezogen, bereinigt, in Stücke geschnitten, durch Embedding-Modelle geschickt und in Vektorspeicher geladen; genannt werden Pinecone, Qdrant und Milvus. Die Last am Tag wird nie berührt.

Überzeugend ist nicht die Technik, sondern die Beispielantwort. Auf die Frage, warum Maschine B-450 beim Start überhitzt, obwohl der Druck normal anzeigt, liefert eine Stichwortsuche nach Überhitzung nichts: Das Ticket von 2018 sagt, der Motor laufe beim Hochfahren heiß. Die Bedeutungssuche findet es trotzdem, und die Antwort enthält den Namen des Technikers, die Lösung und die Teilenummer des Druckventilfilters, 33-B.

Alte Dinge fallen um, und das ist ins Verhalten eingeschrieben. Bei einer Zeitüberschreitung wartet der Agent zwei Sekunden, dann vier, dann acht. Bleibt das System ausgefallen, zeigt er keinen Fehler, sondern antwortet aus dem letzten bekannten Zwischenspeicher: Vor fünfzehn Minuten waren zwölf Stück auf Lager, eine Vorbestellung ist aufgegeben, die Reservierung wird bestätigt, sobald alles wieder läuft. Parallel stellt ein Hintergrundagent einen Fehlerbericht mit Protokollen zusammen und schickt ihn den Ingenieuren über Slack.

Die Einführung ist in vier Phasen angelegt. Zwei bis drei Wochen Schattenbetrieb, in dem Agenten nur lesen und Antworten für menschliche Mitarbeiter entwerfen. Drei bis vier Wochen als interner Kopilot, der Moment, in dem Schreibzugriff auf unkritische Systeme hinzukommt. Vier bis sechs Wochen, bevor es an die Kunden geht, und nur nach einem Sicherheitsaudit. Dann fortlaufend: eine Flotte enger Agenten, ein nächtlicher Transaktionsprüfer, ein Einkaufsagent, ein Marketer.

Die Gewinne werden ehrlicher berichtet, als solche Texte es meist schaffen, und diese Ehrlichkeit sollte ganz übernommen werden. Eine Entlastung des Personals um 30–40 Prozent ist die Schätzung der Autoren für typische Szenarien. Das Wachstum der Konversion in Phase drei wird erheblich genannt, ohne eine einzige Zahl. Das Transportunternehmen und die Bank werden als Szenarien beschrieben, nicht als benannte Kunden; der Artikel nennt überhaupt keinen Kunden.

Klar benannte Grenzen

Wo Richtlinien die Cloud verbieten — Rüstungsaufträge, Gesundheitswesen, Kartenzahlungen —, lautet der Vorschlag, offene Modelle im eigenen Haus zu betreiben: Llama 3, Mistral, Qwen, komprimiert auf GGUF, AWQ oder EXL2, bis hin zu einem vollständig abgeschotteten Bereich ganz ohne Internet. Die Ausgaben für Modelle werden durch strenge Token-Grenzen eingezäunt, und bei einem Angriff verwirft das Gateway Spam-Verkehr selbst, damit niemand das Budget verbrennen kann.

Aus dem Koan folgt der praktische Schluss, für den das Ganze gebaut wurde. Der Wert eines Monolithen liegt nicht in seinem Code, sondern in dem, was sich in ihm angesammelt hat, und genau das gefährdet jede Migration. Die Methode schlägt vor, das Angesammelte nicht zu bewegen, sondern es liegen zu lassen, wo es liegt, und zu lernen, ihm Fragen zu stellen. Den Preis nennen die Autoren selbst: eine Schicht von Vermittlern, die für immer gepflegt werden muss.