subscribe  |    email  |    print  |    continue the debate

In the spring of 2005, a tactical problem met a technical solution. While working as a program manager in the Information Processing Technology Office of the Defense Advanced Research Projects Agency (DARPA), Mari Maeda began speaking with soldiers returning from Iraq and discovered an operational need: Soldiers at the battalion level and below needed additional information technology to better conduct counterinsurgency operations.

Every day, soldiers were learning about their operating environment and their enemy. The knowledge they gained while on patrol or conducting a mission could mean the difference between life and death, mission success or failure. However, they had only limited information technology assets available and none properly suited to the challenges of counterinsurgency, where information must not only be passed between echelons, it must be shared laterally between small units and stored for replacement units.

Troops in theater had been creative in their approaches to the challenge. Some units developed databases employing Microsoft Access, some used massive spreadsheets linked to relevant files, others simply did things the old fashioned way — with filing cabinets full of paper reports. One of the more creative and well-resourced approaches was the development of CavNet by the 1st Cavalry Division. Developed entirely in house by 1st Cavalry, CavNet was essentially a collection of blogs and forums that allowed junior leaders down to the squad level to share information with one another across the entire division. It was so successful that various forms are still in use.

Although CavNet and its successors allowed information-sharing, they lacked a robust database for multimedia and reports. Patrol debriefs and other important reports could not be easily stored and disseminated. Information on friendly and enemy actions, local personalities and local infrastructure was simply lost as a result, particularly when a unit left theater. Seeing gaps in capability and a clear operational need, soldiers from the 1st Cavalry Division teamed with Maeda to work on what would be called the Tactical Ground Reporting system, or TIGR (pronounced “tiger”).

TIGR was an atypical project for DARPA, which generally conducts research and development on technologies that won’t become widely available for 10 years or more. DARPA traditionally has been the futurist arm of the Defense Department, while service programs of record have filled the role of near-term development of technology. However, given the ongoing wars in Iraq and Afghanistan and the greater war on terrorism, DARPA leaders were encouraging program managers to “fast-track” new technologies to the troops.

As Maeda began her work, operational needs in the realm of information technology received attention from three other organizations: the Army’s XVIII Airborne Corps, Central Command and the Marine Corps. Each effort began independently and focused on enhancing information storage and dissemination at different echelons. Although the projects resulted in differing products with differing levels of success, in all cases, relatively innovative approaches were used to get information technology to the field as rapidly as possible.

MAP-CENTRIC SOFTWARE

TIGR is map-centric software developed to aid information-sharing at the battalion and below, with emphasis on the squad and platoon levels. Along with Force XXI Battle Command Brigade-and-Below (FBCB2), it is one of very few pieces of information technology created for small units. To develop TIGR, Maeda built a team of programmers who worked directly with soldiers from the 1st Cavalry Division. As new versions were developed, 1st Cav tested them in exercises at its home station and at Army training centers. The goal was to have the system ready for the division’s deployment in early 2007. By working directly with the soldiers who would use the software, developers were able to meet a one-year development schedule and to create a system meeting or exceeding user requirements.

The rapid fielding schedule and unorthodox development method meant TIGR had not gone through all the normal development channels. TIGR was not a program of record. It did not have Army support for fielding, and it was not initially sanctioned for use over wireless tactical networks. The system would only be used within 1st Cav, and network use would be limited to a few base camps in Iraq.

However, there was enough backing for the program within 1st Cav that the division helped fund the program, developed standard operating procedures and encouraged use down to the squad level. To ensure the system could be maintained in Iraq, DARPA teamed with Lt. Col. William Garland and Lt. Col. Timothy Abbott of the Rapid Equipping Force, which provided critical support and funding to send a training and engineering team to theater.

Among users in the field, TIGR has been a success. It is routinely cited for saving lives and being an indispensable tool for effective counterinsurgency operations. A user-friendly, map-based graphic user interface, flexible reporting and search tools, and the ability to store multimedia are cited as strengths of the system. TIGR has a decentralized server architecture that allows for relatively low bandwidth requirements and for operation even when networks are down. However, the most important aspect is the ability to share information with any other user, be they peers or from a lower or higher echelon. Every user has access to a common understanding of the battlefield.

Though popular with troops in the field, TIGR gained support within the Army more slowly. The unorthodox fielding method put it outside of the normal acquisition system. In addition, the capabilities that make it popular — principally the ability to share information across all echelons — are somewhat at odds with standards for the sharing of classified information. In spite of setbacks, the program appears to be reaching a tipping point and is scheduled for fielding to most of the brigades in Iraq by early 2009. In the meantime, DARPA will continue to develop the software and its capabilities.

