Practicing Interoperability

(Editor’s Note: Following are edited excerpts from remarks given at a panel session entitled, “Interoperability Policies and Practices,” held at the MILCOM 2007 conference held in Orlando, Fla., in October.)

LIEUTENANT GENERAL CHARLES E. CROOM, JR.
DIRECTOR
DEFENSE INFORMATION SYSTEMS AGENCY

We’re a nation at war. Operational speaking, we have more than 23 joint task forces stood up and growing, and a number of variants. The technical reality is that the command and control system that serves those 23 task forces relies on more than 90 technical, service-specific, hard-wired interfaces to other C2 systems. And each of those 90 systems has imprisoned their data so no one can get to it.

The network that that application rides on is not really a network, but is composed of more than 15,000 networks with more than 5 million users. Thousands of warfighting and support applications run on that network, and we all recognize that those applications do not interoperate in a way we need them to, leaving great capability gaps. Fortunately, our soldiers, airmen, sailors and Marines are pretty innovative. We leave them on the tactical edge, trying to fix the mess we gave them. That’s the challenge.

We need to move away from these tightly coupled technical interfaces to be more flexible and agile. A team effort is required to move away from our stovepiped, point-to-point systems, to disestablish rigid regulations and practices, and in some cases go beyond the technical aspect of non-interoperability, to focus on data, security and tactics, techniques and procedures. We’ve already established communities of interest, which are coming together to agree upon common vocabularies, schemas for shared information, and an approach for orchestrating applications to react quickly to changes.

There are numerous other impediments to us moving forward. I’ve spoken before about our lack of speed in delivering capabilities to the field. Despite demonstrated benefits of speed, we are still unable to achieve it, not only in our acquisition, but also our ability to quickly adopt and implement in the field. When we do have proven applications, those who own the legacy systems remain resistant to change.

LIEUTENANT GENERAL MICHAEL W. PETERSON
CHIEF OF WARFIGHTING INTEGRATION/ CHIEF INFORMATION OFFICER
OFFICE OF SECRETARY OF THE AIR FORCE

You know about the takedown of al-Zarqawi about 18 months ago. That effort may have looked uncoordinated from the outside, but there was a plan in place. The special operations forces and their intelligence team were tracking him down, and finally able to fix the target. When they got close to fixing the target, a Predator was made available. There was no F-16 orbiting overhead that target, but as soon as the special operations forces knew that it was time to strike, the F-16s were made available.

Over the past year in Iraq, the average time in minutes to respond to a time-sensitive target has been in the low teens. You may be thinking that with response times in the low teens, our work must be about done. But the work has barely begun, because 67 percent of the time from when the call is made until the aircraft is there is spent on manual communications, because we don’t have machine-to-machine transfer of information, and because we are not fully interoperable.

Not only out in the battlefield, but also in the air operations center, you couldn’t account for that effort without yellow “stickies.” As soon as we pulled the two F-16s off their previous mission, countering IEDs, someone at combat plans should have been immediately able to assess whether to swing two other F-16s to counter IEDs. Instead, what we do is fill out a yellow sticky and stick it on their computer screen. That’s because we don’t expose our data in a net-centric environment.

What are we doing about that? Secretary Wynne knows that it’s all about the data, and he’s put us on a path of data transparency. There are five efforts, which we call pathfinders, to teach us how to expose data, build communities of interest, work on vocabularies, and eventually create a metadata environment that we could exploit to give us the ability to access authoritative data.

We started off with financial information. DoD had already put in place a standard financial information systems vocabulary. We copied that, and have done the vocabulary for all our data work. Because of that, for the 300 systems that we operate that report financial data to DoD, we didn’t have to write the interfaces. The cost of an interface and annual operations and maintenance for each of those systems could be $250,000 or more, so we’re talking about $100 million that we didn’t have to spend.

