NECC forges joint command and control with SOA

The Defense Department aims to establish a new C2 environment that will offer a less expensive way to develop C2 capabilities, a faster way to deliver them to warfighters, and a more flexible way for users to shape them to their needs. In that environment, DOD could rapidly deploy forces to respond to conflicts.

As the Defense Department moves toward a network-centric approach to communications, the department is modernizing its command-and-control (C2) infrastructure by transitioning from a system that tightly couples hardware with the applications that run on them to a system based on a serviceoriented architecture (SOA).

DOD aims to establish a new C2 environment that will offer a less expensive way to develop C2 capabilities, a faster way to deliver them to warfighters, and a more flexible way for users to shape them to their needs. In that environment, DOD could rapidly deploy forces to respond to conflicts.

The ultimate goal is to deliver data and information to commanders and fighters in the field in any way they desire without going through long, tedious development cycles. C2 systems are tied closely to specific functions. If a commander asks for a specific type of system for delivering data, developers would typically need one to two years to complete the work.

They would need to create interfaces that would enable unconnected systems to share data and then verify that the system could deliver data in the intended way from one end of the chain to the other.

In that scenario, the application is the focus. In a SOA, a set of standard software services that is available to everyone can quickly pull information from multiple sources and deliver it in almost any format.

“Data becomes king and applications become commodities,” said Lt. Col. Kevin Leonard, Army program manager for the Global Command and Control System (GCCS). “If a commander wants to see the number of [improvised explosive devices] discovered in his area in the past 24 hours, we could deliver that into the field with relatively little effort” using the new SOA capabilities.

The new C2 environment will be called the Net-Enabled Command Capability (NECC). DOD originally planned to name it the Joint Command and Control ( JC2) Capability but changed the name because of potential confusion between it and a Defense Information Systems Agency program and other uses of the term JC2 at DOD.

NECC will replace the GCCS family of services. Although many of its initial applications will be based on existing GCCS services, NECC will provide more services, said Laura Knight, DISA’s program manager for NECC.

“By the nature of moving to a net-centric approach and to SOA, [NECC] brings a whole new way of doing command and control,” she said. “It will move well beyond the GCCS of today, with a number of new capabilities in such things as adaptive planning, situational awareness, force deployment and improvements in C2 for force protection.”

DISA plans to release the system’s initial operational version in fiscal 2010 followed by a more complete operational version in fiscal 2011, she said.

SOFTWARE AT THE CORE
The core of NECC is the software services being developed for the new C2 environment. Known as capability modules (CMs), they will operate on Global Information Grid (GIG) computing nodes. DISA leads development of the projects and works with Air Force, Army and Navy component program offices. Together, they outline goals for the modules, and the component offices handle development of specific modules.

DISA is expected to decide this fall which CMs the services will develop. DISA will probably ask the component offices to develop CMs that are most relevant to their missions. For example, the Navy would work on modules that are primarily maritime applications. But the goal for all CMs is to test and certify them so that they can reside in a central facility, called the Federated Development and Certification Environment, for any military service to use.

Shared resources are supposed to lead to shorter and less expensive development times compared with developing each application from scratch. Instead of waiting for a long acquisition process, users will choose from services that have already been developed, tested and certified.

SOA services are already well developed in some areas of expertise. GCCS’ intelligence sectors have already completed a significant amount of work with SOA, Knight said, so those capabilities can probably be rapidly incorporated into NECC.

However, it’s likely that older GCCS systems will exist alongside NECC services for a while. Although Knight said the first release of NECC, known as Increment 1, will allow individual military organizations to replace some of the GCCS family of services, they must form a strategy for implementing NECC.

“They are responsible for services in the local nodes” of the GIG, she said. “We understand it won’t happen overnight, even though by delivering Increment 1, we will enable the move.”

For example, the Air Force expects to convert to NECC during scheduled technology upgrades. In the meantime, the service will maintain existing systems and applications that are already in the field, said Ronald Norton, deputy chief of the 350th Electronic Systems Group’s Global C2 Systems Division.

“Over time, as we modernize, we’ll move in the direction of less fielded hardware,” Norton said. “As the [upgrade] spirals occur, we’ll see those legacy systems replaced.”

The problem is how to get the GCCS systems and new NECC services to work with one another as the transition occurs, which means being able to interoperate through SOA-based services.

One strategy is to take existing systems that don’t talk SOA and put SOA code around them, said Chris Partridge, a Theatre Battle Management Core Systems (TBMCS) Force Level engineer. The SOA code encapsulates the older system code and acts as an intermediary between the older code and the SOA services.

Another strategy would be to install SOA-type interfaces and then work with existing standards to develop the data interoperability features needed for existing systems to work with those interfaces.

TEST AND EVALUATION CHALLENGES
Meanwhile, there are potential problems with using SOA in the military. No one is sure how to test and evaluate SOA-based systems, said Lee Whitt, a technical fellow at Northrop Grumman Mission Systems. “If you put several new services into an environment where there are already thousands of services, what are the end-to-end considerations?” Whitt asked. “How do we even test for that?”

