Admiral, ladies, gentlemen, my name is Tacto. The system I will describe has been at sea on three test ships for more than a year. It has received excellent reviews and has performed so well that commanding officers have installed stations in their cabins. On one ship, the embarked commander relocated a station for his staff's use. Based on commercial off-the-shelf technology, it has reduced operator workload significantly and has the potential to reduce manning. It has been developed for under a million dollars; units can be obtained for as little as fifty thousand dollars; and further expansion is very easy.
Do these words sound familiar? They should, because we are hearing them more each day. The pitch is all true, but unfortunately, it is only part of the truth. As operational leaders become more technically aware, they must be cautious not to assume that the average user can do what the supertech computer geek giving the show can do.
Building the Techno Horse
The process begins with a team of tactically proficient and technically excellent implementers. The tactically proficient members focus on a specific problem and the technically excellent implementers develop graphic displays, data bases, and interfaces to solve it.
The next step is to convince someone with the problem to support a prototype effort. Once the prototype is installed, the users are briefed on how it will help them. As prototyping proceeds, errors arise. If they are critical, the design team fixes them. If they are not, the team comes up with a work-around and indicates that it "will fix it in production." In the meantime, the development team is creating even more features.
This fix-and-improve process has several results. First, the users get confidence in the system. Real improvements in capability are attained as they put the system through its paces. Over time, a few will become the ship's "experts," and others will rely on their expertise. As the "experts" continue to work with the design team, lessons get learned faster and the fixes fine-tune system performance.
At this point, the test users are asked to write a report on the prototype system. Assuming that the design team is competent, the "experts" will describe how they used the system and how it solved their problems. They also will identify things that could help make it even better.
Armed with several favorable reports, the design team recommends implementation. They know there are some problems, but they are easy to fix. They also have a list of added features the fleet is requesting, and these are said to be attainable in short order.
This is the critical moment for the presenters. To continue, the presenters must provide the benefits. In too many cases, however, they imply that the system can solve a host of other problems, as well. They compound the problem by minimizing the troubles and limitations they have encountered. If they are too candid, the decision maker will hesitate and the sale will fall through.
At this point, the decision maker needs to go through a critical assessment—based on fact, not potential.
What's Actually Inside?
In a recent article entitled "Moving to the 3rd Stage," Admiral Archie Clemins listed "Seven Habits of a Highly Effective Fleet Information Technology System":
- If the boss doesn't use it, don't buy it.
- We must integrate the tactical and nontactical.
- We must stay common with industry.
- We must drive everything to a single PC.
- We must use commercial off-the-shelf (COTS) products for almost everything we do.
- We must have seamless transition from shore to sea.
- We cannot allow stovepipes to develop within our C4I architecture. We must buy icons, not hardware.1
These are admirable goals, but not facts, and each raises additional questions:
- The boss can use it, but can subordinates? In today's technical Navy, the officer corps is reasonably computer literate and rapidly becoming more proficient. This does not and—despite our sincerest wishes—will not extend completely to the enlisted ranks. Imagine, for example, that you are the first lieutenant. You want the BM2 to update the Abandon Ship Bill with graphics of the life raft and motor whaleboat locations and a spread sheet linked to the most recent inventory of the survival equipment. This probably will not happen unless you do it yourself. As another simple experiment, ask ten people who use word processors if they know how to generate a table of contents and show a document revision history.
- What is the line between tactical and nontactical? There must be a way to distinguish between real-time, near-term, and as-available information. Real-time tactical data are required to do such things as putting guided weapons such as SM-2s on target, providing target deconfliction, and controlling aircraft. Near-term strategic data are required to put forces in position, target intelligent weapons such as Tomahawk, and ensure that logistic support is coordinated during an engagement. As-available information includes such routine matters as personnel transfers, payroll, and other administrative tasks. If the integration of these information users and providers is not handled carefully, real-time data will be preempted by routine information. In one instance a ship on counterdrug surveillance operations was having trouble getting shipping data through the joint operational tactical system (JOTS) because of the message traffic load. That same ship didn't help matters when it used JOTS to arrange a personnel transfer scheduled for a week later.
- Is there really a civilian counterpart? The military is a niche market; commercial systems may do similar things, but will they do everything necessary, on the scale required for military application? If not, will vendors be willing to make the necessary changes? Consider vehicle tracking systems. There are commercially available systems that receive GPS updates from vehicles and plot their locations. But the military might need updates every 1-2 minutes instead of every 10-15 minutes. Those minutes could mean the difference between bombing the retreating hostile tank column and bombing our own advancing tanks. We also handle several thousand vehicles in a smaller area, track their fuel and ammo, and link them with resupply and repair schedules.
- Can a PC handle the load? For as-required strategic and nontactical applications, a PC-based system may be adequate. For real-time tactical applications the processing requirement is less likely to be met in the near future. One issue is the suitability of software to meet the needed data and security loads. Military weapon systems are enterprise systems that have large numbers of users and require high levels of security and reliability. At present, these capabilities are available in UNIX-based systems but not in Windows 95 or Windows NT. In other words, the pure PC environment is not ready for the demands of real-time tactical operations.
- Can we afford COTS? Today there are more computers running Windows 3.1 than Windows 95—because owners cannot justify the cost of converting. It seems ideal that we can just take a piece of equipment to the local repair shop to get it fixed, but what happens if they don't make it any more? The SQQ-89 project built a system entirely of COTS and TAC-3 components. One-third of the way through the production run, before units were ever installed, the computer and monitors were taken off the market. In addition, the replacement computer used a different set of "commercially standard" connectors, meaning that wiring harnesses had to be redesigned. To maintain configuration management, the program office is removing the old computers and backfitting new ones—at a cost close to half a million dollars, excluding the expense of actually performing the modification. The entire cycle occurred in under four years.
- Is it solving a problem or using technology just because we can? A laboratory and prime contractor set up video conferences to reduce travel costs. This involved a significant effort to coordinate schedules and to arrange for the equipment at both locations. After several meetings it became apparent that a telephone conference call and fax machines were both adequate and easier to set up.
- Is it information we need or just information? Gulf War reporting made a great deal of the fact that we could see our smart weapons' video. Should we take that a step further and transmit that video to the battle group commander for real-time decisions? Consider this scenario. An attack is launched and the weapons' real-time video is sent back. One weapon stops transmitting just after its final maneuver; the other is seen to "hit" the target. Which target gets reattacked? Now consider that it was the transmitter in the first weapon that failed and the fuze in the second.
Further complicating this issue is information "push" versus information "pull" and data bandwidth to support it. In push, a source presumes which users need which information and automatically sends it to them; in pull, the consumer asks for specific information. Recent articles reported on unanticipated problems with the latest Microsoft web browser, which set up push situations for its users, which in turn caused a dramatic increase in the number of data calls. Response time slowed and many providers had to upgrade their servers. In other words, getting "information" sometimes can just thicken the fog of war.
After the Geeks Depart
The decision maker must consider all of these issues before making a commitment. In particular, going from the micro to the macro is a very risky undertaking, whenever exploiting personal skills is involved. It is important to go back to Mr. Tacto's effort, to see what happened to the test ships and the project after he left.
As the project progressed, time and assets could not support all three ships. In addition, Tacto—because he was just "prototyping"—had not been concerned about all the little things that did not work quite right. Without hand-holding from Tacto, lacking visibility from higher command to encourage them, and frustrated by the minor problems, the operators had to revert to earlier methods to ensure that they could perform their mission. The "technology improvement" became extra effort—and eventually was ignored.
This is not hypothetical. The two ships were the Stump (DD-978) and the Fletcher (DD-992) and the system was the prototype AN/USQ-132 Tactical Decision Support Subsystem. Because of the efforts needed to convert from prototype to production, the system could not be supported. When the decision was made to remove the prototype hardware, there was no complaint from the ships—the systems weren't being used.
This is key to understanding technology implementation in today's rapidly changing environment. It is easy to put together a focused prototype, set up an environment that makes it look good, and provide the expert geek, but it is an order of magnitude more difficult to keep the system running. Decision makers—especially the senior officers who are tasked to make procurement recommendations—must beware this information-technology fast shuffle.
Especially vulnerable are those in the aviation and submarine communities, because of their lack of experience in coordinated multi-unit combat. Looking at the computer technology of five to ten years ago, they had the hottest technology—but it focused on a single unit attacking a single target. Multiple targets existed, but they usually were assigned by external sources and attacked serially. The aviator dealt with dogfights (shoot one, look for the next) or preplanned strikes. The submariner hunted for a sub or a few surface vessels. Surface warriors, on the other hand, relied on coordinated units dealing with multiple targets and real-time reallocation of engagement responsibility. They had to respond to sea/air strikes consisting of cruise missile, torpedo, and gun engagements—occurring nearly simultaneously. Growing up in the world of NTDS, Link 11, and now Aegis, these warfighters have a leg up when it comes to dealing with how information technology applies to the littoral tactical situation.
Senior officers also are accustomed to having staffs set up information presentations. On this limited scale, it is affordable and manageable to have dedicated specialists supporting them. Unfortunately, the everyday ship does not have that luxury. In one case, a ship had to ration color printouts because it did not have the operating funds to buy printer cartridges. It is critical that the decision makers recognize this difference and not presume that information technology support as they receive it is effective, appropriate, or even available for frontline assets.
Expanding a small capability supported by specialists to one used by moderately experienced or untrained operators without real-time assistance can be a burden rather than an improvement. The geeks will always come up with interesting and flashy things, but that does not mean they are workable for an 18-year-old sailor. If it takes memorizing four menus and three subwindows to find them, the functions never will be used.
One solution is not to bypass the acquisition process. When JOTS was introduced in the 1980s, it was procured by the type commander and crossdecked. No one tested compatibility with existing systems. When Earnest Will was executed, the Oliver Hazard Perry (FFG-7) frigates were given JOTS. Unfortunately, the installation method never had been verified, and it scrambled the LINK 11 signals being sent. This led to major confusion at exactly the wrong time.
To see if a system is truly worthwhile, it should be installed on one or two ships. After reasonable training they should be left unattended for a deployment cycle. (This assumes bypassing the traditional technical and operational evaluation, and also that the technology is not meeting a crisis need.) Find out if the division officers, chiefs, and second-class petty officers like it or if they use it only because their department heads and commanding officer want visibility. If the system really works, the ships will have made it part of their routine.
Remember the prototype tactical decision support system on the Stump and Fletcher? It took three years to implement "the little things" that made the system functional. It is now operational, but major lessons were learned in the difference between real-time tactical and near-real-time strategic software requirements. This beats the 10-15 years previously encountered with weapon systems, but it represents the reality of what must be accomplished to transition from prototype efforts.
The Mk 1 Mod 0 sailors are willing, but they must be able to use the technology tools we purchase. They are the ones who will exploit the capabilities and move us to Admiral Clemins's third stage. We can benefit from technology, but we must ensure that upgrades perform before implementing them fleetwide and especially before moving to newer versions. Unlike the civilian world, we cannot ask the customer to call back in a little while. The packages we deliver are lethal. If we get it wrong, innocent civilians or our own troops get killed.
Commander Johns has systems engineering degrees from the U.S. Naval Academy and the Naval Postgraduate School and 20 years' experience operating, designing, and testing weapon systems. On active duty, he was project officer for the prototyping and initial design of the AN/USQ-132 Tactical Decision Support Subsystem. He now works at the Naval Surface Warfare Center Dahlgren Division, as project leader for the COTS-based AN/SSQ-101 Computer-Aided Dead Reckoning Tracer.
1. Adm. Archie Clemins, USN, "Moving to the 3rd Stage," U.S. Naval Institute Proceedings, May 1997, p. 51. back to article