Document created: 19 September 03
Air University Review, January-February 1974
The relative merit of centralization of data processing versus decentralization has been a subject of concern for those associated with Air Force automatic data processing (ADP) for a number of years. In 1972, as a result of the installation of third-generation computers, budget limitations, and pressures from the federal government to manage ADP resources more efficiently, the Air Force reorganized data processing at major air command and higher levels. This reorganization reduces the decentralization arguments to academic discussions but does not necessarily solve the problems that promoted concern in the first place.
The purpose of this article is to identify problems in the interrelationship between the functional user of automatic data processing and those specialists tasked with supporting the user. A brief history of the Air Force ADP move towards centralization will provide the background.
The Air Force has several automatic data processing systems located at all levels within its organization. Located at base level are usually two third-generation computers, a UNIVAC 1050-II supporting a worldwide logistics system and a Burroughs 3500 providing support for Accounting and Finance, Personnel, Pay, Civil Engineering, and others as required. At major command level there are computers from most of the major computer manufacturers to support command and control, intelligence, planning, and special applications such as weather, strategic planning, airlift, tactical control, and weapon system development. Hq USAF uses Honeywell and IBM computers to support the Air Staff, the Office of the Secretary of Defense, and other agencies of the federal government.
In 1955 the Directorate of Statistical Services (predecessor to the current Directorate Data Automation) was given responsibility for managing the punched card accounting machine (PCAM) equipment and computers throughout the Air Force. During the following seven-year period, most PCAM procedures and computer programs were developed by the statistical services activity at the organizational level where the equipment was used. Generally, the standardization of report formats was the only centralized effort directed towards ADP. In 1961 an Assistant for Data Automation was designated at Hq USAF under the Comptroller to centralize and coordinate all ADP design efforts. This move was followed in 1962 by the establishment of the Directorate of Data Systems and Statistics and the Data Service Center, a field extension for centralized Hq USAF computer processing in the Pentagon. At this time functional areas were given the responsibility for design and development of standardized systems. Decentralization of data systems responsibilities, including operation of equipment, occurred in some areas.1
Initially all base-level support was provided by one computer operated by the base comptroller. The second base-level computer was installed when Hq Air Force Systems and Logistics developed a worldwide base-level supply system. The system was centralized to the extent that the hardware procurement and software systems were developed and standardized at Hq AF. Base-level ADP personnel were prohibited from making local modifications. The true test of the worldwide supply system came in Vietnam, and the system proved to be a valuable management tool.
The base comptroller’s computer was upgraded to third-generation equipment and used to support worldwide management information systems in several functional areas: Personnel developed the Base Level Military Personnel System (BLMPS); Civil Engineering, the Base Engineering Automated Management System (BEAMS); and Comptroller, the Budgeting and Accounting System (PRIME). All three systems utilize remote terminals interfaced with the Burroughs 3500 (B-3500) central computer. The software for all three systems was designed and maintained by a central Data Systems Design Center. Functional analysts assigned to the center played a key role in developing these systems.
Although the base-level B-3500s are not linked directly with other bases, they do output standard reports that are transmitted over the Automatic Digital Network (AUTODIN) to other bases.
During the late fifties and early sixties Air Force technology was producing rapid advances in computer technology. These industry-leading advancements were to develop command and control systems for the Air Defense Command, Strategic Air Command, and the North American Air Defense Command.
ADC’s SAGE (semiautomatic ground environment) system pioneered the development of magnetic core memory and cathode ray tube (CRT) display consoles. SAGE also pioneered in integrating data acquisition, processing, and controlling functions. The management of the system was centralized to the extent of hardware procurement and software systems. Initially the system was deployed at 29 locations with decentralized operational control. SAGE was developed at Massachusetts Institute of Technology Lincoln Laboratory in the mid-1950s and was upgraded in the 1960s by the backup intercept control (BUIC) system. In essence, BUIC is a transistorized SAGE system operating at twelve locations. Its management control is similar to that of the SAGE centers.
A second major system was developed for SAC. Strategic Air Command and Control System (SACCS) was the first major system to combine specialized communications with computers. Both teletype terminals and voice communications provided a worldwide link between the Hq SAC Command Post and each unit’s command post. Large computer-generated multicolored displays were another advancement pioneered by SACCS.
NORAD developed the Ballistic Missile Early Warning System (BMEWS), which combined communications and radar inputs with the computer. All three systems were designed, developed, and managed within their separate organizations. Both SACCS and BMEWS were highly centralized, with computers installed in only a few locations. In SACCS all personnel and hardware were managed by the functional manager.
While SAC was developing its own command and control system, the other major commands were centralizing their command and control systems under the Air Force Integrated Command and Control System (AFICCS). The degree of centralization under AFICCS called for common hardware (IBM-1410), operating systems software, and report formats. Since the computers were not tied together, each location had its own files and functional user applications programs. The centralization started to fall apart when third-generation computers (IBM-360) replaced the original second-generation computers in AFICCS. The IBM-360 offered a variety of operating systems, and each organization made its decision as to which system would be best for its operation. As a result, at least four different systems were installed as of May 1971.2
Another ADP system located at major command and higher levels is the Intelligence Data Handling System (IDHS). The differences in IDHS requirements at each operating location precluded any standardization of hardware or software. The only centralization in IDHS was in the planning and procurement of hardware; otherwise, each IDHS computer was autonomous in both hardware operation and software design. Air Force Systems Command’s ADP requirements resulted in a similar system.
The evolution of Air Force ADP personnel was also decentralized at the start. The only Air Force Specialty Codes (AFSC) utilized exclusively with the computer were in the comptroller-statistical career field. Other ADP personnel had a prefix added to their functional AFSC—or in the case of mathematicians a suffix—to identify their computer expertise.
By the late sixties the Air Force had a large number of computers, along with supporting staffs from different functional career fields, with no single manager of the system. In 1967 Hq USAF established the USAF Data Systems Design Center (AFDSDC) with the mission to analyze, design, develop, program, test, implement, and maintain all automated data processing systems as assigned by Hq USAF.3 Primarily, their efforts were directed towards the base-level systems. Responsibilities in the areas of command and control and Intelligence Data Handling System were not assigned to AFDSDC.
The next step towards centralization took place in 1970, when Air Force established the “Computer Technology” career field (AFSC: 51XX). The ADP AFSC’s in the comptroller and mathematician career fields were converted to 51XX, thus allowing for a more flexible utilization of computer expertise within the Air Force. Since 1970 many ADP organizations have also converted functional AFSC’s with the “C” or “D” prefixes to 51XX. This move gives the ADP organization a better mix between functional and computer expertise.
For a number of years the Congress has been critical of DOD ADP management.4 The Air Force had over 1200 computers in FY 72, valued at almost $1 billion.5 The Secretary of the Air Force had become concerned with the cost and time involved in acquiring ADP due to the DOD centralized control of ADP procurement.6 The logical step was to appoint a single manager over Air Force ADP. Since the Executive Office of the President and the Department of Defense had placed ADP under their comptroller organizations, the Air Force followed suit. Effective 29 February 1972, the Air Force Data Automation Agency (AFDAA) was activated, with three subordinate centers: the Air Force Data Services Center (AFDSC), the Air Force Data Systems Design Center (AFDSDC), and the Federal Automatic Data Processing Simulation Center (FEDSIM).7 The overall mission of AFDAA is to provide centralized management and common organizational alignment of similarly engaged ADP activities.8 The Comptroller’s Director of Data Automation also serves as the Commander, AFDAA.9
Throughout the Air Force at major command level, similar reorganizations took place. As an example, SAC, which has the largest number of military ADP personnel assigned to one major command in the Air Force,10 combined its operations, intelligence, and comptroller ADP organizations into one organization. Of the more than 1400 ADP personnel assigned to Hq SAC, fewer than 200 were left with the functional user.11 One difference exists at SAC in that the Director of Data Automation reports to the Chief of Staff instead of the Comptroller.
Today the Air Force has third-generation computers with enormous potential to assist the functional manager in his decision-making. The ADP organization has come of age, with its own career field and control through its centralized organization. There are still complaints from the functional users. In the 1971-72 classes at Air War College and Air Command and Staff College, the problems of ADP constituted a popular area of research.12 An underlying theme in many of the research reports was how to improve the relationship between the user and ADP. A recent study of the SAC ADP reorganization uncovered areas of discontent in the relationship. Therefore, let us examine some elements of the relationship.
Base level. At the base level the initial reaction of the user is that he has to live with a system forced on him by regulations. He is told what information he must submit to the ADP center and what output he is to receive. True, he now has some flexibility through remote computers to query the computer and receive some data on a random basis, but the format of his query and the output are highly structured. Whether he uses an output product or not, he still receives them. (He soon learns after an operational readiness inspection that there usually is a good use for the product.) If he desires additional information or reformatted data on a continuing basis, he is discouraged in his efforts by the paperwork required by ADP to consider the request.
Very little innovation is done at the base level. The relationship between user and ADP is firmly structured. A poor relationship exists only when personalities conflict or if mechanical problems create excessive “computer downtime” when a user has a pressing need for support.
ADP personnel at the base level sometimes forget that they exist to support the user, not just to operate the computer. Without the user, the need for the computer does not exist. Thus, base-level ADP personnel must become familiar with the users’ products and requirements. Often they have the ability to assist the user in solving a unique or one-time requirement. The functional user also has a responsibility to educate himself on the base-level ADP system. ADP cannot support him if he does not ask for the support or if he does not know what support is available.
How many functional managers who are required to submit data to or who receive reports from the ADP center have ever visited the center or received a briefing on its operation? How often has the same manager sat down with the ADP manager and discussed mutual problems? In order to have an effective relationship, there has to be a line of communication and understanding.
As previously mentioned, the base-level application software is designed and maintained at higher headquarters. Representatives of the functional areas participate in the design. For the most part there are experienced functional personnel trained in ADP. Most were selected from the very type of organization that will be supported by the product under design. The Air Force operates in a dynamic environment; the functional expert one or two years out of the area begins to lose touch with the day-to-day problems with which he was once so familiar. The base-level functional manager therefore has a responsibility to provide feedback on the effectiveness of his ADP support. He is an important person! The system exists to support him, not for him to support the system. If he finds he no longer needs a certain ADP product or could use some additional information, he should inform his higher headquarters of the situation.
This does not necessarily mean that he has to submit a formal change request (which is highly desirable), but it does mean that he is responsible for providing the feedback to his functional representative at the design center so that ADP analysts can review the situation.
The base-level Data Processing Installation (DPI) manager has a similar responsibility towards the higher headquarters. He also is an important person! The ADP analyst responsible for system operation needs the feedback from the unit level in order to provide the best support possible. The DPI manager can also assist the functional manager in forwarding his feedback to the proper analysts. By working together at base level and providing feedback to the design centers, these managers naturally improve the harmony and effectiveness of the system.
Major Command Level. At the major command level the situation is different. The type of ADP in operation provides for daily contact between the functional user and the ADP analysts designing and maintaining the system supporting the user. Therefore, the feedback should be easy and the relationship at its best—but it isn’t necessarily true. For the most part, it is even less favorable than at base level. At the base level the user and ADP personnel work within a system directed from above, and thus they develop a sense of comradeship in a situation over which they have little control. By contrast, at major command level the user often perceives that ADP can do more for him, and the ADP analyst perceives that the user could be more helpful, understanding, and cooperative in solving ADP problems.
It was at major command level that the recent reorganization had its biggest impact. Prior to the centralization, the ADP function was often located within the functional area, with the functional user and ADP personnel working for the same manager. If problems arose that affected the user/ADP relationship, they could be resolved at the manager’s level.
Also, at major command headquarters the user/ADP relationship is similar to that in industry, especially in the management decision-making involved in planning and analyzing performance. Centralized Air Force-wide applications programs cannot be used in this environment. Close interaction between user and ADP analyst is required. The types of programs developed have to be highly flexible and dynamic. Weapon systems change, guidance changes, concepts change, and the planning factors change. The decisions required this year are not the same as the decisions made last year, nor will they likely be the same as the ones required next year.
It is in this dynamic environment that the functional user has to operate. The increased complexity and sophistication of the Air Force require increased and more efficient ADP support. As an example, the target application of the newest missile systems cannot be accomplished manually. Each sortie’s trajectory has to be simulated through a computer program to insure that the targets selected are valid. The days of “pins and strings” and range arcs on charts are gone forever. In addition to those problems that cannot be resolved manually, there are increasing requirements to make optimal decisions requiring computer iterations in support of the impacts of budget cuts, SALT talks, personnel cuts, and weapon system allocations. Effective decisions in many areas are highly dependent on ADP support; yet ADP is not a simple tool to use.
The functional manager is often limited in his ability to question the computer. The computer restrains him from asking all possible types of questions. In addition, the answer he receives is often in a format that gives him more or less information than he needs.13 He is also often frustrated by the time required to receive an answer to his questions. If the manager is not educated in the ADP system providing his support, he can be frustrated also by asking simple (to his mind) questions that the computer cannot answer either because it does not understand the request or the data required are not available.
On the other side of the relationship, the ADP specialist is often frustrated in his dealings with the user. The ADP analyst would like to have the user describe the problem and be available for consultation and operational testing, but otherwise he wants to be left alone to design the solution. He is very unhappy when changes are requested after the design phase is started. The inability of the user to state exactly what he wants is rarely perceived as a lack of ADP knowledge but more often from the viewpoint that the user does not know what he is doing or what he wants. The analyst therefore proceeds to design a system as he thinks it should be. If it is not accepted with enthusiasm by the user, the analyst often retreats into a shell and turns his efforts to another project that hopefully will be more rewarding psychologically.
Two characteristics emerge from this discussion that often create unfavorable user/ADP relationships. The relationship begins to deteriorate when either or both parties have a lack of understanding of their opposite activities. Five lieutenant colonels conducted research on the relationship while attending the Air War College in fiscal year 1972. They developed three possible alternatives for improving the relationship:
1. Require functional users to develop a detailed understanding of ADP.
2. Require ADP analysts to develop a detailed understanding of the functional area they support.
3. To both the functional organization and the ADP organization, assign only personnel who have a thorough understanding of both activities.
Their recommendation was to select the third alternative.14
To a great extent their recommendation was followed in decentralizing ADP organizations. As an example, until the establishment of the computer technology career field, most analyst programmers assigned to Hq SAC’s operations and intelligence ADP organizations had functional AFSC’s with “C” or “D” prefixes. It became apparent over the years that there was a weakness in the system. A SAC navigator trained in ADP and assigned as an analyst to support the activities of the Joint Strategic Target Planning Staff (JSTPS) could communicate with the planner in the planner’s terminology, but he did not really understand the day-to-day job of the planner. The only thing they had in common was their SAC crew background—neither fully understood the other’s activities.
Major command activities of functional users are unique to that major command. Personnel are normally assigned to a three-or four-year tour. Thus it is rare that the ADP manager can find an individual experienced in both ADP and the specific functional areas he is tasked to support. It was sometimes accomplished when both organizations were under one manager; intra-division transfers could be accomplished, especially when an individual was promoted out of a job. Under the new centralized organization and AFSC’s, it will become less frequent. The sophistication of present-day computers requires more training and dedication than the early computers. ADP specialists are more effective in the ADP organization than functional specialists trained in ADP.
One answer is to develop the functional ADP analyst located in the functional area.15 In the Air War College report previously cited were the following recommendations:
1. That the ADP office provide ADP familiarization for
the functional managers they are tasked to support.
2. That a “functional ADP analyst” position be created in each functional organization at an appropriate level in the hierarchy to allow him to perform effectively.
3. That the functional ADP analyst’s duties be:
a. To serve as the centralized ADP authority in his areas of assignment.
b. To act as liaison between his area, the ADP organization, and other interacting functional areas.
c. To maintain ADP expertise.
d. To lead all efforts within his area that concern the application of ADP to the area’s activities.
e. To participate with like analysts to improve the overall system.
These recommendations deserve serious consideration by Air Force personnel and manpower planners. In the interim a more practical solution must be found. Not every organization has the work load to support a dedicated analyst. Yet the organization needs to participate in the user/ADP relationship. The budget and consequent personnel limitations imposed by Congress will also hamper enactment of the recommendations. What is needed is a solution that can be implemented today.
There is a danger in the overcentralization of automatic data processing. The functional user can become frustrated when he lacks an understanding of the support that ADP can provide him. If he becomes too isolated as a result of the centralization, he has difficulty communicating with the ADP analyst. Their relationship may soon deteriorate. The ADP analyst also contributes to the deterioration when his own activities become more important than supporting the user or when through lack of effective communication with the user his products do not fulfill the user’s requirements.
The centralization of ADP organizations is here to stay. Both the functional user who lost control over his ADP support and the new ADP organization must learn to live with it effectively. Just because he no longer has an ADP element in his organization, the functional manager cannot stop being involved with ADP. ADP exists to support him, and he has a responsibility to work closely with the ADP analyst to assist him in developing the required support.
The ADP manager must guard against the computer’s becoming more important than the functions it is tasked to support. Even though he has functional experts assigned, they may never have actually worked in the exact areas supported, or they can soon become outdated in their knowledge of the details of the area they represent. At Centralized Design Centers such as AFDSDC, they can become stale very rapidly if feedback is not provided by the base-level user. At major command level the problem is more a “people” problem in the communications and interactions between the analyst and the functional user.
Functional managers who rely on ADP support should first become familiar with the capabilities of the ADP system tasked with their support. They should also task at least one individual in their subordinate area with the responsibility of becoming a central ADP authority. If the workload is apparent and the position can be justified, they should create a “functional ADP analyst” as recommended by the AWC study; otherwise they should assign the function as an additional duty. With either choice, they should insure that the individual selected has a thorough knowledge of the ADP systems applicable or else have him receive adequate training. In many functional organizations, company-grade and junior field-grade officers have had computer courses in college. The functional managers should seek out those within the organization with computer expertise and put them to work to help both the manager and the overall system.
ADP managers should live by and preach the following guidelines for an effective relationship with the user:
In the past the Air Force has been an industry leader in computer technology and applications. In the future the Air Force should continue to develop if it can enjoy a strong relationship and positive feedback between functional users and automatic data processing organizations.
University of Nebraska (AFIT)
1. Major Donald J. Berg, “Establishment of a Computer Command,” Air Command and Staff College thesis, 1972, p. 16.
2. Lieutenant Colonel Phillip J. Wendt, “WWMCCS—1980 Command and Control: A Study of Computer Management,” Air War College thesis, 1972, p. 19.
3. Air Force Regulation 23-42, para 2-a.
4. Government Electronic Data Processing Systems, p. 302. See also Report to the President and the Secretary of Defense on the Department of Defense, pp. 151-58.
5. Spencer J. Schedler, “Data Automation Program Redirection,” Supplement to the Air Force Policy Letter for Commanders, July 1972, p. 24.
7. AFR 23-40, para 1-a.
8. Ibid., para 2-a.
9. Ibid., para 3-a.
10. SAC’s authorized manning of AFSC 51XX was 225 as of January 1973. USAF authorized manning of AFSC 51XX on the same date was 1812.
11. Reorganization background data supplied by SAC/ADE.
12. Air University Abstracts of Research Reports, 1972, pp. 36, 46, 71, and 86.
13. Eric W. Wolf, “Command Information Systems—What Was Promised, What We Have, What We Need,” Data Automation Digest, August 1969, pp. 24-25.
14. Lieutenant Colonel Clark R. Aamodt et al., “Relationships Between Functional and Computer Elements,” Air War College thesis, 1972, p. 5.
15. Ibid., pp. 58-59.
Major Edward E. Reynolds, Jr., (M.A., University of Nebraska-Lincoln) is a Data Automation Survey Analyst, USAF ADP Evaluation and Assistance Office, Washington, D.C. Commissioned from navigator training, he has served on SAC KC-97s and KC-135s; as a missile target intelligence planner, Hq SAC; and as Senior Intelligence Advisor to the Vietnamese Air Force. Major Reynolds is a graduate of Squadron Officer School, Air Command and Staff College Nonresident Seminar Program, and AFIT programs.
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.