UAF: Enterprise Architecture trifft MBSE

Model Based Systems Engineering (MBSE) hat sich inzwischen als Nischentechnologie etabliert. Gleichzeitig entstehen Capability-Maps, Betriebsprozesse, Sicherheitskonzepte und Roadmaps oft außerhalb des eigentlichen Systemmodells. UAF hilft, um hier Silobildung zu verhindern.

Das Unified Architecture Framework (UAF) der OMG versucht, Enterprise Architecture, Missionsarchitektur und Systems Engineering in einem gemeinsamen Modell zusammenzuführen. Der Ansatz entstand ursprünglich im Umfeld großer Verteidigungs- und Raumfahrtprogramme, adressiert heute aber zunehmend industrielle Plattformstrategien, Digital Engineering und System-of-Systems-Architekturen.

Gerade in großen Entwicklungsorganisationen entsteht häufig ein Bruch zwischen strategischer Planung und technischer Umsetzung. Enterprise-Architecture-Teams arbeiten mit Capability-Maps und Transformationsroadmaps, während MBSE-Teams Funktionen, Schnittstellen und Requirements modellieren. UAF liefert einen gemeinsamen Begriffsraum für beide Welten.

Angebot: Nimm an meiner zweitägigen Präsenzschulung „Product Velocity“ vom 30. Juni bis 1. Juli 2026 in München teil. Weitere Informationen & Anmeldung >>

Was ist UAF und wer braucht es?

UAF ist ein Architekturframework der Object Management Group (OMG). Die OMG positioniert den Standard als modellbasierten Ansatz für Enterprise Architecture, System-of-Systems und Mission Engineering. Im Gegensatz zu vielen klassischen Architekturframeworks definiert UAF nicht nur Dokumentstrukturen oder Diagrammtypen, sondern auch ein gemeinsames Metamodell.

Der Standard besteht aus zwei normativen Dokumenten. Das Domain Metamodel (DMM) beschreibt die Architekturkonzepte und ihre Beziehungen. Dazu gehören unter anderem Capabilities, Operational Activities, Resources, Services, Projects oder Security Controls. Die UAF Modeling Language (UAFML) beschreibt die konkrete Umsetzung dieser Konzepte auf Basis von UML und SysML.

Daneben stellt die OMG weitere Artefakte bereit. Dazu gehören UML-Profile, XMI-Dateien, Beispielmodelle sowie informative Dokumente zur Anwendung des Standards. Dadurch können Werkzeughersteller UAF direkt unterstützen und Modelle zwischen Werkzeugen austauschen.

Interessant wird UAF vor allem dort, wo klassische Systemmodelle organisatorische Grenzen erreichen. Ein eingebettetes Einzelsystem mit wenigen Stakeholdern benötigt meist kein Enterprise-Architecture-Framework. Anders sieht es bei Plattformstrategien, Software-defined Products oder organisationsübergreifenden Systemlandschaften aus.

Gerade im Umfeld software-definierter Produkte verschwimmen die Grenzen zwischen IT, Systementwicklung und Betrieb zunehmend.

Typische Einsatzfelder sind System-of-Systems, Mission Engineering, Plattform- und Produktlinienarchitekturen, Defence- und Aerospace-Programme sowie große Transformationsvorhaben mit starker MBSE- oder Enterprise-Architecture-Komponente. Gerade im Umfeld software-definierter Produkte verschwimmen die Grenzen zwischen IT, Systementwicklung und Betrieb zunehmend. Cloud-Plattformen, OTA-Updates, Security-Infrastrukturen und Entwicklungsplattformen werden Teil der eigentlichen Produktarchitektur. UAF adressiert genau diese Zusammenhänge.

Hörenswert ist auch diese Episode des MBSE Podcast mit Aurelijus Morkevicius.

Das UAF Grid als Landkarte

Das bekannteste Artefakt des Standards ist das sogenannte UAF Grid.

Das Grid organisiert Architekturinformationen in Zeilen und Spalten. Die Zeilen repräsentieren unterschiedliche Domänen wie Strategic, Operational, Resources, Security oder Projects. Die Spalten beschreiben unterschiedliche Modellarten wie Structure, Connectivity, Processes, States oder Roadmap.

Auf den ersten Blick wirkt das Grid überladen. Tatsächlich liefert es aber eine brauchbare Orientierung für große Architekturmodelle. Ähnlich wie das V-Modell strukturiert es die Architektur entlang unterschiedlicher Fragestellungen und Verantwortlichkeiten.

Ein pragmatischer Einstieg zu UAF führt über drei Kernperspektiven: Strategic, Operational und Resources.

Aurelijus Morkevicius im MBSE Podcast

Die eigentliche Stärke liegt weniger in den einzelnen Zellen als in der Vollständigkeit der Perspektiven. Viele Architekturmodelle fokussieren stark auf Systemstruktur und Verhalten. Strategische Ziele, organisatorische Aspekte oder Transformationspfade bleiben dagegen implizit.

Das Grid macht diese Lücken sichtbar. Ein typisches Beispiel sind Capability-Modelle. In vielen Unternehmen existieren sie isoliert, ohne Verbindung zu konkreten Systemen oder Projekten. UAF verbindet Capabilities mit Operational Activities, Ressourcen, Services und Roadmaps. Dadurch entsteht eine nachvollziehbare Kette von strategischen Zielen bis zur technischen Umsetzung.

