The Department of Defense's Digital Engineering Strategy fundamentally changes how defense programs develop and maintain systems — and it creates specific new software engineering requirements that most cloud teams aren't positioned to handle. Programs adopting Model-Based Systems Engineering (MBSE) need software engineers who understand how digital models, data standards, and cloud infrastructure intersect.
This article covers what the software side of DoD's digital engineering mandate requires, and what prime contractors need from engineering subs working in MBSE-enabled programs.
What Digital Engineering Actually Changes
Traditional systems engineering relies on documents — specifications, interface control documents, design descriptions — that are developed, reviewed, and updated as separate artifacts. Documents become stale. Interfaces between documents aren't machine-readable. Traceability from requirements to implementation is maintained manually and breaks down quickly.
Digital engineering replaces documents with models. A system is described by a connected set of models — a System Model (SysML), performance models, simulation environments, test data — where data flows between models automatically and changes propagate through the digital thread.
For software engineers, this means:
- Source of truth for requirements is a SysML model, not a Word document
- Interface definitions come from the system model, not a manually maintained ICD
- Test data is linked back to the model and traced to requirements
- The deployed system's behavior can be validated against the authoritative model
The software engineering team needs to know how to consume model-derived data, generate model-compatible outputs, and integrate with MBSE toolchains.
The Digital Thread in Software Delivery
A digital thread is a connected flow of data across the program lifecycle — from requirements through design, implementation, test, and operations. In a fully realized digital thread:
- A requirement in the system model links to the software story/task that implements it
- The story links to the git commit and pull request that delivers it
- The pull request links to the test case that validates it
- The test result links back to the requirement and updates the model's verification status
Building this traceability into software delivery requires:
Requirements traceability tooling: Most DoD MBSE programs use tools like IBM DOORS, Cameo Systems Modeler, or Jama Connect for requirements management. Software engineers need to understand how to reference these requirements in commit messages and pull requests in a format the program's traceability tools can parse.
Bidirectional API integration with MBSE tools: Where the digital thread calls for automated traceability (rather than manual linking), software teams need to build integrations with the MBSE toolchain's APIs. Cameo, Rhapsody, and DOORS all expose REST or OSLC APIs for programmatic interaction.
Interface definition compliance: In programs using the Systems Modeling Language (SysML), software interfaces are derived from the system model's interface definitions. Software engineers need to validate their API implementations against the model-derived interface specifications — not against their own interpretation of a document.
Model validation in CI: Some programs require CI-level validation that software outputs conform to the system model's behavioral specifications. This requires integrating model simulation outputs or model-derived test vectors into the standard CI pipeline.
Software Engineering in an MBSE Program Context
Working on a program that uses MBSE requires software engineers to engage with the broader SE community in ways that pure software programs don't:
System model reviews: Software engineers participate in system model reviews — System Requirements Reviews (SRR), System Functional Review (SFR), Preliminary Design Review (PDR) — not as passive participants but as active contributors who identify software feasibility issues in the model before they become implementation problems.
Behavior conformance: Software implementations must conform to the system model's behavioral specifications. Where the model specifies a state machine, the software implements that state machine. Where the model specifies timing constraints, the software meets them. Deviations require formal Change Requests against the model.
Data product delivery: Digital engineering programs often specify "digital data products" as CDRLs — machine-readable artifacts in standard formats (SysML XMI, JSON-LD, OSLC) rather than traditional document deliverables. Software engineers need to produce these artifacts alongside working software.
Cloud Infrastructure for MBSE Toolchains
Many defense programs run MBSE toolchains in cloud environments — either commercial or GovCloud — rather than on-premises. Cloud infrastructure for MBSE programs has specific requirements:
High-memory compute: MBSE tools like Cameo and Rhapsody are memory-intensive. Instance sizing for MBSE workloads is typically higher than standard application hosting — 32–64GB RAM instances are common for team-scale model environments.
Persistent storage with access controls: Model files are large, binary (in many cases), and require access control at the file level. S3 with IAM permissions and versioning is the standard approach for model artifact storage in AWS environments.
Integration with program security architecture: MBSE toolchain infrastructure needs to meet the program's IL requirements and participate in the program's ATO boundary. A standalone MBSE server outside the ATO boundary isn't acceptable for programs with classified or CUI model data.
Learn how Rutagon integrates with MBSE programs →
Frequently Asked Questions
What is the DoD Digital Engineering Strategy and how does it affect software programs?
DoD's Digital Engineering Strategy (2018) mandates that programs use authoritative digital system models as the source of truth, replacing document-centric approaches. For software teams, this means consuming requirements from system models rather than Word documents, maintaining digital thread traceability, and producing model-compatible data products as deliverables.
What is MBSE and why do software engineers need to understand it?
Model-Based Systems Engineering (MBSE) is the practice of describing systems using formal models (typically SysML) rather than documents. Software engineers on MBSE programs need to understand how to derive implementation requirements from the model, trace their work back to model elements, and produce artifacts that integrate with the program's digital thread.
What MBSE toolchains do DoD programs commonly use?
IBM DOORS and DOORS Next Generation for requirements management; Cameo Systems Modeler (MagicDraw) and IBM Rhapsody for SysML modeling; Jama Connect and PTC Windchill for integrated PLM/requirements management. Programs vary widely. Software engineers need to be able to integrate with whichever toolchain the program uses rather than requiring a specific tool.
Does digital engineering change the ATO process?
Digital engineering affects ATO documentation by creating machine-readable sources for system configuration and requirements traceability. Programs using MBSE can potentially generate portions of their SSP and traceability matrix from model data rather than manual documentation. This is an emerging area — most programs still bridge between MBSE artifacts and traditional ATO documentation formats.
What cloud infrastructure considerations are specific to MBSE programs?
MBSE toolchains have higher compute and memory requirements than standard application hosting. Model data is sensitive and needs appropriate access controls and ATO coverage. Integration with the digital thread often requires API connectivity between cloud-hosted toolchains and external program systems, which needs to be scoped into the security architecture.