In modern business parlance, “stovepipe” is a dirty word. Believe it or not, however, stovepipes used to be useful. When they became commonplace in the 19th century, wood-burning stoves were connected to literal stovepipes that drew smoke out of the stove’s belly into a flue or chimney, which coughed it into the sky. In business and government, figurative stovepipes likewise move information from the bottom of an organization to the top. Like smoke from a wood-burning stove, the information flows upward to senior leaders, then out in the form of streamlined decision-making. Because it’s rigid and linear, the stovepipe promotes security, ensures accountability, and reinforces the chain of command, all of which can yield benefits in highly regimented organizations.
There’s just one problem: Stovepipes only flow in one direction. If you’re trying to move smoke through a chimney, that’s ideal. If you’re trying to move information through an enterprise, however, it’s problematic, as vertical processes are prone to inefficiency, duplication, and myopia. In that case, stovepipes don’t always eliminate smoke; often, they create more of it.
The Department of Defense (DoD) came to this realization when it transitioned from analog to digital imagery for airborne intelligence, surveillance, and reconnaissance (ISR), said Ralph Wade, a former Air Force imagery analyst and now vice president of Booz Allen Hamilton’s Strategic Innovation Group.
“The technology for digital sensors came about in the mid-1980s, when electronic communication made it possible to send information digitally from an airplane to a ground station in near real time,” explained Wade, who served as program manager for one of the first and largest such ground stations. “It was a huge increase in capability.”
It was also a huge increase in cost, as each newly acquired platform in turn acquired its own dedicated data link and ground station.
“What you started seeing in the late 1980s and early 1990s was a proliferation of platforms with one-of-a-kind ground stations that were stovepiped,” Wade said. “Every time you wanted to put a sensor onboard an airplane, you had people reinventing the wheel by building custom systems. Congress looked at that and began challenging the Department of Defense: Why aren’t we getting more commonality?”
When Operation Desert Storm exposed a need for more and better imagery, the DoD began asking itself the same question. And when Congress subsequently reduced defense spending under President Bill Clinton, it felt compelled to answer it.
“Budgets were being cut and ISR was on the chopping block because … many of the services at that time didn’t see ISR as their core mission,” Wade recalled. “At the same time, a lot of new technology was coming along—particularly, unmanned vehicles—that wasn’t getting enough attention.”
To protect and prioritize airborne ISR funding, in 1993 the DoD created the Defense Airborne Reconnaissance Office (DARO) to develop and acquire department-wide airborne ISR capabilities.
The objective is the same now as it was then: interoperability. And it’s getting nearer every day, thanks to ongoing horizontal integration efforts within and among the services.
Embracing the Enterprise
Although the business case for interoperability is clear today, it wasn’t always apparent at the outset of DARO. Fortunately, the Air Force had already sown the seeds.
“It started somewhat by accident,” recalled Col. Jason Brown, commander of the Air Force’s 480th ISR Wing. “When digital imagery platforms came about, the Air Force put a digital imagery sensor on the U-2 so that the ones and zeros, if you will, would go down to a ground station … They later decided to put signals intelligence sensors on the same U-2, which went down to the same ground station. So, here you had imagery analysts and signals intelligence analysts all working in the same spot.”
It was an unorthodox but effective arrangement.
“You had folks who didn’t normally work together working together, which was a very powerful capability,” Brown continued.
DCGS was the first attempt at saying: When data comes off a sensor and gets processed, it’s got to be made ‘enterprise-able’—which means, it’s got to be made for use by all.
—John Snevely, DCGS FoS Leader, OUSD(I)
When the Cold War ended, the Air Force saw an opportunity to exploit that capability even further. Therefore, in 1992 it established the Contingency Airborne Reconnaissance System (CARS). Encompassing mobile ground stations in deployable vans, the system migrated in 1994 to a trio of permanent shelters that collected, processed, and exploited data from multiple airborne ISR platforms, then distributed it through a federated architecture to sites across the globe. In 1996, the permanent shelters—Distributed Ground Stations 1, 2, and 3—became known holistically as the Air Force Distributed Common Ground System (AF DCGS), which now includes 27 regionally aligned, globally networked sites around the world.
By leveraging multi-source inputs and federated architecture, AF DCGS had solved the problems posed by stovepiped Air Force ground stations. As a result, the DoD sought sister systems to work in the same fashion across all services. And so was born the Distributed Common Ground System (DCGS) Family of Systems (FoS), consisting of AF DCGS, DCGS-A, DCGS-N, DCGS-MC, and DCGS-SOF—belonging to the Air Force, Army, Navy, Marine Corps, and Special Operations Forces, respectively—each of which integrates with the next via a common software construct known as the DCGS Integration Backbone, or DIB.
“The DIB is essentially a data architecture that everybody publishes to and exploits from,” said Todd Probert, vice president of mission sustainment and modernization at Raytheon, which along with Northrop Grumman, Lockheed Martin, and other industry partners has contracted with the DoD to build the systems necessary to achieve interoperability. “It’s foundational, and without that foundation it’s difficult to do sharing at speed.”
In humans, the spine integrates the body’s various anatomical systems via a shared nervous system through which they can communicate and share resources while still performing their own independent functions. In the DCGS FoS, the DIB is the spine. Although each service-specific DCGS architecture has its own functions and applications, it must be configured to store and share data through the DIB.
“DCGS was the first attempt at saying: When data comes off a sensor and gets processed, it’s got to be made ‘enterprise-able’—which means, it’s got to be made for use by all,” explained John Snevely, who leads the DCGS FoS at the Office of the Under Secretary of Defense for Intelligence OUSD(I). “It took us away from proprietary intelligence data and forced us to start meeting and testing to standards.”
Inspired by the Air Force, DARO and the National Imagery and Mapping Agency (NGA’s predecessor) began to consider the idea of interoperable ground stations across the services in 1994. The idea didn’t fully mature, however, until some time after the dissolution of DARO, when OUSD(I) assumed the work of standing up the DCGS FoS.
Prior to DARO’s termination in 1998, each of the services had formed a DCGS program office. Under OUSD(I) oversight, the program managers transitioned from an informal working group to a formal structure called the Multi-Service Execution Team (MET). MET collaborated—and still does—to determine the requirements and configuration of the DIB software. When this work was completed in 2003, OUSD(I) issued a mandate requiring the services to develop and acquire technology to DIB standards, which was made easier on the services by the provision of extra resources.
“We invested in enterprise governance,” Snevely said. “We paid for engineering support at the enterprise level so the program offices didn’t have to figure things out for themselves. It was done for them. All they had to do was take the technology off the shelf and implement it.”
The result was seamless discovery and dissemination.
“Sometimes, I anecdotally call DCGS ‘the Napster for intelligence,’” said retired Marine Col. Phillip Chudoba, assistant director of intelligence at Marine Corps headquarters, recalling the popular music-sharing platform of the early aughts. “That file-sharing platform allowed you to look on my computer and see what music files existed there that you might want to have. The same kind of logic exists with DCGS. A user at the tactical level theoretically has the ability via DCGS and the DIB to look across the joint services and see what information products and data are available.”
Current State: Operational Interoperability
Since OUSD(I) issued its DIB mandate, implementation of interoperability in general—and DCGS in particular—has unfolded in different ways and at different speeds across the services. In the last five years, however, the maturation of mobile computing and cloud architecture has allowed the defense intelligence community to enter a new phase of execution toward horizontal integration.
“You used to have intelligence analysts sitting in very specific seats doing very specific things with very specific intelligence types,” said Sean Love, director of business development at Northrop Grumman. “And that was fine, because the technology—the bandwidth and sheer connectivity—didn’t exist to do a whole lot more than that. Now that those barriers are coming down very quickly, you’re starting to see a lot more cross-sharing.”
The evolution of DCGS from concept to reality began with GEOINT. For example, within the Marine Corps—which initiated its DCGS-MC program in 2007—the first DIB-enabled systems were the Tactical Exploitation Group, an imagery system, and the Topographic Production Capability, which provides topographic and mapping capabilities.
“The GEOINT layer is the first intelligence capability that we elected to pursue in DCGS because the GEOINT layer offers us tremendous potential for enhancing our decision support to commanders,” explained Chudoba.
He added the Marine Corps wants to move from what he calls a “mall cop” environment—intelligence analysts trying to make cognitive sense of a single, limited-view input, like a mall cop monitoring a security-camera feed—to a multi-INT environment wherein analysts can get a more holistic view.
“We want to have a single integrated system consisting of a synoptic GEOINT layer on top of which we can toggle all the other intelligence disciplines in order to look at a problem from different dimensions and make good, timely, accurate decisions.”
With foundation GEOINT in place, the Marine Corps can now pursue DIB-enabled capabilities for other intelligence disciplines.
“DCGS started with sharing only GEOINT,” Snevely said. “We’ve since taken that model and used it to establish sharing in HUMINT, MASINT, and SIGINT. Each of those threads is growing and has its own level of success.”
What we’ve seen is an explosive growth in collected data. Historically, we’ve done what we had to do, which is throwing a ton of manpower at the problem. But we’re starting to realize that we need automation to assist. The goal is to remove hay from the haystack.
—Capt. Jeffrey Czerewko, Office of Digital Warfare within the Office of the Chief of Naval Operations
The Navy is focused on data fusion as it develops the next generation of DCGS-N. The Navy’s forthcoming upgrade, DCGS-N Increment 2, which recently entered its initial development phase, will likewise allow users to synchronize intelligence data from multiple sources within a single computing environment.
“I’m taking tools that sailors have seen, and I’m integrating them at the data layer so the individual can use them from a single work page without having to jump from product to product,” said Capt. Mark Kempf, program manager for the Navy’s Battlespace Awareness and Information Operations Program Office, which oversees DCGS-N.
In many ways, DCGS-N Increment 2 represents the future of the DCGS FoS in that it will embrace automation.
“What we’ve seen is an explosive growth in collected data,” said Capt. Jeffrey Czerewko, who serves in the Navy’s newly formed Office of Digital Warfare within the Office of the Chief of Naval Operations. “Historically, we’ve done what we had to do, which is throwing a ton of manpower at the problem. But we’re starting to realize that we need automation to assist. The goal is to remove hay from the haystack.”
DCGS-N Increment 2 will “remove hay” via real-time automated aggregation, correlation, and fusion of all-source intelligence.
“I want the analyst to be able to do analysis instead of having to do production,” Kempf said. “The button pushing should all be automated.”
Automation isn’t the only forward-looking aspect of DCGS-N Increment 2. Another is the way in which the program is being delivered: using an agile software development framework whereby new capabilities are tested by and delivered to users on a rolling basis through a series of incremental releases.
That approach to developing and acquiring capabilities is the future of DCGS and the key to DoD ISR interoperability, according to Wade, who says the entire defense intelligence community must go the way of the Navy by transitioning the focus from hardware to software. Consider, for example, the difference between navigating in your car using a dash-mounted GPS unit, like a Garmin or TomTom, versus a smartphone app such as Google Maps or Waze.
“The way we buy things right now in DoD is we buy Garmin- and TomTom-type systems. These are single-capability systems,” explained Wade, who said such hardware takes the DoD many years and extensive manpower to design, develop, manufacture, test, deploy, install, integrate, and maintain. “Contrast that to the Waze application that provides the same capability, but can be developed by a handful of people and deployed on millions of smartphones around the world in a matter of minutes.”
What’s missing, according to Wade, is the common IT platform—the DoD version of Apple’s iOS or Google’s Android—on which to run the software. “When you talk about the future vision for DCGS, what you want to have is a common ISR IT platform that you can rapidly build out with applications and services.”
That’s exactly where the Air Force intends to take its DCGS platform, according to Col. Kristofer Gifford, chief of the Air Intelligence Staff’s Multi-Domain Operations Division.
“Historically, the way we’ve acquired and fielded DCGS is like acquiring and fielding an aircraft carrier or a fighter jet, which is a five- to seven-year process of block fielding,” Gifford said. “At the end of that you get one thing: Everything from the tires to the software to the navigation system and the weapons is all rolled up. If you acquired [DCGS like a consumer acquires an] iPhone [then downloads apps], you’d break it apart into bits and pieces, and you’d field the separate pieces as you go.”
Across the services, the key to breaking DCGS apart is breaking it open. As in, open architecture.
Although the DIB and its core component, the Distributed Data Framework, unlocked the door to open architecture, they didn’t completely open it, according to Jerry Mamrol, director of ISR systems at Lockheed Martin, which helped develop the DIB.
“The DIB took an important step toward an open architecture by providing a standardized method to query and access finished intel product data,” Mamrol said. “This provided some degree of openness by enabling interoperability and sharing of finished products between the services via the DDF. For the architecture to be fully open, it also needs a standardized, common infrastructure that allows applications to be developed and ‘plugged in’ by different providers.”
A plug-and-play infrastructure will activate a whole new level of interoperability by way of flexibility.
“If you have an open architecture, you can horse trade what tools you like better for any given mission,” Love said. “You’re not going to send a really geospatial-heavy system out into the field, for example, because you won’t have the power you need and you won’t have the bandwidth. So, being able to use something that’s a lot lighter without having to change your data standards to make it happen is absolutely key.”
The weapons that matter most in the next war won’t be hardware…they will be software and data, and our decisive advantage will be how quickly our airmen can access, leverage, develop, and create those software and data.
—Col. Jason Brown, Commander, 480th ISR Wing, U.S. Air Force
Ultimately, DCGS open architecture will be similar to that of a smart home environment, according to Love. “There are five or six different standards out there for [connected home devices]. If you put all those in your house and you don’t have a way for them to interconnect, you’re going to need four different pieces of software to control your house, which is super irritating,” he continued. “Now there’s a single hub out there that accepts all the different signals so you can control your entire house with one app. It’s truly a system of systems.”
This plug-and-play approach allows data to flow freely between service- and mission-specific applications that can be created cheaper and deployed faster, according to Brown, who said the Air Force is currently piloting an “open architecture” version of AF DCGS, known as OADCGS, that allows airmen to develop their own scripts and apps.
“The weapons that matter most in the next war won’t be hardware—a stealth aircraft, a ship, or a tank,” Brown said. “They will be software and data, and our decisive advantage will be how quickly our airmen can access, leverage, develop, and create those software and data.”
Although technology will continue to advance the DCGS FoS, strategic governance will drive it. While there are several constructs through which the services manage ISR interoperability, principal among them is the Defense Intelligence Information Enterprise (DI2E), an umbrella under which OUSD(I) organizes and unites disparate defense intelligence systems, including the DCGS FoS. The DCGS Multi-Service Execution Team, made up of the DCGS program managers from each of the services, meets regularly to prioritize, establish, and resolve issues with DCGS standards, specifications, and architecture. This group operates under the auspices of a high-level governance group known as the DI2E Council.
“We use the DI2E Council to bring all the services together along with the [intelligence] agencies—anybody who has a role to play in DCGS—to make sure we’re [aligned],” said retired Air Force intelligence analyst Jack Jones, director of ISR infrastructure at OUSD(I). “Because if everybody’s in charge and has their own unique budget set and their own idea about where they want to go, then nobody’s in charge and you end up with non-compatible solutions.”
As the fountainhead of DCGS objectives, the DI2E Council is responsible in large part for the services’ drive toward open architecture, having laid out the standards by which such architectures will be executed. Likewise, it’s the driving force behind the next major milestone in DoD ISR interoperability: IT integration with the larger defense enterprise—via the Joint Information Environment (JIE)—and with the Intelligence Community (IC) via the IC Information Technology Enterprise (IC ITE).
“The challenge is making sure that as these large enterprise deliveries and concepts get put in place that they don’t ignore the need for interoperability to go all the way down to the Joint Task Force-level and below, which is where DCGS is,” Snevely said. “We spend a lot of time ensuring that IC ITE standards and specifications, and JIE vision, are going to be executable at the DCGS level.”
The challenge is significant, but so are the promised returns, according to Chudoba, who said a number of IC organizations already share intelligence products and data across the DCGS FoS via their own versions of the DIB.
“Stuff I previously had to request through formal processes and linear channels now can be exposed to me through the same methodology as commercial file-sharing capabilities,” Chudoba said. “The power there is incredible.”
Progress is incremental. Eventually, the IT standards enabling interoperability across the defense intelligence community will enable interoperability at a global scale, uniting the DoD, the IC, and even their international mission partners through shared data.
“We’re looking for ways for intelligence information to be readily shared at the appropriate level with partners in all regions of the world,” explained Snevely, who said such sharing would happen by automatically extracting intelligence from DCGS and distributing it within the combatant commands via the U.S. Battlefield Information Collection and Exploitation Systems program. “It’s very difficult to do, but that’s the future.”
A ‘Fungible’ Future
Good governance and cutting-edge technology have turned interoperability from an ethereal goal into a tangible reality. As a result, stovepipes are crumbling. And yet, work remains.
“I think we’re doing OK, but we have a long way to go,” Jones said, citing DoD’s size, complexity, and culture as major challenges to overcome on the way to increased interoperability. “We’re in an environment that’s used to building planes, ships, and tanks. Even with our ISR capabilities, we build a collector, a sensor, a link, and a ground station—a point-to-point solution. Instead, we need to be more focused on data as an asset. If we do that, then build backward, it won’t be about the collector; it will be about what we’re trying to do with the data. That, in turn, will help us get better synchronized.”
When that happens, DoD ISR will truly become a team sport.
“We’re evolving into an enterprise construct that makes intelligence capability and capacity fungible,” Chudoba concluded. “By that, I mean systems like DCGS give us the ability to play [young children’s] soccer when a problem arises. Most people say that in a pejorative fashion. To me it’s a positive thing. When a problem arises—when we see the ball—we can get everyone to converge around it and kick it into the goal. That’s what [interoperability] does for us, and that’s how we want to operate.”
The Army has not yet decided how to modernize DCGS-A amid ongoing litigation with Palantir Technologies Inc. The service declined an interview request from trajectory.