Software-defined tactics are the key to quickly adding capabilities to different assets that are supposed to work together. It’s kill chain vs kill web for acquisitions.
In the kill chain – you devise a new weapon for a shooter, then figure out the sensor you need for the ISR node, then you figure out the network that makes the most sense for data transmission, then you write the messages you’ll send from sensor to shooter. After that, you have to try to sequence all the capabilities so that they arrive roughly at the same time.
Then when you add a sensor or a weapon, you have to teach the sensor asset what the new weapon brings to the table, or vice versa, and how they can maximize it. It’s hard for a community to get good at operating their own new sensors or weapons. It’s harder to get good at helping another community employ their capabilities.
All of that adds so much time to acquiring and fielding new capabilities, so you end up buying weapons and sensors much slower than the pace of what is technologically possible.
In the kill web – you buy whatever improves your capability as a sensor or a shooter. Period. If there isn’t a perfect network to transmit information right away, it’s okay. Just write a software-defined tactics application that can leverage information from a basic data-link, has some basic modeling assumptions, and can give the task force a good, ad hoc plan that gets to a local maximum solution. The force can figure out the absolute best way to work together as they experiment, we just need an acceptable way to work together that can get the ball rolling.
We actually just did this for a new sensor/weapon combination in less than 20 hours of software development. The application we fielded solved the entire coordination problem for a completely new concept and optimized the sensor/shooter team. It lets the sensor act as a cloud processing node for the team, even if the human in the sensor aircraft isn’t really an expert in what the shooter brings to the table.
This process means the limiting factor in technology adoption is not the acquisitions process as is typical, but the actual science.
That was Lt Sean Lavelle in a nice interview with Robbin Laird, “The Maritime Patrol Reconnaissance and Man Machine Teaming.” See more from Lt Lavelle, including on software defined tactices, in my podcast with him. Here’s a bit more:
“The ideal acquisitions process is to conduct operations, learn from those operations and then decide what we want to buy based on that experience. The paradigm that the FAR forces us into doesn’t always lend itself to that sort of iterative, learning-oriented acquisitions process.”
“Rather than trying to fix the entire contracting process, we are focused on finding ways to in-house talent to get more rapid software upgrades driven by operational experience.
“We want a tighter coupling of operations and software development than is really possible with current acquisitions regulations.”
The FAR isn’t the problem. It’s the risk averse application of the FAR and the lack of understanding of how to apply it in a way that meets mission need and rapid technology shifts/prototyping. Same issue with Other Transactions. People avoid risk at all cost and don’t understand the application and flexibility that OT authority allows. They write an OT agreement that mirrors the clauses and length of FAR contracts. That is how people are trained. So, risk aversion, training, and a lack of updated and current business acumen focused on rapidly changing technology are the problems. Everything else is a symptom.
I tend to agree, but one issue is that there’s simply so much to know with the FAR, statute, executive orders, implementation guides, and so forth, that its a huge web of information. It’s hard to expect people to know all of that, and so risk aversion is built in because they might fear what they do not know, and that could come back to bite them.