Blog     e-Newsletter       Resource Library      Directories      Webinars     Apps
AFCEA logo

The Strong May Beat the Weak, but the Smart Defeat the Strong

April 2007
By Cmdr. Gregory E. Glaros, USN (Ret.)

Information architectures are needed for all platforms.

The U.S. Army and Marine Corps are shouldering the nation’s burden in Iraq and Afghanistan, and they are suffering the majority of their casualties from roadside bombs. To dramatically reduce injuries and loss of life caused by fragmentation and blast overpressure, the two services are rapidly fielding 4,000 to 6,000 mine resistant ambush protected (MRAP) vehicles. There is no question that the immediate fielding of these mine-resistant vehicles will help protect our nation’s most valuable military assets—service members. But is this the complete answer to a problem?

When these forces are on patrol, the most critical commodity besides leadership and training is information. It gives them an understanding of not just where the threat is but who the threat is and when it will be present. Most of this battlefield intelligence does not come from a magical data repository within higher headquarters, but instead it is generated directly by the troops in the field sharing with each other what they know, when they know it and how they came to know it.

The capability to mitigate the effects of an attack with armor is unquestionably paramount, but a system designed without the means to anticipate the threat is foolish. Trucks that cannot network, task, access, post, share and subscribe to the volumes of information present cannot be expected to win the fight—the only hope is to survive. If current designs such as the expeditionary fighting vehicle (EFV) are any indication of the “accepted” way to survive, then the U.S. Defense Department surely is doomed to repeat another dramatic system engineering failure.

As the enemy adapts, so too must our equipment. Tactical vehicles must have a networked information system as part of the vehicles’ basic design. Within its framework, each vehicle must have an information backbone that rapidly can accept communication, sensor and weapon advancements. Information flow by these systems has outpaced the ability to convert this power at our fingertips. Current bolt-on designs are killing us—they increase power consumption, increase weight, reduce reliability, delay fielding and increase cost. To keep pace with change, the MRAP vehicle needs a flexible information architecture that can be customized without significant integration costs. Vehicle system designs that cannot anticipate change or will not accept the speed of change simply provide our enemies with a steel-caged target.

The war’s asymmetry is not the threat as much as is our inability to keep pace with current operations. Information-livened capabilities demand rapid system integration for emerging operational markets. But writing a requirement for a system to satisfy an unpredictable or emerging threat is an illusive endeavor. Growing information throughput requirements, improved sensor performance and firepower reaction time increasingly are difficult to specify because of inherent uncertainty and ambiguity. The only successful path is to design and install a system that is capable of accepting software and hardware modifications without adversely affecting operational forces. An information databus designed to manage rapid technology cycles, mitigate operational uncertainty and reduce future system integration cost growth is a requirement by itself.

So what would this information backbone look like? All too often adjectives such as “open standard” and “open architecture” leave us wanting. There is little technical understanding of these terms—only expressed desire to employ them. The need for a databus that can manage ever-changing technology, missions and threats truly demands that the Defense Department awaken to its growing system engineering incompetence.

But these systems do exist. They contain clustered supercomputing power and genuine plug-and-play functionality with full internal and external networked connectivity. They inexpensively and rapidly integrate any Internet protocol (IP)-based weapon system, communication module or sensor package. They reliably share information between large numbers of unmanned systems, and they remotely control a wide array of onboard and offboard sensors and weapons without additional cost to the architecture. But these systems did not come from within the acquisition system. Instead, they came from government mavericks and Defense Department academics. The department needs only to open its eyes to the progress made in this area and to the existence of these advanced systems.

The contribution of information architectures will be not only the ability to easily control organic intelligence, surveillance and reconnaissance assets or to access global intelligence sources rapidly, but also the lasting value of distributed forces able to survive complex urban environments better. Geographically dispersed units must have broader operational options not just to survive an attack but also to counter an adversary’s constantly changing tactics.

We are on the threshold of command and control chaos because too few investments have been provided to the “art and science” of information system engineering. Large numbers of shiny things on the battlefield, while a distinct advantage, burden dismounted forces unless they are horizontally networked from the start.

Before MRAP vehicles are sent forward, let us take advantage of the technical superiority that government institutions already have advanced and leverage the power they have developed. Don’t just send a strong but dumb truck in harm’s way and think the problem is solved. The enemy is smarter than that.


Is the military heading for a systems engineering failure? Can our equipment keep pace with the changing face of the enemy? Is information needed for protecting the troops as important as mine-resistant vehicles? We welcome your comments on the SIGNAL blog at, or e-mail us at

The opinions in this column and on the SIGNAL blog are those of the authors and do not necessarily reflect those of SIGNAL or of AFCEA.