Expanding Capabilities: IBM and Control Data, 1960

While IBM’s substantial work in services has been obscured, so too has Control Data Corporation, IBM’s competitor in mainframes. Control Data bundled (included within the price of hardware) services less, and established and grew its data services and programming services businesses (as profit centers) from the 1960s forward, but the services activities and businesses of the corporation have been overshadowed by its supercomputer enterprise. This chapter briefly surveys the services work of these two mainframe computer companies. Between the 1960s and the late 1980s, no information technology firm in the world approached IBM in the number of workers devoted to computer services; and no computer manufacturer was more committed early on to making services a recognized business (or businesses—data processing, time sharing, programming services, and systems integration) than CDC.³

Continuity and Change in IBM’s Field Services

IBM’s organizational capabilities with maintenance and applications dates back virtually to the company’s C-T-R origins, and to a degree even to its late-nineteenth-century and early-twentieth-century prehistory with Herman Hollerith assisting at major punch card tabulating machine installations. Shortly after Thomas J. Watson established field services education at Endicott in 1916, class after class of field services workers were taught to help customers with punch card tabulation machines (and other office machines) and their applications. Their positions began with a heavy training regimen, but that was merely the start. As equipment and applications evolved, C-T-R/IBM field services workers returned to Endicott, Poughkeepsie, Kingston, and other IBM locations time and again for continuing education. In the late teens, these workers were designated by C-T-R as “Customer Engineers” (CEs), and were part of the firm’s Customer Engineering Departments for its various product divisions. In the 1950s, the largest group of IBM’s CEs served the Electronic Accounting Machine (EAM) Division, which graduated its 10,000th CE trainee in 1956.⁴ By that time, schools had been set up for IBM’s rapidly expanding Data Processing Division (DPD), which trained CEs for its early computers—including the IBM 650 and IBM 1401. With the rapid proliferation of IBM computer installations in the late 1950s and the early 1960s, DPD CEs soon exceeded those of EAM, and had no rival in providing services support in the computer industry. These CE departments recruited from accredited technical schools, colleges, and universities and established an extensive infrastructure, where a portion of CEs would later become instructors to other field services personnel in IBM’s equipment-specific training courses, while a smaller cadre became authors of “Field Engineering Manuals” for the company’s many systems.⁵

Though IBM hired its first female salesperson in 1936, women only made slow inroads into the male-dominated IBM sales culture. Not until ten years later did the first woman become a member of the “100 Percent Club” for exceeding her annual sales quota, and not until the middle years of the century were there multiple female members of the club (three by 1949).⁶ In contrast, in 1935, IBM already had held its first “System Service” training school for women college graduates. That year, Virginia Linkenhoker became IBM’s first system services employee, soon followed by the other two dozen graduates of the training school.⁷ The second class, in 1936, had 31 female graduates, and the numbers continued to grow from there.⁸ This was the first wave of women to have both technical positions at IBM and customer contact in the field. CEs, as a group, were predominately male, though jobs in CE were more open to women than jobs in sales. Meanwhile, graduates of the 1935 all-women System Service School, and subsequent annual classes, became part of what was referred to as the “System Service Women Corps” of field services technical and marketing employees. In the pre–World War II era this corps was focused exclusively on pre-computer electronic accounting, punch card tabulation, and other office machines. The System Service Women Corps flourished during the war, and through IBM’s hiring only select college graduates to become System Service trainees (a higher requirement than for CE trainees), the group earned a reputation for excellence.⁹ They helped customers solve data processing problems, and educated both customers and other IBM staff on equipment and programming.¹⁰

Customer engineers and the System Service Women Corps were critical to setting up and servicing IBM 701s, IBM 650s, IBM 704s, and other machines in the 1950s. On complex, larger installations IBM often placed support staff on site for extended periods of time. In addition to installation, maintenance, and hardware optimization work (typical of CEs), IBM also commonly supplied professional engineers and skilled programmers. A short biographical account by IBM’s Glenn Meyers provides rare insight into certain aspects of early IBM field engineering in computing. He received extensive instruction in both pre-computing equipment and mainframe computers and his account hints at how IBM’s know-how and organizational capabilities in maintenance and field services were important to the early computer age.

Meyers, a merchant marine radio operator from late in World War II to 1948, “came ashore” that year and became a RCA television technician. In August 1956, at age 29, he was hired as an IBM field service engineer. Immediately designated for servicing a Westinghouse IBM 704 installation, he underwent training for six months. This included training on key punch machines, card readers, line printers, and other machines that predated the IBM 704 but were essential components of the overall Westinghouse IBM system installation in East Pittsburgh. Meyers’ training, of course, included training on the IBM 704 mainframe and instruction in assembly language—the language of IBM 704 diagnostics.¹¹

For Meyers, and for all of his field service colleagues, training was continual. Looking back at his first ten years at IBM, Meyers recalled he spent a full three years of combined time in Endicott, Poughkeepsie, and Kingston receiving training on the IBM 704, IBM 709, the IBM System/360 series, and various peripheral machines and software. Reflecting on the early years, he reminisced that operational problems on the IBM 704 often consisted of burned-out tube filaments, or as the system aged, “silver migration” (the coated silver shifting between pins with potential differences caused outages). Other times the diagnosis and the fixes were more complex.¹²

Meyers traveled frequently on service calls, serving installations such as NASA Glenn near Cleveland, Redstone Arsenal in Huntsville, and the headquarters of the Chrysler Corporation in Detroit. This travel included driving through snowstorms to reach customer locations quickly and get their system up and running again. In addition to fixes, Meyers spent considerable time at installations on preventative maintenance, as well as implementing techniques to ensure that systems ran at their rated efficiencies. Hurricanes, tornados, fires, and other disasters also required Meyers to rapidly mobilize to assist customers.¹³

As maintenance increasingly involved debugging, and hence a knowledge of programming, the need for more field personnel with a wider range of skills became apparent to IBM’s leaders. In 1963 IBM announced a new division to start the following year, the Field Engineering (FE) Division, to replace the former “Customer Engineering Departments” for its main product divisions. With this, IBM’s Data Processing (DPD) and General Systems (GSD) Divisions came together to establish a symmetrical five employment class structure for field engineering (in order of least to greatest responsibility): CE Trainee, Associate CE, CE, Senior CE, and FE Specialist.¹⁴ It also established centralized management, regions, and offices, as well as the latest data management and deployment communication technologies.¹⁵ In the second half of the 1960s, many FE staff members in the highest three classes (CE and above) took courses, built skills, and assisted with systems and applications programming.¹⁶ In 1969 alone—after the Field Engineering Division ramped up CE programming courses—more than a thousand CEs received training on OS/360 and a range of associated IBM programs to become “program support” CEs (to assist customers with software). These program support CEs, given unbundling (separate, or broken out, pricing for software and services), suddenly had responsibility for determining an entirely new and separate category of billing for certain “programming maintenance services.”¹⁷

