Netcentric In a Snap

The goal of netcentric warfare is to enable troops to adapt on the fly, but that means technology has to become plug-and-play.

A line of Humvees carrying U.S. soldiers rumbles through the night in enemy territory in 2016. The convoy turns right, but one section mistakenly goes left-straight into the leading edge of a superior adversarial force. They rain fire on the lost group. Today, the likely result would be heavy casualties. But in 2016, something different happens. A nearby ground unit immediately heads out to aid the errant Humvees. So does an air unit. Far away, maybe in an office building inside the Beltway, an analyst focuses a camera on the scene.

Within an online collaboration zone established within seconds of the first cry for help, information flies back and forth. Enemy forces are coming from the northwest, so the evacuation heads southeast. A mobile medical unit already knows the blood types and other relevant data about the American soldiers. For a short time, many different battlefield units join up in an ad hoc formation that dissolves as soon as the convoy is rescued.

Defense officials use this story to illustrate the new type of warfare the Pentagon wants to wage: a network-centric fight in which information awareness is a weapon. Netcentric warfare is about piercing the fog of war. On the netcentric battlefield, American warfighters know where they are in relation to friend and foe. Fighters are connected to every relevant data collection system. Superior knowledge, and the ability to use it to spontaneously reorganize and act, enables the U.S. military to shoot first.

Netcentricity is hardly a new idea. It stems from the 1990s explosion of commercial information technology applications, when forward-thinking defense planners decided they wanted a wired-up military. Since then, the services have made some, mostly mixed, progress in information agility.

"Technology has evolved much quicker than the process by which it can be acquired within the DoD," says Frank Higgins, until recently a Defense Information Systems Agency deputy program manager, now a senior manager of strategic planning and business development at Raytheon's McKinney, Texas-based Network Centric Systems. Plus, the military can't afford to ditch and replace all its existing equipment in one clean sweep.

But deeper factors hinder a truly netcentric military. If future wars will depend on battlefield information, then networks and applications are more important than ever. Like most military equipment and structure, however, defense IT systems are legacies of the Cold War. America's enemy then had long, clunky planning cycles, so it didn't matter that U.S. military IT systems were tightly integrated and difficult to change-the Soviet Union's weren't all that flexible either. But with the relentlessly adaptable opponents the United States faces today, the Pentagon is working to adjust its planning, training, doctrine, equipment and technology to dynamically shifting environments and enemies. The next step is to make the core of netcentricity, the code it's based on, equally adaptable, say proponents of a software development framework called service-oriented architecture.

Don't let the jargon scare you. Behind that ungainly moniker hides an IT paradigm shift that will help make netcentric warfare possible. "We believe this is the best way, and quite frankly, the only way going forward, in terms of addressing the level of complexity we're dealing with," said Rob Vietmeyer, DISA's Net-Centric Enterprise Services chief engineer, speaking to an industry audience in March. DISA in particular, as well as the military branches, are increasingly turning to SOA. "The models that we used in the past for systems development aren't going to cut it," he said.

Software Stovepipes

The Defense Department's Global Combat and Control System is, without argument, the best in the world. "We use it every day, and we've been kicking butt with it," said Bernal Allen, chief of DISA's enterprise application division, at a conference earlier this year. "So why would we want to change it?"

Well, for one thing, it took DISA about 18 months to get the latest version out the door. What's more, GCCS interfaces with 94 other systems, and to change one interface is to change them all. Adding software capabilities is difficult and expensive; getting sign-off for a change from each of GCCS' 23 executive agents requires herculean effort. "It was very difficult to dynamically add data into the stream and take data out," recalls Dennis Nadler, a former GCCS chief engineer, now chief technology officer at Merlin Technical Solutions based in Greenwood Village, Colo. If a military command wanted to extract information detailing the weapons system specialties of soldiers from passenger manifests kept by the U.S. Transportation Command, for example, the command would say, "No problem, we have that data, but it'll take us three months and $4 million," to craft an interface, Nadler says.

That's where SOA comes in. It's not so much a new technology as a new framework for developing IT systems. Today, disparate software is stitched together to create an overarching, monolithic system of systems, such as GCCS. Service-oriented architecture breaks down these huge, interlocked processes into their individual components, small software modules that perform basic tasks, such as checking temperature and precipitation in a particular location. Each of these modules has standardized interfaces through which they can connect to other modules. Data hops from application to application without custom-built middleware to translate between incompatible programs. "Application development becomes assembly" of many atom-size components, says Grace Lewis, a technical staff senior member at the Carnegie Mellon University's Software Engineering Institute. After testing and certification, each module is registered and available for general use. "Little-bitty things, but all together, they empower pretty complex processes," DISA's Allen says.

Why does this matter to netcentric operations and warfare? SOA frees data so it can travel horizontally across networks, getting to those who need it sooner than if it must run up and down vertically integrated stovepipes. It allows new data applications to be constructed quickly to respond to changing conditions on the battlefield and elsewhere. The eventual goal is to get computer users to integrate their own data and applications. "The idea is to establish on-the-fly collaborative information environments that people can pile into," Allen says. This would solve a perennial government problem, especially at Defense: falling behind the IT development curve. "You never know where to put your oar in the water and take a big stroke, because that's a huge commitment," says retired Army Maj. Gen. Dean Cash, Raytheon's director of netcentric operations.

