wfedstaff | April 17, 2015 9:21 pm
For the last several years, military acquisition leaders have gone out of their way to extol the virtues of open system architectures. But the Pentagon’s biggest evangelists for openness freely acknowledge that DoD has done a much better job of talking about those policies than implementing them.
Going forward though, things will be different, some of the Army and Navy’s most senior procurement officials insisted Tuesday. That’s partially because advances in technology and business processes have made open architectures more practical to implement than they were a few years ago. It’s also because shrinking budgets have left DoD with little choice.
“We can’t continue down a path where we have proprietary hardware and software that causes us to spend a lot of money in post-production just to try to maintain connectivity and interoperability between proprietary systems,” said Lt. Gen. Michael Williamson, the Army’s top uniformed acquisition official. “It’s just unaffordable.”
While the Pentagon’s acquisition system has been slow to embrace the open architectures that its most senior officials have endorsed in speeches and public documents, the migration toward service-oriented, standards-based systems can’t be stalled any longer, top procurement officials said during an open architecture summit organized by Defense Daily — an annual meeting the industry publication has set up each year to discuss open systems since 2006.
Insight by Tableau: Executives will discuss how data has driven the success behind their hiring and retention strategies in this exclusive executive briefing.
In the intervening years, DoD has invested significant money and brainpower into settling on several sets of commercially-based standards that it hopes will tie many of its systems together via open interfaces.
The Army has its Common Operating Environment, designed to make sure systems in its command posts, its vehicles and the radios its soldiers wear all fit into their own interoperable environments.
The Navy is leaning on the Future Airborne Capabilities Environment (FACE) — an open-interface approach to integrating the technologies on the military’s planes and helicopters.
Writing the standards is one thing. Enforcing them through the acquisition process is another, and Williamson said DoD still hasn’t cracked that code. “We have not vigorously defended those standards,” he said. “Once we pick something, we have to be very consistent with industry and our own developers and make sure they follow the standards. If we waver, we send the wrong message to industry, and we’re still back where we were six years ago.”
Even six years ago, the Pentagon was paying lip service to open architecture on the front pages of its solicitations. But DoD has nonetheless struggled to make clear precisely what it’s willing to pay for systems that are architected to open standards — which tend to cost more up front but are cheaper to sustain over time because they allow the flexibility to plug in new technologies or adapt existing ones when new military needs arise.
And since the military has not made open architectures a priority in the evaluation factors that guide its real-world procurement decisions in the deeper pages of its requests for proposals, the government has wound up buying more proprietary systems than it otherwise might have, mostly because they had lower sticker prices during the fiscal year in which the first check was written.
Vice Adm. David Dunaway, the commander of the Naval Air Systems Command, vowed a change in behavior on that front. He said the Navy will make very clear in all future RFPs that it doesn’t just prefer open systems, it insists on them. “The way the price of sustainment is going, we are going out of business if we do not do something different,” he said. “We are spending a lot of money right now on point-to-point integrations so that we can get our systems to interoperate. We do not need to be spending that money, but we’re there because it’s what we’ve demanded of industry. We are going to demand something else from industry, which is open-architected integration.”
Dunaway said his command, NAVAIR, has taken nine concrete steps over the past two years to make sure that open architected systems become the standard — not just a vague objective. He cited a new “horizontal” structure that requires aircraft system acquirers to think about everything they’re buying as part of a system of systems as opposed to a stovepiped component that moves through the acquisition process with its own agenda.
“In NAVAIR, we have more than 20 [electro-optical/infrared sensors] that require their own unique integrations,” Dunaway said. “When I find something that’s very good on one of them and I want to put that capability on another one, I’ve got to go out and put out another RFP and do another unique integration on another platform. This is wasted money. We have a common standard for those sensors now, but if we had that five years ago, the money could have gone toward buying things instead of integrating things.”
As part of the same horizontal mentality, Dunaway said the Navy is investing heavily in building a NAVAIR laboratory that’s organized entirely around FACE — the common standard set it wants to use for future aviation systems. “I have a lot of infrastructure and a lot of facilities, and I want to consolidate them all along the backbone of FACE,” he said. “It’s not the only common standard in the universe, but it’s the one we’re using right now. We’re happy to work with any other open commercial standard, because if they’re open enough, we should be able to use them concurrently. The vision I’ve given to my team is that the next generation of aircraft should have a completely open architecture, where the government competes services all along a common backbone. We might even buy a completely [commercial] airframe, and then compete all of the individual components of that aircraft to industry as individual services.”
The Navy is pursuing its ship-based technologies in a similar vein, said William Bray, a top official for the Naval Sea Systems Command.
NAVSEA has built a set of objective architectures that mean that once a new technology comes into the Navy’s surface fleet, it can be deployed across several classes of ships with just few trivial changes.
“We’ve adopted what we call a Common Source Library, really maximizing the use of the software we already have under development,” he said. “The same library of source code delivers to every platform we have out there — the cruisers, the destroyers, our AEGIS ashore programs, the [Freedom Class] littoral combat ship, plus the Coast Guard. Before, we would have developed a dedicated baseline for each one of those platforms. Now we have one dedicated software baseline that goes out to many ships.”
NAVSEA’s objective is to decouple hardware and software procurements in such a way that IT hardware is a pure commodity. In that environment, it could turn most of its attention toward developing software that’s already designed to interoperate, not writing new code to translate between system A and system B. Traditionally, hardware and software functions have made their way into government systems as a take-it-or-leave it package because of industry’s incentives to make sure individual companies can continue to generate revenue via long-term sustainment contracts and contacting officers’ reticence to insist on open architectures and a reasonable level of government-owned data rights.
“If we have a problem and we have to respond to it, the folks that have to respond to it are the engineers who might not have ever experienced an open architecture, and so they can’t imagine writing it into an RFP,” Dunaway said. “They can’t imagine the business case because they’ve never done it before. We have to change that so that it’s exercised on a routine basis. We have done open architecture multiple times on our programs, and it’s worked great. We chose not to do it on other programs, and it doesn’t work when you choose not to do it. That’s fascinating.”
The Pentagon will not solve all of its acquisition problems via open architectures, but it’s a good start, Williamson said.
“There is still a requirement for leadership and management. You can put out as many standards as you want, but you still have to make sure you understand how those are implemented within your program. I’m fully supportive of open architecture, but we need to manage and lead these efforts. We need to understand what we’re doing, have a disciplined effort and have a consistent message to industry.”