By the late 1960s, IBM even applied its considerable know-how in real-time systems to effectively and efficiently deploy its large base of CEs. Using data from its Brooklyn, New York and Washington Field Engineering Division branch offices, it developed PACE (Programmed Automatic Customer Engineer), an optimizing mathematically programmed dispatching system with an outer adaptive feedback loop adjusting parameters on the basis of a performance index.¹⁸ For IBM, effective logistical responses—deploying appropriate people and replacements parts quickly—was critical. IBM had numerous storerooms at branch sales offices, as well as specialized support centers. In the late 1960s, to further speed the process in major cities, IBM began adding “Satellite Centers” in the downtowns of major cities to cut the messenger delivery time of parts to CEs by ten minutes to an hour when serving downtown installations. In 1969 five such downtown satellites were operating—in San Francisco, Seattle, Minneapolis, Washington, and New York—and more were planned.¹⁹

IBM CEs were fundamental to IBM’s success and strong reputation, despite the fact that only design engineers (and to a lesser extent software engineers) have made their way into the secondary historical literature on IBM. Like CEs, “System Engineers” (a new classification for IBM as of 1960) also have remained in the shadows of those designing and developing hardware, or the engineers leading the highest profile operating systems development projects, such as OS/360. System engineers were particularly important on larger-scale commercial applications and systems integration projects, of which none in the first half of the 1960s rivaled SABRE.

IBM and the Development of SABRE

IBM’s work on SAGE computer systems (and earlier collaboration with MIT on precursor’s Whirlwind and IBM’s modified XD-1) helped the company to prepare for its work on SABRE. No previous computer contract came close to the one secured in the mid 1950s for IBM to supply the Air Force AN/FSQ-7 mainframes to operate in parallel at 23 Semi-Automatic Ground Environment (SAGE) air defense radar communication sites. While IBM had declined on seeking the SAGE programming contract, which went to newly created System Development Corporation (spun out of the RAND Corporation), IBM engineers, in serving these important mainframe installations, worked in concert with SDC on SAGE and systems integration efforts. This set a precedent for a heavy services component on major Department of Defense IBM computer installations, a precedent that carried over to other federal government sites as well as corporate installations. In 1959, IBM’s leaders launched a major reorganization of the company, re-designating its Military Products Division as the IBM Federal Systems Division, and creating an Advanced Systems Development Division to “explore new markets.”²⁰ As part of the reorganization, IBM divided its Data Processing Division into the General Products Division (focused on product development and manufacturing) and Data Processing Division (which focused on applications and marketing). In servicing installations with maintenance, IBM was building on long-established service capabilities and work routines (that carried back to pre-computer punch card tabulation days). In working with applications programming and systems integration, it was seeking to develop new capabilities—a challenging but increasingly fruitful endeavor.

IBM benefited from early learning with SAGE (and its MIT precursors) when its leaders solidified plans to partner with American Airlines to build the Semi-Automatic Business Research Environment (SABRE), a real-time airline reservation system. Back in 1952, IBM hired Perry Crawford, an insider in the Office of Naval Research and in Project Whirlwind, to bolster its know-how in real-time systems. In the mid 1950s, IBM Kingston trained many of the newly hired RAND/System Development programmers for SAGE.²¹ And IBM provided teams of engineers to handle “testing, installation, and maintenance” for all SAGE computer centers.²² These IBM engineers were important to setting up and keeping SAGE computers running, working together with SDC in the mid 1950s to ensure that hardware and software came together to create a reliable real-time system. This was during SABRE’s formative stages, when key elements of the system were being defined and established.

Discussion for what became SABRE had begun in late 1953 with a chance encounter between American Airlines’ founder and chairman C. R. Smith and IBM’s sales manager R. Blair Smith when they were seated next to one another on an American Airlines flight. This conversation resulted in Perry Crawford’s being assigned to work with a small group at American Airlines in the mid 1950s. Crawford would go on to lead the design and development project established in 1957, after coordinating a research effort on it in 1956. In 1960, Crawford (and IBM) would name it SABRE—the “SA” standing for “semi-automatic,” recognizing and paying homage to SAGE.²³ By late spring of 1958, much of the equipment necessary to operate SABRE had been specified. In 1959, IBM and American Airlines personnel began to program the system. Early estimates placed the total cost of IBM 7090 computers (as in SAGE, duplexed with one operating online and one offline and as a backup), disk storage units, and typewriter terminals with special networking equipment for agents at $30 million.²⁴ The programming was bundled into the hardware cost. For instance, the modified IBM Selectric typewriters that were to be used as reservation terminals were priced at $16,000 each, and about a thousand of them would be needed. IBM developed and continually updated estimates for programming in “man-months.” This problematic measure (or rather problematic underlying rationale that boosting human resources in programming could reduce delivery time) would later be famous after OS/360 leader Frederick Brooks reflected on the OS/360 programming project in his book on software engineering, The Mythical Man-Month.²⁵

The huge expenditure for SABRE was justified by American Airlines in light of the rapid expansion of its fleet, to ensure strong customer service, and to either fill planes to capacity or to full demand. Back in the 1930s, use of radio telegraphy at American Airlines began to give way to the 60-word-per-minute teletype, in use by all major US airlines by 1938. From the late 1930s on, huge rooms in select airports contained teletypes, many rows of desks, and hundreds of workers with eyes glued to frequently updated reservation boards up front. Some of these rooms were so large that employees near the back would use field glasses to see the boards showing the number of seats available for sale. American, working with the Teleregister Corporation, had pioneered the electromechanical and electronic “Reservisor” in Boston in 1946. The Reservisor, and various later iterations (Magnetronic Reservisor I, with arithmetic capability and memory to hold two weeks worth of reservations, was in place at LaGuardia Airport in New York in 1952), used a plug-board system and cards, but still suffered from delays and tickets were issued manually. This could risk either oversold situations, or the most “perishable product,” an empty seat, when demand existed, going unsold.²⁶

For IBM this was a commercial programming effort of unprecedented proportion. As Robert V. Head (one of the SABRE software developers) recalled, “the traditional IBM business model, whereby IBM sold [or leased] the hardware and the customer did the needed applications programming with ‘assistance’ from IBM, would not see SABRE through to completion.” As Head put it, “even though [IBM] had essentially sold hardware to the customer, IBM would have to foot the bill for a large number of onsite programmers.”²⁷ These programmers were part of IBM’s newly formed Advanced Systems Development Division (ASDD). “The programming task,” Head added, “was far more complex and sizable than the sales types and engineers realized … . Our initial estimate was 100,000 instructions.”²⁸ Once fully operational, the system, and associated simulation programs developed in testing, included far more than half a million lines of code. Ultimately, between IBM and American Airlines, more than 200 people participated in SABRE’s development.²⁹

Although IBM’s leaders unquestionably underestimated the programming and system integration effort required to create SABRE, internal documents indicate that IBM team leaders were not caught completely off guard. In 1959 they recognized some of the risks, including “each programmer’s work affecting and [being] affected by, every other programmers,” that “later changes [would] probably occur on a frequent basis … over years,” and that “a trail must be left behind the programming.” In addition to the needs for interdependent iterative efforts and for quality documentation, IBM managers foresaw that many of the programmers would be “completely inexperienced,” and that there would be the great challenge of “division of responsibility” between IBM and American Airlines.³⁰ These and other challenges all played out in the SABRE project, and in many of IBM’s major programming and systems integration projects in the coming years and decades, and also in the projects of other computer companies and computer services enterprises.