The next effort was with the medical system. Our doctors wanted to be able to transfer Air Force medical records and images directly and electronically to the VA. They had already started down the vocabulary path, and the secretary gave them a little more work, and after a few more months they had it done. The third effort involved going to a data source, putting an XML wrapper around it, and displaying it so we can access that data authoritatively. For example, one of the things we needed to know was whether personnel had all their shots to be able to deploy. Since they had already done all the vocabulary work, it took only seven hours to write all the software to get at that data. Now you can type in a Social Security number and see all the immunization information for someone deploying.

VERNON M. BETTENCOURT
DEPUTY CHIEF INFORMATION OFFICER/G-6
DEPARTMENT OF THE ARMY

The Army CIO/G6 office recently brought out a campaign plan. Prior to that, we had a 500-day plan, and we’re onto our second of those. We have six goals in the 500-day and campaign plans. As you look at these goals, and think back to the definition of interoperability, you can see how it weaves its way through the strategic goals.

The first goal is to set up LandWarNet, which you can think of as the transport and NetOps piece, and interoperability as it pertains to those layers of the architecture. The second goal talks to what transitions on that transport layer—the data, business processes and applications—and how we foster interoperability in the data, services, SOA, applications, governance and standards. The third goal is to protect and defend. Information assurance is a huge piece of interoperability. It both protects and ensures interoperability, but if you’re not careful, it can also impede it.

Goal number four is resource management. We have a large effort in the Army in IT portfolio integration. We are bringing down the number of applications. We have 18 domains in the Army based on functions, such as personnel, finance, training, battle command, battlefield situational awareness, and institutional and battlefield logistics, and four mission areas that oversee those. There is a lot of reduction, and as we reduce, we heighten interoperability by reducing all of the individual stovepipes.

If you wait until the end of the DoD acquisition process, and then check at the end whether you are interoperable, you can find yourself back five or six years. So a key piece of what we’re doing is looking at interoperability from the concept phase of the system. One of the things we do in the CIO office is that as systems go through the acquisition process, we’re looking earlier at their plans for interoperability.

We’ve gotten a lot of feedback that compliance and certification is a real issue—the length of time that it takes to certify the interoperability, net-worthiness and IA of systems. We’ve tried to do a lot these certifications in parallel. We’re doing our best to shorten this. The key thing for industry is not to wait until the end of an 18-24 month acquisition and development process and then say, how come it’s taking me 18 months to get certified? A lot of that can be done in parallel.

REAR ADMIRAL, LOWER HALF (SEL) SANDY DANIELS
DIRECTOR
NAVY SPACE AND NETWORK WARFARE PROGRAM N6R

The focus any time we deal with policy and governance has got to be on execution. What are the execution strategies? That gets back to the motivation factors. I’m going to give a few examples of what we’re doing in the Navy to address that.

One is a community of interest example. In the maritime domain awareness, we have a data-sharing community of interest, established in February 2006. It’s focused on sharing maritime information among federal agencies and their partners. The primary objective is to develop data standards and support net-centric information sharing across the whole spectrum of maritime domain awareness stakeholders. It’s led by an executive committee co-chaired by the Navy and Coast Guard. There is a steering group and three working groups, and the data-management working group is charged with developing a common vocabulary.

There are multiple spirals. The idea is to take a spiral approach, so that you try some things and then you learn. The first spiral for the Navy provides a limited number of sources of unclassified, automatic identification system information net-centrically available on DISA’s Net-Centric Enterprise Services. The publishers for this include the Coast Guard Research and Development Center, Office of Naval Intelligence, Department of Transportation Volpe Center, and the U.S. organic afloat and ashore areas. Follow-on spirals will increase that availability. By taking a particular mission area, bringing together a lot of the stakeholders and identifying where the conflicts are and ways of resolving them, this will offer ideas for becoming more interoperable.

The second piece we’re focused on is governance. This goes to how you change behaviors, especially when it comes to acquisition. You need to have oversight, and it needs to deal with money. In the Navy over the last couple of years, we’ve developed the ForceNet requirements and capabilities compliance policy. They have a consolidated checklist, so you know what you’re supposed to do for end-to-end compliance. More importantly, this has been linked to the budget process, so that documents must be certified for ForceNet interoperability by the N6, Admiral Edwards, using that checklist. So it’s become part of an integral review process. The requirements will now be used as the foundation for system engineering technical reviews of acquisition programs. You need to embed it in the process.