“Also, even if you use best practices and show that the service is compliant with all Web services standards, assuming then that you have something that the warfighter can use is delusional,” he said. “It can pass every test and still be useless.”

In software development, an idea called the conservation of software suggests that you can’t eliminate the complexity of the software, Whitt said.

“With SOA, you can easily build a Web service and register it so others can discover it, but if the overall complexity of C2 is still there, where has it gone with Web services?”

“It’s gone into the test and evaluation phase,” he said. “In the past, everyone had a piece of this complexity they had to deal with. Now we produce this little service that others can discover, but it’s basically left up to the warfighter to test it.”

Commercial software developers are starting to use testing methods that involve users early in the development and testing phases, Partridge said.

“But I don’t think we do that very well at all,” he said. “We need to work that through user events, apply risk-reduction techniques in prototypes and get feedback from users, and so on. That’s something we really need to learn how to do.”

Testing Web services also involves some time constraints. In the past, development and testing has followed a cycle of one to two years, said Carl Benkley, the TBMCS Force Level lead engineer. But in the future, NECC capability modules must be delivered independently from the overall system.

“You are talking about almost continuous testing,” he said.

The military must tackle that challenge to realize SOA’s advantage of quickly developing and deploying new capabilities, said Capt. Steven McPhillips, program manager of C2 at the Navy’s Program Executive Office for Command, Control, Communications, Computers and Intelligence (PEO-C4I).

There has already been some progress, McPhillips said. For example, PEO-C4I and the Air Force Electronic Systems Center have collaborated to develop the Net-Centric Enterprise Solutions for Interoperability program as a way to introduce the open-standards guidance and governance needed for C4I interoperability.

“We need to look at how we can quickly field new services without having to retest and recertify the whole system,” he said. “We need to leverage common testing and security certification and accreditation processes across the DOD.”

BANDWIDTH HURDLES
The military environment is also different from the commercial environment in other ways, Whitt said, particularly in the field, where low and intermittent bandwidth availability is common. Even in the commercial world, where offices can have multiple T1 lines, problems with SOA availability occur, he said.

“Can you have a dialogue between Web services in the battlefield environment at 56 kilobits/sec?” he asked.

Although adding Web services to existing systems so users can access systems through Web services sounds like a good idea, “out at the tactical edge, with services bolted on and what’s required to run them, you have a lot of [network] overhead to manage.”

That could pose a problem, Leonard said.

“Does it really work for a specialist operating somewhere in Baghdad with limited communication pipes back” to DISA, he asked.

NECC is intended to provide Web services capabilities even at the divisional level, Leonard said, but that requires knowing how to operate locally with limited bandwidths.

If a division doesn’t have the necessary bandwidth to connect to a DISA service center, it will need a way to make sure there is still a local capability and then sync with the center after the bandwidth becomes available, he said.

A service that depends to some degree on satellite communications will be challenged in a SOA environment, McPhillips said. Disconnected, interrupted and low-bandwidth communications are common in the Navy operational environment, he said. What’s more, there’s no single equation you can use to model the maritime environment.

“So we need to carefully determine exactly what sort of reach-back services are appropriate for [which] platform and mission and scale our services accordingly to ensure warfighters don’t lose capability when they lose connectivity,” McPhillips said.

Another lesson learned from development of NECC is that one size doesn’t fit all needs, Leonard said. At first, officials believed that what developers produced would be suitable for use by all combatant commands, he said. But officials now understand that each command has specific missions with different needs.

“So as we are developing situational awareness capabilities, we need to understand that what that means to Central Command will not have the same implications for Northern Command, for example,” he said. “Whatever we develop has to have user conformability.”

<b>PATH TO MATURITY</b><br> Warren Suss, president of Suss Consulting, has followed DOD’s strategy for SOA-based C2 from the beginning. Although he said he believes SOA is a good long-term strategy, he added that SOA is a relatively immature field that is still in the early phase of identifying standards and applying them to ensure that SOA elements are compatible.

“Based on what the people I’ve talked to tell me, many are not yet convinced that SOA is something that’s battleready,” Suss said. “It’s certainly worth [DOD] moving to, as long as it keeps an eye on the ultimate goal and it doesn’t become just another layer [of complexity] with all of the added costs that implies.”

Changes to supporting processes are also needed, such as the development of an acquisition model that aligns with SOA’s needs, he said. And that’s a challenge because the military services tend to develop solutions for only their particular needs.

“Someone who develops solutions for the Army is the last person that the Air Force would want to deal with, because they see it as not being theirs,” he said. However, Suss said he thinks the military is buying into SOA “pretty much across the board and the challenge now is more to do with how to get there and in managing expectations.”

Some people who have been involved in the early stages of the transition to the SOA-based C2 agree.

With all the activities that he and others have been involved in during the past year, Leonard still sees SOA as something in the early developmental stages, with many lessons learned being pumped back into the program to make the eventual fielding of NECC that much smoother in the future.

In a crawl-walk-run process, he said, “we’re still very much in the crawl stage.”