Inevitably with integrating large-scale systems, software modifications and hardware re-engineering occurred frequently. In May 1961, IBM and American Airlines presented (to great fanfare) an operable system using redesigned IBM 7090s. For several years thereafter, SABRE was run in tandem with a manual system and many bugs had to be identified and fixed. The SABRE system was not fully operational until late 1965. By that time it could handle 65,000 phone calls, 40,000 reservations, and 20,000 ticket sales a day.³¹ IBM leveraged its learning on SABRE to develop Programmed Airline Reservations Systems (PARS), a software system that worked on various System/360 models that IBM delivered to Delta and other airlines in the mid 1960s.

SABRE, which involved what was by far the largest software and systems integration contract for a commercial customer in the computer industry up to that time, was an eye opener for IBM’s management. The company gained unique large-scale programming experience that it could use to create transformative mainframe computing applications. The project contributed to IBM’s know-how for future software and systems integration projects. But all such efforts presented unique challenges, and, as IBM found with OS/360, coordinating very large programming efforts would always be extremely difficult.

IBM’s Systems Engineers

SAGE and the start of the SABRE project, without question, alerted Thomas Watson Jr. and his leadership team to the need for systems specialists—engineers who could do advanced programming, manage major programming projects, and integrate hardware, software, and computer networking to design important new applications and realize new possibilities (including, and especially, real-time systems). However, the origin of the idea of “System Engineers” as a formal class of IBM employees originated with William Lawless, an IBM engineer and executive assistant to vice president Al Williams, who not only looked to present and future needs but also considered the more distant past.³²

At the end of the 1950s, Lawless was seeking to address the problem of attracting more technical people to the marketing side of the company—to work in the field at customer locations. This was critical to creating demand for IBM computer systems and maintaining and extending its competitive advantage over other mainframe computer firms. At the time, virtually anyone wanting a technical career at IBM would opt to work within either one of the product divisions (Data Processing Division or the Federal Systems Division—for computers), IBM Research (if they had an advanced science or engineering degree), or the Advanced Systems Development Division. The technically inclined already at or joining IBM generally were not drawn in meaningful numbers to data processing field work, in which sales personnel and Customer Engineers marketed and maintained machines. The main opportunity for advancement was to become either an instructor or a marketing manager. Lawless recognized that some people were better suited for technical rather than managerial responsibilities, but of course they still wanted to advance in their careers.³³

Lawless envisioned a new job family to attract top technical talent to the field services side of IBM. He conveyed his general goal to Al Williams, who encouraged him to put some research together and prepare a proposal. Lawless proceeded to survey the existing technical staff in field services and identified three groups. First, he “found the System Services Women Corps,” which had grown steadily since its origin in 1935. By the end of the 1950s, the System Services Women Corps consisted of more than 500 field service women.³⁴ It was composed entirely of college-educated women who increasingly became involved with computer electronics and computer programming. As the male-dominated sales force adhered to IBM’s dress code (dark suit, white shirt, dark tie), the “System Service” women wore “hats and white gloves.” Ellen Kerksieck Schaefer of System Services recalled: “Mr. Watson [Sr.] believed we had a certain image to maintain … . We did a lot of marketing as well as installation … . [We] wired the boards … . We’d take off our gloves do the work and put our gloves back on.”³⁵ Schaefer later became IBM’s first female “consulting systems engineer.” Another alumna of that first class, Loraine McLennan, a graduate of the University of Iowa with post-graduate training in business at Columbia University, had been with IBM for more than 25 years in technical and managerial positions, working out of Detroit, Chicago, New York, and Los Angeles.³⁶ Alongside this corps of women, IBM had an all-male Customer Technical Representative group that did many of the same jobs as the System Service Women Corps. Lawless also identified a third group of technical employees with experience in field interaction: Applied Science Representatives, individuals with advanced degrees who helped with installations for scientific applications at universities and laboratories.³⁷

Lawless thought there should be a cohesive group that recognized the talent of computer-oriented engineers in the field, rewarded them with appropriate salary and rank, and created various forms of infrastructure for the exchange of ideas and techniques. Drawing on the name of the corps of women, he came up with a formal proposal for a new employee class to be called “System Engineers.” He outlined that this was “a profession for people of superior intelligence, solid technical education, a demonstrated flair for problem solving, and the desire to work in a field of unlimited possibilities to make significant contributions.”³⁸ Lawless successfully presented his proposal to Williams and to IBM’s president, Thomas J. Watson Jr., and IBM officially established the System Engineer employment classification in December 1960.³⁹

Lawless, who was named Director of Systems Engineering, established five levels of SEs: Trainee, Associate SE, SE, Advisory SE, and Senior SE. Later, Consulting SE became the sixth and highest level. With this reorganization, the gender separation of Customer Technical Representative in the System Service was eliminated and coeducational SE training courses were launched. As an employment class, “System Engineer” was “open to system services women.”⁴⁰ There were trainee courses, but also many advanced ones to allow SEs to further their career within the Field Engineering Division hierarchy, or seek promotions within other parts of the company. In 1961 SE Maggie Wilcox attended advanced training, as did SE Alan Seelenfreund. Both found the course useful to advance their career within IBM. Seelenfreund, who had a background in mechanical engineering and operations research, soon applied knowledge from the course to helping customers by educating them in inventory management simulation.⁴¹

Lawless and his staff established institutions to help engineers grow intellectually and to learn from one another. This included establishing the Systems Research Institute (where employees took “graduate level” engineering courses), setting up a major annual System Engineering Symposium, and launching the IBM Systems Journal. The first SE Symposium was held in October 1961, and the first issue of IBM Systems Journal was published the following year.⁴² The competitive, symposium program included more than seventy technical papers. Thomas J. Watson Jr. spoke at the first SE Symposium’s banquet, stating “the fact that we are beginning to recognize the tremendous need for systems engineering is an indication that IBM is still able to improve and change.”⁴³ That Ellen Kerksieck Schaefer reached the rare and esteemed status of Consulting SE is suggestive of the relative greater opportunity for women to advance in the field engineering path as opposed to sales in the 1960s.

By the end of the first year of launching the SE job class, IBM had more than 1,000 of them; by 1965 there were more than 5,000.⁴⁴ Rapid growth continued in succeeding years. In late 1968, IBM’s leaders made and soon announced the firm’s “unbundling” decision—that it would separately price much of its software and programming services. One challenge to implementing the SE program was that SEs bundled countless hours of work, in serving major IBM hardware customers and their systems needs. SEs supported the marketing mission, but initially were not formally part of the marketing division. Before unbundling, they represented IBM, but they did not have to sell themselves as consultants—they were seen by customers as a helpful and a “free” benefit of buying or leasing hardware. The fear of a newfound need to sell themselves as consultants led some to leave the SE ranks after the unbundling announcement, and others to resign. Many, however, stayed with IBM. Less than two years after announcing unbundling, IBM’s leaders made SEs full members of the marketing team (which had an associated technical managerial hierarchy). The number of SEs then continued to grow. By 1985 there were more than 20,000, outnumbering all non-SEs in marketing. Unlike CEs, who were around for initial installation and for shorter spans, SEs became true fixtures at customers’ facilities.⁴⁵ As Joy Greenwood, General Dynamics’ manager of data processing, put it in the first half of the 1980s, “the best SEs think of themselves as an extension of the customer [and] give you that extra effort to help you solve problems.”⁴⁶ With SEs, IBM advanced its stature in becoming a (or the) “solutions” company, which would later become an important component of its marketing.