FUSIONNET SOFTWARE

FusionNet was developed by the staff of the XVIII Airborne Corps in conjunction with CC Intelligent Solutions, a private software-development firm. FusionNet was a means for the corps to streamline the bottom-up flow of information typical of counterinsurgency and help it develop a common operating picture across the theater. Interestingly, work on FusionNet began in 2001 based on observations of requirements for operating in Afghanistan and it was first fielded to Afghanistan in 2002. It was also fielded to Iraq during the corps’ first rotation as Multi-National Corps-Iraq, where it provided a central repository of vetted reports on enemy activities and offered a means for corps-level staff to track and tap in to certain other reports and databases.

FusionNet was similar to TIGR in that it was Web-based, though it differed in that it employed a centralized server architecture. Like all software used over tactical networks, FusionNet had to conform to the bandwidth limitations of the network. In spite of the Army being increasingly networked and reliant on information-sharing, much of the equipment used to create the network was old, bandwidth was limited and care had to be taken to avoid crashing the system. Though FusionNet was developed and fielded with astonishing rapidity by military standards, it had not yet been officially certified for use on Army networks by the Army G-6 (information management). The corps commander made the decision to operate FusionNet “at risk” and thereby bypassed the G-6 certification process. Primarily because of this, the system became unique to XVIII Airborne Corps and has been phased out in Iraq and Afghanistan.

Following the departure of the corps, the Combined Information Data Network Exchange (CIDNE) came into prominence. Developed by Intelligent Software Solutions in conjunction with III Corps and championed by Central Command, CIDNE is a Web-based system with similar attributes to FusionNet, but with enhancements such as a leader engagement tool. Like FusionNet and TIGR, CIDNE incorporated commercial off-the-shelf technologies in a novel way. With four major releases since fall 2006, CIDNE has become standard for enemy activity reporting in Iraq, though it has not been adopted Army-wide. Like FusionNet, CIDNE has a suite of tools generally used at brigade and above. Discussions are underway for linking CIDNE and TIGR to address the needs of higher-echelon staff users that CIDNE serves and the patrol leaders that are served by TIGR.

MarineLink was conceived about the same time as TIGR and CIDNE. MarineLink is similar to the other programs in that it is a web-based system developed by a small team of software engineers working directly with troops in the field to fill an operational need. What really set MarineLink apart was the rapidity with which it was adopted across the Marine Corps and became ubiquitous among Marine units. In contrast, FusionNet essentially ceased to exist outside of the XVIII Airborne Corps, while CIDNE and TIGR are generally restricted to Iraq.

What made the difference was the fielding system the Marine Corps had in place for networked software. While the requirements are the same as those for the Army — with regard to bandwidth, information security and other requirements — the Marine Corps has put emphasis on expediting review and approval for new systems that meet operational needs in the field. The result is Marines have the information technology they need down to the lowest level and have in place the infrastructure to support the program worldwide.

Fielding new equipment has never been a simple process. Multiple staff elements at multiple echelons are involved, and many different technical and administrative requirements must be met. It is no different for information technology.

WARTIME FIELDING

Wartime fielding of information technology begins with an operational needs statement (ONS). A commander at any echelon determines he has a gap in capability and issues an ONS detailing the requirement and, in some cases, describing the exact equipment desired to fill the gap. In the Army, the ONS works its way up a chain of command until it reaches Department of the Army headquarters. There, the Army G-3 (operations and plans) staff reviews needs statements on a weekly basis. If validated by Army G-3, resources are allocated to fulfill identified needs. The process from identification of an operational need to resourcing by Army G-3 generally takes 60 days or more, depending on the priority of the requirement.

After a program or technology is resourced for wartime use, it is reviewed semiannually for adoption as a program of record through a process called Capability Development for Rapid Transition. This process entails Training and Doctrine Command recommending the program to Army G-3. The program is again validated by G-3, and resources are allocated for Army-wide adoption. The Army vice chief of staff must ultimately approve adoption.

But G-3 is not the only group that must approve a system. For information technology, G-6 is also involved. As described earlier, information technology employing networks must be certified to ensure interoperability with information infrastructure and systems. The process can take a year or more and does not prioritize systems requested by units in combat. Commanders may take risks and allow the use of uncertified systems in theater with approval of their combatant command. However, wider adoption of a technology outside of the theater or as an official program of record requires G-6 certification. The flow becomes: ONS written by unit with a requirement; ONS approval by service G-3; theater approval for networks; combat command approval for networks; G-6 certification. FusionNet, TIGR and CIDNE were able to reach theater rapidly because theater commanders approved “at risk” operation. They are still bogged down with further certification.

