Many of us can remember when the personal computer was new to market, especially the frustration of sending data between computers with different features and operating systems. A Microsoft Word document created on a PC would look like hieroglyphics when opened in Apple. We all wondered how this could be possible; they all write in English! Technological interoperability in the private sector has advanced since then; but for those of us in the military, the Digital Mission Command Information Systems (MCIS), on the other hand, have not. Just like early incarnations of computer tech, the systems our force relies on to provide automated support to operations render each other’s messages in what essentially amounts to wingdings.

Digital systems within Army operational and tactical command posts are pitched as providing decision-makers with critically needed data at the speed of information to outthink the enemy. The Army additionally claims these systems aid smaller staffs in accomplishing more work at higher tempo with more consistent results. The fact is, however, the currently fielded suites of MCIS (formerly the Army Battle Command Systems) do not fulfill these claims. The new Command Post Computing Environment program of record can fulfill the promise of MCIS, but only if it overcomes the existing flawed integration and interoperability strategy and evolves into a unified computing environment that spans all information sources and products.

The Diamonds are Stuck in the Computer

The intelligence warfighting function—one of six doctrinally defined warfighting functions—uses a suite of systems together known as the Distributed Common Ground Station–Army (DCGS-A). While continuously updated since 2006, it is a new facade on a technically ancient construct. The same corporations that pioneered and built the All Source Analysis System in 1984 designed the framework of the core DCGS-A system: the Intelligence Fusion Server. The two systems are essentially one in the same. Furthermore, the Analysis Control Element Block-II has only been retired this year as the main bulk data processor on DoD’s Top Secret network. The behemoth of ACE Block-II was first coupled with the All Source Analysis System suite in 1996 and was “validated” in the “first digital division,” the 4th Infantry Division.

There has been no true update to the foundational operating parameters of DCGS-A from these origins. Analysts still have to integrate six to ten major end-item servers and systems-of-systems, just to execute cursory intelligence functionality at echelon. These systems acquire, process, exploit, and disseminate intelligence information on three different classified networks: SIPR, JWICS, and NSANet.

All-source analysts create a consolidated enemy picture on the Intelligence Fusion Server once all single-source exploitation and analysis is complete. It is this that is sent to all the other MCIS via the Digital Distribution Service (DDS). The point of dissemination is where the flawed strategy of digital mission command becomes clear. Any problems with the Intelligence Fusion Server, the DDS, the routing, or the receiving MCIS will cause enemy activity reports (represented by red diamonds) to remain stuck in the intelligence MCIS. All these issues exist for want of true interoperability.

Picture a UN Security Council Meeting . . .

First fielded in 1996, the bulk of the Army’s MCIS originated at a time when floppy disks were still standard forms of exchanging data. Each system has had its upgrades, but the governing principles of interoperability remain as ‘90s as America Online and dial-up internet.

Each MCIS is a stovepipe of self-contained data because the systems were, and remain, independently sourced through DoD procurement law. No MCIS is built to directly work with or support any other system. By design all MCIS alternatively work through the middleware of the DDS. This concept briefs well and even tests well in laboratories. However, it does not execute at the speed of mission command in a distributed, disconnected, intermittent, and low-bandwidth environment under stress.

Essentially, the current construct of MCIS operates like a meeting of an international body—say the United Nations Security Council. Members sit around a table, just as different components of the MCIS connect to the others. In the Security Council meeting, members might all speak their native languages, relying on interpreters whose voices they hear through earpieces to relay and organize everything. Everyone claims to be able to speak with other members, but the reality is they only speak and hear through interpreters; for the MCIS, that’s the DDS.

This antiquated, and now flawed, strategy prevents the formation—at the speed of information—of a common operating picture that is truly “common.” Commanders are nearly forced to direct staffs on what needs to be depicted on the common operating picture. Staff soldiers then have to fight the system to give the commander the requested information to achieve situational understanding. In most cases, soldiers fight the systems more than they fight the enemy. These issues are so common that soldiers have built muscle memory to bypass their MCIS by using chat, email, and swivel chair (manually re-creating data between multiple machines) methods.

The foundation of the Army’s MCIS strategy is in such a state that any system or software added to it simply adds to the problem. It becomes something else soldiers have to maintain, integrate, exchange through temperamental DDSs, and confirm receipt of on another system. This is because the Army’s current method of procuring MCIS technological solutions is set up to deliver the equivalent of yet another native-language-speaking member to the Security Council instead of building a truly collaborative environment.

Figure 1. Portrayal v. Realities of MCIS


Doing the Same Thing Over and Over and Expecting Different Results

A new phrase has entered the vernacular of service members involved in resolving the Army’s MCIS challenges. Those service members are to “reduce the cognitive burden” for Army formations. The reference underscores the need to field capabilities that help soldiers think less about how to get data or where data comes from, and focus more on relaying what data means and how to exploit situational dominance.