IBM’s leaders made the unbundling decision in the context of escalating scrutiny by anti-trust lawyers in the US Department of Justice. In the early 1960s an independent software products industry had emerged; by the late 1960s it was rapidly expanding. Meanwhile, the computer services industry grew quickly. Many companies in both industries believed that bundling provided an anti-competitive advantage to IBM and thwarted their future growth. At the same time, IBM’s hardware competitors believed that the ties of bundling (offering “free” software and services, which was popular with customers), as well as IBM’s pre-announcements, made it more difficult to sell hardware (or software or services) to compete with the computer giant. These factors inspired the filing of lawsuits against IBM in the late 1960s by Applied Data Research (largely at the hands of this services firm’s relatively new Software Products Division), by Control Data Corporation (highlighting that a pre-announcement hurt its supercomputer business), and by the US Department of Justice (very shortly after unbundling was announced). Ultimately, IBM settled with CDC in 1973, one major component of the settlement being IBM’s sale of its Service Bureau Corporation (data processing services centers) subsidiary to CDC at an attractive price. The Department of Justice’s case was dismissed—in a changed political and computer industry environment—in 1986.⁴⁷

The pressured sale of SBC to CDC did not mean that IBM was exiting from computer services in 1973; it was merely exiting a particular segment—that of service bureaus or data centers. And SBC had already been separated as a wholly owned subsidiary, as a result of the 1956 consent decree that focused on pre-computer tabulating machines. By the early 1970s, IBM’s SEs generated far more value for the company than SBC, when both what was bundled and what was priced out are considered. At the time CDC acquired SBC, that subsidiary was creating substantially less than 0.7 percent of IBM’s overall revenue and even a lesser share of IBM’s profits. SEs generally had far more education, greater technical ability, and better programming and systems skills than the vast majority of employees within SBC. By 1985, with more than 20,000 in their ranks, SEs made up roughly 5 percent of IBM’s workforce, and were growing in number much faster than the company’s overall employees.⁴⁸

In addition to serving at many corporate computer installations, IBM Systems Engineers worked at many government facilities. The IBM Federal Systems Division, which initially was largely an extension of SAGE, began in the 1960s to serve (or to provide extended service to) many different government departments and agencies, including the Department of Defense, the Department of Energy, the Department of Transportation, the Department of Justice, the Federal Aviation Administration, the National Security Agency, the Federal Bureau of Investigation, Los Alamos National Laboratory, other federal labs, and NASA. IBM Systems Engineers ran the control systems that helped to put men on the moon. To a certain degree, the Federal Systems Division was set apart, as it served entities that did sensitive and sometimes highly classified work. In 1992, IBM’s Federal Systems Division had revenue of more than $2 billion and a net income of more than $70 million, and employed more than 11,000 workers.⁴⁹ Though some of its business was supplying hardware, most often the division was focused on designing and developing large-scale complex systems and applications that also required extensive advanced programming, networking, and systems integration services work—and, of course, considerable maintenance support. Such work was usually done by a combination of federal employees, government contractors, and on-site IBM technical personnel.

In the 1980s, with CEs, Federal Systems Division engineers, the Advanced Systems Development Division, and especially SEs, IBM was very much a services company (with tens of thousands focused on services work) before it focused on services as a (and in time the) primary profit center for the corporation. In contrast, services became a major profit center for one of IBM’s core mainframe competitors Control Data by the early 1970s and remained so through the 1980s.

Control Data Corporation’s Origins

By acquiring two pioneering computer startups—the Philadelphia-based Eckert-Mauchly Computer Corporation in 1950 and the St. Paul–based Engineering Research Associates (ERA) in 1952—Remington Rand gained early leadership in the computer industry. Its lead, however, was soon eclipsed with IBM’s entrance into the field. In 1955, the Sperry Corporation merged with Remington Rand; the resulting computer division was named Sperry-Univac after Remington Rand’s early and influential computer. Mismanagement, tight research and development budgets, and rivalry between the Philadelphia and Minnesota computer groups, left many engineers disgruntled, especially those in Minnesota.⁵⁰ Among the most talented and prominent of these engineers were William Norris and Seymour Cray. Sperry-Univac’s Willis Drake (an engineer) and Arnold Ryden (ERA’s former treasurer) developed a plan in the first half of 1957 to siphon away some of Sperry-Univac’s best technical and managerial talent—with Norris and Cray at the head of the list—for a new startup computer firm that was to be based in Minneapolis. Norris’ recent demotion from Sperry-Univac vice president and division manager aided the opportunity to successfully recruit Norris. Drake and Ryden teamed with three Minneapolis businessmen to found the Control Data Corporation (CDC) on July 8, 1957, the incorporation papers listing Norris as president.⁵¹ In September, the small team of roughly a dozen set up shop in a warehouse building at 501 Park Avenue in Minneapolis. Since the Department of Defense would be a primary focus for CDC, Cray was unwilling to leave an existing Sperry-Univac military project—the Naval Tactical Data System—in the lurch (the department and agencies of the DoD would be important customers for CDC from the start); he came aboard several months later, becoming CDC’s chief engineer and its leading computer designer.⁵²

9375_008_T8.1 — Table 8.1 Control Data’s first decade.

Control Data’s founders, through their own investments and the issuance of stock, raised more than half a million dollars, but the young firm soon developed financial difficulties. Facilities, the purchasing of Cedar Engineering (a supplier of aircraft components), and personnel costs all strained the company’s resources as it sought military computer contracts in its first years. Control Data’s early financial challenges eased greatly in 1959 when it was awarded several Department of Defense contracts, the most important of them a $2.5 million contract for the first CDC 1604 mainframe computer, which was to go to the Naval Postgraduate School in Monterey, California to be used principally for weather predictions for the Pacific Fleet. With a number of even larger contracts from the Department of Defense and the Department of Energy in the following two years, and a growing number of CDC 1604 installations, the company was growing rapidly and moving beyond its early financial struggles.⁵³ The CDC 1604, designed by Seymour Cray, was the first successful transistorized computer, and at the time of its delivery, early in 1960, was one of the most powerful computers in the world. The company followed the CDC 1604 with the Cray-designed CDC 6600, arguably the world’s first “supercomputer,” which was delivered in 1964. While CDC was producing the most powerful computers, it was also successfully developing other important computing businesses. By the early 1960s, it had a thriving business in computer peripherals, selling disk drives and other components and sub-assemblies to original equipment manufacturers. It also had fast-growing businesses in computer services.⁵⁴

CDC’s Early Data Centers, Programming Services, Engineering Services, and CYBERNET

One of CDC’s first six 1604 mainframes was installed at its downtown Minneapolis headquarters. It was used by CDC engineering staff for design work and for the company’s internal data processing needs (financial and managerial accounting), but also to launch a new type of business. William Norris was committed to starting and rapidly expanding computer services as a business from early in his tenure leading Control Data. This initial center aided customers purchasing a 1604—they could come to “perfect” planned computer applications programs before receiving their mainframe. The center, from its origin, also served as a traditional service bureau, where a range of scientific and business data processing customers purchased computer processing time and programming services.⁵⁵

