Air University Review, January-February 1981

Computers and Pickups

In the May-June 1980 issue of Air University Review, Major Frank J. Derfler’s article, "When Is a Computer Like a Pickup Truck?" addresses some of the reasons behind the proliferation of microcomputers in the office environment and some conclusions about the management of these "humble and sturdy" devices.

If we are going to continue the pickup truck analogy to analyze microcomputers, we need to go a little deeper. There are varying sizes of pickup trucks, and we should determine what size is needed by analyzing the task to be performed. We don’t send a quarter-ton pickup to handle a two-ton load. Pickup trucks are cheaper than dump trucks or semis, but that doesn’t mean we should buy a dozen pickups to do the job of one dump truck. Finally, pickups come with a variety of options (hydraulic lifts, winches, four-wheel drive, etc.), but we don’t buy pickups with all options included just to cover all eventual uses; nor do we get them completely stripped down so they are incapable of doing most of the work. Instead, we have to match requirements with capabilities and make economic comparisons to ensure that we pay for something that is going to provide real rather than perceived benefits. This principle holds whether we are buying pickup trucks, airplanes, large computers, or micros.

Major Derfler’s principal question is: Should the acquisition and use of micros be regulated? If the answer is yes, then how should it be done, and who should do it? I disagree with Derfler’s response to these questions and challenge some of his answers.

Micro software is the major factor (80 percent) in the cost of automated systems. Since the micros are just beginning to proliferate into the office environment, good figures on micro software versus large-scale software are unavailable; software costs for micros may go beyond 80 percent. Because we have amateurs doing the programming and working in an uncontrolled environment, I would predict an increase.

I disagree with the idea that the increased proportional cost of software is due to the decreasing proportional cost of hardware. Granted, hardware costs relative to actual performance capability have declined, and that has influenced the equation. Yet, practical experience indicates that software costs have increased because we are developing larger, more complex systems. Additionally, we are applying better management controls to software development to ensure that it meets functional user requirements and works right the first time, thus significantly decreasing the follow-on ‘‘maintenance" cost.

It is also worth noting that we do not pay additional attention to the software aspect of automated systems just because of the higher cost but because we recognize software as the most critical aspect in making the system work properly.

According to Derfler "The small systems are so unfettered by complicated program interrelationships that program maintenance (updates) can be done by almost any experienced user." Sure, micro software systems usually do simple, uncomplicated tasks, but how long will it take before users of these micros take on bigger and more complex projects? Efforts are being made to provide high order languages like COBOL and FORTRAN and Data Base Management System capabilities for the micro. When these capabilities become a reality, micro users will feel obligated to take advantage of the new power and try to automate everything in sight, resulting in very complex and interrelated micro systems.

Micro users will tend to look only at initial cost of software development and not consider the long-term cost of program maintenance. If they write their software quick and dirty, they are bound to have much follow-on maintenance. Also functional users change their minds frequently, and the more frequently they change their minds, the more reprogramming is involved.

I disagree with Derfler’s conclusion to let the dust settle and then consider the development of standard programs, which would cause a long, hard struggle to regain control. The better approach is to get control of micro software development now.

micro maintenance

If we have to retain a manual mode of operation, as Derfler suggests, because we don’t trust the micro’s reliability, we are going to double the amount of effort doing our jobs. And if we have to keep both manual data files and magnetic media data files, we’re not only duplicating work, we’re creating a situation wherein the two files may get out of sync. The result is more work to do the same job and the risk of having inaccurate information

One answer may be to develop an internal maintenance function. Since the micros are designed around chips and plug-in boards, we may want to build an inventory of spare parts, do our own troubleshooting, and replace the defective components. The bad parts could be shipped to the factory for repair.

Micro maintenance is not as simple as writing a purchase order. Service may not be available in many areas, and when it is, the cost may be high. We should also be prepared to accept some maintenance delays because support service seems to lag behind sales.

micro applications

Is there really a place for micros in our complex environment? They are great for doing simple things, but are we doing anything simple? I do not like Derfler’s idea of purchasing these devices in response to a "perceived need that can be met expeditiously and at a low cost.

