The Data Mesh and Model-Based Systems Engineering Nexus

The DoD Acquisition community will require digital engineering (DE) environments to deliver Joint All Domain Command & Control (JADC2) capabilities at the speed of relevance. DE provides the means to link acquisition strategies, system requirements, M&S models, architectural data, hardware-in-the-loop testing, and live testing into a unified digital thread to govern the full acquisition lifecycle. A DE environment is an ecosystem of integrated tools that include requirements and architecture authoring tools, high-performance computational (HPC) modeling, product lifecycle management, Computer-Aided Design, digital twin tooling, and data platforms. These tools will be hosted on hybrid, multi-cloud infrastructure with services that facilitate cross-tool management and support for model artifact discovery and data governance. See this link for information about the DoD Digital Engineering Strategy. The Model-Based Systems Engineering (MBSE) paradigm is the approach that governs the unifying source of truth for all architectural data with a modeling language that standardizes model elements and architectural views. The MBSE paradigm was always considered a foundational element for DE. Recently, a new paradigm called Data Mesh has emerged with a vision to share ubiquitous multi-modal data at scale. Multi-modal data refers to data that combines different modalities of data including text, images, audio, video, and more. The nexus between the MBSE and Data Mesh paradigms will strengthen the foundation of future DE environments. The purpose of this article is to introduce both paradigms and discuss how their nexus along with a hybrid, multi-cloud infrastructure environment empowered by Artificial Intelligence (AI) will digitally transform the DoD acquisition lifecycle.

The Model-Based Systems Engineering Paradigm

Traditionally, systems engineering practices involved a document-based approach where architecture artifacts were developed in disparate products (Excel, PowerPoint, Visio, pdfs, etc.). These disparate products made it nearly impossible to propagate architectural changes resulting in outdated, disconnected, and potentially contradictory information. The MBSE approach addresses this challenge by formalizing the application of modeling to support system requirements, design, analysis, verification, and validation activities throughout the entire system life cycle from concept to disposal. The MBSE approach uses the Systems Modeling Language (SysML) to define system elements once for use in various architectural views that express system structure, behavior, requirements, and parametrics (math equations for trade space analysis). In practice, organizations use frameworks as a methodology to develop model artifacts. These frameworks inherit the SysML language syntax into views to facilitate integration and promote interoperability across capabilities and integrated architectures.

The DoD Architecture Framework (DoDAF) is one example of a framework. The Unified Architecture Framework (UAF) is another framework that evolved from both the DoDAF and the Ministry of Defense Architecture Framework (MODAF) and is becoming the framework of choice across DoD. The UAF has several view specifications that facilitate the MBSE approach including metadata, strategic, operational, services, resources, security, and more. To help facilitate system interoperability, the Multilateral Interoperability Programme (MIP) Information Model (MIM) provides the semantic foundation for information exchange in the Command and Control (C2) domain. MIP is a military standardization body comprising 24 member nations, the European Defense Agency, and NATO. Because the JADC2 concept relies heavily on the Joint Forces’ integration with mission partner nations, the MIM information exchange specifications provide a consistent standard for interoperability governance. JADC2 capabilities will require complex system-of-systems architectures involving humans, distributed systems, edge and hybrid cloud computing, space, 5G, other electromagnetic terrestrial communications transports, and more. To achieve the JADC2 vision, the DoD must govern these complex system-of-systems architectures with consistent authoritative modeling artifacts and MIM specification information exchanges that can be traced to ubiquitous multi-modal data sources. The Data Mesh paradigm provides an excellent blueprint to manage and govern the exponential growth of ubiquitous data.

The Data Mesh Paradigm