The center’s first client (in 1960) was Klink Realty, located in northeast Minneapolis. The fixed-price contract of $400 was for developing a program to produce amortization tables. After the program had been delivered and the bill was 60 days past due, the center’s manager, making a personal collection effort, “found the office abandoned and no forwarding address.”⁵⁶ Despite its inauspicious start, the center soon secured business for data processing with three large companies based in Minnesota’s Twin Cities: Northern States Power (NSP), General Mills, and the Honeywell Corporation. The fact that Honeywell’s Aerospace and Ordnance divisions became frequent customers of CDC caused a rift with Honeywell’s top management, which wanted to nurture Honeywell’s emerging computer division on the East Coast. Thanks to business from Honeywell, General Mills, Northern States Power, and other firms, the data center’s monthly revenue exceeded $50,000 by the summer of 1961.⁵⁷

In 1961, CDC built a major new facility, which became its future headquarters, in Bloomington, Minnesota. The company also moved forward with plans for a large computing center in the heart of the region soon to be known as Silicon Valley—Palo Alto, California. The latter, in Stanford Industrial Park, was acquired under a lease-back arrangement and was more than 12,000 square feet in area; it housed a CDC 1604 that was installed in December 1961.⁵⁸

Figure 8.1 CDC Headquarters Data Center, Bloomington, Minnesota, 1962. Courtesy of Charles Babbage Institute, University of Minnesota.

CDC had entered the region a year earlier with a sales office in Sunnyvale, California that virtually from the start included an Applications Services Group to aid CDC’s computer hardware customers.⁵⁹ This group grew organically in serving programming and systems services needs of major customers such as Lockheed, and quickly expanded in lockstep with this rapidly growing technology region in the 1960s and the early 1970s. As R. C. Gunderson of CDC later articulated, “this strategy was born of necessity … . In a move to help the customer gain earlier use, we decided that each [CDC] system should be accompanied by a trained analyst, or applications programmer, as well as a customer engineer, for a period of six months at no additional cost to the customer.” While this initial six months was bundled, as Gunderson explained, “some of these people stayed on at the site, on analyst contracts [billed by CDC] or [leaving CDC] on customer’s payroll; for many were worth their weight in gold—to us and our customer.”⁶⁰ Even if they joined the customer organization, it enhanced a relationship between a customer and CDC—and its growing ecosystem of mainframes, peripherals, and (billed) services. Similar to and largely concurrent with a major CDC Applications Services Group emerging in Northern California, one also was born out of serving aerospace CDC hardware systems customers in Southern California (from CDC’s Los Angeles sales office). More generally, CDC’s sales offices, especially fast-growing ones, continually added additional programming staff to assist with custom software or with consulting, or to develop software products. (A CDC Software Development Group, which created standard products, also soon was launched in Silicon Valley). The Sunnyvale/Palo Alto locations truly stood out in the early 1960s and in subsequent years as many transplants from Minneapolis and elsewhere (as well as some nearby Californians) went to CDC’s facilities on the peninsula south of San Francisco as programmers, systems analysts, and managers.⁶¹

This Northern California CDC operation, however, also had its share of early organizational challenges. CDC essentially had the same problem throughout the 1960s that IBM had gone a long way to address by adding the job classification of five (later six) levels of Systems Engineers (SEs) in 1960. CDC’s “Application Analyst” organization (a designation that in the early years was used interchangeably with “Application Services Group”) faced considerable hurdles to upward mobility and had less functional reporting lines in comparison with programming staff at CDC data centers. Securing and retaining top technical talent was difficult insofar as application analysts (systems and applications programmers doing customer field work) were under the sales and marketing division and these analysts reported to sales managers who often had limited technical understanding.

In 1961, Robert M. Price joined CDC as a manager of the Application Analysts/Application Programming Group in Northern California. Price was an engineer with extensive programming experience. He had worked at Livermore National Laboratory (on a Univac), at the Georgia Institute of Technology (on an ERA 1101), at Convair (on an ERA 1103), and at Standard Oil.⁶² Because the Sunnyvale/Palo Alto operation had major contracts with Lockheed and other large firms, in just a few years it quickly grew to more than “several hundred” Application Analyst personnel. Price’s position created a technical/managerial layer that helped make the Application Analyst position more attractive; however, because of the overarching sales and marketing hierarchy, some awkwardness remained—for example, members of the technical staff reported to sales and marketing leaders. After several years in California, Price—who one day would succeed Norris as CDC’s president and CEO—became Sales Manager for International Operations, and soon thereafter, in 1966, General Manager for US Sales. His origins on the applications programming support side raised that side’s stature in the corporation and helped facilitate important incremental reporting changes. However, major organizational changes for Application Analysts, facilitating meaningful growth of the field services programming business within the company, required lifting of the artificial barrier within programming services between those in the sales and marketing organization (Application Analysts) and in the data centers (Analytical Services) to create the CDC Programming Services Division, or PSD, in the early 1970s.⁶³

Figure 8.2 A software programming group in CDC’s Palo Alto facility, circa late 1960s. Courtesy of Charles Babbage Institute, University of Minnesota.

From the first shipments of CDC 1604 systems in 1960 forward, another type of services—Engineering Services—also played a fundamental role. As several in this area recalled, the “product maintenance people received their training by actually helping to build the machines or engaging in ‘systems check-out.’” They essentially were sent in tandem with the shipped equipment to become site maintenance personnel. While known as “Engineering Services” for many years, the original name was the “Product Maintenance Group,” which soon evolved to the “Customer Engineer Group.” In 1962, R. F. Buelow took over as manager of the Product Maintenance Group. In 1963, the company established its first Customer Engineering Parts Warehouse, in Minneapolis, which was expanded multiple times in the 1960s before an even larger CDC World Distribution Center was built in neighboring St. Paul the following decade. In acquiring Bendix’s computer division in 1963, CDC’s Customer Engineering staff grew from 150 to 300.⁶⁴

Even before CDC’s 1970 “unbundling,” Customer Engineering was partially set up as a profit center for the firm. Two challenges for Customer Engineering during the 1960s were (lack of) “standardization,” and “staffing strategy” in association with the sales and marketing organization. This resulted from the fact that “no two of” the early CDC 6600 computers from Chippewa Falls, Wisconsin (a CDC computer development and manufacturing location Seymour Cray argued for, set up, and ran), “were built alike.”⁶⁵ This made all aspects of maintenance more difficult. With the latter, sales and marketing leaders wanted Customer Engineers (CEs) on hand for all major sales efforts, but CEs were responsible for keeping existing systems up and running 24/7. Sales and marketing invariably wanted CEs deployed to regions on the basis of sales forecasts, which often were substantially off the mark. This resulted in deployments of CEs (often from the US) to worldwide locations where sales failed to materialize at predicted levels, and shortages in areas (usually in certain regions of the US) where sales exceeded expectations. In 1968, R. C. Hall became vice president of customer engineering. He brought rationalized processes to Customer Engineering and to its integration and its interactions with the rest of the company. In 1968 and 1969, he established protocols that were still in place more than ten years later, working with design, production, sales, and marketing to improve engineering, logistics, finance, quality assurance, and operational support. One part of this effort was convincing top leaders throughout the corporation to be dedicated to “reliability, availability, and maintainability in the design of its products.”⁶⁶ Under Hall’s leadership, a Unified Field Reporting System was established so that Maintenance Services, the new name in 1969 (in taking on additional roles of “facilities engineering and construction” for new research and development and manufacturing sites), could have the best possible data readily at hand to serve installations. In 1969, under Hall’s guidance, Maintenance Services also took on the role of software maintenance or debugging, to enable Application Analysts to concentrate more fully on programming new applications.⁶⁷