The fundamental problem is one of perceived need versus actual need. We should not buy $1000 "toys" because of perceived needs. No doubt, there are some real requirements that can be effectively and efficiently satisfied with micros, and we have to weed out the real requirements from perceived ones. Although $1000 may not sound like much, remember that is only hardware cost. I have not seen any good estimates of software costs, but if we use the 80 percent estimate, we can expect to invest $4000 in software for every $1000 invested in hardware.

Requirements for micros will be determined by functional users on a case-by-case basis. Senior managers must make the final decisions about buying a "toy’’ or buying something that will contribute to productivity. In short, senior management needs to get involved.

Should the acquisition and use of micros be regulated? Derfler proposes ". . .that the Air Force [issue] one simple directive: Any computer devices, aside from weapon systems and other than test equipment, that can talk to other computer devices must have one common Air Forcewide standard for transmission."

That sounds like a good idea, but that is standardization and not management. It is limited to the technical aspects and does not address the need to manage the acquisition and use of micros. Additionally, it does not address micros that "stand alone" (those that communicate with other computers).

I think the Air Force has generally succeeded in managing micros. We recognize that they are computers and the dangers associated with their proliferation: the potentially high cost of software development within the functional areas and that we become dependent on them. Functional users desiring micros must analyze their needs, identify the potential benefits of using micros, and compare those benefits to costs. They should also manage development of micro applications to ensure the preparation of adequate documentation. If we do not manage this microevolution, we will be exposing ourselves to what a respected co-worker describes as the "hobby shop approach to developing critical automated systems. The end result will be systems that do not work very well and are worthless when the developer leaves.

If some form of regulation is needed, we have to determine what kind and how it should be applied. Rather than regulate, I prefer the term manage. We need to manage the acquisition and use of micros so as to make them an effective, reliable part of our work environment. Thus we must have procedures that enable us to define our requirements, identify alternative ways to satisfy the requirements, and select the best alternative. We need just enough regulation to stop proliferation. I submit that the procedures outlined in the AFR 300 series are sufficient for this type of regulation (management).

micro regulation—who?

Who should do the regulating (managing)? Whenever we start talking about regulation. We seem to wind up talking about bureaucracy. According to Derfler:

The bureaucracy involved is seriously threatened by the flow of information that such systems provide . . . but actually there is a strong perceived threat to the existing channels of communications and ways of doing things.

I strongly disagree. The bureaucracy (and I assume Derfler is referring to the data automators) does not have hang-ups about whether the information flows from our computers or someone else’s. We are concerned about the data integrity problems caused by having redundant data collected and stored in different machines and about dependency on unreliable automated systems. Experience is a key factor in the development and use of automated systems—even micro-based systems.

Defler answers the "who" questions as the ". . . job of the communicators on any base. They would not validate needs, but they would regulate compatibility in the same way that they ensure that intrabase radios programmed under the appropriate table of allowances can talk together." This amounts to standardization, and I concur that it is needed. Whether Air Force communicators should establish the standards is up to the communicators and the Department of Commerce, which publishes the Federal Information Processing Standards (FIPS).

My main concern is who will validate the need for micros and manage their overall use. The functional users and data automators have this responsibility for identifying the requirements and alternative solutions.

Also, communicators are not the only ones in the Air Force who are ". . . by mission, training, and experience, providers of high technology service." Computers performed many functions before they were integrated into the communicator’s world.

Who, then, should be managing micros? I feel that the task belongs to the functional area managers and data automators with help from communications, contracting, logistics, finance, and many other experts to make our automated systems (including micros) a dependable, effective part of our Air Force.

Micros are proliferating in our office environment, and we need to apply controls now to ensure that they help instead of hurt us. The controls must be applied by functional users and data automators since these groups are closest to the action. Remember, just because micros are little and cute does not mean they lack the potential of causing large problems.

Major Hugh M. Lochrane, Jr., is Chief, Automatic Data Processing Plans and Programs, Directorate of Data Automation, Washington, D.C.

The conclusions and opinions expressed in this document are those of the author cultivated in the freedom of expression, academic environment of Air University. They do not reflect the official position of the U.S. Government, Department of Defense, the United States Air Force or the Air University.

Air & Space Power Home Page | Feedback? Email the Editor