Army to Revamp, Simplify Mobile Command Posts
They comprise a mishmash of different operating systems and applications, most of which require their own monitors or servers. There is little interoperability. A small cadre of field service representatives — civilian contractors — have to stand by to ensure that everything runs smoothly, or worse fly halfway around the world just to install updates.
“We have an enormous amount of systems that fit into an Army command post. ... a huge amount of systems, resources and people that go in to setting them up and operating them,” said Phillip Minor, deputy director for the common operating environment at the office of the assistant secretary of the Army acquisition logistics and technology.
The Army now has a goal to revamp and simplify the posts by 2019 called the command post computing environment project, Minor said at the Milcom conference in Baltimore. That will require changing a system that has somewhere near 30 different computing systems for 30 different applications managed by about five different program managers.
To tackle this problem, the Army is in the beginning stages of radically changing the way it acquires, maintains and uses information technology and software. Part of this effort is creating the “common operating environment,” a streamlined and simplified software backbone that every application will ride on, Minor said.
The common operating environment will be interoperable, but divided into three categories: mobile handheld for dismounted troops, mounted for vehicles and aircraft and command posts. Each category will have its own program manager.
“If I develop IT for a dismounted soldier, I have different considerations than I would if I’m developing IT for a major command center,” Minor said.
The command posts are a ripe target for the Army to radically alter, other leaders said at the conference.
“It’s as if every time you bought software at Best Buy, you bought a separate computer to go with it,” said Mike McCaffery, chief of tactical applications at the Department of the Army, G-8.
For a decade during the two wars, money was no object. If a new application could help save lives, it was purchased and integrated into the command post. Contractors were flown to remote spots to install all the equipment. Soldiers were taken away from their regular duties to sit in classrooms for 40 to 80 hours to learn to operate the new systems, McCaffery said.
“We want to get away from that. We have to get away from that. And the common operating environment is the way to do that,” he added.
The Army is going to completely change the way it creates the requirements, funds, develops and tests software, Minor said.
Currently, the service uses the same acquisition processes to procure software as it does a landmine or tank, McCaffery said. Information technology changes in six months to a year — or even sooner, he said, but the current acquisition processes take about seven years. First Training and Doctrine Command must write the requirements. Then the G-8 budget personnel such as himself have to secure the funding. After the software is developed, it is tested for two years.
The rapid acquisition of life-saving software for the Afghanistan and Iraq wars showed that this timeline can be drastically reduced. However, the systems delivered were proprietary software and stovepiped, he said.
“It’s effective but not optimal,” he said.
The first step toward a new command post that is streamlined and easier to set up, operate and tear down, is creating standards for the software. Just like Microsoft or Apple operating systems, it will have basic functions like chat, maps and email. Current systems must reinvent all these simple tasks for each new application. Every three years there will be a new standards release and a test of the infrastructure to make sure the Army stays current with industry, McCaffery said.
The intelligence community has a council of chief information officers that reviews the standards that it will bake into the next software iteration and builds, tests, and releases it, he said. The Army may model its new process similarly.
As for requirements, TRADOC is on board with a new way to write the necessary documents, called “IT Box.” Once a need for a new application is identified, the command will get to work and produce the requirements rapidly, Minor said.
As for funding, McCaffery said the project has support on Capitol Hill, and the money to implement the new system is secured. If the Army can make a case that it is spending a nickel to save a quarter, that resonates with lawmakers today.
“The money is there. And in this environment, that is no small feat. This is something that is gaining momentum,” he said.
Once a requirement is created, it will be posted on FedBizOpps, and vendors can respond.
Since all the applications will be used on the common operating environment using established standards, development time should be shortened drastically, he said.
As will the testing, said John Sellner, technical standards team lead at the Army CIO/G-6.
“Testing will no longer be the long pole in the tent in this process,” he said.
Program managers already go through several rounds of testing as the application is developed, and because they are using the same standards, the final tests should not take as long as they have in the past. Sellner said it could take about a week to put a new application through the wringer.
“As long as the testing is done properly at the [program manager] and [computing environment] levels, we believe that this process will be extremely quick,” Sellner said. “We have worked with the test-and-evaluation community to make sure these timelines are feasible.”
McCaffery said this streamlined approach “will remove a lot of the barriers for industry to come in and develop software for the Army.”
This new way of doing business is common in the commercial industry today, he said. Operating systems are standardized and refreshed periodically. Users pick and choose what they need.
“A fires guy needs different kinds of software than the logistician. But he doesn’t need a complete system that does fire. He just needs his unique fire functionalities. Why can’t we give him his fire functionalities on a common platform?” Minor asked.
The standards will allow more interoperability with systems coordinating with each other.
Do we really have to have a distinct database for each system? Minor asked. “Can I build a database that supports all of my users in the command post?”
Updates will also be done over the secure networks. That will reduce the number of field service representatives.
“Sometimes we have more field service reps than we have soldiers on the ground. It’s a problem,” McCaffery said. Personnel going to Iraq took days or a week to download all of the security patches that have built up over time. “We can’t do that anymore,” he added.
“This is nothing new. This is nothing unusual. We’re just trying to catch up with the civilian market,” McCaffery said.
Yet Minor said implementing the common operating environment may not come easily.
“It’s an enormous cultural challenge for the Army… It’s significantly different than the way we develop software today and how we developed it in the past,” he said.
Industry representatives listening in on the presentation at Milcom asked panelists who would be creating and maintaining the common operating environment. They expressed skepticism that the Army could do it alone and do away with the contractors who must co-locate with soldiers.
Maintenance and software updates will be handled by program managers and program executive officers, McCaffrey said.
Minor said, as always, it will still be a partnership between industry and the military. But he has already met with vendors who are eager to build the common operating environment. Their ideas had “caveats,” he said.
“We didn’t want to be locked into a vendor for the command post common foundation,” he said.
Stephen Kreider, program executive officer for intelligence, electronic warfare and sensors, indicated at a separate panel that the Army will be bringing more of these functions in house.
“We’re getting the Army and the soldiers back to managing and owning their own system as opposed to turning over their shoulder and saying, ‘I need the [field service representative] support,’” he said.
He pointed to the Army’s recent effort to streamline and simplify the distributed common ground system, an intelligence processing system fed by some 700 different sensors.
It cost the Army about $250 million per year just to update the software, and about all of it was done through contractor support.
“We can’t afford that in the construct going forward,” he added.
By having Army personnel do more of these tasks, the service is shaving $60 million per year off the distributed common ground system program, which should come to $1.2 billion in savings over the life of the system, he said.