As engineering organizations seek to benefit from digital engineering, many consider strengthening how models are used across engineering work under the banner of model-based systems engineering (MBSE). The International Council on Systems Engineering (INCOSE) defines MBSE as the formalized application of modeling to support requirements, design, analysis, verification, and validation throughout the system life cycle. The distinction is not whether an organization uses models, since nearly all engineering activities do, but whether to adopt practices that make selected models authoritative, connected, and governed. This means that models are used as primary support for making and verifying lifecycle decisions and for reducing technical risk. This blog post explains how organizations can get started with an MBSE strategy through a pathfinder project that focuses on one team and one target system, relates models to specific decisions, and measures the results before expanding.

The choices of relevant models depend on the decisions being faced or technical risks to be mitigated. Examples include:

• a SysML v2 model that links requirements to system structure, interfaces, behavior, and verification
• an AADL model that represents embedded software and hardware, processor and bus bindings, communication paths, and end-to-end latency
• a requirements model in IBM DOORS that manages requirement decomposition, allocation, baselines, change history, and verification links
• a government reference architecture modeled in SysML v1 in Cameo Systems Modeler that defines reusable mission, system, and interface patterns for programs to tailor
• and a UAF model that connects operational goals, activities, roles, resources, and measures

These models answer different questions and require different expertise, evidence, validation, and governance.

Consequently, adopting MBSE should not be treated as a binary choice, as in, you’re either “doing MBSE” or you’re not. A useful MBSE practice names the model, the decisions it supports, when it is created and updated, how it connects to other engineering information, how it is validated, and how its results are checked with respect to the as-built system. A SysML v2 model may be checked for semantic consistency, design acceptance criteria, and traceability; an AADL model may be instantiated and analyzed against latency or resource limits; an IBM DOORS requirements model may be reviewed for attribute completeness, baseline integrity, and traceability coverage; a government reference architecture in Cameo may be checked for conformance to its SysML v1 profile and for complete mission, system, and interface patterns; and a UAF model may be reviewed for alignment among goals, activities, roles, and resources.

Scaling considerations can be significant, including horizontal (i.e., across elements of integrated systems) and vertical (i.e., in support of systems that must support multiple variants and continue to evolve). Product-line SysML models, for example, must manage variants and traceability; AADL models spanning computing platforms must manage bindings and timing assumptions; DOORS repositories must manage baselines, access, and link integrity; and reference architectures in SysML or UAF reused across programs must manage profile, library, version, and tailoring governance.

The National Academies' 2025 study Digital Transformation in the Department of the Air Force describes digital transformation as the advancement of practices supporting MBSE, digital twins, and digital threads across full system life cycles. It also concludes that there is no proven formula for enterprise-wide success. A model does not create value merely by existing. It creates value when people use trustworthy, appropriately validated model information to make and verify decisions.

The evidence base reinforces the need for a measured approach. Campo and colleagues reviewed 60 sources and coded more than 2,900 claims about MBSE; 47 percent of the claims rested on author opinion, and 86 percent were not supported by a metric. Henderson and Salado similarly found that two-thirds of claimed MBSE benefits were supported only by perceived evidence and that only two papers in their review reported measured evidence. These findings do not show that MBSE lacks value. They show that organizations need explicit, model-specific value hypotheses and measures that connect a defined model and its use in a decision to engineering and mission outcomes.

Adoption studies also identify practical obstacles. Vogelsang and colleagues interviewed 20 experts from 10 German embedded-systems companies and found concerns about immature tooling, uncertain return on investment, and migration of existing data and processes. Their participants often expected MBSE to manage complexity and reduce cost but could not always identify which models, analyses, or decision workflows would produce those benefits. The researchers concluded that poor experiences frequently began with expectations that were too high or insufficiently concrete.

The SEI's first MBSynergy Workshop brought together 25 subject-matter experts from defense and intelligence programs and identified five recurring barriers: a mismatch between program-management needs and MBSE expertise, vague definitions of correct implementation, the absence of a community of practice, adoption driven by tools or policy rather than mission needs, and unclear ownership of the MBSE approach. These are socio-technical problems. Buying a tool or producing a set of diagrams does not resolve them.

The SEI's MBSynergy project addresses these problems by modeling the modeling process: the mission goal, target decisions, stakeholders, model types, skills, triggers, inputs, activities, outputs, quality measures, validation methods, risks, and governance that make modeling useful. Its workshop series helps an organization define, prioritize, and model an initial MBSE strategy. The organization then exercises that strategy through a deliberately scoped pathfinder, measures what happens, and uses the resulting evidence to refine the strategy before expanding it.