On the data center side, by the end of 1963, Control Data was providing data processing services not only out of its large Bloomington, Minnesota, and Palo Alto, California facilities, but also dedicated data services centers in Washington, San Francisco, and Los Angeles. The following year CDC added centers in New York City and Houston.⁶⁸ This formed the basis of its newly established Data Services Division (DSD). This division, as one early DSD veteran B. T. von Schmidt-Pauli recalled, was able to “corral between 10 [and] 15 experienced [IBM] Service Bureau Corporation salesmen to form the nucleus of the DSD marketing force” in 1963 and 1964.⁶⁹ They had a difficult proposition, as these ex-IBMers had been focused on selling back-office business data processing (unit record equipment and IBM 1401s), and all of a sudden had to transition to marketing the powerful CDC 1604, a computer system that better fit advanced number-crunching, operations research, and simulation needs of the government and scientific computing market. After a steep learning curve, the DSD’s marketing staff adjusted to a very different clientele and set of needs. In 1964 the company reported that typical applications for its data centers were operations research, traffic surveying and planning, medical and hospital information processing, school scheduling and grading, and seismic record conversion.⁷⁰

From the launch of the Minneapolis data center forward, Control Data provided programming services out of its data centers. Its service bureau geographical reach and especially its programming services resources grew considerably with the 1967 acquisition of C-E-I-R, Inc., an all-stock deal of roughly $36 million in CDC shares.⁷¹ As it integrated C-E-I-R’s personnel and facilities, Control Data, by late 1968, had more than 33 data centers, including centers in Huntsville, Omaha, Detroit, Mexico City, Ottawa, Frankfurt, and Melbourne. Some of these centers utilized CDC 3600 and CDC 3800 computers, and some 1604s were redeployed or retired. Meanwhile, seven CDC 6600 supercomputers were installed in the second half of the 1960s at CDC data centers in New York, Boston, Washington, Bloomington (Minnesota), Houston, Los Angeles, and Palo Alto. With CDC’s extensive data center capacity, making efficient use of these resources became all the more important.⁷²

By the end of 1968, Control Data had multiple time-sharing centers in some major cities, with six in Washington, four in New York, three in Boston, and three in San Francisco. In these centers, users could utilize small computers or terminals to access processing resources and software on CDC 3000 series machines or its CDC 6600 supercomputers. Control Data set up high-speed transmission lines to connect centers on the West Coast (San Francisco, Los Angeles, and San Diego), in the Midwest (Minneapolis, Chicago, Cincinnati, and Cleveland), in the Middle South (Houston and Dallas), and on the East Coast (Washington, New York, and Boston). These regional networks also were connected by high-speed transmission lines. Meanwhile, lower-bandwidth telecommunication lines connected the major regional networks to centers in a number of other cities, including Omaha and Detroit.⁷³ In the late 1960s, CDC named this overall network infrastructure—which was similar in many respects to computer networks of time-sharing services providers GEIS and Tymshare, Inc.—CYBERNET.⁷⁴

Figure 8.3 A map representing CDC’s CYBERNET service, circa early 1970s. Courtesy of Charles Babbage Institute, University of Minnesota.

Organizational users often were purchasing more than just computer processing time. They benefited from libraries of code that CDC maintained in such areas as “operations research, transportation and urban planning, structural engineering, automatic machine tool control, market research, and seismic data reduction and other petroleum applications,” and from customized programming services that the data centers provided.⁷⁵ Control Data’s many sophisticated scientific and engineering users also advanced the software applications field and—following the lead of IBM’s users with SHARE, Inc.—exchanged insights and code through CDC’s user group CO-OP. The user group had been formed in 1959 shortly before the first deliveries of CDC 1604 systems to customers. As customer drew on both the CDC data centers’ resources and participated with CO-OP, these organizations and others also benefited from the Application Analysts who worked on site at their locations. This could be for small projects as well as large ones—an example of the latter was CDC’s consulting work in operations research to simulate Panama Canal traffic routing to offer greater efficiency and account for “a wide range of operating conditions, including such remote possibilities as a ship sinking in the canal.”⁷⁶

CDC’s Educational Services

Historian Nathan Ensmenger richly explored the “software crisis,” a labor crisis in the United States (and elsewhere) defined in part by the near perpetual shortage of programmers throughout the 1960s and much of the 1970s (and notions that software was not keeping up with hardware and the trajectory of circuitry advances—Moore’s Law).⁷⁷ The software crisis, frequently written about in trade publications such as Datamation in the 1960s and the 1970s, co-existed with a broader labor crisis that included many new and evolving occupations involving computing. Shortages of computer engineers, software engineers, systems analysts, and programmers often were prevalent, but alongside this there were also substantial shortages in computer technicians, an important occupational category vastly understudied by computer historians.

Figure 8.4 Students being instructed in computer maintenance at the Control Data Institute, 1968. Courtesy of Charles Babbage Institute, University of Minnesota.

Norris and Control Data witnessed firsthand the impact of the shortage of computer technicians (a broad category including certain types of computer operators, computer maintenance personnel, and computer factory laborers), and in 1964 they followed through on plans for a proprietary vocational school to be called the Control Data Institute. Existing vocational schools for training in electronics—including the RCA Institute, Brown Institute, and the DeVry Technical Institute—trained electronic technicians, but not computer technicians. CDC, other mainframe firms, and computer user organizations needed to retrain or extend electronics education into computing to meet their need for computer technicians. Control Data Institute, from the start, was focused on training computer technicians to work in “manufacturing, development, and field maintenance.” It was created to address the company’s workforce shortage in manufacturing, and maintenance services (internally, at customer sites, and data centers), but would soon evolve to train technicians, and later programmers, for the broader industry.⁷⁸

Control Data Institute (CDI), which recruited staff members in the spring of 1965, began instruction in Minneapolis in the fall of that year. Swen A. Larsen, a former employee of CDC-acquired DATATROL, was named General Manager of CDI. Taking possession of the facility of the former Gale Institute at 3255 Hennepin Avenue in Minneapolis in the summer of 1965 (the end of Gale’s summer session), very little time existed to improve the dilapidated building before the first CDI term. In the early months of CDI, it had problems of roof leaks, air conditioner malfunctions, and falling light fixtures. Nevertheless, the term continued uninterrupted as maintenance work and essential renovations were completed. The course of study entailed 4 hours of instruction per day for a year—a thousand hours in all—at a tuition rate of $1,795. The price was at the high end of the vocational school market, but, as Larsen saw it, a substantial price was associated with high-quality education and was necessary to support such education. In the initial term, which began in September 1965, there were 72 students (half of them instructed in the morning and half in the afternoon). New cohorts were added at six-week intervals. CDI received considerable attention, including a reported congratulatory letter to William Norris from Vice President Hubert Humphrey. To the company’s surprise, its justification (having been involved in internal corporate education for several years) to qualify for GI Bill funding from the start (obviating the two years in existence requirement) was accepted, and students who were military veterans qualified for support under the GI Bill in CDI’s first year.⁷⁹

