Case Study: J. Lyons & Co.By Brian Hayes | Posted 11-01-2001
Case Study: J. Lyons & Co.
Congratulations! You've just been named CIO of J. Lyons & Co., a prosperous British firm with a chain of tea shops and popular brands of baked goods and ice cream. The board of directors expects your department to streamline the company's clerical work and provide up-to-the-minute analysis of sales and costs. With your experience in office automation and decision-support systems, the task ought to be straightforward. There's just one catch: It's 1949, and software for the tasks you've been assigned doesn't exist. As a matter of fact, the very word "software" has yet to be coined. You'll have to write all your own applications. As you get to work on that job, keep in mind that programming languages are still in the future as well, so you'll have to code in absolute binary. Oh, and one more thing: Lyons doesn't actually have a computer yet. Your first job is to build one.
A tall order at any time, but remarkably, all these challenges were met by the Lyons staff. For starters, they assembled a do-it-yourself computer they called LEO, for Lyons Electronic Office, which filled up a room the size of a tennis court at Cadby Hall, the Lyons headquarters in London. While the hardware was under construction, another in-house team set to work on flowcharts for the software, and then turned these specifications into finely tuned and carefully checked machine code. In mid-November 1951 just 50 years ago this monthLEO ran its first program on live data. It was the first time anywhere in the world that an electronic stored-program computer had been applied to routine business operationsand some operations that weren't so routine. LEO was designed not just to automate clerical tasks such as payroll but also to provide management with a tool for analyzing near-real-time sales data, giving Lyons a strategic advantage over its competitors. It's a story about innovation in the service of clear business goalsand it led to an extraordinary record of exponential growth in computing power. Yet the most important lesson to be learned from the story of LEO stems from its inventors' warning, early on, that productivity isn't just a matter of power, but of applying that power creatively to the task at hand.
Crumpets and Computers
Crumpets and Computers
How did a chain of English tea shops wind up in the vanguard of business computing? Other companies surely had greater resources for such an undertaking, and perhaps a greater need for the blessings of information technology. One might have expected to find the earliest IT leader among the big banks or insurance companies, with their tremendous burden of paperwork, or perhaps in the aircraft industry, where computers were already in use for engineering and research. For an outfit such as Lyons to leapfrog all of those larger and likelier contenders seems preposterous.
A closer look at J. Lyons & Co. suggests, however, that it's not quite so bizarre. First, describing the company as a chain of tea shops makes it sound small, quaint and probably old-fashioned. In fact, Lyons was a major British manufacturer and retailer with 33,000 employeesthe 1950s equivalent of Starbucks, or perhaps McDonald's. And it already had a reputation for managerial and technological innovation. Long before it became the first company to use a computer for business, it was the first to use microfilm, and it was an early adopter of frozen foods and microwave ovens. While the rest of Britain was still counting money in pounds, shillings and pence, Lyons had decimalized its internal accounts. And it had plenty of prior experience with technological "in-sourcing"; the Cadby Hall workshops where LEO was assembled had earlier built custom bakery equipment and delivery vans. Lyons even ran its own laundry and dressmaking operations.
The company attracted serious intellectual talent. John R.M. Simmons and T. Raymond Thompson, the two senior proponents of the LEO project, were both Cambridge "wranglers"graduates who had earned high honors in mathematics. The pair hired a younger Cambridge alumnus John Pinkerton to oversee hardware development. Other key figures came up within the organization. David T. Caminer, whose function would today be described as system architect, had been hired as a young management trainee. E. H. Lenaerts, Pinkerton's assistant, started out as a clerk and an electrician. (Another junior employee bears mentioning even though she had nothing to do with LEO. Margaret Roberts worked as a chemist at Lyons before launching a political career under her married name, Margaret Thatcher.)
In a memoir about the LEO project, Caminer wrote, "Those who afterwards smiled at the notion of a tea shop concern designing and manufacturing advanced electronic equipment and putting it to work are misleading themselves. Lyons was not just a small back room of cooks and waitresses. Technically, it was a remarkably comprehensive and self-reliant organization that had long experience of recognizing way-out ideas and carrying them through to timely fruition."
A self-reliant organizationbut not an isolated one. The group that built LEO were not basement tinkerers, working alone and cut off from the rest of the world. They were well aware of the computer work going on in various U.S. laboratories. Thompson and an assistant had visited the University of Pennsylvania and Princeton and Harvard universities in 1947. And the team worked in especially close collaboration with Cambridge University, where the pioneering computer called EDSAC was under construction. Indeed, much of LEO's design was copied directly from EDSAC.
Even with these resources to draw upon, however, the board's decision to build LEO was clearly an act of high adventure. You can't help but admire their pluck. For a similarly situated company to try the same thing today would be unthinkable folly.
In our age of gigahertz processors and gigabyte memories, it's hard to fathom what "state of the art" meant 50 years ago. LEO's entire memory was able to accommodate 2,048 numbers, or 17-bit instructions. Everything had to fit within that spaceapplication programs, system software, device drivers, data. There was no swapping out pages to disk, because there was no disk. The original plan had called for magnetic tape storage, but the balky tape decks didn't work until several years later, so all input and output had to be done with punch cards and perforated paper tape.
The memory units were not dynamic RAM chips or even the magnetic cores familiar to an earlier generation; instead, they were based on a long-forgottenand unmournedtechnology called mercury delay lines. A long tube filled with liquid mercury was fitted at each end with acoustic transducers, equivalent to a microphone and a loudspeaker, to create a sort of barometer wired for stereo. Bits to be stored were converted by one transducer into sonic pulses, which traveled through the mercury as sound waves, to be detected at the far end by the other transducer. The detected signal was amplified and sent back to the first transducer, so that a train of pulses was kept circulating constantly. To read any particular bit, you had to wait for it to come around to the detector, once every 500 microseconds. In all, there were 80 of these bulky and temperamental delay lines.
LEO's logical and arithmetical circuits were built of vacuum tubes (or valves, as the British called them). More than 5,000 glowing tubes were mounted in 21 floor- to-ceiling racks. In photographs of the installation, the rows of tall racks, with ventilation ducts overhead and a raised floor for cabling underfoot, look remarkably like a modern Internet server farm. All that's missing are the brightly colored skeins of fiber-optic cable.
The speed of LEO's processor was determined mainly by the 500-microsecond access time of its acoustic memory. A basic operation, such as adding two numbers, took about 1,300 microseconds. Thus the machine could chug along at a few hundred additions per second, assuming it had nothing else to do. Simmons described this rate of calculation as "almost incredible speed."
Indeed, the CPU speed was more than adequate for Lyons's purposes; the real bottleneck in putting the machine to work was input and output. All electronic computers built up to this timeall three or four of themwere meant for CPU-intensive scientific or engineering tasks such as solving differential equations. The input was just a few numbers, which the computer might chew on for hours before it spit out a few more numbers as answers. The primarily clerical tasks envisioned for LEO were quite different. In processing a payroll, for example, the calculations amounted to just a few additions and subtractions for each employee, but thousands of employee records had to be read in and thousands of paychecks printed out. The challenge was building input/output gear that could keep up with the processoreven a processor running at half a megahertz.
The most fundamental I/O problem, which was deeply vexing to the LEO designers, is one that has totally slipped beneath our notice today. The LEO processor (like modern chips) operated on binary numbers, but people demanded decimal input and output. If the conversions had been done in software, they would have consumed 90 percent of the machine's capacity. Where pounds, shillings and pence couldn't be avoided, the routines would have to deal with base 12 and base 20 as well as base 10. After some false starts, the whole problem was solved by wiring up a special hardware unit just for base conversions.
's Last Roar">
LEO's Last Roar
Looking back on the LEO story from 50 years on, there is much to marvel at, starting with the mere fact that the contraption actually worked. Indeed, it succeeded so well that Lyons was soon taking in computing jobs on a service-bureau basis. (At one point, they were hired to calculate the distances between all 7,000 railway stations in Britain.) When this business also proved popular, Lyons set up a subsidiary to build and sell LEO computers, transforming the tea-and-pastry company into an electronics manufacturer. The first machine offered for sale, in 1956, was an updated version called the LEO II, followed in 1961 by a transistorized LEO III. Major customers included the British division of Ford Motor Co. and the British Post Office, which at one point had five LEOs churning out telephone bills.
Within Lyons, the biggest regular computing job was the weekly payroll. LEO took a second and a half for each employee, compared with eight minutes using manual methods.
Other early LEO computations offer a more revealing glimpse of how business computing was to evolve in the years to come. An example that seems well ahead of its time is the job referred to as Tea Shops Distribution. In a period when computing was almost always done as a batch process, this was a near-real-time operation. Before the computer came along, the 200 Lyons tea shops sent in nightly order forms for the next day's supplies. "In a very few hours," Caminer writes, "the orders from all the shops had to be collated so that requisitions could be forwarded to the bakeries and kitchens and other departments. Then the orders had to be valued and the goods assembled and loaded onto the waiting distribution vans."
It was easy to see how the computer could speed the mathematical parts of this process, but if all the information on the order forms had to be key-punched every night, data entry would swallow up all the savings of time and labor. The key to finding a solution involved recognizing that the order forms were highly repetitive. In the new system, each shop had a standing order for each day of the week; changes were received by telephone each afternoon and entered directly onto punch cards by the telephone operator. This scheme is a long way from the kind of networked supply-chain system that might be proposed today for the same function, but it was the closest approximation possible, given the technology available in the early 1950s.
The very first LEO applicationthe program that was run back in November 1951is also an interesting case study. The function of this program was "valuation" of the weekly bakery outputsumming up all the costs of labor and ingredients and then distributing appropriate shares of these costs across the various product lines and retail outlets. This job was chosen for the first run because it made only modest demands on the I/O equipment, which was not yet fully working in 1951. More interesting, the computer's function here was not so much to mechanize routine administrative work but to provide managers with prompt summary statistics and an analysis of costs and profits. In other words, from the very outset LEO was not just a data-processing installation but a management-information system.
The LEO experiment was a remarkable success in its time, and yet today you will not find the LEO name in any catalog of computer brands. In the late 1960s, as competition among computer makers grew more intense, the Lyons board had to choose between the company's traditional lines of business and the computer division. LEO was merged, and eventually submerged, in the British firm International Computers Ltd., which was acquired by Fujitsu Ltd. in 1990. Lyons itself met a similar fate. In 1978 it was acquired by a consortium of breweries, and then passed from hand to hand in an immensely complicated series of mergers and acquisitions. Today, almost nothing remains of the original Lyons businesses. Cadby Hall, where the vacuum tubes of the first LEO hummed and glowed half a century ago, was torn down in 1985.
If you compare LEO with an off-the-shelf desktop PC of 2001, you see that 50 years of technological progress have increased memory capacity almost a million-fold and processor speed by a factor of roughly a thousand. Meanwhile, prices have fallen by another factor of a thousand. Although these measures of computing efficiency are rather crude, when you combine them in the obvious way, they suggest that one dollar's worth of computing today is equal to nearly a trillion dollars' worth in LEO's era. This represents an extraordinary record of sustained exponential growth in computer power per unit cost. But while toasting our good fortune, we might pause to ask why business productivity has not also increased a trillion-fold.
The architects of the LEO system already had a glimmer of an answer to this question. They recognized that computing horsepower was of little use if it could not be effectively harnessed to the problem at hand. Caminer writes, "It was plain that applications for the computer had to be defined in such a way that an item of data, once taken into the system, must automatically be used and reused for every purpose in which it played a part."
John Aris, another LEO veteran, echoes that theme. "Getting anything into a computer is a major effort, so make the most of it," he says. "Understand the system in its entirety. Plan it as a whole. Rethink, rather than automate, what is there. Maximize the savings in clerical effort, stock holdings, response time to customers or whatever. Make the data sweat by producing management information as well as transactions. Don't leave what could be done effectively by computer to be done by hand."
In retrospect, all these entreaties to system integration and business re-engineering suggest a hypothesis: that the factor limiting computer efficiency was never memory capacity or processor speed, but rather the awkward interface between the computer and the outside world. In the 1950s, and for some decades afterward, the way to alleviate this congestion at the interface was to speed input and output. When a computer was viewed as a tool for converting a deck of punch cards into a heap of printouts, it made sense to invest first in faster keypunches and line printers.
Only in recent years has another strategy become possible: not to improve the interface but to eliminate it, by moving the whole core of the business permanently into the computer. Input and output cease to be a serious constraint when everything of importance lives and dies inside the computer and never leaves that digital environment. With ubiquitous networking, with industry standards for data interchange and electronic commerce, and with the attitude that digital information is primary and archival, the merits of this idea can finally be put to the test.
Brian Hayes writes about science, technology and mathematics for American Scientist magazine and other publications. Comments on this story can be sent to firstname.lastname@example.org.
ICL: A Business and Technical History
By Martin Campbell-Kelly
Oxford: The Clarendon Press, 1989
LEO: The Incredible Story of the World's First Business Computer
By David T. Caminer, John Aris, Peter Hermon and Frank Land
New York: McGraw-Hill Professional Publishing, 1997
Inventing System Engineering
By John Aris. IEEE Annals of the History of Computing; 22(3): 415, 2000
LEO and Its Applications: The Beginning of Business Computing
By David T. Caminer. The Computer Journal; 40(10), 1997
www.is.lse.ac.uk/BusinessComputing50/ Business Computing: The Second 50 Years