However, the current MCIS strategy, combined with smaller manning among staff sections, is actually increasing the cognitive burden. Since the current batch of MCIS is from the 1990s, we can look at the Army Research Institute’s 2002 review of the first digital division for insights into longstanding challenges that need resolution. The review highlighted issues including manning and personnel challenges, the importance of mentorship and training, and more. The summation of these long-standing challenges is as follows: First, the current MCIS strategy requires near full staff manning at all times and that those soldiers must work exclusively from their MCIS workstations to maintain proficiency. Second, the strategy of integrating the MCIS suites requires such expertise that operators are at risk of focusing more on the system than their staff role. Third, the systems are so labor intensive they inhibit the simultaneous updating of digital and analog common operating pictures. Fourth, new systems and modifications to the current MCIS strategy put increased pressure on the command post’s already strained Achilles heel: the G6.

In short, the current MCIS strategy cannot be sustained to overcome manning constraints, keep pace with dynamic warfare in multi-domain environments, operate in distributed mission-command nodes in a disconnected, intermittent, and low-bandwidth environment, and aid in removing the cognitive burden on the staffs of Army units.

The Army Needs an Actual Computing Environment for the Command Post

The new MCIS is the Command Post Computing Environment (CP CE). This system is supposed to augment the capabilities of the current Command Post of the Future to the point of nearly replacing the system. Initially intended to resolve many of the challenges outlined above, Warfighter Exercise 19-4 proved the system is yet another native-language speaker—to continue the Security Council analogy—destined to repeat the mistakes of the past.

Soldiers have to work to integrate a new suite of workflows across an overly complicated network and still tether everything to the DDS. When issues arise with getting information to project on CP CE, soldiers have to immediately get with the G6 and troubleshoot. The familiar (jargon-heavy) refrains ensue: Is the JBC-P feed making it to GCCS? Is GCCS parsing to the DDS? Is DDS corrupting? Is the DDS advertisement coming into CP CE? Is the CP CE server having issues? Is message traffic being sent in USMTF 1998, 2000, or 2004 format? Is the security wrapper an issue? Is the message USMTF, VMF, SADL, or any other military-standard format? Are the symbols CS 11-12 or CS 13-14? Are the graphics sent from DCGS through the DDS to CP CE three-point or two-point render? Are the maps not displaying because of a file upload or Web Mapping Service limitation issue?

Hardly out of the gate, initial trials suggest CP CE is a casualty of a challenged MCIS strategy and an acquisitions process which seeks to bring too many uniquely engineered capabilities together to achieve common or unified understanding without a drastic, bottom-up, strategic refashioning. Users and maintainers are already cognitively strained, commanders short on situational understanding, and decisional advantage lost by the time all the kinks in feeding CP CE are resolved.

The ideal solution is for MCIS to stop being individual Mission Command Systems and become one unified Mission Command Information System. CP CE should be the ecosystem from which all staff warfighting functions operate. There should be one set of servers managed by the G6, with all command post users establishing client relationships directly to it. Within CP CE, the G2’s geospatial intelligence team should manage the single map service that the entire staff uses. Fielded to all staff soldiers are generic workstations with baseline warfighting-function applications that plug into the Battle Command Common Services (BCCS) stacks and launch CP CE. The G6 and warfighting-function content managers grant rights and privileges to each user to ensure sensitive source material is not exposed. All warfighting-function-specific software is embedded in the BCCS stacks and implicitly interfaces with the common CP CE open software framework. This would mean all the data simply exists and transfers between Mission Command applications without operator interface or DDS exchanges.

Just as every application on a smartphone works and automatically exchanges data, warfighting-function applications should ride and exchange data within CP CE. Data should be ubiquitous, only requiring permissions and user-defined filters from which to generate information. Metaphorically, the simple solution to the current MCIS challenge is for CP CE to act as the base map and the Modified Combined Obstacle Overlay, while the embedded warfighting-function applications operate as acetate layers. The key is a unified environment within which all software exists. Everyone shows up to the Security Council meeting speaking an agreed-on common language or they do not show up at all.

Figure 2. Possible CP CE setup for true computing environment


Digital Mission Command has aided the Army in attaining situational dominance, but at a significant cost that burdens ever-shrinking staffs in a dynamic environment. Technological advancements since the inception of the Army Battle Command Systems in 1996 provide an opportunity to reduce the cognitive burden of the staff to fight the enemy more than the system. To achieve decision-making dominance, CP CE must use a new strategy to form a true command post computing environment anchored on integrated, open-framework Mission Command software, not based around independent warfighting-function systems.


At the time of this writing CW3 Garrett Hopp was an All Source Intelligence Technician (350F) assigned to III Corps G2. He is currently transferring duty stations to JBLM, WA. His previous assignments include III Corps G2, 82nd ABN DIV, 1/2ID ABCT, and 1st CAV DIV. He has served in multiple deployments to Iraq and a rotation to Korea, and is a Digital Intelligence Master Gunner.


Image credit: Sgt. Anthony Bryant, 4th Infantry Division