CDI in Minneapolis was a success from its start, and William Norris and the CDC Board authorized plans to launch two more Control Data Institutes in the fall of 1966, one in Los Angeles and one in Arlington, Virginia. The schools in Los Angeles and Arlington required more marketing than the one in Minneapolis and were in the red for a couple of years. Control Data Institutes were created in Dallas and Detroit in 1967, and in Atlanta, Miami, New York, St. Louis, and Rockville, Maryland the following year. Many graduates were hired by Control Data, though a substantial number were hired by CDC’s computer industry competitors, as well as computer user organizations in industry and government. From the beginning, coursework prepared computer manufacturing technicians, computer operators, and maintenance personnel.⁸⁰

Most new hires by CDC in programming, unlike the majority of CDI students, were college graduates. Before the end of the 1960s, however, CDI added coursework for “programmer” tracks in response to demand by existing and prospective students. Many small programmer schools had begun in the 1960s, with some having poor reputations for quality and placement of graduates. CDI graduates of the late 1960s had little trouble finding positions, with some receiving multiple offers. Over time, the various CDI locations trained many thousands of programmers. In 1969 there were sixteen CDI schools spread throughout the nation and annual enrollment approached 4,000 students. By the early 1970s, CDI had expanded to offer training in additional areas such as “computer age secretary,” “credit specialist,” “bio-medical technician,” and “radio/television repair,” but these courses suffered from uneven or poor instruction and such tracks ultimately faltered. However, CDI’s courses for computer technicians and computer programmers were successful in the late 1960s. The Control Data brand, and the focus on quality instructors for these specialties, mattered. The success of CDI spawned imitators within the computer industry (at Honeywell and at Sperry Rand’s Sperry-Univac Division) and outside of it (at Bell and Howell and at Sylvania).⁸¹

The recessionary years of the early to mid 1970s proved difficult for the CDI Division and the school’s graduates. In contrast to the favorable job market of the late 1960s, in the 1970s CDI graduates were having difficulties securing job offers. Somewhat similar to the “great financial recession” of 2007–2010, government officials and media responded harshly to CDI and other for-profit educational institutions that were heavily dependent on government loan programs when graduates could not find jobs and defaulted on loans.⁸² Despite challenges and critique, CDI expanded nationally and internationally with more than sixty locations by the late 1970s. This highlighted another challenge for CDC, one outside its core capabilities: managing the real estate assets to provide these educational services. But with Norris at the helm, CDI pressed onward. Norris expected it to become a major test bed for an equally favored initiative of his: computer-based education.

William Norris was dedicated to, and was in many ways a pioneering figure in, what today is commonly termed corporate social responsibility. He saw the poverty of North Minneapolis neighborhoods, and of neighborhoods in other inner cities where CDC had facilities, and wanted to help. CDC invested in building a major manufacturing operation in North Minneapolis, and hired people who often had been excluded from the workforce, especially in IT—individuals with little formal education, members of racial and ethnic minorities, and former convicts. Norris saw this as the right thing to do and also as good business. His aim was largely the same with CDI, and he and fellow CDC executives saw PLATO (a computer/software educational and instructional system) as part of a continuing saga of CDC educational services. CDC’s goal with CDIs was educating and placing students who did not have the means or inclination to attend four-year colleges and universities in careers—and, in the process, helping CDC and the computer field. Norris also wanted to broaden education and make it more affordable, to use computing to enhance efficiency in education, and to offer new opportunities and techniques for learning.⁸³

In the early 1960s, pioneers at the University of Illinois developed a version of PLATO, a high-end graphics-based computer educational/instructional system that went through a number of iterations in succeeding years. Norris and CDC secured rights to market PLATO technology in the early 1970s and sought to do this through CDC’s CDIs and by forming partnerships with clients in existing educational institutions—K–12 schools, colleges, and universities—throughout the US and beyond. But PLATO was not a cost-effective, suitable solution for education in the mid 1970s to the mid 1980s, a time when CDC devoted considerable resources to developing, marketing, and deploying versions of PLATO and associated courseware.⁸⁴ Similarly, the Control Data Institutes, despite their great start in Minneapolis in the late 1960s, produced inconsistent contributions to the corporation’s bottom line. Nonetheless, these institutes did educate many current and future CDC employees, including many who went on to perform maintenance, applications programming, and other services for Control Data and its customers.

Establishing and Rapidly Growing CDC’s Professional Services Division

Control Data’s educational services had some modest successes (a subset of CDI tracks and locations that thrived for shorter periods of time) coupled with failed long-term business initiatives (PLATO). CDC’s overall services operation, however, grew substantially in the late 1960s and the 1970s—both as an activity and as a core business. At the start of the 1970s, CDC rationalized its hitherto disparate services activities and businesses by unbundling services from hardware, as well as through organizational changes.

Throughout the 1960s, CDC typically (at new installations) bundled some maintenance and applications programming services into customers’ computer hardware contracts. IBM’s 1968 unbundling decision led CDC’s management to revisit its own policies and practices with software and services. Norris appointed a “Software Task Force” that met on September 12, 1969 and recommended unbundling, or separate pricing for equipment, software, programming services, and maintenance. The task force believed the transition for customers would be eased because “IBM has set the stage … which should make the concept … easier for our sales force to explain in the market place.”⁸⁵ Control Data moved quickly with unbundling. After a small CDC team toured the sales regions in the US to inform field personnel about it, CDC publicly announced its unbundling policy on October 1, 1969. On December 19, 1969, Norris formed a Pricing Committee Unbundling Subcommittee; it began implementation of unbundling software and services in 1970. The customer base readily accepted the new pricing for “engineering services,” “education services,” and “training.” There was more resistance from customers regarding systems software and “analyst support” services (applications programming).⁸⁶ Nonetheless, the company moved forward with unbundling all these types of services. Initially, CDC set forth a policy of maintaining ownership of all programming services resulting in a software “product” (a customer merely had a license to use what it purchased). Negative response from customers and in the trade press led to a revision of this policy in January 1970 so that all paid-for application services programs and packages (work product) belonged to the customer. CDC still learned from and benefited from applying one programming services effort to the next of a similar type.⁸⁷

Unbundling had many advantages and positive results for Control Data. First, IBM’s unbundling helped lessen the advantage that IBM had gained through bundling and its unparalleled support services. Second, IBM’s having unbundled first allowed CDC to raise prices (by not reducing hardware prices commensurate to the newly priced services) without losing many customers as a consequence. Third, IBM’s unbundling provided momentum to the independent software products and services industries. Overwhelmingly, companies in these industries targeted IBM’s base and its market share of more than 60 percent. Also, since CDC was more concentrated on science and engineering customers, it was more immune to the core of the software and services industries, which focused on business applications. And fourth, it forced CDC management to give serious thought to the organization and rationalization of its services (and its much smaller software products) businesses.⁸⁸ Beginning in the early 1970s, this led to a much more coherent and integrated services strategy.

Figure 8.5 Ken Clary (left), an operator at CDC’s CYBERNET Services Center in Houston, working with a client (Donald McLain of Tetra Tech, Inc.), circa late 1970s. Courtesy of Charles Babbage Institute, University of Minnesota.