Gleichzeitig zwingt UAF niemanden, jede Zelle des Grids zu modellieren. Erfolgreiche UAF-Einführungen arbeiten selektiv und konzentrieren sich auf die Sichten, die konkrete Stakeholder-Fragen beantworten. Damit nähert sich UAF stark dem Architekturverständnis von ISO 42010 an. Architektur entsteht aus Concerns und Stakeholdern, nicht aus einer Sammlung vorgeschriebener Diagramme.

UAF und Mission Engineering

Besonders interessant ist UAF im Kontext von Mission Engineering. Der Begriff stammt ursprünglich aus dem Verteidigungsumfeld, beschreibt aber ein allgemeines Problem komplexer Systemlandschaften. Dabei steht die Fähigkeit einer Organisation, bestimmte Missionen oder Geschäftsziele zu erfüllen, im Mittelpunkt.

Ein modernes Fahrzeug entsteht beispielsweise nicht nur aus Steuergeräten und Softwarekomponenten, sondern auch Cloud-Services, OTA-Infrastruktur, Security-Mechanismen, Entwicklungsplattformen und Betriebsorganisationen. Genau diese Zusammenhänge lassen sich mit klassischen Systemmodellen nur schwer erfassen.

UAF liefert dafür ein gemeinsames Architekturvokabular. Strategische Ziele werden mit Capabilities verknüpft. Capabilities hängen mit Operational Activities zusammen. Diese benötigen wiederum Ressourcen, Services und Personal.

Dadurch lassen sich Fragen beantworten, die in vielen Organisationen nur implizit existieren. Zum Beispiel welche Capabilities von welchen Systemen abhängen oder welche Sicherheitsmechanismen welche Operational Activities schützen. Gerade in großen Transformationsprogrammen entsteht dadurch ein erheblicher Mehrwert.

SysML v2

Bereits heute basiert UAFML auf UML und SysML. UAF bewegt sich also bewusst innerhalb derselben Modellierungswelt wie klassisches MBSE. SysML v2 verbessert nun mehrere technische Grundlagen, die für große integrierte Architekturmodelle relevant sind.

Dazu gehören insbesondere API-basierte Modellintegration, textuelle Modellierung, konsistente Modellabfragen und stärkere Werkzeuginteroperabilität. Interessant wird insbesondere die Verbindung zwischen strategischen und technischen Modellen. Ein strategisches Ziel kann eine Capability motivieren. Diese Capability benötigt Operational Activities. Die Operational Activities referenzieren konkrete Ressourcen oder Systeme. Diese wiederum existieren als SysML-v2-Modelle mit Anforderungen, Schnittstellen und Verifikationsartefakten. Dadurch entsteht eine durchgängige Traceability vom strategischen Ziel bis zum Verifikationsergebnis.

Morkevicius erwartet, dass SysML v2 UAF stark beeinflussen wird. Gleichzeitig sieht er die Herausforderung weniger in der fachlichen Passung als in der Migration: UAF muss SysML v2 unterstützen, ohne bestehende SysML-1.x-basierte UAF-Anwendungen zu brechen.

Gerade große Entwicklungsorganisationen versuchen seit Jahren, solche Zusammenhänge sauber abzubilden. Die Kombination aus UAF und SysML v2 liefert dafür eine deutlich bessere technische Grundlage als viele heutige Werkzeuglandschaften.

Praktisches Beispiel

Ein interessantes Beispiel für den praktischen Einsatz von UAF liefert die Aerospace Corporation im Umfeld von Mission Engineering und Space Systems.

Dort werden strategische Missionsziele mit Operational Activities, Ressourcen und technischen Systemen verbunden. Satelliten, Bodenstationen, Kommunikationssysteme und Betriebsorganisationen erscheinen als zusammenhängende Architektur.

Dadurch lassen sich Auswirkungen von Änderungen deutlich besser analysieren. Fällt beispielsweise ein bestimmter Kommunikationsservice aus, kann nachvollzogen werden, welche Mission Phases und Operational Activities betroffen sind. Gleichzeitig lassen sich organisatorische und technische Abhängigkeiten sichtbar machen.

Interessant ist außerdem die explizite Modellierung von Transformation und Evolution. UAF enthält eigene Konzepte für Projekte und Roadmaps. Dadurch können die Zielarchitekturen und deren zeitliche Entwicklung beschrieben werden. Das ist besonders relevant für Plattformmigrationen, Legacy-Ablösungen oder Cloud-Transformationen.

UAF kann nicht nur die Zielarchitekturen beschreiben, sondern auch deren zeitliche Entwicklung.

Fazit

UAF adressiert ein Problem, das in vielen MBSE-Initiativen gern vergessen wird. Große Systeme sind Teil organisatorischer, strategischer und betrieblicher Zusammenhänge, was explizit berücksichtigt werden sollte. Genau diese Zusammenhänge modelliert UAF.

Besonders spannend wird UAF dort, wo Enterprise Architecture und Systems Engineering zusammenwachsen. Software-defined Products, Digital Engineering und System-of-Systems treiben genau diese Entwicklung voran.

Mit SysML v2 verbessert sich gleichzeitig die technische Grundlage für integrierte Architekturmodelle erheblich. Dadurch dürfte UAF in den kommenden Jahren eher an Bedeutung gewinnen als verschwinden.

Gerade für MBSE-Teams lohnt sich daher ein genauer Blick auf den Standard. Nicht unbedingt als vollständiges Framework, sondern als strukturierte Erweiterung des Modellierungsraums über die eigentliche Systemgrenze hinaus.