Defense organizations use Sparx EA as their primary MBSE and enterprise architecture platform for capability planning, acquisition program architecture, and systems integration. DoDAF and SysML are the dominant frameworks; both are natively supported in a single repository with cross-view traceability. AI integration in defense requires data residency controls: typically Azure Government Cloud (FedRAMP High / IL4/IL5) or on-premises deployment for classified environments. The repository governance challenge in defense is unique: large models accumulated across multiple contractor contributions with inconsistent MDG governance and no single baseline.
Key Takeaways
Defense capability planning in Sparx EA centers on the DoDAF Capability Viewpoint: specifically CV-1 (Vision), CV-2 (Capability Taxonomy), CV-3 (Capability Phasing), CV-4 (Capability Dependencies), and CV-6 (Capability to Operational Activities Mapping).
The capability hierarchy defines what the force needs to do, organized from strategic capability through operational capability to system capability. Sparx EA maintains this hierarchy as a structured element tree with relationship types that enforce the logical dependency between levels. Capability gap analysis connects the operational need (what the force currently cannot do adequately) to the system requirement (what the program must deliver), creating the traceability chain that DAU and program offices require.
Capability phasing (CV-3) in Sparx EA supports the phased delivery structure typical of Major Defense Acquisition Programs (MDAPs): increments, blocks, and spirals each mapped to the capability they deliver, with dependency tracking across increments.
DoDAF for Operational and System Views: DoDAF Operational Viewpoint models (OV-1 through OV-6) capture the operational context: nodes, activities, information exchanges, and operational rules that define the environment the system must operate in. System Viewpoint models (SV-1 through SV-11) define the system itself: interfaces, functions, data exchanges, performance parameters, and the technology standards the system implements (connecting to StdV-1 and StdV-2).
SysML for System Specification: SysML Block Definition Diagrams (BDDs) and Internal Block Diagrams (IBDs) provide the engineering precision that DoDAF system views lack. In defense acquisition, SysML is used for system decomposition (the physical and logical architecture), interface definition (flow ports, connectors, item flows), behavioral specification (sequence diagrams, state machines, activity diagrams), and parametric modeling for performance and constraint analysis.
Cross-Framework Traceability: The critical practice value is traceability across both frameworks in a single repository. A stakeholder requirement traces to an operational activity (OV-5b), which traces to a system function (SV-4), which traces to a SysML block and its interface definitions (IBD), which traces to a test case and verification event. This chain: maintained in the Sparx EA repository: is what milestone reviewers and DCMA want to see, and it’s what contractor-fragmented repositories typically fail to provide.
Interface Control Documents (ICDs) are a contractual deliverable in defense programs. Generating them manually from SysML models is labor-intensive and error-prone: changes in the model don’t automatically propagate to the document. Sparx EA’s document generation capability, configured against SysML IBDs, produces ICDs directly from the authoritative model. When the interface definition changes in the model, the ICD regenerates. This is a standard practice capability, not an advanced feature: but it requires clean MDG governance and consistent IBD modeling conventions, which is where most programs fall short.
Systems integration architecture in Sparx EA uses SysML IBDs for interface definition between subsystems and DoDAF OV models for operational dependency documentation. The combination supports both the engineering view (what signals/data/power cross which interface, at what rate, in what format) and the operational view (which nodes depend on which other nodes for what operational activities). Configuration baseline management: identifying the authoritative version of the model that corresponds to a program baseline: is handled through Sparx EA’s baseline and version management capabilities combined with Pro Cloud Server’s access control.
CMMC (Cybersecurity Maturity Model Certification) Level 2 and Level 3 govern the handling of Controlled Unclassified Information (CUI) in the defense industrial base. EA repository content for defense programs routinely contains CUI: system specifications, capability descriptions, interface definitions, technology architectures for weapons and national security systems. This content cannot be transmitted to commercial cloud AI APIs without violating CMMC and potentially ITAR.
This is not a theoretical concern. Connecting a defense EA repository directly to OpenAI’s API, Anthropic’s API, or any other commercial AI service without a data processing agreement and FedRAMP High authorization is a compliance violation. The MDG data quality work that precedes AI integration must account for CUI classification of repository content as its first step.
Azure Government Cloud (azure.us) operates under FedRAMP High authorization. Azure OpenAI Service is available within Azure Government, making it the standard compliant path for cloud AI integration with defense EA repositories. The specific impact level (IL4 vs. IL5) depends on the classification of the data and the agency’s authorization decisions: IL5 covers DoD CUI requiring higher protection.
An EA GraphLink deployment in a defense context routes through the agency’s or contractor’s Azure Government tenant. The EA repository data: transformed by MDG Technology into AI-queryable structured data: is processed within the authorization boundary. This requires an existing Azure Government tenancy with appropriate authorizations, which is one of the first questions in a Discover assessment.
For classified networks, JWICS-adjacent programs, and truly air-gapped environments, cloud AI is not an option. Sparx EA’s AI Modeling Workbench supports configuration with locally deployed open-weight models: Llama variants, Mistral variants, and other open-weight models that can be deployed within the classified enclave without any data leaving the network boundary.
Performance is lower than frontier commercial models, but the most valuable use cases in classified defense programs: requirements traceability queries, model consistency checks, view completeness verification, documentation generation from model content: are within the capability of current local models at quantized deployment weights.
A defense-scoped Discover engagement assesses:
Defense programs accumulate large repositories across multiple contractor contributions: prime, subcontractors, subcontractor-of-subcontractors, government program office models: each with its own modeling conventions. MDG inconsistency across contractor contributions is the norm in every defense program we’ve assessed. It is the primary blocker for both AI integration and effective architecture analysis.
The common failure points: stereotype profiles applied inconsistently, relationship types used with different semantics by different contributors, element naming conventions that vary by contractor team, tagged values defined but not populated, and SysML block hierarchies that don’t align to the DoDAF capability hierarchy. The practical result is a repository that looks populated but cannot answer the questions it’s supposed to answer.
Establishing MDG consistency across a multi-contractor program requires a governance framework with teeth: defined profiles, mandatory tagged values, modeling conventions documented in the repository’s governing standards, and validation scripts that run against model submissions before they’re merged into the baseline. Amplify addresses this as a practice capability development engagement.
Sparx EA’s baseline capability allows a named snapshot of a model package to be created and preserved without branching the live repository. This supports configuration control: associating a baseline label (e.g., “Milestone B Baseline, March 2025”) with the specific model state at a point in time. Combined with Pro Cloud Server’s audit logging, this provides the configuration history that program offices and DCMA require.
Pro Cloud Server supports role-based access control with Active Directory/SSO integration. This is essential for multi-contractor programs where different teams need different levels of repository access: read-only for some subcontractors, write access scoped to specific packages for others, and administrator access restricted to the program office configuration manager. Access control architecture is part of a Deploy engagement for defense programs.
Does Sparx EA support DoDAF 2.0 out of the box?
Yes. Sparx EA includes built-in DoDAF 2.0 support with the full viewpoint suite: AV, OV, SV, SvcV, DIV, StdV, PV, and CV viewpoints. The DoDAF MDG profile defines the stereotypes, tagged values, and diagram types required for each view. Programs requiring customization (additional tagged values for program-specific metadata, custom diagram templates for deliverable formats) can extend the built-in profile through MDG Technology configuration.
Can I use SysML and DoDAF in the same Sparx EA repository?
Yes, and this is the standard practice for defense acquisition programs. DoDAF views and SysML models coexist in the same repository with direct traceability relationships between them: a DoDAF SV-4 system function can trace to a SysML activity, a DoDAF OV-2 operational node to a SysML block. This cross-framework traceability is the primary repository governance challenge in multi-contractor programs, and it’s what Sparx EA’s unified repository architecture is specifically designed to support.
What AI tools are approved for use with EA repositories in defense contexts?
The compliance answer: Azure OpenAI Service on Azure Government Cloud (FedRAMP High, IL4/IL5) for repositories containing CUI. On-premises locally deployed models for classified environments. No commercial AI APIs without a data processing agreement, FedRAMP High authorization, and CMMC compliance review. The practical answer: Sparx Services designs EA GraphLink implementations against the specific compliance boundary of the program: there is no one-size-fits-all answer.
How does CMMC affect my Sparx EA AI integration plans?
CMMC Level 2 (aligned to NIST SP 800-171) requires that CUI be protected in transit and at rest, with access controls and audit logging. AI integration that sends EA repository data to an external API is a CUI transmission event: it must be to a FedRAMP High authorized endpoint with appropriate data processing agreements. CMMC Level 3 (aligned to NIST SP 800-172) adds additional requirements for high-priority CUI programs. Discover assesses your specific compliance status and maps it to AI integration options.
Can Sparx EA generate Interface Control Documents from SysML models?
Yes. Sparx EA’s document generation framework (RTF/DOCX templates) can be configured to generate ICDs directly from SysML IBD content: interface definitions, port specifications, item flow data, and associated constraints. The key requirements are consistent IBD modeling conventions across the repository (MDG governance) and an ICD template aligned to the program’s contractual format. A clean MDG baseline is the prerequisite.
How do I manage baseline configurations in a defense Sparx EA repository?
Sparx EA’s built-in baseline capability creates named point-in-time snapshots of model packages. For program milestone management, baselines are created at each milestone event and labeled with the milestone identifier. Pro Cloud Server’s audit logging tracks all changes between baselines. For programs requiring formal configuration management integrated with external CM tools, Sparx EA’s API supports integration with CM systems. This architecture is designed and implemented as part of a Deploy engagement.
What Sparx EA deployment options work in classified or restricted environments?
Sparx EA Pro Cloud Server can be deployed entirely on-premises or within a classified network enclave. The database tier (SQL Server, Oracle, or PostgreSQL) runs within the enclave; the Pro Cloud Server application runs within the enclave; clients access via the internal network. No internet connectivity is required. AI integration in this configuration uses locally deployed open-weight models running within the same enclave. Sparx EA licensing in these environments requires an offline license mechanism: Sparx Services coordinates this with Sparx Systems.
How do I maintain MDG consistency across contractor-contributed models?
The governance framework required: a documented MDG profile standard that all contractors must follow (not just a reference: a contractual requirement), validation tooling that runs automated consistency checks against model submissions, a designated configuration management authority in the program office who reviews model merges, and a defined process for handling deviations. Amplify builds this practice capability within the program team. Discover scopes the baseline gap before that work begins.
Defense architecture programs require architects who understand DoDAF, SysML, CMMC, and the contractor-contribution governance problem from direct program experience.
Platform Support: Ongoing Sparx EA technical expertise for defense programs: DoDAF/SysML configuration, MDG governance, Pro Cloud Server deployment, and AI integration within your compliance boundary.
Discover ($25K–$75K): MDG readiness assessment, CUI classification audit, AI integration feasibility scoped to your program’s compliance requirements.
Contact Sparx Services → | DoDAF Practice Guide → | SysML Practice Guide → | Azure OpenAI Integration Guide →
Talk to a Sparx Services architect about where your organization is on the journey and what the next stage looks like.