From the time of CDC’s launching of programming and data services at the beginning of the 1960s, these services were provided to customers by two very different organizations within Control Data: the data centers and the sales and marketing organization. The Data Services Division ran the data centers that grew steadily in number and size—especially with the acquisition of C-E-I-R in 1967. Integrating C-E-I-R doubled the size of the DSD and lent momentum to rapidly expanding time-sharing services operations and optimization of resources with CYBERNET. In the early 1970s, CDC ran more than forty data centers, about three fourths of them in the US and one fourth overseas. Within the data centers, there were advancement opportunities for both technical and managerial staff—upward mobility within and between data centers.⁸⁹

Nothing comparable existed for the “Application Analyst” programmers working out of sales and marketing in the field, who overlapped in function with some DSD staff in providing applications programming for customers. In response, in January 1971, Norris and the board reorganized the company to establish the Professional Services Division (PSD). The new division included both the programmers and analysts of the former DSD and those with the sales and marketing organization. This was a major step in the maturation of services at Control Data, and along with unbundling it set the stage for rapid growth of services as a CDC business. Control Data immediately instituted a more aggressive approach to market services to customers of systems and the data centers. Although the “Total Services,” strategy and the “Total Marketing” concepts and mantras withered somewhat, some of their attributes—for example, aggressively selling services whenever possible and targeting key industries as well as government—did not. With “Total Marketing” the company sought to analyze customers’ needs and put together a particular package of “hardware, software, and service that is best suited to meet those needs,” with an “emphasis … not on pushing our products but on solving their problems.”⁹⁰ With the start of PSD, CDC also began to break out and publicly report the revenue of its services business. (See table 8.2.)

9375_008_T8.2 — Table 8.2 Control Data’s Services Business.

With the 1971 reorganization, Control Data had a renewed and heightened commitment to sell services within its Military Division.⁹¹ This division’s first contract in its founding year of 1958, in fact, had been for services—a consultant study of replacing prelaunch fire-control computers for Polaris missiles. The following year, CDC received the prime contract (for $7.4 million) from the US Navy to design and build those computers. Throughout the 1960s and increasingly in the 1970s, CDC sold services along with hardware to government clients, including the Air Force, the Navy, the Army, NASA, NSA, and other departments and agencies.⁹²

CDC’s computer services thrived in the first half of the 1970s in a difficult overall economic environment characterized by a deep recession resulting from the OPEC oil crisis. Between 1971 and 1975, CDC’s services business more than tripled its revenue from $139 million to $445 million, while services went from being one fourth of CDC’s overall computer revenue to more than one third. The acquisition of Service Bureau Corporation in 1973 from IBM was important to this rise.⁹³

In 1974, as a result of integrating SBC, CDC had data centers in seventy US cities—and multiple data centers in some major cities. CDC’s data center services, as well as field consulting, were supplying services to some of the largest industries including banking, insurance, finance, utilities, and retail, as well as government. CDC also rapidly expanded its international services operations in the first half of the 1970s. By the mid 1970s, CDC had substantial data centers and time-sharing infrastructure in Canada, Europe, Brazil, and the Near East.⁹⁴ Networking made these operations all the more efficient (more efficient use of computer processing resources) as CDC immediately began integrating its CYBERNET and SBC’s computer network.⁹⁵

For a number of years computer services were in the shadows of CDC’s supercomputers, but by the mid 1970s the company’s leaders began placing it in the spotlight. CDC’s 1975 annual report contained an item titled “Services Profits Improve Markedly.” “The mature data services,” it stated, “produce a higher rate of return than any of our product businesses [and] offer the company our greatest growth potential with less risk than most hardware products now that we have the major part of our world network in place.”⁹⁶ CDC had thousands of computer services specialists serving customers around the world by the mid 1970s.⁹⁷ A 1975 planning document highlighted the diversity of CDC’s professional services, which included “data management consulting services, structural engineering, engineering management operations, information services, automated engineering and production consultants, and network consulting services.”⁹⁸

While growing markedly in the first half of the 1970s, CDC also suffered some setbacks on delivering on the largest, most complex contracts for programming services. The setbacks highlighted the fact that real-time systems integration (which had long delayed SAGE and SABRE) remained a perpetual challenge in the industry. In the early 1970s, CDC won the contract for the Air Force’s Advanced Logistic System (ALS) project, a $250 million multi-year project to build a real-time system (hardware, software, networking, and systems integration) to control logistics (personnel, food, equipment, weaponry, supplies, etc.) for the Air Force.⁹⁹ Many of CDC’s military projects were successful, but this one was not—and the Air Force had been warned that it was too ambitious by Willis Ware of the RAND Corporation.¹⁰⁰ Ultimately, CDC and the Air Force reprogrammed the ALS just for batch processing, rather than its raison d’être—real-time processing. The company also experienced a setback on a major networked banking system for Union Bank of Switzerland in the first half of the 1970s, further highlighting the great challenges for massive real-time transaction processing systems.¹⁰¹

In the second half of the 1970s, CDC’s computer services continued to expand quickly. By 1977, CDC had a staff of more than 1,000 who were focused on marketing the services of the company’s data center employees and field consultants. That year, in the United States, it provided computer services to more than half of the Fortune 500 companies, for eighty leading banks, for seventy-five major finance firms, and for fifty large insurance companies. It also did substantial business servicing the Department of Defense, the Department of Energy, the civilian federal government, and local governments. Its services clients also included 4,500 smaller businesses. Meanwhile, its telecommunications and satellite communications network allowed CDC to serve customers in two dozen countries.¹⁰²

Figure 8.6 Robert Price (foreground) succeeded William Norris (background) as CDC’s CEO in 1985. Courtesy of Charles Babbage Institute, University of Minnesota.

In the early 1980s, Robert Price was named Control Data’s president and chief operating officer. William Norris continued as CEO and chairman of the board. During that time period, Norbert Berg, vice chairman of the board, was the third member of the company’s leadership. In 1985, Norris retired and Price became CEO and chairman of the board, inheriting the reigns at a difficult time. In 1984, after many consecutive years of growing earnings, CDC lost $45 million. More troubling, the following year it had a decline in revenue and a loss of $563 million, including a $209 million loss from operating activity. (Most of the remainder was a result of restructuring charges—largely the sale of Commercial Credit, a financing subsidiary.) CDC had become too diverse, had too much overhead, and was vulnerable to an economic downturn. When a downturn occurred, events spiraled out of control for CDC and resulted in a liquidity crisis that became all the more challenging when a 1985 public offering of additional stock faltered. Price and CDC focused on trying to shorten receivables while delaying payables, essentially doing whatever they could to conserve cash and stay solvent.¹⁰³

CDC’s businesses in mainframe systems and computer peripherals were declining, and the company had invested heavily in unprofitable educational services with PLATO. CDC’s computer business (systems, services, and peripherals), now the entire firm with divestment of Commercial Credit, lost another $311 million in 1986 before showing a profit of $57 million in 1987 on revenue that was down by about 10 percent from its 1984 level. CDC achieved earnings of merely $19 million and $2 million in 1987 and 1988 before a disastrous 1989. In that year, revenue was down more $700 million from mid-1980s levels; the company lost $680 million, and that led to changes in top management.¹⁰⁴

8 Expanding Capabilities: IBM and Control Data, 1960–1988