Model-Based Systems Engineering at Scale: What Actually Changes When Hundreds of Engineers Are Involved
Most MBSE introductions describe the same concept: replace document-centric engineering with a shared, structured model that captures system behavior, structure, and requirements in one place. The logic is sound. The diagrams are clean. The reference implementations fit on one team and one server.
Then a real program starts. Four subsystem contractors. Two integration partners. A government customer with their own SysML toolchain. A heritage model from the previous program phase that no one fully understands. Three hundred engineers who have never used SysML in production.
The introductory definition doesn’t survive contact with this environment. What MBSE means at scale — across a large program, across organizational boundaries, across a multi-year development cycle — is a different question entirely. This article addresses that question directly.
The Core Problem: Models Are Not Documents
Documents have a property that engineers underestimate until it’s gone: they degrade gracefully. A requirement specification from eighteen months ago is still readable. It may be wrong, but it communicates. A SysML model from eighteen months ago, if it hasn’t been maintained, may be unloadable, inconsistent, or silently stale in ways that aren’t visible until you execute a query and get wrong answers.
This asymmetry matters at scale because maintenance burden grows with the number of contributors. On a small program, one or two lead systems engineers own the model and keep it current. On a large program, that ownership must be distributed — and distribution requires explicit governance that document-based programs never needed.
The two dominant approaches to distributing that ownership are federated architectures and centralized architectures. Neither is universally correct. Understanding the tradeoffs is the first practical decision any large MBSE program must make.
Federated vs. Centralized Model Architectures
Centralized Architecture
A centralized model stores all system elements — requirements, behavior, structure, interfaces — in a single shared repository. Every engineer queries and commits to the same artifact. Tools like IBM DOORS Next with OSLC integrations, or Cameo Systems Modeler connected to Teamwork Cloud, can support this model.
Advantages: Single source of truth. Traceability queries run across the entire system without cross-model federation. Reviews pull from one place. Governance is structurally enforced because there is no other model to conflict with.
Disadvantages: Performance degrades with scale. Concurrent editing becomes contentious. Contractor boundaries become complicated — a subcontractor with their own IT environment and export control obligations cannot always connect to a prime contractor’s centralized server. The model becomes a single point of failure for the entire program.
Federated Architecture
A federated architecture partitions the model across multiple repositories — typically aligned to subsystem boundaries or organizational responsibilities. Each partition is locally owned. Integration is achieved through defined interfaces between partitions, with explicit mechanisms for exchanging model fragments and synchronizing shared elements.
Advantages: Scales to large teams and contractor boundaries. Each organization owns and controls their partition. Performance is local. Organizational autonomy is preserved.
Disadvantages: Synchronization between partitions is manual or tool-dependent and frequently breaks. Interface definitions between partitions must be rigorously maintained — they become the program’s most critical engineering artifacts. Traceability across partitions requires federation queries that are slow, fragile, and tool-specific. The “single source of truth” property is lost by design.
What Actually Happens on Large Programs
Most large programs end up with informal hybrids. The prime contractor maintains a centralized integration model. Subsystem contractors maintain their own models. There is a periodic, often painful, integration event where the prime attempts to reconcile the subsystem models with the integration model. Requirements change in one partition without propagating to others. Interface assumptions diverge.
This is not a failure of intent. It is the predictable result of treating MBSE as a modeling problem rather than a governance problem. The models are fine. The authority structure — who owns what, who can change what, and what happens when something changes — is undefined or unenforced.
Model Authority: The Governance Problem That Tooling Cannot Solve
Model authority answers a specific question: when two elements in two models conflict, which one governs?
On a document-based program, this question has a default answer: the contract-deliverable specification governs. It’s slow, but it’s unambiguous. On an MBSE program, the answer is often unclear. Is the SysML Block Definition Diagram authoritative over the interface control document? Does a requirement in the model supersede the same requirement in the contractual statement of work? When the simulation team updates a behavioral model, does that update the requirements?
Authority must be defined explicitly, in writing, before the program reaches the point where it matters — which is before the first design review. A minimal authority framework needs to answer:
- Which model elements are authoritative and which are derivative?
- What is the change control process for authoritative elements?
- What is the notification process when authoritative elements change?
- Who approves changes across organizational boundaries?
Without this framework, engineers make local decisions. Those decisions accumulate into program-level inconsistencies that surface at reviews, integration events, or — worst case — in the delivered system.
Version Management at Scale
Version management for models is harder than version management for code, and the software industry has spent thirty years solving version management for code.
SysML models are not text files. A merge conflict in a model is not two lines of code pointing to different values — it is two structural representations of the same system that may be logically inconsistent in ways that aren’t syntactically visible. Most model versioning tools handle this poorly. Teamwork Cloud has branching and merging capabilities, but the semantics of a model merge are complex enough that automated tools regularly produce results that are syntactically valid but semantically wrong.
Practical version management at scale requires several things that tools alone don’t provide:
Baseline discipline. Models must be formally baselined at program milestones. A baseline is not a file save or a commit. It is a named, locked configuration that future changes are tracked against. Programs that don’t baseline rigorously find themselves unable to answer audit questions about what the model said at a given review.
Change request integration. Model changes on a large program should flow through the same change request process as hardware changes. A systems engineer who edits a model element to resolve a conflict without a corresponding change request has created an undocumented change. This is the same discipline required for document-based programs, applied to a new artifact type.
Dependency tracking. When element A changes, what elements depend on A? This question is tractable on a small model. On a large federated model, the dependency graph spans partitions, organizations, and tool boundaries. Answering it requires explicit interface management, not just model navigation.
SSE-PDR, SRR, and CDR Readiness in an MBSE Context
Design reviews in an MBSE context should be model-driven, not document-driven. The phrase is easy to say and operationally complicated to achieve.
System Requirements Review (SRR)
SRR readiness in an MBSE context means the model contains all system-level requirements, those requirements are traceable to stakeholder needs, and the coverage is verifiable. This is not a claim that can be made by walking through slides. It requires a live query of the model demonstrating that every requirement has an upward trace to a stakeholder need and a downward trace to at least a provisional allocation.
The common failure mode at SRR: requirements have been entered into the model but not structured — they sit as text blocks without formal relationships. The model exists but doesn’t demonstrate the traceability that justifies the MBSE investment.
Preliminary Design Review (PDR) — SSE-PDR Context
At PDR, the model must show that requirements are allocated to subsystems, interfaces between subsystems are defined and consistent, and the design architecture satisfies the requirements. In a federated architecture, this means subsystem models must be integrated for the review in a coherent state. Programs that haven’t solved their federation and authority problems discover it at PDR, which is an expensive place to discover it.
Critical Design Review (CDR)
CDR in an MBSE context requires the model to reflect the design as it will be built — not as it was planned at PDR. Requirements that have changed through the design phase must be updated in the model and re-traced. Verification methods must be allocated and current. The model must be the engineering record of the design, not a parallel artifact that was maintained through PDR and then stopped receiving updates.
The pattern of model neglect between PDR and CDR is endemic. The design team stops updating the model because the hardware design tools are the working environment. By CDR, the model is a historical artifact.
How Requirements Authority Interacts With the System Model
The core architectural challenge in a mature MBSE program is the relationship between the requirements layer and the model. These are not the same thing, and conflating them causes specific failure modes.
Requirements are contractual artifacts. They are owned, versioned, baselined, and changed through formal processes. They are the governing obligation for the system. The system model is an engineering artifact — a structured representation of how the system satisfies those requirements.
When requirements change — and on any real program, they change — the model must reflect those changes. This is the synchronization problem. On small programs, the same engineer who owns the requirements owns the model and keeps them aligned. On large programs, requirements management is often a separate function from model management, and the link between them is informal.
This informality is what kills MBSE implementations at scale. Requirements change in a requirements management tool. A change notice goes to the systems engineering lead. The model is updated — sometimes. Weeks later, a subsystem engineer queries the model for the current requirement value and gets a stale answer. The model has diverged from the governing requirements without any visible signal.
Flow Engineering as the Requirements Authority Layer
Flow Engineering approaches this problem from the requirements side rather than the model side. It functions as the requirements authority layer in an MBSE stack — the system of record for what the requirements actually are, which feeds, validates, and is traceable to the system model.
This distinction matters. In a traditional MBSE implementation, requirements often live in the model or in a separate requirements tool with a fragile OSLC or CSV-based link to the model. In either case, the requirements aren’t truly authoritative — they’re managed in a tool optimized for modeling, not for requirements governance.
Flow Engineering is built around graph-based requirements management, which maps naturally to the relational structure of an MBSE model. Requirements exist as nodes in a graph, with explicit typed relationships to stakeholder needs, to each other (derivation, allocation, decomposition), and to model elements. When a requirement changes, the graph structure makes the impact immediately visible: which derived requirements are affected, which model allocations need review, which verification methods need to be reconsidered.
For a federated MBSE program, Flow Engineering addresses the synchronization problem directly. The requirements authority layer sits outside the model partitions and governs all of them. Subsystem models pull their governing requirements from Flow Engineering. When a requirement changes in Flow Engineering, the change propagates through the graph with an explicit notification to the model owners who need to update their partitions. The model never silently diverges because the authority layer is separate from and senior to the model.
At review milestones — SRR, PDR, CDR — Flow Engineering provides the traceability evidence that model-based reviews require. Coverage queries run against the requirements graph, not the model, and the model is validated against that authoritative baseline. A CDR package built from Flow Engineering shows not just that traceability exists, but that the traceability is current: every requirement is traced to a model element that was last validated against the current requirement version.
Flow Engineering’s deliberate scope is requirements authority and traceability. It does not replace the system model or the modeling tools. It fills the gap that modeling tools leave: rigorous requirements governance that the model can be built against and validated against with confidence.
Practical Starting Points for Large Programs
If you are entering a large MBSE program or trying to recover one that has drifted, the leverage points are ordered:
First: define model authority before adding more engineers. Every person added to an unresolved authority structure adds to the divergence problem. Authority agreements should precede scale.
Second: separate the requirements layer from the model layer explicitly. Whether you use Flow Engineering or another tool, the requirements that govern the design should live in a system optimized for requirements governance — one with formal change control, baseline management, and impact analysis — not embedded in the model where they are difficult to extract and compare.
Third: establish baseline discipline at every milestone. Baselines are not bureaucratic overhead. They are the mechanism by which a program can answer audit questions and detect drift between the model and reality.
Fourth: plan for federation as the default. Centralized architectures fail at contractor boundaries. Design for federation from the beginning, with explicit interface definitions and synchronization processes, rather than retrofitting federation after the centralized approach has already encountered its limits.
Fifth: treat CDR model currency as a program risk. The interval between PDR and CDR is where MBSE implementations typically break down. If you are not actively tracking whether the model is being maintained through the design phase, it is not being maintained.
MBSE at scale is an organizational and governance discipline that happens to use modeling tools. The tools are necessary but not sufficient. The programs that succeed are the ones that treat model authority, synchronization, and requirements governance with the same rigor they apply to hardware configuration management — because the consequences of getting it wrong are the same.