Figure 1 provides a scoping heuristic for that initial pathfinder. One axis represents product scope, from a component to a system of systems. The other represents enterprise scope, from an individual practitioner to an enterprise capability. The point labeled (1,1) represents one project team using a named set of models to support specific decisions for one target system. For example, a team might use a SysML v2 model to coordinate requirements, interfaces, behavior, and verification for an unmanned aircraft subsystem, an AADL model to analyze timing and resource use in its flight-control architecture, and an IBM DOORS requirements model to manage allocation and verification evidence. It could also tailor or update a government reference architecture modeled in SysML v1 in Cameo Systems Modeler to establish common mission, system, and interface patterns. This is the minimum scope likely to expose the coordination, lifecycle, and decision-making concerns needed to learn how MBSE will work beyond an individual modeling task.

The categories on both axes are cumulative working definitions, not normative MBSE terms or maturity levels. Each level adds scope and coordination, but technical consequences depend on the models involved. A SysML v2 model for a product line introduces variant and traceability management; an AADL model spanning processors and networks introduces binding, timing, and resource analysis concerns; IBM DOORS requirements models spanning organizations introduce baseline, access-control, and link-integrity concerns; and a government reference architecture in SysML v1 in Cameo Systems Modeler introduces profile, library, version, and tailoring governance as programs reuse it.

Product Scope

• Component. A bounded subsystem, interface, function, or system attribute managed within a limited engineering scope.
• Target system. One system of interest whose engineering disciplines, models, and lifecycle artifacts are coordinated under a common decision authority.
• Product line. A family of related systems or variants that shares assets and must support decisions across product variants, model configurations and release horizons.
• System of systems. Independently managed systems whose interactions create mission-level capabilities and cross-system analysis dependencies involving model ownership, interfaces, and analysis.

Enterprise Scope

• Individuals. Practitioners apply modeling within specialized roles, often through locally managed or sequential workflows.
• Project team. Contributors share an objective, budget, schedule, leadership, and a common understanding of key terms and authoritative information.
• Product group. Multiple project teams coordinate modeling practices, technical scope, and planning horizons to support related products or releases.
• Enterprise. Roles, governance, infrastructure, and modeling practices are coordinated across the organization and its portfolio.

Why Scope Matters

An MBSE adoption strategy must account for both enterprise systems-engineering needs and the decisions and workflows of constituent teams. Just as independently developed systems can create integration cost and delay, disconnected engineering workflows can produce inconsistent assumptions, duplicate analysis, and late discovery of cross-system effects. Enterprise-level MBSE can enable reuse, portfolio-level tradeoffs, consistent acquisition expectations, and reduced reinvention, but those benefits depend on coordinated processes and trustworthy model information.

A component modeled by one practitioner can demonstrate a notation or tool, but it may reveal little about team coordination, governance, skills, or lifecycle integration. At the other extreme, beginning with an enterprise-wide or system-of-systems deployment introduces too many organizational and technical variables at once. A (1,1) pathfinder creates a practical learning environment: broad enough to expose real workflow and governance concerns but narrow enough to provide timely feedback and control risk.

This is why a pathfinder must be selected with future scale in mind. Its immediate objective is not to complete an enterprise transformation. It is to test assumptions about which models support which decisions, how their results will be validated, what resources the work requires, and which technical and organizational decisions will preserve future options.

From Strategy to a Measurable Pathfinder

Before choosing a pathfinder, an organization should identify the following:

• a mission-oriented business goal and a specific value hypothesis for using models
• current engineering workflows, existing models, and the decisions they support
• the roles, skills, and competencies required to perform and review the work
• data, modeling tools, digital engineering environments, and integration constraints
• applicable policies, governance decisions, and ownership of the MBSE approach
• success measures, risks, and the decision criteria for adapting or expanding the effort

MBSynergy uses pathfinder to mean a scoped pilot whose purpose is to generate evidence for scaling, not an isolated demonstration that a tool can produce a model. The pathfinder should test a real modeling process for a real target system, with specified model types and stakeholders who own the decisions and outputs. That could mean updating a SysML v2 architecture after a requirement change and reviewing interface impacts, instantiating an AADL architecture to check whether flight-control flows remain within latency budgets, establishing an IBM DOORS requirements baseline and checking verification coverage, or tailoring a SysML v1 government reference architecture in Cameo for one program. It should also produce evidence about the time, skills, tooling, governance, validation, and model-management effort that broader adoption will require.

Measures should reflect both near-term process performance and longer-term program outcomes, and they should match the model and decision. A SysML v2 pathfinder might track semantic validation errors, unresolved interfaces, traceability gaps, review effort, and the time needed to propagate a requirement change. An AADL pathfinder might track successful instantiation, analysis coverage, timing or resource-limit violations, and analysis turnaround time. An IBM DOORS pathfinder might track missing attributes, orphan or suspect links, baseline cycle time, and verification coverage. A Cameo reference architecture pathfinder might track profile violations, reused versus tailored elements, unresolved deviations, and cross-program update effort. Lagging outcomes can include rework, qualification delays, late defect discovery, lifecycle cost, and risk reduction. Defining both prevents early stakeholders from judging the effort only by costs incurred before lifecycle benefits can appear.