Zhamak Dehghani is known as the founder of Data Mesh. She describes Data Mesh as “a sociotechnical approach to share, access, and manage analytical data in complex and large-scale environments —within or across organizations.” To achieve this vision, Zhamak proposes a paradigm shift that converges the following four principles, domain ownership, data as a product, self-serve data platform, and federated computational governance. Domain ownership is a decentralized approach to empower lower-level organizations to develop, build, and maintain data products related to a specific domain. Data as a product is a concept that applies product thinking to data to ensure it is discoverable, addressable, trustworthy, self-describing, interoperable, and secure. A data product is much more than a data table. It includes metadata, APIs, transformation code, multi-model interfaces (SQL or NoSQL), and embedded computational policies that enforce governance, interoperability, and security. The self-serve data platform manages the interconnected data products with reusable data engineering and governance common services that facilitate data sharing. Federated computational governance involves an operating model that balances the autonomy and agility of a data domain with the global interoperability of the data mesh. Computational policies are conceptually enforced in the form of a sidecar Docker container that lives with the data product. These sidecar containers can enforce global interoperability requirements, security compliance, access, and management of data products. It is important to note that the Data Mesh is currently an aspiration vision. The decentralized nature of the domain-managed data products implies that subordinate organizations have the technical talent to manage the data products. In many cases, this implication makes the data mesh paradigm unrealistic. Therefore, organizations should build realistic self-serve data platforms with an awareness of their digital talent maturity. As the talent maturity grows, so could the maturity of the platform.    

The Nexus

The DoD Digital Engineering strategy roadmap would benefit from leveraging both the MBSE and Data Mesh paradigms. The architectural products built using the MBSE approach could serve as data products that become part of the ecosystem with other data products produced by engineering tooling and live testing. This idea is best illustrated with an example. The Program Executive Offices manages a system architecture model using the Unified Architecture Framework with requirements allocated to systems elements within the model. These system elements are defined once and used throughout the operational and logical architectural views. While the Government owns and manages the operational and logical views, vendors deliver physical instantiations of the logical architecture expressed as SysML models. Together, these architectural products act as a hinge to relate other domain data products created from engineering tooling and live testing. Examples of data products include data generated from operational performance modeling & simulations, HPC physics-based modeling, digital twin representations for trade space analysis, lifecycle cost modeling, non-functional “ilities modeling, hardware-in-the-loop testing, and live testing. A successful DE environment will allow the DoD to govern an ecosystem of engineering tooling to author and manage requirements and architectures with explicit traceability across data products produced from the various data domains. The full traceability between requirements, architectural views, modeling artifacts, and domain data products provides a consistent digital thread that acts as the single source of truth throughout the entire system lifecycle.

Digital Engineering Environment

Goal number four of the DoD Digital Engineering Strategy is to establish a supporting infrastructure and environment to perform activities, collaborate, and communicate across stakeholders. This DE environment will require a hybrid, multi-cloud infrastructure that will include on-prem computing centers from the DoD HPC Modernization Program, disconnected cloud edge computing for expeditionary field testing, and services from multiple cloud solution providers. These hybrid, multi-cloud environments will allow the DoD to host applications everywhere with data residing anywhere. To help manage this inherent complexity, the DoD needs a consistent control plan to govern the infrastructure landscape and the data estate across the hybrid, multi-cloud environment. To govern effectively, the control plane should provide a unified experience over the entire environment, ideally with a single identity provider, that would enforce zero trust security policies, allow for consistent deployments using GitOps, and manage the lifecycles of virtual machines and Kubernetes clusters. In addition to the environment, the data products themselves need governance solutions that provide a unified experience that allows for data discovery, data scanning, classification, and data catalog management. Effective data catalogs will allow for consistent data taxonomy and metadata management, and the ability to visually trace the lineage of data assets.  

Conclusion

Interfacing engineering tooling with architecture models is an active area of research. See this technical report about discovering the relationships between system element value properties and emergent behavioral properties of M&S model outputs. These abstract research ideas are now becoming a reality with the release of SysML 2.0 which will enable REST APIs, advances in engineering tooling API exposures, and the DoD’s commitment to upskill digital talent, adopt digital processes, and partner with industry to provide Government cloud infrastructure environments, and digital capabilities. Additionally, the AI revolution is here. Leveraging ChatGPT and future multi-modal large language model advancements within the DE environments will accelerate JADC2 capabilities. See this blog for one solution pattern that leverages ChatGPT with an organization’s private data. An ecosystem of data products combined with digital engineering tool artifacts will create a rich data corpus that can leverage multi-modal large language models to uncover integration challenges, reveal the impacts of configuration changes, suggest new architectural patterns, discover unforeseen emergent properties, and so much more. The nexus between the Data Mesh and MBSE paradigms, the maturity of data platforms hosted on hybrid multi-cloud infrastructure, and AI will facilitate a more cohesive cross-tool DE environment that will digitally transform the DoD acquisition processes.