The need for change is there, and what we need to do is focus on the motivators. It’s not just about the technology, which in many ways is the easy part. Our challenge is addressing the alignment of interoperability policies and processes, and make it part of our culture change.

BRYAN M. SCURRY
DIRECTOR OF OPERATIONS/TECHNICAL DIRECTOR
NAVY PROGRAM EXECUTIVE OFFICE, SPACE SYSTEMS

The Mobile User Objective System [MUOS] program was directed from the beginning to focus on the satellite component. We were to take advantage of the newly formed Joint Tactical Radio System [JTRS] for the terminal piece, and we had to plug into the teleports for the connection into the global information grid. As time went on, there were resourcing delays, and the program got kicked off with a key decision point in 2004. As we started to do the design, pieces started to materialize as disconnects.

We moved quickly to establish links to the JTRS program office and the associated clusters, which were the terminal developers. We brought the director of the joint program office into our source selection, to ensure that the interoperability between the ground and satellite components would not be broken. What we found out was that because of the way the JTRS concept was then, there was a disconnect between the responsibilities the joint program office had and the actual authority they had with the clusters. That and other issues brought about the formation of the JTRS Joint Program Executive Office [JPEO], to bring the clusters and the program office together to form a cohesive capability on the ground.

When they did that, JPEO Dennis Bauman realized that he had to rescope all the programs. So they went through the requirements revision with the joint staff. Unfortunately, during the process some of the requirements were changed, and we were the victim of one of those changes, with MUOS dropped to be an increment one for JTRS for only one platform, the airborne, maritime, fixed [AMF]. At the same time, the Handheld/Manpack/Small Form Fit [HMS] was going through its source selection, and because there was a disconnect with the program office, we started to create some technical disconnects with interoperability, for power and processing requirements.

When JPEO started moving, our office moved quickly to work with it to solve some of these emerging problems. We formed a trade study in early 2006 to look at where the disconnects were from a technical perspective. After several months, we realized we could close some of these gaps. But the funding wasn’t there, so we were still at a roadblock. More recently, the MUOS program office has been working with the associated offices at JTRS, and we’re working together to build the waveform to work on the AMF terminal.

How can we bring together on these joint, federated interoperable capabilities a governance structure that allows the execution of all these interoperable instructions and guidance to ensure success so that we’re not playing catch-up as we go through program execution? A possible solution is a DoD-designated system integrator. But then again, that’s another layer of governance.

DAVE LUDWIG
ARMY DEPUTY PROGRAM EXECUTIVE OFFICER
COMMAND, CONTROL, COMMUNICATIONS TACTICAL

In the Army, we had a whole series of systems that were not necessarily harmonized, or bringing together and leveraging the various pieces that they could. Maneuver needs to understand what’s happening with fires, and the air defender needs to know what’s happening with intelligence. All the systems need information, and if the programs were not harmonized, that was a problem. Then we’d bring the programs together, and find that they couldn’t exchange information in the right way. That led to cost overruns, schedule slippage and disappointment on the part of the warfighter.

We came up with the “software blocking” concept, which is the idea of having a balanced and disciplined policy and process for harmonizing requirements, to ensure rapid delivery of integrated and operationally suitable capabilities to the warfighter. In 2004, they put into the Army policies that program managers were going to have to do planning and guidance to make sure that the systems are developed and maintained with the software blocking process. Systems have to go through a variety of tests before they are deemed interoperable.

What we’re doing now is to work this now with all new and upgraded systems. A system like maneuver control has been out there for a while, and there are various versions, as new capabilities are added on each year. As you know, when you change a capability in a software package, you can cause problems in other areas. Right now, software blocking is serving as the Army acquisition policy for synchronization of software programs. If you’re trying to synchronize 60-plus software programs to be interoperable, it can be very challenging, and you need a system to do that. It’s taken us a couple of years, but it’s falling into place. ♦

Back to Top