Joint All-Domain Command and Control (JADC2) is the DoD's vision for connecting sensors and shooters across all warfighting domains — air, land, sea, space, and cyberspace — into an integrated, rapidly responsive command network. The technology challenge is formidable: disparate legacy systems, different classification levels, varied communication protocols, and the need for real-time decision support across domains that have historically operated in isolation.
The software architecture patterns that make JADC2 technically feasible are not exotic — they draw from the same distributed systems principles used in large-scale commercial platforms. What makes JADC2 unique is the operational environment: contested communications, classification boundary complexity, real-time latency requirements, and the consequence of failure.
This article covers the architectural patterns relevant to JADC2 software development — specifically the data mesh, API-first interoperability, and edge-cloud distribution models that are appearing across JADC2 programs.
The Core Technical Challenge: Interoperability Across Decades of Legacy
The DoD's sensor and effector inventory spans generations of technology — from legacy datalinks (Link 16, SADL) through modern IP-based communications to emerging software-defined radio systems. These systems were not designed to interoperate. They use different data formats, different communication protocols, different timing models, and different classification enclaves.
JADC2's software architecture challenge is fundamentally an integration challenge: how do you build a connected command network on top of systems that were never designed to talk to each other, without replacing everything (which is neither feasible nor desirable)?
The answer is a layered architecture that decouples the sensor/effector systems from the command network through standards-based interfaces.
Pattern 1: Data Mesh for Multi-Domain Data Integration
A data mesh architecture treats sensor data from each domain as a product, owned by the domain that produces it, accessible to authorized consumers through standardized interfaces.
Core data mesh principles for JADC2:
Domain ownership: Air domain data (aircraft positions, tracks, sensor readings) is owned and published by air domain systems. Land domain data is published by ground systems. Neither domain needs to understand the internal architecture of the other — only the published data contract.
Self-describing data products: Each domain publishes data with sufficient metadata to be discovered and consumed without out-of-band documentation. This is critical for JADC2 because new sensors and effectors are continuously added — a rigid catalog approach breaks with every new capability.
Federated governance: A central governance layer defines the data standards (formats, classification markings, metadata requirements), but does not centrally manage the data itself. Each domain system produces data that conforms to the standard; consumption is pull-based by authorized consumers.
Implementation pattern:
Domain A (Air) Domain B (Land) Domain C (Sea)
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Track Data │ │ Ground Intel │ │ Maritime TAC │
│ Published as │ │ Published as │ │ Published as │
│ STANAG 4559 │ │ NIIRS-coded │ │ LINK 22 + IP │
│ → Adapter │ │ → Adapter │ │ → Adapter │
└──────┬───────┘ └──────┬───────┘ └──────┬───────┘
│ │ │
▼ ▼ ▼
┌─────────────────────────────────────────────────────────────────┐
│ Data Mesh Fabric (Message Broker + Schema Registry) │
│ Kafka / NATS JetStream at cloud layer │
│ Tactical data links at edge layer │
└──────────────────────────────┬──────────────────────────────────┘
│
┌──────────▼──────────┐
│ Command & Control │
│ Applications │
│ (consume authorized │
│ domain feeds) │
└─────────────────────┘Schema registry and contract management: Every data product has a versioned schema registered in a central registry. Consumers bind to a specific schema version, and producers publish against it. Schema evolution follows backward-compatible patterns — new fields are optional; breaking changes create new schema versions with a migration period.
Pattern 2: API-First Interoperability
JADC2's component programs (ABMS, Project Convergence, Operation Blended Warrior) have been pushing toward API-first interfaces — where every system capability is accessible through a standardized API rather than point-to-point integration.
API-first implications for JADC2:
REST and MQTT coexistence: Request-response APIs (REST/HTTP) work for non-real-time queries (retrieve a track history, query available effectors). Pub/sub messaging (MQTT at the edge, Kafka at the cloud layer) handles real-time sensor data streams. A JADC2 platform that forces all interaction through REST will fail for real-time fire control timing; one that uses only pub/sub is difficult to query and orchestrate.
OpenAPI specification as the contract: Machine-readable API specifications (OpenAPI 3.x) enable automated client generation, contract testing, and policy enforcement. For JADC2 programs, the API specification IS the interoperability agreement between program teams — it replaces informal interface control documents with executable contracts.
Classification-aware API design: APIs in a multi-classification environment must enforce data-level access controls, not just API-level authentication. An authorized consumer at the Unclassified level should receive a response that includes only unclassified data, not an error or a filtered payload that reveals the existence of classified data. This is a subtle but critical distinction for JADC2 security architecture.
Pattern 3: Edge-Cloud Distribution
JADC2 operations happen at the edge — on aircraft, in vehicles, on ships, at forward operating bases — where connectivity to cloud infrastructure is intermittent or severely constrained. The architecture must function in degraded communications conditions.
Edge-cloud distribution model:
Cloud Layer (CONUS / OCONUS data centers):
- Full data lake (complete sensor history)
- AI/ML inference services
- Long-term planning and analysis
- Full-resolution sensor fusion
- Connected continuously
Gateway Layer (Theater HQ / Ship / Base):
- Mission-critical data subset
- Local sensor fusion
- Tactical decision support
- Synchronizes with cloud when connected
- Operates independently for hours/days
Edge Layer (Aircraft / Vehicle / Individual):
- Minimum data for current mission
- Direct sensor feeds
- Immediate fire control data
- Operates independently for mission durationData prioritization for sync: When connectivity is restored after a period of edge-only operation, data synchronization must be prioritized. Fire control events and intelligence reports sync first; administrative and logistics data sync later. Conflict resolution for data modified at both edge and cloud during the disconnected period requires CRDT (Conflict-free Replicated Data Type) patterns or application-level merge logic.
Software-defined at every layer: The data each tier holds, the capabilities it runs, and the synchronization priority are all configurable — not hardcoded. A mission profile change should reconfigure which data and services are pushed to the edge for that mission without requiring a software deployment.
Classification Boundary Handling
Perhaps the most challenging aspect of JADC2 software architecture is handling data across classification boundaries. Some sensor data is unclassified; some is Secret; some is SCI. Command applications need to correlate across classification levels without inadvertently exposing higher-classification data to lower-classification consumers.
Key patterns:
Cross-domain solutions (CDS): Hardware/software systems certified to pass data between classification domains under defined data filter rules. Software architecture must account for CDS latency (CDS filter rules introduce measurable delay) and the constraint that only data types approved for the CDS filter rule can cross.
Releasability tags: Every data object carries a releasability marking (CAPCO marking system) that is enforced at the API layer. The platform's policy enforcement point strips or blocks data based on the consumer's clearance level and need-to-know attributes.
Aggregation controls: Even if individual data items are releasable, aggregation may reveal sensitive information. Architecture must prevent queries that would allow inference attacks (e.g., "I can't see the classified track, but I can infer its position from the gaps in the unclassified track cordon").
Rutagon's Perspective
Rutagon designs distributed systems that operate at the intersection of real-time performance and compliance constraints — the same engineering environment that JADC2 programs demand. Production systems built on data mesh, API-first, and edge-cloud patterns at scale provide the architectural foundation for contributing to multi-domain integration programs.
Rutagon Defense Software Capabilities →
MLOps and AI in Classified Defense Cloud →
Frequently Asked Questions
What messaging systems are used in JADC2 architectures?
At the cloud and enterprise layer, Kafka is dominant for high-throughput event streaming — it provides durable, replay-capable message storage that supports multiple consumers and integrates well with cloud-native analytics pipelines. At the tactical edge, MQTT (lightweight pub/sub) and NATS JetStream are used where resource constraints limit Kafka's footprint. Proprietary military datalinks (Link 16, TTNT, CDL) remain in use for legacy platforms and are bridged to IP networks via gateway adapters.
How does JADC2 handle latency for time-critical applications?
Fire control and time-sensitive targeting applications require sub-100ms end-to-end latency from sensor detection to effector cue — far less than what typical cloud-based architectures provide. These applications run at the edge or gateway layer with local data. The cloud layer handles analytics, planning, and historical data — not real-time fire control. JADC2's architecture explicitly separates the latency tiers based on application requirements.
What role do AI/ML systems play in JADC2 software architecture?
AI/ML in JADC2 primarily supports sensor fusion (combining tracks from multiple sensor types into a unified common operating picture), anomaly detection (identifying unusual patterns in sensor data), and decision support (recommending effector assignments for detected threats). These systems run primarily at the gateway and cloud layers where full data access and compute resources are available. Edge AI (inference on constrained platforms) is an active area of JADC2 program investment.
How is identity and access management handled across JADC2 domains?
JADC2 programs are building toward attribute-based access control (ABAC) — where access to data is determined by the consumer's attributes (clearance level, coalition nationality, mission role, operational context) rather than just their identity. This enables dynamic, fine-grained access control that can adapt to multi-coalition operations where the same data may be releasable to U.S. and allied consumers but not others. Implementation relies on identity federation across domain authentication systems.
How does software development for JADC2 differ from standard cloud development?
JADC2 development combines the speed expectations of modern DevSecOps with the compliance requirements of classified defense programs. Software factories (DoD's term for automated CI/CD pipelines with hardened build environments) provide the development infrastructure. Iron Bank (DoD's hardened container image repository) provides base images. cATO (continuous ATO) processes allow software updates without full re-authorization if changes are within the defined ATO boundary. The engineering challenge is maintaining development velocity while producing the compliance artifacts these programs require.