2017-10-09 By Robbin Laird
With the cross learning among the combat forces as they shape more effective integrated combat forces to prevail in a contested environment, the business rules need to change to adapt platforms more rapidly to evolving combat requirements.
The force will be built around core multi-mission platforms, which are software upgradeable.
The challenge will be to ensure that those platforms are more rapidly upgraded and modernized.
The answer is large part to shape business rules that allow the combat users to work directly with the software code writers to provide for what the RAAF refers to as gaining software transient advantage.
The legacy requirements setting process in DoD needs to be replaced by a new set of business rules which allow for such cross development and modernization.
Put bluntly, DoD is not in the software age even though several of their cutting edge platforms are.
Let me be even more blunt: our own business rules guarantee that we will not take full advantage of the software upgradeable platforms we are ALREADY buying.
And to be even blunter, our own overly bureaucratic and multiple layered testing and requirements community will guarantee that we will sub optimize the performance and success of our combat force.
To take one case, the new Triton unmanned aircraft is a cutting edge capability which the US and Australia are about to deploy in the maritime domain awareness kill web mission area.
The impact of the Triton will change the approach to maritime domain awareness and strike.
As one senior Canadian ASW officer put it with regard to the coming of UAVs to the maritime strike space:
“Is the next approach to park UAVs to monitor a wide, wide area and your manned platform becomes a sonobuoy carrier where it goes and lays barriers and then it leaves? Does the manned platform become the shooter in a broad UAV enabled sensor grid?”
Put bluntly, the Triton is part of game changing technology.
It is carrying significant F-35 technologies onboard and is of course compete software upgradeable. But because of the way DoD sets and managed requirements, the dynamic adaptive capability of a flexible software system which can provide for transient software advantage will be undercut from its full performance by the antiquated requirements setting process.
This is not about technology – it is about the business rules governing the management of upgrades. It is a horse and buggy approach to managing 21st century assets.
The core issue is that as the services shift more towards core platforms which ARE software upgradeable, the challenge to upgrade becomes more significant.
With regard to a system like Triton something more flexible like the SOF acquisition approach but applied to core platforms needs to emerge.
In the Triton case, the Navy could have easily spent several years more fixing the software gripes for the platform about to be deployed. But then it would not be deployed and the user feedback, which is central to development, would not become determinate in further development.
This created a problem even in terms of how to describe the nature of the first deployment – it is not really an IOC deployment but what to call it. We could call it early operational deployment but that would send the wrong signal but really how do we best describe what we are doing and what we need to do to modernize a software upgradeable platform?
160113-N-AT895-251 PATUXENT RIVER Md. (Jan. 13, 2016) Chief of Naval Operations (CNO) Adm. John Richardson views the MQ-4C Triton unmanned aircraft system at Naval Air Station Patuxent River. Richardson also held an all-hands call, toured facilities and viewed aircraft and systems including the E-2D Advanced Hawkeye and F-35C Lightning II carrier variant joint strike fighter . (U.S. Navy photo by Mass Communication Specialist 1st Class Nathan Laird/Released)
According to one source: “If you use the term early deployment it would suggest that you are cutting something short from what you originally started out to do and that is not the case.
“If you go back to the milestones set in the 2007-2008 time frame and the requirements set at the time, we are delivering virtually everything.
“We are delivering on the ESM, the EO/IR, the AIS, the basic sensor suite, the performance of the air vehicle and how we manage the data – we are meeting these baseline capabilities but not fully in how we will do as the software and its integration evolves.”
They are calling it EOC for early operational capability in spite of the problems with such a label.
“You have something that’s real, that can be operated and provides value to your customer.
“The notion of continuing to fine tune the software without operational experience makes no freaking sense.”
And where they want to go cannot be easily funded in terms of the current acquisition approach. They would like to in effect isolate the flight system from the sensor systems so that they can more easily upgrade the sensor suites with cards and chips as required.
“For me, an ability to pace the threat, you don’t need to worry about the flight side of the software so much.
“You worry about the mission side of it.
“And so, what we’ve figured out how to do is segregate the two we can have a much more rapid insertion of software on the mission systems side which is what needs to evolve with the threat.”
Another source highlighted the core business rule problem: “The challenge is that today the funding cycle needs long lead times to request a specific upgrade, and that makes no sense given the evolution of software itself.
“We don’t fund appropriate to software upgradeable aircraft.
“With today’s system I have a onesie-twosie approach. For example, I want a weather radar so I request 30 million dollars to do a weather radar. In need to provide an issue sheet four years in advance so that I can start working on getting weather radar. That clearly makes no sense if you want to keep pace with the threat with a software upgradeable program.
“You have to have the money in hand so that you can react and immediately and to go the contractor and say, here is 10 million dollars and modify the software to give me this new capability.
“Unless you have the money in hand, you will not be able to fund software upgradeability in a way that makes any sense given the evolving operational experience which is informing the upgrade effort itself.”
A presentation earlier this year by the head of Air Force Materiel Command hit this issue head on.
We have to change the way we think about requirements definition if we’re going to really adopt Agile Software Development.
“Maybe the answer isn’t this detailed requirements’ slow down.”
“By the way, once you put it in the hands of the operator maybe some of those requirements you had in the beginning, maybe they don’t make any sense anymore because the operator sees how they can actually use this and they change it.”
She went on to highlight what the Aussies are doing in Willliamtown with Wedgetail without mentioning them at all.
“You need to put the coder and the user together…
“We have to empower at the right level, and that has to be at the level of the person that’s going to use the software, and we have to stop thinking about independent OT.”
Also in play is another business rule change – getting rid of needless competition.
Competition is certainly a good thing except when it is simply an excuse to provide the force with the kind of equipment which can allow it prevail in a contested environment.
With regard to modernization built upon software upgradeability, once the key platform is chosen and the prime has been selected, the users are now working with a core software development team throughout the life of that program.
As General Ellen Pawlikowski, Commander of Air Force Materiel Command, put it in her presentation:
“The teams are there for life.
“I don’t mean that it’s one person, but we don’t think about putting a team together to do the development and then push them out the door.
“That team stays with that system forever…
“We need to make the user the operational user and acceptance authority.
“Perhaps we need to shift to more use of time and materials contracts to support such teams.”
In the case of one core Naval program, the prime owns the software developed for and with the Navy, the prime has developed middleware and the evolution of new specific capabilities are driven by work in a lab developing apps for this combat program. And in that lab a majority of the companies present are not the prime and are populated by several types of companies, notably smaller ones.
Shifting the business rules is what is required not pining for some kind of abstract and mythical third offset.
One way to conceptualize the shift is simply to ask what business rules need to be put in place to allow this to happen?
The RAF officer in charge of the ISTAR force described this shift to strategic acquisition leadership as opposed to hierarchical assurance of slow mo software upgrades as follows:
“We have the iPhone 6 generation in the Force now, yesterday’s analogue approach to our business is no longer appropriate.
“With the aperture fully open, the individual platforms and capabilities become the apps that enable the integrated Force ‘iPhone’.
“Thinking of it in this way, will allow us to tap this new generation of warriors.”
He also seeks to build a sense of strategic purpose and community from bottom to top.
He cited the example of when President Johnson met a janitor at the NASA space center in Houston and when asked what he was doing, the janitor replied: “I am helping put a man on the moon, Mr. President.”
“We are driving to a similar mindset in the ISTAR Force – everyone contributing regardless of where they work.”
He argued that this perspective was essential to mission success.
“The paradigm shift needs to be cultural and organizational if the ISTAR force with a large F to become a reality.
“We are going from a tradition where we have operated isolated force elements to one where an integrated force can deliver 24/7 support and we need to shape a Whole Force solution approach.”
Getting it right for ISTAR is critical to the success of the RAF’s contributions to operations and to the UK’s intelligence and understanding of the world.
The Air Commodore concluded:
“One cannot simply pause, and recapitalize the force in a vacuous power point exercise.
“It is about transformation ‘in contact’ and ensuring that we leverage maximum integrated capability from the new platforms coming to the RAF, while re-brigading the legacy systems as best we can and putting in place the foundations required for an adaptable, upgradeable and technology driven capital F force in the 2025 time frame and beyond.”