Mission 006 · Portability, Sovereignty & Economics

In 30 Sekunden

Modell-, Cloud- und Plattformabhängigkeiten müssen steuerbar bleiben — ohne die Architektur durch übermäßige Abstraktion zu verkomplizieren. Portabilität entsteht durch klare Verträge, eigene Evaluationsdaten und bewusst gewählte Abhängigkeiten.

Warum das wichtig ist

Modelle, Clouds und Frameworks ändern sich schnell. Wer ohne Wechselmöglichkeit baut, zahlt später mit Lock-in, steigenden Kosten oder fehlender Souveränität.

Gleichzeitig ist totale Anbieterunabhängigkeit teuer. Ziel ist nicht maximale Abstraktion, sondern eine bewusste, dokumentierte Entscheidung pro Abhängigkeit.

Redaktionelle EinordnungPortabilität heißt nicht „alles austauschbar machen“, sondern wissen, was austauschbar sein muss. Ein Model Gateway und eigene Evaluationsdaten bringen mehr als eine generische Abstraktionsschicht über allem.

Die zentralen Architekturfragen

Welche Abhängigkeiten sind bewusst gewählt — und welche schleichend entstanden?
Können wir den Modellanbieter wechseln, ohne die Anwendung neu zu bauen?
Ist der Agent-State portabel oder an einen Anbieter gebunden?
Kennen wir die Kosten pro Geschäftsergebnis, nicht nur pro Token?
Evaluieren wir Qualität vor und nach einem Anbieterwechsel?

Typische Muster

Model Gateway: ein kontrollierter Punkt für Modellauswahl und -wechsel.
Portabler Agent State: Zustand nicht an proprietäre Dienste gebunden.
Cloud Exit & Data Residency: bewusste Entscheidungen über Ort und Ausstieg.
FinOps for AI: Kosten- und Wertsteuerung von KI-Workloads.
Kosten pro Ergebnis: Wirtschaftlichkeit am Geschäftsergebnis gemessen.

Häufige Fehlannahmen & Anti-Patterns

Direkte Bindung an proprietäres Anbieter-Memory ohne Ausweg.
Abstraktion über alles — Komplexität ohne realen Nutzen.
Kosten nur pro Token, nie pro Geschäftsergebnis betrachtet.
Anbieterwechsel ohne Vorher-Nachher-Evaluation.

Praktische Prüffragen

Könnten wir den Hauptmodellanbieter in vertretbarer Zeit wechseln?
Ist der Agent-State exportierbar?
Kennen wir die Kosten pro Geschäftsergebnis?
Haben wir eigene Evaluationsdaten für einen Wechselvergleich?

Bezug zum durchgehenden Praxisbeispiel

Welche Anbieterabhängigkeiten bestehen, was kostet ein Vorgang — und welche Daten verlassen das Haus?

Der Modellanbieter ist über ein Model Gateway austauschbar, ohne die Anwendung neu zu bauen.
Die Kosten werden pro bearbeitetem Fall (Geschäftsergebnis) gemessen, nicht nur pro Token.
Es ist bewusst entschieden, welche Daten externe Dienste erreichen dürfen und welche im Haus bleiben.
Eigene Evaluationsdaten erlauben einen Vorher-Nachher-Vergleich bei einem Anbieterwechsel.

Zum vollständigen Praxisbeispiel: Service-Agent

Bezug zur Referenzarchitektur

Diese Mission betrifft die unteren Ebenen (Core Systems, Cloud) und das Control Plane (Model Routing, Cost & Usage). Sie hält die in 003 gebauten Integrationen wirtschaftlich und souverän.

Mission 003 APIs werden zu Werkzeugen Mission 007 AI verändert Software Engineering