Modeling the Modeling Process

MBSynergy represents modeling concerns as scenarios. A scenario captures an MBSE process in a multi-faceted context including the specific models used and the decisions they inform. It can be summarized by a pattern sentence: within an environment, stakeholders with specific skills achieve a business goal when a trigger occurs, executing a process that uses named models to generate outputs from inputs with measured quality attributes. A complete scenario also records preconditions, postconditions, risks, references, tradeoffs, validation methods, and the governance or tools needed for execution.

Consider a pathfinder focused on evaluating a Modular Open Systems Approach (MOSA) proposal. A bidder's proposal triggers the process. Program office evaluators apply criteria from the request for proposal and other authoritative guidance. The response is an evaluation report, and measures assess its quality, cycle time, effort, and consistency. In this case, the primary modeled artifact is a UAF representation of the evaluation process: its goals, activities, information, roles, competencies, measures, and risks. The proposal and evaluation report remain inputs and outputs. Modeling the scenario makes the required stakeholder roles, skills, information, tools, decision points, and risks explicit before the organization expands the process.

Working through scenarios with key stakeholders helps answer practical questions:

• Which mission outcome or engineering decision should a specific model improve?
• Which trigger, inputs, model types, process steps, and outputs are in scope?
• How will the organization validate the model and judge process execution, model quality, and decision quality?
• Which roles, skills, tools, and authoritative information are required?
• Which governance decisions and risks could prevent local success from scaling?

Each scenario is captured in two complementary forms. A document-based definition supports early elicitation and review by stakeholders who may not use modeling notation. A model-based definition maps the same information into the Unified Architecture Framework (UAF), where explicit semantics support traceability, consistency checking, analysis, and connection to enterprise architecture. A coherent collection of prioritized and connected scenarios becomes an initial, analyzable MBSE strategy.

How the Workshop Series Works

The MBSE Strategy Workshop Guidebook describes a repeatable three-workshop process for defining, modeling, and planning a pathfinder. The workshops construct scenarios for activities that are or will be supported by named models and other digital assets. Elaborating those scenarios establishes a rationale for each modeling activity, identifies workforce and model-quality needs, and exposes execution risks.

Organizations are best positioned to benefit when they have begun to establish basic modeling tools and have staff with foundational modeling skills. The approach works best when mission needs, rather than a tool mandate, drive the effort; a modeling champion owns and guides the approach; stakeholders from acquisition, systems engineering, software engineering, verification and validation, and digital engineering participate; and leadership supports iterative learning rather than demanding a complete baseline before value can be demonstrated.

The workshop series progresses from context to an actionable initial strategy:

• Workshop 1 establishes the program context, introduces the MBSynergy scenario approach, and brainstorms a contextual set of candidate scenarios.
• Workshop 2 prioritizes the highest-impact scenarios and elaborates a subset using the MBSynergy scenario template.
• Workshop 3 validates a UAF model of the elaborated scenarios and identifies near-term actions for piloting the initial strategy.

The output is not a finished enterprise deployment. It is a documented, prioritized, and analyzable initial strategy, together with the near-term actions needed to exercise it through a pathfinder. As the organization runs the pathfinder, measures results, and incorporates lessons, the strategy model evolves.

Figure 2 shows how the MBSynergy profile maps scenario content to UAF concepts. Goals and objectives establish why the scenario matters; activities, information, and measures describe what it does; posts and competencies identify who performs it; and quality attributes, risks, and tradeoffs support analysis. This formal structure connects organizational intent to executable modeling processes.

Modeling the Path Ahead

Getting through square one with MBSE does not require a program to define or deploy an enterprise-wide solution at the outset. It requires an initial strategy and a deliberately scoped pathfinder: one project team, one target system, named model types, specific decisions, and a clear, mission-oriented value hypothesis. Capturing the pathfinder as scenarios connects organizational goals to stakeholders, activities, model outputs, validation methods, quality measures, risks, and tradeoffs. Executing those scenarios produces evidence that leaders can use to refine the approach, preserve future options, and expand MBSE practices where particular models deliver measurable value.

The SEI's MBSynergy: MBSE Strategy, Modeling, and Scenario Tools collection brings together the workshop guidance, scenario templates, UAF 1.2-based profile, scenario library, and tutorial needed to support that progression. Together, these resources help programs document current practices, analyze alternative adoption paths, plan a focused pathfinder, and evolve toward an organizationally sustainable and mission-relevant MBSE capability.

For more information or to collaborate with the SEI, email info@sei.cmu.edu.