Die Zukunft von Enterprise Software

Wie KI Systems Engineering unterstützen und Kryptografie ausgewählte Aussagen verifizieren kann

Veröffentlicht von Polity | Juli 2026
Autoren: Alexandre Kotcherguine, Vision Officer & Investor, Polity;
Kevin Riedl, Managing Partner, Wavect GmbH

Dieser Artikel wurde am 2. September 2026 vollständig anhand öffentlicher Forschung, offizieller Dokumentation, Branchenumfragen und Praxisberichte geprüft. Mehrere Technologien befinden sich noch in einem frühen Stadium. Leistungs- und Nutzungsangaben von Anbietern sind als solche gekennzeichnet; Zahlen sind Momentaufnahmen, keine Garantien. Nichts darin stellt professionelle, rechtliche oder Anlageberatung dar.

Executive Summary

Enterprise Software kann durch Zerlegung an Kohärenz verlieren und zum Distributed Monolith werden. KI-gestützte Analyse kann einen Teil der Arbeit zur Pflege des Gesamtsystemblicks reduzieren. Aktuelle MBSE-Forschung verlangt jedoch menschliche Aufsicht und belegt keine autonome Systemmodellierung im Enterprise-Maßstab. Kryptografische Beweise und manipulationssichtbare Ledger können ausgewählte Berechnungen und Datensätze prüfbar machen. Sie beweisen weder eine gesamte Architektur noch wahre Inputs, Modelleignung oder Compliance. Solche Mechanismen können Audits und Verträge an ausgewählten Grenzen ergänzen; Wirtschaftlichkeit und Einführungsreihenfolge bleiben workload-spezifisch.

Das Zeitalter der Fragmentierung

Die dominante Bewegung in der Enterprise-Architektur der 2010er-Jahre hatte eine klare und weitgehend vernünftige Motivation. Monolithen waren zu „Big Balls of Mud“ geworden (eng gekoppelt, schwer zu ändern, langsam auszuliefern), und Microservices versprachen einen Ausweg: die Anwendung entlang von Business Capabilities zerlegen, jedem Service ein unabhängiges Deployment geben und Teams parallel arbeiten lassen. Für viele Organisationen funktionierte das zunächst. Doch das Muster wurde weithin als Default statt als abgewogener Trade-off übernommen, und das branchenweit wiederholte Ergebnis war ein charakteristischer Fehlermodus, dem Praktiker einen präzisen Namen gaben. Der „Distributed Monolith“ besitzt, so eine häufig zitierte Beschreibung, die operative Komplexität von Microservices ohne die architektonische Unabhängigkeit: Services, die physisch getrennt, aber logisch gekoppelt sind, voneinander abhängige Datenbankschemas, synchronisierte Deployments und lange Aufrufketten, sodass eine Änderung in einem Service drei andere beschädigt und jedes Release zu einer Koordinationsübung wird (1). Die Organisation gewann mehr Repositories, mehr Pipelines, mehr Logs, mehr Fehlermodi und mehr Governance-Aufwand, ohne die Fähigkeit zu gewinnen, sich schneller zu bewegen.

Die offizielle CNCF-Umfrage belegt keine branchenweite Rückkehr von Microservices zu Monolithen. Für 2024 meldete sie 89 Prozent Cloud-Native-Adoption; Service-Mesh-Adoption sank angesichts operativer Komplexität von 50 Prozent 2023 auf 42 Prozent 2024 (2). Das ist selektive Vereinfachung bei fortgesetzter Cloud-Native-Nutzung, nicht die zuvor genannte Behauptung einer Konsolidierung bei 42 Prozent oder eines Falls von 18 auf 8 Prozent. Prime Video meldete für einen einzelnen Monitoring-Workload 90 Prozent niedrigere Infrastrukturkosten nach der Konsolidierung in einen Monolithen. Werner Vogels betonte, es gebe keine Universalarchitektur und evolvierbare Systeme seien eine Strategie, keine Religion (3).

Was verloren ging: Systems Engineering

Systems Engineering ist die ältere Disziplin, die durch Fragmentierung verdrängt wurde. Sie behandelt das System als Ganzes, nicht als Sammlung unabhängig optimierter Teile, als primäres Designobjekt. Ihre Instrumente sind Anforderungen, die die Absicht vor dem Bau erfassen, Interface-Verträge, die das Zusammenspiel der Teile regeln, Architekturmodelle, die das Ganze lesbar machen, und Verifikation, die das gebaute System gegen das Spezifizierte prüft. Das sind wenig glamouröse Praktiken, und die Move-fast-Kultur der Fragmentierungsära behandelte sie als bürokratischen Ballast, der im Namen der Geschwindigkeit abgeworfen werden müsse. Die Ironie, bekannt aus der früheren Geschichte von Enterprise Agile, besteht darin, dass das Abwerfen der Disziplin keine dauerhafte Geschwindigkeit erzeugte; es erzeugte Systeme, die gerade deshalb langsamer und brüchiger wurden, weil niemand mehr das Ganze pflegte.

