Defense Intelligence Aims for Savings Via Reforms

Convergence and federation join forces in a new approach.

The defense intelligence community is considering an unlikely pairing of architecture approaches to enable necessary budget cuts without savaging performance. This hybrid method would team convergence and federation to allow all the disparate members of the community to strengthen their interoperability while maintaining a degree of autonomy necessary for their unique mission requirements.

The vehicle for this approach is the Defense Intelligence Information Enterprise, or DI²E. This architecture would permit agencies and services to share some functions while maintaining others. It would establish a means for future capabilities to meet broad-based standards where possible or separate specifications where necessary. The goal is not a compromise, but rather a complementary architecture.

Equally important to improving intelligence community functions is saving money. With budget cuts threatening to eviscerate intelligence programs and operations, the DI²E may be the best way to maintain an effective intelligence community while realizing significant cost savings, intelligence officials say.

Kevin Meiners, deputy undersecretary of defense for Portfolio, Programs and Resources, Office of the Undersecretary of Defense for Intelligence, professes that the DI²E offers the best chance for the defense intelligence community to make substantial budget cuts without sacrificing performance. Under worst-case-scenario budget cuts, the intelligence community could be driven to exercise convergence across the board, Meiners allows. But this approach ignores the fact that each service has its own needs.

“It’s all driven by mission-based architecture, so each service has a different mission to satisfy,” Meiners relates.

“If we were converging at a mission level, then all the warfighters would be a little nervous,” he continues. Instead, the approach is to focus on the information technology arena. All of the services are looking at some element of convergence within a federated construct. This allows them to build the mission-based architecture that they need to execute their missions while realizing the efficiencies inherent in convergence where applicable.

Meiners points out that intelligence organizations can cut systems, such as sensor platforms, or they can cut information technology to meet mandated budget savings. With each defense agency having its own network, converging functions can save billions of dollars without a loss of capability.

“The debate that you’re going to have for the next five years is do we converge on a single cloud versus stay federated,” Meiners declares. “When we talk to the [defense chief information office], the guidance is that you’re going to be federated or you’re going to be converged. We’ve been pushing convergence where it makes sense.”

Effectively, the DI²E would be the intelligence community’s approach to providing some degree of tailoring to different segments of the community without resorting to a “one size fits all” approach to intelligence collection, processing and dissemination. Many traditional intelligence architectures, such as the Joint Worldwide Intelligence Communications System (JWICS) and the Joint Service Imagery Processing System (JSIPS), involved centralized configurations. When the Global Information Grid opened the door to distributed systems, the intelligence community adopted the original version of the Distributed Common Ground Station (DCGS) and the Global Command and Control System (GCCS).

Now, the intelligence community is narrowing the difference between the two methodologies by adopting either federated or converged approaches. Examples of converged systems are the DCGS Integration Backbone (DIB) and the Navy/Marine Corps Intranet (NMCI). Federated systems include the current DCGS family of systems (DCGS FoS) and the Joint Command and Control (JC²) capability.

In a federated approach, each service maintains its own architecture based on mission requirements. The Defense Department currently is working to federate those architectures so that each service can access one another’s data. The next step is for each service to have access to the others’ apps.

The DI²E represents a federation of defense intelligence, surveillance and reconnaissance (ISR) processing systems, Meiners explains. But, it also allows convergence to enter the process.

“Our strategy is we’re still going to stay federated, but we’re going to converge where it makes sense,” he declares. “We’re going to pick our convergence points.”

The department will show the services where it wants to converge and what it will do to enable that convergence. For example, if a convergence involves apps, then the department draws from agency expertise to develop an app storefront, Meiners explains.

He relates that the first big convergence point was to build fiber links via the Defense Information Systems Agency (DISA). So, the community jumped on the GIG Bandwidth Expansion (GIG-BE). The second convergence point was the DIB, where the services converged to share data.

Meiners points out that the DIB convergence opened the door to a means of federation. The use of the DIB allowed the services to share analysts, which was especially useful where one group might be more adept at analyzing a particular type of intelligence. Some service groups now rely on others to process a specific type of data, he states.