Though the Army has made an effort to streamline its acquisitions process and had some successes, the process for information technology remains slow. It is important to protect networks, to ensure unity of effort and to ensure IT platforms can communicate with one another. However, the process could be made to operate more efficiently. With MarineLink, the Marine Corps demonstrated an ability to do in months what takes the Army years.

TECH-SAVVY ENEMIES

A great deal has been made of the “revolution in military affairs” that accompanied the incorporation of information technology into U.S. military forces. We must keep in mind a similar revolution has occurred among the nonstate enemies the U.S. is confronting in Iraq, Afghanistan and the wider war on terrorism. Our enemies have access to wireless communications, satellite communications, the Internet, computers and many of the same software tools used within the military. They have relatively flat hierarchies, so information can flow quickly from one group to the next. Attacks can be planned and coordinated via e-mail, executed with the assistance of cell phones and reported for propaganda value on a Web site.

The information technology employed by insurgents and terrorists is easy to use, inexpensive and readily available via commercial channels. Because these are relatively small organizations, they are able to upgrade capabilities rapidly. Terrorist and insurgent organizations have shown themselves to be extremely adaptable in their use of IT: propaganda has been spread via YouTube, digital videos have been e-mailed to major news networks, cell phones are used to detonate improvised explosive devices, and Google Earth has been used to plan missions and target artillery attacks. Lacking a hierarchical bureaucracy and rules for IT acquisition, small groups of terrorists or insurgents simply procure what they need and upgrade their capabilities as new technology becomes available. Information can be disseminated relatively freely without necessarily having to be cleared through a hierarchical bureaucracy. In these areas, it seems, they have an advantage over the U.S. military.

The military’s challenges are similar to those of any large organization adopting IT in a competitive environment: How do we keep our system of systems relevant and effective given the rapid pace of change in technology? Smaller, less-hierarchical organizations, such as terrorist groups, have a natural advantage in adoption of new technologies. Adoption, training and fielding can be accomplished in a much shorter period of time and with far fewer resources required.

To maintain an information edge, the U.S. military must be able to keep pace with much smaller, nimbler organizations. Lessons taken from experience developing TIGR, FusionNet, CIDNE and MarineLink indicate we can do much better in this. The U.S. military has its own advantages that can be exploited: a tremendous research and development budget and direct access to developers. Americans invented much of the IT powering the world today, and the U.S. is home to thousands of brilliant men and women creating newer and better hardware and software every day. During wartime, the military can harness these assets by bringing the scientists to the troops. This is precisely what happened with all of the software explored in this article: Troops in the field identified a way to operate more effectively and worked directly with software engineers to rapidly develop the means.

BEATING BOTTLENECKS

Getting scientists and troops together is not enough, however. Other steps are necessary to get software fielded in a timely fashion. The examples in this article demonstrate that the military can develop software relatively rapidly and inexpensively. Bottlenecks in the acquisition system may unnecessarily slow development and fielding, however. For instance, the Army gives no special priority for the certification of networked hardware or software specifically designed for troops in combat. It can take months or years of testing and evaluation to officially clear systems for the field. In contrast, the Marines and Special Forces have created fast-track certification for wartime IT.

Another lesson learned is to maintain teams dedicated to rapidly upgrading software. TIGR, FusionNet and MarineLink all met this challenge by having a small team of programmers and support personnel dedicated to continuously upgrading the software based on input from troops. These personnel were split into two groups. The first group forward deployed to provide direct support to troops and collect feedback. The second group provided updates and patches to the software from the U.S. as it was needed.

The software explored in this article also demonstrates the value of Web-based databases for counterinsurgency. Various developers independently arrived at Web-based solutions because of their flexibility, ease of upgrade, relatively low bandwidth requirements, protection of data on physically secure servers and ease of distribution. An added bonus is that units can monitor events in theater from their home station while preparing for deployment.

Finally, information must be allowed to flow freely from peer to peer and between echelons in counterinsurgency operations. Tools such as TIGR allow platoon leaders on opposite sides of Baghdad to share information on new tactics without ever meeting one another, for a brigade S-2 to push intelligence to line companies, a battalion S-3 to pull patrol reporting of interest and for a new unit coming in to theater to monitor the fight before deployment. Tools such as CIDNE allow a commander or staff officer to track targets and civil affairs activities with a few mouse clicks. In short, the bottlenecks to information flow are removed, enabling U.S. personnel to learn and adapt as rapidly as their adversaries, or more so. This does not mean allowing an information free-for-all. There must be procedures in place to ensure the quality of reporting and security of information. The information must be allowed to flow, however, or we will be at a permanent disadvantage.