Ein präzises Modell eines großen Systems mit Komponenten, Abhängigkeiten, Verträgen und Constraints zu pflegen, kann arbeitsintensiv und driftanfällig sein. Das belegt nicht, dass Systems Engineering allgemein aufgegeben oder unbezahlbar wurde. Eine MBSE-Roadmap von 2026 nennt praktische Einführungsbarrieren, Infrastrukturkosten und begrenzte Evidenz für vollautomatische, skalierbare Lösungen in großen Modellierungsumgebungen (4).

Warum KI die Disziplin zurückbringt

Der vorherige Teil dieser Serie argumentierte, dass KI Engineering-Arbeit teilweise von der Implementierung zur Spezifikation verschiebt. Modelle können Code-Mapping, Zusammenfassung, Rückverfolgbarkeit und Konsistenzprüfungen unterstützen, gewinnen aber unausgesprochene Geschäftsabsicht nicht zuverlässig zurück. Das MBSE-Co-Pilot-Paper von 2026 ist eine Forschungsroadmap: Aktuelle Werkzeuge benötigen oft erhebliche menschliche Intervention, und selbst die höchste vorgeschlagene Assistenzstufe belässt die Designautorität beim Menschen (4).

Eine lebende, versionierte und mit dem laufenden System abgeglichene Spezifikation ist daher ein Designziel, kein automatisches Ergebnis von KI-Einsatz. Agenten können Interfaces vorschlagen, vermuteten Drift markieren und Modellentwürfe aktualisieren, während verantwortliche Engineers Anforderungen, Kontext und Sicherheitsfolgen prüfen. Ob dies Gesamtkosten senkt, hängt von Modellqualität, Tooling, Review-Aufwand und Organisationspraxis ab.

Die Grenze von KI allein: Vertraut ist nicht bewiesen

Doch das durch KI wiederhergestellte Systems Engineering führt für sich genommen das Problem, das es löst, in subtilerer Form wieder ein. Eine von einem Agenten abgeglichene Spezifikation bleibt ein Dokument; ein von einer Pipeline durchgesetzter Interface-Vertrag wird weiterhin von demjenigen durchgesetzt, der die Pipeline kontrolliert; ein vom System geschriebenes Audit-Log ist nur so vertrauenswürdig wie die Partei, die es umschreiben kann. Der gesamte Apparat beruht auf delegiertem Vertrauen: der Nutzer verlässt sich darauf, dass die deployende Organisation korrekt spezifiziert, ehrlich verifiziert und den Datensatz nicht manipuliert hat. Innerhalb eines einzelnen Unternehmens mag das akzeptabel sein. Über jene Grenzen hinweg, die moderne Systeme definieren (zwischen Firmen, zwischen einer Institution und ihrer Aufsicht, zwischen einem Netzwerk und seinen Teilnehmern), ist es genau die Annahme, die nicht trägt. Und im agentischen Zeitalter steigt der Einsatz: Wenn Code und sogar Architekturänderungen schneller erzeugt werden, als irgendein Mensch sie unabhängig prüfen kann, wird „Vertraut uns, das System tut, was die Spezifikation sagt“ zu einer Behauptung, die keine Gegenpartei im Glauben akzeptieren sollte.

Institutionelle Assurance und kryptografische Verifikation treffen unterschiedliche Aussagen. Verträge, Audits und Governance schaffen Verantwortlichkeit rund um eine Organisation und ihre Controls. Ein kryptografischer Beweis kann einen Verifier eine codierte Aussage prüfen lassen, ohne allein der Behauptung des Betreibers zu vertrauen. Seine Aussagekraft ist auf diese Aussage und ihre Annahmen begrenzt. Systems Engineering kann Architektur explizit machen; weder Spezifikation noch Rechenbeweis machen die Architektur als Ganzes „wahr“.

Wie Dezentralisierung sie härtet

Kryptografische Verifikation kann eine präzise codierte Berechnung prüfbar machen. Bindet eine Aussage das beabsichtigte Programm oder Modell und festgeschriebene Inputs, kann eine Quittung zeigen, dass die codierte Berechnung den behaupteten Output erzeugte (5). Zero Knowledge kann einen privaten Witness verbergen, wenn System und Aussage dafür entworfen wurden. Das belegt weder wahre Inputs, Modelleignung oder Fairness noch Rechtskonformität. NIST beschreibt Blockchains als manipulationssichtbar und manipulationsresistent unter ihren Validierungs-, Konsens- und Governance-Annahmen, nicht als bedingungslos unveränderlich oder vertrauensfrei (8).

