INFO: Dieser Artikel ist vollständig durch eine KI generiert worden. Er kann Fehler enthalten.
Die sieben ausgewählten Veröffentlichungen behandeln Enterprise Architecture, IT-Souveränität, Cloud-Strategie, Low-Code, Integrationsarchitektur und Business Capabilities. Ein Schwerpunkt ist die Gewinnung von Architekturwissen aus operativen Systemen: Technische Schnittstellen, beobachtete Geschäftsabläufe und AI-gestützte Modellierung können die klassische Architekturarbeit ergänzen.
Ein zweiter Schwerpunkt betrifft die Grenzen technologischer Unabhängigkeit. Open Source und mehrere Cloud-Anbieter schaffen zusätzliche Optionen, gewährleisten für sich genommen jedoch weder Souveränität noch Resilienz. Die Quellen dieser Ausgabe stammen vom 30. September bis zum 8. Oktober 2026 beziehungsweise aus dem Programm der MODELS-Konferenz im Oktober.
Business Capabilities aus technischen Artefakten ableiten
Quelle: API Evangelist – Business Capabilities Provide the Context You Need for AI Engineering
Autor: Kin Lane · Veröffentlicht: 8. Oktober 2026
Kin Lane beschreibt einen Ansatz, um aus APIs, OpenAPI-Spezifikationen, Arazzo-Workflows und weiteren technischen Artefakten Hinweise auf Business Capabilities abzuleiten. Ausgangspunkt ist die Beobachtung, dass technische Infrastruktur bereits Informationen über implementierte geschäftliche Fähigkeiten enthält. Diese Informationen liegen allerdings häufig in einer Form vor, die für fachliche Verantwortliche schwer zugänglich ist.
Am Beispiel der Zahlungsabwicklung untersucht Lane, wie sich technische Operationen in geschäftliche Fähigkeiten und verständliche Beschreibungen übersetzen lassen. Der Ansatz befindet sich in der Entwicklung und ist keine empirisch validierte EAM-Methode.
Einordnung: Die Analyse technischer Artefakte kann Workshops, Interviews und konzeptionelle Capability-Modellierung ergänzen. Sie bietet insbesondere Anhaltspunkte für den Abgleich zwischen beabsichtigten und implementierten Fähigkeiten. Dabei ist die Abstraktionsebene zu beachten: Eine API zum Erzeugen einer Rechnung bildet nur einen Teil der vollständigen Fähigkeit zur Rechnungsstellung ab. Technische Operationen müssen deshalb fachlich eingeordnet und mit Prozessen, Verantwortlichkeiten und strategischen Zielen verknüpft werden.
Technologien für kontinuierliche Architektursteuerung
Quelle: Gartner – Top Emerging Technologies to Transform Enterprise Architecture
Autoren: Ankita Khilare, Lucas Kobat · Veröffentlicht: 30. September 2026
Gartner untersucht fünf Technologieansätze: Digital Twins of Organizations, Agentic AI, Process Intelligence, Observability und Event-driven Architectures. Gemeinsam ist ihnen das Potenzial, Architekturinformationen kontinuierlicher aus dem Unternehmensbetrieb zu gewinnen und Entscheidungen näher am operativen Geschehen zu unterstützen. Diese Ausrichtung ist im öffentlich zugänglichen Abstract beschrieben; die Detailanalyse ist zugangsbeschränkt.
Einordnung: Observability liefert Laufzeitinformationen, Process Mining erschließt tatsächliche Prozessabläufe und ereignisbasierte Architekturen melden Zustandsänderungen. In Kombination können diese Verfahren die Aktualität von EAM-Repositorys verbessern. Für die Architektursteuerung lassen sich drei ergänzende Perspektiven unterscheiden:
| Perspektive | Funktion |
|---|---|
| Geplante Architektur | Beschreibt beabsichtigte Strukturen, Prinzipien und Zielzustände. |
| Beobachtete Architektur | Erfasst tatsächliche Abhängigkeiten, Prozesse und Datenflüsse. |
| Entscheidungsunterstützung | Bewertet Abweichungen und bereitet Architekturentscheidungen vor. |
Diese Unterscheidung verhindert, dass beobachtete technische Zustände ohne fachliche Bewertung als verbindliches Architekturmodell übernommen werden.
Modernisierung dauerhaft heterogener IT-Landschaften
Quellen: Kyndryl – State of Modernization Report · Zusammenfassung der Studienergebnisse
Herausgeber: Kyndryl · Veröffentlicht: 1. Oktober 2026
Kyndryl hat 2.000 Business- und Technologieentscheider aus zwölf Branchen befragt. Der Report nennt folgende Ergebnisse:
- 48 Prozent der Unternehmen liegen bei ihren Modernisierungszielen hinter dem Zeitplan.
- 9 Prozent haben ihre geschäftskritischen Anwendungen und deren Abhängigkeiten vollständig erfasst.
- 44 Prozent verfolgen bereits einen kontinuierlichen Modernisierungsansatz.
- 63 Prozent erwarten eine zunehmende Nutzung souveräner Cloud-Angebote.
- 6 Prozent berücksichtigen Souveränitätsprinzipien bereits zu Beginn ihrer umfassenderen Transformationsstrategie.
Geschäftskritische Anwendungen bleiben auf Public Cloud, Private Cloud, Mainframes und On-Premises-Systeme verteilt. AI kann diese Heterogenität zusätzlich erhöhen. Die Ergebnisse beruhen auf einer von einem Anbieter veröffentlichten Befragung und sind entsprechend einzuordnen.
Einordnung: Cloud-Strategien müssen die dauerhafte Weiterentwicklung heterogener Landschaften berücksichtigen. Integrationsfähigkeit, Architekturtransparenz und Portabilität gewinnen damit gegenüber einer ausschließlich migrationsorientierten Betrachtung an Gewicht. Application Portfolio Management und Dependency Mapping liefern Grundlagen, um je Anwendung zwischen Modernisierung, Migration, Weiterbetrieb und Ablösung abzuwägen. Relevante Kriterien sind Geschäftswert, Modernisierungsbedarf, Souveränitätsanforderungen, Integrationskomplexität und Ausstiegsfähigkeit.
Open Source und Einfluss auf Technologieentwicklung
Quelle: Forrester – My Take on Open Source and Sovereignty From Open Source Summit Europe 2026
Autor: Dario Maisto, Principal Analyst · Veröffentlicht: 8. Oktober 2026
Maisto unterscheidet zwischen der Nutzung von Open-Source-Software und der Fähigkeit, ihre Entwicklung mitzugestalten. Digitale Souveränität setzt demnach auch Einfluss auf Governance, Wartung und Weiterentwicklung kritischer Technologien voraus.
Die Analyse verweist auf einen erheblichen europäischen Anteil an Open-Source-Aktivitäten bei zugleich geringerer Präsenz in manchen Governance-Strukturen. Die genannte Größenordnung von etwa 40 Prozent der Projektaktivitäten stammt aus dem Konferenzkontext und ist keine unabhängig verifizierte Marktstatistik.
Einordnung: Open Source kann bestimmte technologische Abhängigkeiten reduzieren, garantiert aber weder wirtschaftliche Unabhängigkeit noch langfristige Handlungsfähigkeit. Auch offene Projekte können maßgeblich von einzelnen Unternehmen kontrolliert werden. Für strategische Komponenten sind deshalb mehrere Fähigkeiten getrennt zu bewerten:
| Dimension | Bewertungsgegenstand |
|---|---|
| Nutzung | Möglichkeit, die Technologie unabhängig einzusetzen. |
| Betrieb | Fähigkeit, sie eigenständig und dauerhaft zu betreiben. |
| Weiterentwicklung | Verfügbarkeit von Kompetenzen und Ressourcen für eigene Änderungen. |
| Governance | Einfluss auf die zukünftige Entwicklung und Entscheidungsstrukturen des Projekts. |
Qualitätssicherung bei Low-Code-Modellierung
Quelle: ZHAW – Understanding Modelling Assistance in Low-Code/No-Code Tools: An Empirical Study and the AssiStarMe Framework
Autoren: Jose David Mosquera Tobón, Marcela Ruiz, Michael Wahler, Oscar Pastor · Veröffentlicht: 3. Oktober 2026, ACM/IEEE MODELS 2026 · DOI: 10.1145/3822455.3830321
Das peer-reviewte Paper untersucht Unterstützungsbedarf bei der Modellierung mit Low-Code- und No-Code-Werkzeugen. Zwei Fokusgruppen mit insgesamt 35 Anwendern bilden die empirische Grundlage. Die Ergebnisse wurden in 22 thematischen Clustern zusammengefasst und in das Framework AssiStarMe überführt.
Das Framework verbindet Ziele und Schwierigkeiten der Anwender mit Unterstützungsfunktionen, darunter Modellierungsassistenten, semantische Prüfungen und AI-basierte Hilfen. Es liefert eine konzeptionelle Grundlage für deren Bewertung, aber noch keinen umfassenden Wirksamkeitsnachweis für große Unternehmensumgebungen.
Einordnung: Die Beurteilung von Low-Code-Plattformen muss neben Produktivität und Entwicklungsgeschwindigkeit auch Modellierungsqualität berücksichtigen. Relevant ist, wie zuverlässig Anwender tragfähige Anwendungen erstellen und Architekturvorgaben einhalten können. Befähigung, Modellqualität, Architekturkonformität und Lebenszyklus-Governance bilden dafür ergänzende Bewertungsperspektiven.
Konzentrationsrisiken trotz Anbieterdiversität
Quelle: Forrester – AI Is Hiding Concentration Risk in Plain Sight
Autorin: Alla Valente, Principal Analyst · Veröffentlicht: 7. Oktober 2026
Valente untersucht gemeinsame Abhängigkeiten scheinbar unabhängiger Anbieter. Dazu können Infrastruktur, technische Dienstleister, Datenquellen oder Kontrollmechanismen gehören. Als Beispiel behandelt sie gemeinsam genutzte Prüf- und Testinfrastrukturen im AI-Umfeld. Die Analyse unterscheidet zwischen nachgewiesenen Abhängigkeiten und möglichen, aber nicht bestätigten Zusammenhängen.
Einordnung: Mehrere Anbieter gewährleisten nur dann zusätzliche Resilienz, wenn kritische Abhängigkeiten ausreichend unabhängig voneinander sind. Für Cloud-Architekturen betrifft dies unter anderem Identitätsdienste, DNS, Netzwerkanbindungen, Zertifizierungsstellen und Softwarelieferketten. Eine Risikoanalyse muss deshalb die Beziehungen von Business Capabilities über Anwendungen und Anbieter bis zu gemeinsam genutzten Infrastrukturkomponenten erfassen. Die Anzahl der Anbieter allein ist kein belastbarer Resilienzindikator.
Validierbare Zwischenmodelle für AI-gestützte Prozessmodellierung
Quelle: Autorenfassung – Towards LLM-Assisted Business Process Modeling in an Industrial Modeling Tool: An Experience Report
Autoren: Andrey Sadovykh, Loay Chlih, Bilal Said, Hugo Bruneliere · Veröffentlicht: Oktober 2026, ACM/IEEE MODELS 2026, 4.–9. Oktober · DOI: 10.1145/3822455.3830328
Die Autoren vergleichen zwei Verfahren zur Erzeugung von BPMN-Prozessmodellen aus natürlichsprachlichen Beschreibungen: die direkte Generierung von Skripten zur Steuerung eines Modellierungswerkzeugs und die Erzeugung einer strukturierten Zwischenrepräsentation, die anschließend in ein Prozessmodell überführt wird.
Die Untersuchung umfasst 24 Szenarien von sieben Industriepartnern sowie 55 weitere BPMN-Szenarien aus einem offenen Datensatz. Eine kompakte Zwischenrepräsentation reduziert typischerweise Rechenaufwand, Tokenverbrauch und Generierungszeit. Grenzen bestehen bei komplexen Modellen und bei der Bewertung semantischer Korrektheit.
Einordnung: Eine deklarative Zwischenschicht schafft zusätzliche Möglichkeiten zur Validierung, Transformation und Versionierung generierter Modelle. Für andere EA-Modellierungssprachen könnte dieses Architekturprinzip ebenfalls relevant sein; eine entsprechende Übertragbarkeit ist durch die BPMN-Untersuchung jedoch noch nicht nachgewiesen. Metamodelle und fachliche Prüfungen bleiben entscheidend, um syntaktisch korrekte Ergebnisse auch inhaltlich bewerten zu können.
Gesamtbewertung
Operative Daten ergänzen die Architekturmodellierung
Die Beiträge zu API-basiertem Capability Discovery, kontinuierlicher Architektursteuerung und LLM-gestützter Prozessmodellierung beschreiben unterschiedliche Zugänge zu einer aktuelleren Informationsgrundlage. Gemeinsam legen sie nahe, manuelle Modellpflege durch technische Erkennung, assistierte Modellgenerierung und regelmäßige Validierung zu ergänzen.
| Architekturaktivität | Ergänzende Verfahren |
|---|---|
| Discovery | Analyse operativer Systeme zusätzlich zu Interviews und Workshops. |
| Modellierung | AI-gestützte Generierung mit definierten Metamodellen und fachlicher Prüfung. |
| Validierung | Abgleich modellierter Strukturen mit beobachteten Zuständen. |
| Governance | Risikobasierte Kontrollen auf Grundlage aktueller Architekturinformationen. |
Strategische Absichten, organisatorische Verantwortung und zukünftige Zielbilder lassen sich aus technischen Betriebsdaten allein nicht zuverlässig ableiten. Die Verbindung von beobachteten Zuständen und fachlicher Modellierung bleibt deshalb eine Kernaufgabe des EAM.
Souveränität erfordert Kontrolle, Ersetzbarkeit und Einfluss
Die Analysen zu Open Source und Konzentrationsrisiken erweitern die Bewertung technologischer Unabhängigkeit. Kontrolle über Nutzung und Betrieb, die tatsächliche Ersetzbarkeit einer Technologie sowie Einfluss auf ihre Weiterentwicklung sind unterschiedliche Fähigkeiten. Eine belastbare Souveränitätsbewertung muss diese Perspektiven getrennt erfassen und gemeinsame Abhängigkeiten sichtbar machen.
Für Architekturentscheidungen ergibt sich daraus ein gemeinsamer Schwerpunkt: Technische Transparenz muss mit fachlicher Bewertung und klarer Verantwortung verbunden werden. Automatisierte Erkennung und eine größere Anbieterauswahl liefern dafür zusätzliche Informationen und Optionen; ihre Wirkung hängt von der Qualität der Einordnung und den verfügbaren Handlungsmöglichkeiten ab.