The Pentagon's acquisition process makes it difficult to kill or change programs. By the time a finished product appears, if it's IT-related, chances are it's behind the most up-to-date capabilities. The pace of change is faster than the military's ability to keep up-that's the problem with monumental projects. It's a development mentality that has allowed eBay to outpace GCCS in complexity and adaptability, Allen says. DISA is struggling to include 100,000 tracked objects within its command and control system's common operating picture. The online auction company can track 25 million objects for sale. Users of eBay can add software capabilities by downloading common interface standards and testing their programs in a simulated environment. Once a proposed program gains eBay certification, it's allowed into the operating environment. That's how the Pentagon needs to add new applications-"a gazillion folks building stuff and some sort of a governance process to make sure that when they put stuff on the network, it works together," Allen says. Out with complex solutions that take years to field; in with the modular, the quickly developed and swiftly assimilated.

Nothing's Perfect

Service-oriented architecture "is just not the panacea that a lot of people paint it as," says John Reel, chief scientist at Columbia, Md.- based RABA Technologies. New solutions to old problems expose previously hidden complications or create additional ones, and SOA is no exception.

At a basic level, the Pentagon is ill-prepared to support the boundless world SOA promises to create. The architecture "implies a pervasive fabric across the whole world, and this is an organization with a history of boundaries and an assumption of the necessity of boundaries," says Mike Curtis, an executive consulting IT architect for IBM Federal and chairman emeritus of the Network Centric Operations Industry Consortium's technical council. Adopting SOA assumes that if one military branch creates a modular application, another can use it. But in today's Pentagon, that approach punishes creators of popular applications, because the onus is on them to add bigger servers and faster machines. Interdepartmental fees for software reuse could solve that, but the process of crafting those agreements is difficult and time-consuming, just the opposite of what netcentric operations are intended to achieve.

At an even more basic level, SOA interoperability means interdependability. In the future, services and data will originate from outside a military branch's command, and the military values both control over and proximity to data collection. Regular communication between data collectors and data consumers ensures that users get what they really need, Reel says. Without that interaction, it's difficult to trust information, he adds. Even in the private sector, which is years ahead of government in SOA adoption, large organizations have a difficult time relinquishing control over data gathering. Relying on another military branch also means there would be accountability for, but not authority over, a particular service's data format, interface and maintenance, Reel says. "You're adding another layer of dependency there, and when folks are shooting at you, you need as few dependencies as possible," he says.

Another expert says these problems have a partial solution in keeping some SOA components bounded within specific military domains. In effect, SOA makes data and functions into commodities, so the applications targeted for development shouldn't be highly specific, says Haden Land, technical director and chief architect of Lockheed Martin Enterprise and Logistics Solutions. Battlefield-sensitive software still should be built for SOA interoperabil-ity, but mission-sensitive data or applications shouldn't be exposed beyond their immediate circle of users, he adds.

Most proponents agree that SOA is far from ready for the front lines and should be confined in the near future to systems that plan battles rather than fight them. Netcentric wars require netcentric logistics and intelligence systems, too-war isn't just what happens among tanks and helicopters. But the day is coming when an SOA battlefield will exist, they say. If the military services keep doing things the way they've always done them, they'll never get the information integration necessary to form a truly transparent battlefield populated by ad hoc groupings able to take advantage of that information, says Carnegie Mellon's Lewis. She challenges another of Reel's fears, that of combat connectivity. Without a radio frequency connection to a network, SOA is moot, Reel says. During battle, the enemy is doing its utmost to disrupt communications, something developers trumpeting SOA don't always remember. "Most network guys are used to having connectivity pretty much all the time, and few of us have ever been shot at," he says. "We have to be careful that we have a default path where if we don't have connectivity, we can keep going." But, Lewis says, "The last-mile problem has to be solved somehow." Without a way to push SOA down to the troops, true netcentricity could remain elusive.

One more potential problem requiring resolution would be protection of the registry lists that point to where all modular applications are stored. During war, such a list could become an inviting target for enemies. "You're probably looking at a tri-redundant structure," Land says, meaning adversaries would have to incapacitate the registry and its backup systems several times before it would actually fail. The level of redundancy needs to be the equivalent of nuclear plant systems, he adds-although they've been known to occasionally fail, too.

Bureaucratic Realities

Service-oriented architecture depends on a critical mass of applications with common interfaces to create a plug-and-play software world. Getting there requires spending money today for something that won't be useful until tomorrow. "The government procurement process and budgeting kind of fights against building SOA," Merlin's Nadler says.

When program managers get money, it's to build specific requirements. "Anytime there's something that's on the edge that may cost a little bit more money, [managers] have to determine whether that's worth the investment, and they're not looking beyond their own application," Nadler says. Also, the requirements generation process is cumbersome, adding time to an IT development cycle that should last months, not years. Acquisition oversight is necessary, few would disagree, but proponents say it needs loosening so SOA can do its stuff.

The architecture can be quick to make enemies, too, if the argument for it isn't phrased care-fully. By constructing a world of reusable software modules, SOA should save money by cutting out redundant software development. Budget officials love to hear this. But if they then ask which programs can be cut, "immediately, you have not made friends," DISA's Vietmeyer says.

While SOA is red-hot these days among technologists, it's virtually unknown beyond them, making it a hard sell. Top executive buy-in is necessary for the wide-ranging changes SOA would make, but its proponents often make only the purely technical case, as if the benefits were self-evident. SOA is a significant step forward, Vietmeyer says. But, "How to articulate that to a nation that's at war in terms of real, tangible benefits that can be realized immediately, it's difficult," he says.

At an industry lunch late last year, Air Force Lt. Gen. Charles Croom, commander of DISA, said his challenge is to describe SOA in terms that his technology-ignorant mother or the chairman of the Joint Chiefs of Staff could understand. In the main, he favors comparing SOA to an Internet travel reservation portal. Web sites such as Travelocity.com integrate multiple streams of constantly changing data, but to users the information appears seamlessly stitched together. "They built it to standards that allow information to be shared," he said. This is what netcentric aims to achieve during war, and what SOA can do for the warfighter.