We previously wrote that the Joint All-Domain Command and Control (JADC2) is perhaps the most important program in DoD today. The Air Force plays a particularly important role in developing the JADC2 concept.  They have been designated as the Executive Agent.  That means they will have major input into how the framework is shaped.  Their work will influence every sensor, shooter and network advance the Department of Defense puts forward for the next decade.

Air Force’s Advanced Battle Management System (ABMS) is the architecture approach they are using to flush out the JADC2 concept.  Through a carefully structured series of events, they are developing the standards that will enable current and future weapon systems and networks to migrate to a JADC2/Joint All Domain Operations environment.

Careful examination of this might not look like anything new.  But the big take away is this:  the JADC2/ABMS architecture approach acknowledges, up front, that you can never really define the requirements in advance.  Existing warfighting capabilities have always started with a rigorous requirements definition phase.  That’s how DoD ensures that taxpayers get their money’s worth and weapons systems are only built to fill warfighting needs.  These requirements are flushed out throughout the chain of command, so the most important need is funded first.

The problem with that approach becomes evident when you see how rapidly things are changing.  We are moving from a world of stand-alone point-to-point capabilities to one where every sensor is connected, sensors are everywhere, mountains of data is collected, and analyzing this data to make a decision is overwhelming. Add to the mix a new host of new unmanned systems, operating either individually or in swarms, and you see how the “requirements up front” model breaks down.  What we need tomorrow could be fundamentally different from what we can envision today.

The ABMS architecture is focused on creating a framework that can flex with the times.  JADC2 must be able to rapidly provide data and pass information across all domains. The ABMS approach starts with defining the standards, then integrating the sensors, creating cloud-data enclaves to enable a secure processing environment, and establishing connectivity pathways for sensors and shooters.  Notice that this approach doesn’t depend on any one system/program of record.  It’s intentionally developmental and agile, so future capabilities can be quickly added, and retired systems can be removed without impact on the overall design.

It was the Air Force, after all, that sold us on the JADC2 concept.  They fought for improvements that would enable commanders to quickly understand the battlespace, assign military forces – faster than the enemy can, and deliver integrated fires in a synchronized military campaign across all domains.  That’s not something we can easily do right now.  JADC2 will move from concept to policy, doctrine, requirements and inform an overarching research and development strategy.  They have three primary lines of effort to accomplish this:

1. Overall concept of operations (Led by Air Force Warfighting Integration Capability – AFWIC)
2. Systems needed to enable the CONOPS (Let by Air Force Chief Architect)
3. People trained to operate the systems and execute the CONOPS (Led by AFWIC)

Currently, Air Force is performing technology demonstrations to test out competing ideas. These include a series of experiments to identify operational concepts and technologies that work.  And because it’s the Air Force, they use some cute terminology to identify pieces aligned under ABMS.  They all end in “ONE” – to signify the importance of pulling everything together.

Software is being done using DevSecOps and includes several modern software development initiatives.  JADC2 will require a cloud-based architecture with agile software development and government managed platforms.   Done right, it will fix lots of existing problems, and give DoD the ability to actually practice “zero-trust” and continuous monitoring/response.  The goal is to create a self-healing environment that can quickly patch and update software across all domains in hours, instead of years.  Kessel Run, an early example, was developed to deliver combat capabilities using this new software culture.  LevelUP is an Air Force software factory used to develop their PlatformONE.  Kobayashi Maru is their version looking for space C2 capabilities.  BESPIN is the Air Force DevSecOps organization for their enterprise system capabilities.

Cloud solutions are essential considering the amount of data and the vast terrain of the distributed domain.  This could save DoD a ton of money as programs and systems share the costs.  It will also accelerate integration and data sharing. Current cloud efforts are:

• cloudONE
• edgeONE
• crossdomainONE
• deviceONE
• assistONE

Network will pull much from the Navy’s contributions with their Navy Tactical Grid.  Pieces include:

• gatewayONE
• radioONE
• meshONE
• apertureONE
• commercialONE
• nationalONE

Data standards and architectures are looking at:

• feedONE
• wrapONE
• dataONE

Artificial intelligence is the magic that makes all this so important to DoD.  Some of the AI groups include:

• smartONE
• fuseONE
• omniaONE
• commandONE

This Air Force pictorial helps you visualize what they have in mind.   (No one does Power Point better than the Air Force!)

Don’t forget this one important fact:  JADC2 and ABMS are NOT programs of record.  You’ll never see an RFI or Industry Day or Budget Line associated with buying JADC2 or ABMS.  They are frameworks and structures and concepts that will drive experimentation and demonstrations and will inform current and future weapon systems and sensor networks to ensure that all sensors can connect to all shooters and that key information can be processed and rapidly analyzed and passed to where it needs to be.  All services will either “adopt” this framework or “adapt” their framework to it.  It’s a completely new approach to development.