Section 3: Information Processing

"Finding the right piece of information, analyzing it correctly, and getting it to the right customer in time are turning out to be bigger problems than collecting it in the first place."
- Alvin and Heidi Toffler, 1990

Anyone remotely associated with tactical situation management or intelligence will recognize the truth of the above statement. CIC's, Flag Plots, and similar spaces are usually flooded with data. Afloat commanders often operate under the principle of "give me everything and I'll sort it out", only to find that most of the data goes into the byte bucket without ever being looked at. The overworked OS, IS, EW, or CT at the front end simply does not have the time or tools needed to adequately sort through the firehoses of data from multiple sources. As a result, the "golden nuggets" of information that could make all the difference in a tactical situation are often not discovered until well after the fact, if at all.

Fortunately, there are a number of efforts underway to begin to address the problem. New attitudes towards system development are addressing such major issues as interoperability, data sharing, and ease of use.

On the technical side, for example, the Copernicus architecture, with its implementations in the Global Command and Control System (GCCS) and the Joint Maritime Command and Control System (JMCIS), has institutionalized the concepts of interoperability and rapid development. The old stovepipe approach is finally being reduced if not abolished. We are making significant strides toward full interoperability with the other services and with supporting agencies. There is still much to be done, but the Washington mindset has clearly shifted into implementing these much-needed changes. For the information warriors, this will result in significant improvements in the ways they access, manipulate, and use information.

Most data processing systems these days rely on advanced and complicated software. Software, however, has a significant and fundamental problem with bugs. A “bug” can range from a coding error, to a feature used in a different way than originally intended, to a deliberately-planted bomb. Virtually all programs have them, and the longer, more complex, and more involved an operating system or a program is, the more bugs it will have. In any program with more than just a few lines, it becomes literally impossible to test a program for all its faults. The developer considers himself lucky to catch the major bugs before shipping the product. Users will find more, even in corrected versions, for as long as the program is used.

This problem is not unique to the military. It is endemic to commercial software development as well. Even Microsoft is not immune: its latest major product (Windows95) was delayed a number of times and was still shipped with some serious flaws.

Complicated computer systems, with their attendant bugs and "undocumented features", have several important effects in information warfare. First, there will always be openings to break into systems, bring down systems, and confuse systems. The openings may be in the hardware, in the operating systems, in software applications, or in system administration. It is virtually impossible to ensure that all doors are closed. Second, and closely related, our own hardware and software will contain errors that affect our data processing results even without enemy interference (the Pentium chip fiasco, for example). Third, deliberately-planted bugs may or may not be detectable. Virus-scanning software can only search for known characteristics. Viruses, Trojan horses, worms, or other creations that have not yet been documented can easily slip by most scanners. Fourth, it is impossible to completely test the systems we design for errors, and we cannot be 100% sure that our systems will work right. Ask the pilot of an F-22, which is essentially a “flying chip”, whether that's important.

Thorough software development takes a long time to ensure adequate performance and security. Many users believe it takes too long and that by the time the product is released it's obsolete. The concept of "rapid prototyping" was introduced to try to answer this concern. Rapid prototyping essentially moves a relatively untested beta system to the users for early evaluation and testing. While this can sometimes have significant benefits (JSTARS and TIBS are examples from the Gulf War), more often the early prototypes take on a life of their own, resulting in frustrated users crying out for a system that doesn't crash, is user-friendly, and can be supported. Untested systems are also unsecured systems: the more prototypes in the field, the more holes in our data defenses.

Our information warriors are now starting to get better weapons with which to prosecute their battles. As we develop better methods of acquiring and manipulating information, we must also maintain an awareness of how these new tools can be used against us.

Previous Section | Article Main Page | Next Section