Developer-Tooling ist real, Reife und Umfang sind jedoch gemischt. RISC Zero dokumentiert Quittungen für die Ausführung eines festgelegten Programms (5). Axiom bietet derzeit eine nur auf Einladung zugängliche Hosted Proving API für OpenVM (6). Lagrange hat DeepProve als Open Source veröffentlicht und berichtet End-to-End-Beweise für LLM-Inferenz; Leistungs- und Produktionsvolumenangaben sind jedoch Anbieterangaben und benchmark-spezifisch (7). Diese Systeme beweisen keine gesamte Enterprise-Architektur. Bei einer Kreditentscheidung blieben Identität, Datenqualität, Model Governance und Rechtskonformität außerhalb des Rechenbeweises.

Verteilung kann einige Single Points of Failure oder Control reduzieren, beseitigt sie aber nicht automatisch. Das Ergebnis hängt von Node-Unabhängigkeit, Konsens, Governance, Key Management, Upgrade-Autorität und externen Datenquellen ab. Dezentrale Governance kann Regeln sichtbarer machen und wirksame Kontrolle dennoch bei Token-Inhabern, Betreibern, Multisig-Unterzeichnern oder Administratoren konzentrieren. Eine Architektur muss genau benennen, welche Garantie dezentralisiert ist und was vertrauensbasiert bleibt.

Die Einwände: Reife und ob es überhaupt gebraucht wird

Proof-Erzeugung verursacht zusätzliche Rechen- und Betriebskosten, doch der Overhead variiert nach Workload, Proof-System, Hardware und Sicherheitsziel. Die frühere pauschale Aussage, Large-Model-Proving sei tausendfach langsamer und nur teilweise machbar, ist keine belastbare aktuelle Zusammenfassung. Lagrange berichtet inzwischen eine quelloffene End-to-End-Konstruktion für LLM-Inferenz (7). Das belegt weder Produktionswirtschaftlichkeit für beliebige Modelle noch Training und macht Anbieterbenchmarks nicht direkt vergleichbar.

High-Stakes-Anwendungen mit niedrigerem Volumen sind plausibel, wenn unabhängige Verifikation mehr wert ist als ihre Kosten. Sie sind keine gemessene oder unvermeidliche Einführungsreihenfolge. Regulierte Entscheidungen, Finanzabwicklung und Content Provenance haben unterschiedliche Latenz-, Datenschutz-, Rechts- und Threat-Model-Anforderungen. Teams sollten die konkrete Aussage, den Verifier, Ressourcen und Fehlerfälle außerhalb des Proofs bewerten.

SOC-2-Berichte, Trusted Execution Environments und kryptografische Beweise beantworten unterschiedliche Fragen. Ein Beweis kann codierte Berechnung belegen, aber nicht Governance Controls, rechtmäßige Input-Erhebung, Modelleignung oder gesamte Compliance. Ein Audit wiederum spielt nicht jede Berechnung nach. Institutionelle Assurance bleibt notwendig; kryptografische Evidenz kann sie an einer Grenze nur mit konkretem Threat Model und begründetem Verifier ergänzen.

Fazit: Entwickelt, um bewiesen zu werden

KI-Unterstützung kann Aufwand für System-Mapping, Spezifikationspflege und Inkonsistenzerkennung reduzieren, während verantwortliche Engineers die Designautorität behalten. Kryptografische Systeme können ausgewählten Berechnungen und Datensätzen prüfbare Evidenz beifügen. Sie machen keine gesamte Architektur beweisbar und ersetzen keine Prüfung von Inputs, Governance, Abhängigkeiten und Compliance.

Beide Ansätze beschreiben eine Designrichtung, keine feststehende Zukunft. Systems Engineering liefert Kontext dafür, welche Invariante einen Beweis wert ist; Verifikation liefert Evidenz nur für die codierte Aussage. In regulierten On-Chain-Finanzsystemen existieren Developer-Tools und Piloten, während rechtliche Eignung, Betriebskontrollen und Produktionswirtschaftlichkeit implementationsspezifisch bleiben.

Die dauerhafte Designfrage ist nicht nur, wie schnell sich ein System ändern kann, sondern welche folgenreiche Aussage eine andere Partei verifizieren können muss. Starke Organisationen formulieren sie präzise, benennen verbleibende Vertrauensannahmen und wählen Evidenz proportional zum Risiko.

Über Polity

