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.
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.
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
I've only dealt with mission command systems at the Battalion level and most of the time ended up reverting to analog systems in frustration.
To prepare a daily commander's update brief in CPOF would generally require each staff section manually inputting the information on to the single working CPOF system. Most of the time through a trained operator as the system is not especially intuitive or user-friendly and it's much faster to have that trained Soldier "driving" the system than each staff officer. That's assuming the CPOF system was working and hadn't missed out on some critical update that now made it incompatible with the Brigade (probably less of an issue for active duty units as opposed to Guard/Reserve).
I've yet to experience DCGS-A actually working with CPOF in a real-world environment. Usually the intel section ends up having to work directly in CPOF and manually copy information back and forth from DCGS-A – thus making it nearly impossible to provide anything close to real-time updates on the enemy and friendly situation.
Also, to setup the missions command systems at just the battalion level takes hours, sometimes days to get certain systems or connections up and running. Then there's the continuous battle of trying to maintain a digital and an analog common operating picture.
If only it was like the movies where everyone walks in, sets down a system in a box, opens it up, and magically a fully function command post is up and running. Complete with large digital displays with complete operating pictures pulled in from myriad sources and everyone able to instantly pull up any relevant data source.
From a network perspective, I completely agree. We spend as much time troubleshooting why the cpof isn't talking as we do troubleshooting the network pointlessly convoluted with products from as many different vendors as possible. That's before finding which piece of fraud, waste and abuse is currently broken, and bypassing it (Did you know that your satellite terminal has a switch with two unused ten gigabit ports, and that the switch itself is completely unnecessary?).
We need a common software suite, as well as a cleaner network setup.
The number of different systems and vendors is certainly a big part of the problem. An update to one system can break the connection with others – and if Company X broke Company Y's system, Company Y isn't all that inclined to spend time and resources fixing the issue.
The other end of the spectrum is if you have one vendor or one system then you're essentially held hostage by them and you can be sure they'll milk that contract for every dollar and probably end up being years late on delivery.
I'm not sure what the right solution is, but clearly it is not numerous proprietary systems that are inherently unable to communicate with one another. A common set of standards and system architecture that all vendors are required to utilize is probably the best solution. Everyone uses common hardware, i.e. Ethernet plugs and standard power plugs, why can't the software interface be standardized as well?
I'll bet your biggest hurdle to get over to get One Standard System will be all the different people with different solutions from different providers. Everyone will have their reasons why their solution is better (for a specific group and not the others) and will promise that it will convert easily. Most of the cheerleaders will be those getting ready to retire and get a job with that particular company. Don't forget that with more joint operations talking to the other services will also become a factor. Can a Army "Combat Smartphone" talk to a F-15E (USAF) or and F/A-18 (USN) over head? Can a Division level digital OPORD be filtered down to the company level automatically? Maybe part of the problem is going to fast to get big when you haven't even proven small yet. I retired a few years ago, but still think about all this.
What a great article! As a former S6 type, it was infuriating. I spent half my time in the field trying to get these systems to talk to each other even at a rudimentary level. The worst part was that the system could fail silently — the Intel or JBC-P feed would stop updating but neither fires nor I would realize it.
Doing briefs or orders on CPOF was a nightmare. Staff personnel would have to learn a completely new operating system to do basic tasks, and wait for one of 3 working CPOF machine at the BDE main CP to do it. Copy/pasting a large overlay often failed, and sometimes inadvertantly broke someone else's product.
At one point JBC-P became our true COP. Having a very limited — but rock solid reliable — COP that companies and platoons could use seamlessly was preferable We fought on that, radio, and unit internal email.
On point. We have a huge problem with system interoperability and training for each C2 system. Systems that you think should talk don't. As a BN S4 and HHC CDR my struggle was always JCR vs. JCR-LOG. These systems should talk, but if you dont hit that unclassified button, no resupply shows up to your company. The ease of access becomes a greater issue at the BN level when you factor in the CTCP, FTCP, MCP, and TAC concept. There are only so many systems and operators on the MTOE. So you not only have to fight all the other issues, but the limitations of your own MTOE of equipment and personnel.