UAF: Enterprise Architecture Meets MBSE

Model-Based Systems Engineering (MBSE) has now established itself as a niche technology. At the same time, capability maps, operational processes, security concepts, and roadmaps are often created outside of the actual system model. UAF helps to prevent silo formation in these areas.

The OMG's Unified Architecture Framework (UAF) attempts to merge Enterprise Architecture, Mission Architecture, and Systems Engineering into a common model. The approach originally emerged in the context of large defense and aerospace programs, but today it increasingly addresses industrial platform strategies, digital engineering, and system-of-systems architectures.

A gap often emerges between strategic planning and technical implementation, particularly in large development organizations. Enterprise architecture teams work with capability maps and transformation roadmaps, while MBSE teams model functions, interfaces, and requirements. UAF provides a common conceptual space for both worlds.

Offer: Attend my two-day in-person training „Product Velocity“ from June 30th to July 1st, 2026, in Munich. More information & registration >>

What is UAF and who needs it?

UAF is an architectural framework by the Object Management Group (OMG). The OMG positions the standard as a model-based approach for Enterprise Architecture, System-of-Systems, and Mission Engineering. In contrast to many classical architecture frameworks, UAF defines not only document structures or diagram types, but also a common metamodel.

The Standard consists of two normative documents. The Domain Metamodel (DMM) describes the architectural concepts and their relationships. These include, among others, Capabilities, Operational Activities, Resources, Services, Projects, and Security Controls. The UAF Modeling Language (UAFML) describes the concrete implementation of these concepts based on UML and SysML.

In addition, the OMG provides further artifacts. These include UML profiles, XMI files, example models, and informational documents on applying the standard. This allows tool vendors to directly support UAF and exchange models between tools.

UAF becomes particularly interesting where classic system models reach organizational boundaries. An embedded individual system with few stakeholders usually does not require an enterprise architecture framework. The situation is different with platform strategies, software-defined products, or cross-organizational system landscapes.

The lines between IT, system development, and operations are increasingly blurring, especially in the context of software-defined products.

Typical application areas include System-of-Systems, Mission Engineering, platform and product line architectures, defense and aerospace programs, as well as large transformation projects with a strong MBSE or Enterprise Architecture component. Especially in the environment of software-defined products, the boundaries between IT, system development, and operations are increasingly blurring. Cloud platforms, OTA updates, security infrastructures, and development platforms are becoming part of the actual product architecture. UAF addresses precisely these interrelationships.

Worth listening to is also this episode of the MBSE podcast with Aurelijus Morkevicius.

The UAF Grid as a Map

The best-known artifact of the standard is the so-called UAF Grid.

The grid organizes architectural information in rows and columns. The rows represent different domains such as Strategic, Operational, Resources, Security, or Projects. The columns describe different model types such as Structure, Connectivity, Processes, States, or Roadmap.

At first glance, the grid seems overloaded. However, it actually provides useful orientation for large architectural models. Similar to the V-model, it structures the architecture along different questions and responsibilities.

A pragmatic introduction to UAF involves three core perspectives: Strategic, Operational, and Resources.

Aurelijus Morkevicius MBSE Podcast

The real strength lies less in individual cells and more in the completeness of perspectives. Many architectural models focus heavily on system structure and behavior. Strategic goals, organizational aspects, or transformation paths, on the other hand, remain implicit.

The grid makes these gaps visible. A typical example is capability models. In many companies, they exist in isolation, without connection to concrete systems or projects. UAF connects capabilities with operational activities, resources, services, and roadmaps. This creates a traceable chain from strategic goals to technical implementation.

At the same time, UAF does not force anyone to model every cell of the grid. Successful UAF adoptions work selectively, focusing on the views that answer concrete stakeholder questions. This brings UAF very close to the architectural understanding of ISO 42010 Architecture arises from concerns and stakeholders, not from a collection of prescribed diagrams.

UAF and Mission Engineering

Particularly interesting is UAF in the context of Mission Engineering. The term originally comes from the defense sector but describes a general problem of complex system landscapes. The focus is on an organization's ability to fulfill specific missions or business goals.

For example, a modern vehicle is not just made up of control units and software components, but also cloud services, OTA infrastructure, security mechanisms, development platforms, and operational organizations. It is precisely these interrelationships that are difficult to capture with traditional system models.

UAF provides a common architecture vocabulary. Strategic goals are linked to capabilities. Capabilities are related to operational activities. These, in turn, require resources, services, and personnel.

This allows us to answer questions that exist implicitly in many organizations. For example, which capabilities depend on which systems or which security mechanisms protect which operational activities. This creates significant added value, especially in large transformation programs.

SysML v2

Even today, UAFML is based on UML and SysML. UAF is therefore consciously moving within the same modeling world as classic MBSE. SysML v2 now improves several technical foundations that are relevant for large integrated architecture models.

This includes, in particular, API-based model integration, textual modeling, consistent model queries, and stronger tool interoperability. The connection between strategic and technical models will be particularly interesting. A strategic goal can motivate a capability. This capability requires operational activities. The operational activities reference concrete resources or systems. These, in turn, exist as SysML-v2 models with requirements, interfaces, and verification artifacts. This creates end-to-end traceability from the strategic goal to the verification result.

Morkevicius expects that SysML v2 will strongly influence UAF. At the same time, he sees the challenge less in the technical fit and more in the migration: UAF must support SysML v2 without breaking existing SysML 1.x-based UAF applications.

For years now, large development organizations have been trying to cleanly map out such connections. The combination of UAF and SysML v2 provides a significantly better technical foundation for this than many current tool landscapes.

Practical example

An interesting example of the Practical application of UAF The Aerospace Corporation supplies in the field of Mission Engineering and Space Systems.

There, strategic mission objectives are linked with operational activities, resources, and technical systems. Satellites, ground stations, communication systems, and operational organizations appear as a cohesive architecture.

This allows for a much better analysis of the impact of changes. For example, if a specific communication service fails, it can be traced which mission phases and operational activities are affected. At the same time, organizational and technical dependencies can be made visible.

What is also interesting is the explicit modeling of transformation and evolution. UAF contains its own concepts for projects and roadmaps. This allows target architectures and their temporal development to be described. This is particularly relevant for platform migrations, legacy replacements, or cloud transformations.

UAF can not only describe target architectures but also their temporal evolution.

Conclusion

UAF addresses a problem that is often overlooked in many MBSE initiatives. Large systems are part of organizational, strategic, and operational contexts, which should be explicitly considered. UAF models precisely these contexts.

UAF becomes particularly exciting where Enterprise Architecture and Systems Engineering merge. Software-defined Products, Digital Engineering, and Systems of Systems are driving precisely this development.

With SysML v2, the technical foundation for integrated architecture models also improves significantly. This means that UAF is likely to gain importance rather than disappear in the coming years.

Therefore, MBSE teams in particular would benefit from taking a closer look at the standard. Not necessarily as a complete framework, but as a structured extension of the modeling space beyond the actual system boundary.