For example, when everyone converged on the DIB, it was amid the realization that they needed to federate analysis; and the way to federate analysis is to view each other’s data, Meiners points out.

One of the vital DI²E elements currently under development is its framework. This framework “enables or federates architectures and capabilities,” Meiners says. It will help enable the connections among different capabilities, especially those from individual services and their systems.

The framework also is the key to ensuring that the convergence is done correctly. Meiners describes it as the code book—along the lines of construction code rather than cryptography—for people who are building architectures that will need to federate across the enterprise.

Individual services can employ this framework as they build and supplement their own intelligence infrastructure. For example, a service working with a contractor on an intelligence capability can require the contractor to be compliant with the DI²E framework. “It [the framework] serves as a common descriptor of what kind of things we need to build to,” Meiners offers.

Looking back, he continues that, with various intelligence groups building their own different cloud architectures and capabilities, it was difficult to ensure that all parties were following the same guidelines. So, the department allowed participants to choose one agency to serve as the lead. The services selected the National Reconnaissance Office (NRO) to lead the DI²E framework with guidance from the DI²E Council, which comprises representatives from the services, agencies and combatant commands. This council provides governance to the entire program. “NRO is not developing the framework,” Meiners declares.

He notes that the NRO wears multiple hats in this endeavor. The office is building quick reaction capabilities for the ISR Task Force and the DCGS-Intelligence Community (IC) architecture, for example, and he emphasizes that the NRO cannot confuse its DI²E framework tasking with those other activities. The Defense Department has awarded $41 million over two years for the NRO to build the DI²E framework.

The next contract that will emerge from the NRO is the rapid operational multi-INT omnibus, or ROMO, award. It will be an indefinite delivery/indefinite quantity (IDIQ) contract designed for the entire NRO, but only one task order in it will be for DI²E—and it will be for the framework, Meiners explains. This DI²E task order covers efforts to document/develop and maintain/update DI²E reference implementation; to support compliance testing with the DI²E framework and standards; and to provide a DI²E storefront.

The first task effort would use common core services to integrate and share a common DI²E reference implementation. This implementation would be updated as standards, specifications and services are changed or added. As envisioned, a graphical grid would consist of horizontal and vertical layers organized into color-coded blocs. The top would be the user interface layer; the second would feature ISR functions; the third would cover data, which is where the DIB would reside; and the fourth would focus on infrastructure.

“We have taken all the different pieces that services have agreed to, the important [elements], and we’re putting that all online,” Meiners says. “So everybody will be able to find all that online. If you want to develop a full-motion video app, you would click on the appropriate chiclet [box], and it would tell you what the functional manager has listed as the spec.

“All the small companies are really getting excited about this,” he continues. “They believe that, once you give them ‘this is how you build stuff,’ then they can bust into the market where the big guys operate. We’re giving them a more level playing field.”

The second effort would support testing and certification of services for compliance with approved DI²E standards and specifications. It also would verify that services successfully integrate within the approved reference implementation.

For example, if an agency develops an app for targeting, that app could be embraced easily by the services once it passes this certification. Each service’s accrediting authority would know that the app was tested and verified through the DI²E framework, so the individual services would not need to engage in their own verification efforts. This will give customers confidence that they can count on a new app—whether developed internally or by another organization—working well within the architecture.

The third task effort would ensure convergence of apps and tools across the federated community. A DI²E apps storefront would provide a Web-based environment where consumers could find widgets, apps, core services, profiles, service components and source code. This storefront would develop, manage and support multiple software sharing business models. It also would provide support tools and components to register services for developers to submit for DI²E test and certification compliance.

Meiners says the business model remains an issue. “We’re not going to have a storefront that basically says someone can buy the app for 99 cents, so how do the [big contractors] build apps and still make money? We’re still wrestling with that.”

The timeline for the DI²E framework has the task order release scheduled for January 2012, as the final request for proposals was issued in October. The framework’s initial operational capability (IOC) is projected to be in early 2013. That IOC would feature the document/software development kit, the storefront equipped with DI²E core services, and ongoing conformance testing for enterprise services.