Agentic Development und digitale Souveränität zusammen denken

Digitale Souveränität als Architekturziel#

Digitale Souveränität bedeutet, selbst entscheiden zu können, wo und wie ein Unternehmen Daten verarbeitet, Software entwickelt und Anwendungen betreibt. Diese Handlungsfähigkeit wird relevant, sobald ein Cloud-Anbieter Preise, Vertragsbedingungen oder sein Angebot ändert. Dann muss das Unternehmen Dienste ersetzen oder den Betrieb verlagern können, statt zum Bleiben gezwungen zu sein.

Der Standort der Server ist dabei nur ein Teil der Entscheidung. Das Cloud Sovereignty Framework der Europäischen Kommission berücksichtigt auch strategische, rechtliche, operative und technische Aspekte. Unternehmen müssen deshalb ebenso bewerten, welchem Rechtsraum Anbieter und Verträge unterliegen, welche Abhängigkeiten externe Cloud-Dienste erzeugen und ob sich eine kritische Anwendung in einer anderen Infrastruktur weiterbetreiben ließe. Wie weit diese Möglichkeit vorbereitet werden muss, hängt von der Bedeutung der Anwendung und der tolerierbaren Ausfallzeit ab.

Managed Services können trotzdem die richtige Wahl sein, denn sie sparen Zeit und Betriebsaufwand. Zugleich binden sie Anwendungen an APIs, Datenmodelle, Lizenzen und Preise eines Anbieters. Entscheidend ist, ob ihr fachlicher oder wirtschaftlicher Nutzen die möglichen Wechselkosten rechtfertigt. Der Data Act erleichtert zwar Vertragswechsel und Datenexporte, übernimmt aber keine Migration. Dafür braucht das Unternehmen eigene Build-, Test- und Deployment-Prozesse. Genau hier trifft digitale Souveränität auf Agentic Development.[1][2][3][4][5]

Eine containerisierte Foundation für beide Ziele#

Coding Agents brauchen für einen Task eine containerisierte Umgebung mit den erforderlichen Werkzeugen. Automatisierte Builds und Tests zeigen unmittelbar, ob eine Änderung funktioniert.

Nutzen Entwicklungsteams, Agents und Continuous Integration dieselben Umgebungen und Tests, entsteht kein Sonderweg für AI-generierten Code. Der darauf aufbauende Delivery-Prozess lässt sich bei einem Hyperscaler, einem europäischen Cloud-Anbieter oder in eigener Infrastruktur ausführen. Nicht jeder Cloud-Dienst wird dadurch austauschbar. Entwicklung und Delivery bleiben jedoch nicht an einen einzelnen Anbieter gebunden.[8][9][10][11]

Das Zielbild einer Agentic Application Foundry#

Aus dieser gemeinsamen technischen Basis ergibt sich das Zielbild einer Agentic Application Foundry. Gemeint ist kein einzelnes Produkt, sondern ein vom Unternehmen definierter Product Lifecycle, in dem Menschen und Agents Software planen, entwickeln und in Produktion bringen.

Die Foundry führt Product Discovery und Planung mit technischer Umsetzung und Betrieb zusammen. Alle Beteiligten greifen dabei auf dieselben Codebestände, Arbeitsumgebungen und automatisierten Tests zurück. So wird aus einer bestätigten Produktidee in wiederholbaren Schritten eine Anwendung, die sich in unterschiedlichen Cloud-Infrastrukturen bereitstellen lässt, ohne für jedes Ziel einen neuen Delivery-Prozess aufzubauen.

Wie ein erster Ausschnitt davon aussehen kann, zeigt die Application Foundry in der Toolbox. Das Open-Source-Projekt führt eine fachlich bestätigte Anforderung bis zu einer lauffähigen Anwendung in einer Entwicklungsumgebung.[12][13]

Kürzere Time-to-Market und weniger Aufwand beim Cloud-Wechsel#

Ein solcher Product Lifecycle verkürzt den Weg von der Idee bis zum Release. Agentic Development erweitert dabei die bestehende Softwareentwicklung, statt parallel eine zweite Toolchain mit eigenen Regeln aufzubauen.

Dieselbe Architektur senkt später den Aufwand für einen Cloud-Wechsel. Sind Build, Tests und Deployment bereits portabel, muss das Unternehmen seinen Delivery-Prozess nicht erst neu aufbauen, bevor es einen anderen Anbieter prüfen kann. Die Migration konzentriert sich dadurch auf die tatsächlich anbieterspezifischen Teile.

Der strategische Hebel liegt deshalb in einem Stack, der den gesamten Product Lifecycle mit bewährten Open-Source-Werkzeugen und offenen Standards verbindet. Menschen und Agents können im selben Prozess arbeiten, ohne ihn an die Infrastruktur eines einzelnen Cloud-Anbieters zu binden. Datenbanken und proprietäre Managed Services bleiben Migrationsarbeit. Je kritischer die Anwendung ist, desto bewusster sollte das Unternehmen ihre Zahl und Bedeutung begrenzen.[11][8][14][6][7]