Dieser Artikel ist Teil eines fortlaufenden Programms für Governance- und Thought-Leadership-Publikationen im Polity-Governance-Modell. Politys zentrale These lautet, dass dauerhafte Ergebnisse von Regeln, Anreizen und Institutionen geprägt werden. KI-gestütztes Systems Engineering zusammen mit Evidenz für ausgewählte Berechnungen ist in diesem Sinn ein Governance-Problem: Jeder Beweis hat Umfang, Verifier und verbleibende Vertrauensannahmen. Polity baut Infrastruktur für regulierte digitale Finanzsysteme mit Frameworks, die dezentrale Systeme und institutionelle Compliance-Anforderungen verbinden sollen.

Über Wavect

Die Wavect GmbH ist eine österreichische Software-Engineering-Agentur, die produktorientierte Software für Start-ups, Scale-ups und Enterprises entwickelt. Das Spektrum reicht von Full-Stack-Entwicklung über Fractional Engineering und Product Leadership bis zu Software Quality Assurance und angewandter Arbeit in künstlicher Intelligenz, Blockchain und Zero-Knowledge-Systemen. Wavect hat für das Polity-Programm Softwareentwicklungs- und Qualitätssicherungsleistungen erbracht. Co-Autor Kevin Riedl ist Managing Partner des Unternehmens. Weitere Informationen unter https://wavect.io.

Disclaimer: Dieser Artikel dient ausschließlich Informations- und Bildungszwecken. Er stellt weder professionelle, rechtliche, finanzielle noch Engineering-Beratung dar und ist keine Empfehlung für eine Methode, ein Produkt, ein Protokoll, einen Service oder eine Organisation. Verweise auf genannte Forscher, Studien, Tools, Standards und Unternehmen dienen ausschließlich Analyse und Kommentar. Mehrere der diskutierten Technologien, insbesondere verifizierbare Berechnung und Zero-Knowledge-Beweise der Modellausführung, befinden sich noch in einem frühen Reifestadium, und ihre Fähigkeiten und Kosten entwickeln sich weiter; relevante Einschränkungen werden im Text eingeordnet. Alle Drittquellen sind als Referenz zitiert; ihre Aufnahme bedeutet weder Empfehlung durch noch Zugehörigkeit zu Polity. Co-Autor Kevin Riedl ist Managing Partner der Wavect GmbH, die Softwareentwicklungs- und Qualitätssicherungsleistungen für das Polity-Programm erbringt, siehe „Über Wavect“. Diese Geschäftsbeziehung wird im Interesse der Transparenz offengelegt und beeinträchtigt die Unabhängigkeit der Analyse nicht. Die geäußerten Ansichten sind jene der Autoren.

Literatur und Prüfhinweise

Vollständig geprüft am 2. September 2026. Leistungs- und Nutzungsangaben von Anbietern werden als solche behandelt.

1. vFunction (2026), Distributed Monolith Architecture: What It Is, Why It Happens, and How to Fix It. Practitioner definition of the distributed-monolith failure mode. vfunction.com (Accessed: 2 September 2026).
2. Cloud Native Computing Foundation (2025), CNCF Research Reveals How Cloud Native Technology is Reshaping Global Business and Innovation. Official 2024 survey summary: 89% cloud-native adoption and service-mesh adoption moving from 50% in 2023 to 42% in 2024. cncf.io (Accessed: 2 September 2026).
3. Vogels, W. (2023), Monoliths are not dinosaurs. Official discussion of the Prime Video monitoring-workload case, including the reported 90% infrastructure-cost reduction and the linked archived team post. allthingsdistributed.com (Accessed: 2 September 2026).
4. Zhang, W., Cockburn, C., Henshaw, M. et al. (2026), ‘MBSE Co-Pilot: A Research Roadmap’, Systems Engineering, 29(1), 20–33. Current limitations, human oversight and the proposed assistance levels. doi.org/10.1002/sys.70011 (Accessed: 2 September 2026).
5. RISC Zero, Developer Documentation. Receipts certify that a specific program produced a specific output without revealing private inputs when the proof is configured accordingly. dev.risczero.com (Accessed: 2 September 2026).
6. Axiom, OpenVM Proving API Documentation. The current hosted proving API is invite-only. docs.axiom.xyz (Accessed: 2 September 2026).
7. Lagrange (2026), Inside DeepProve: Proving an LLM End-to-End. Official engineering update and vendor-reported end-to-end LLM-inference proof results. lagrange.dev (Accessed: 2 September 2026).
8. NIST (2018, current resource), Blockchain Technology Overview, NISTIR 8202. Blockchain as a shared, tamper-evident and tamper-resistant ledger whose guarantees depend on validation and consensus. csrc.nist.gov (Accessed: 2 September 2026).