Keywords

1 Software and the Contemporary History of Computing

“But the computer is an all-purpose machine, and the computer display - a screen programmed to present text and pictures somehow stored in the computer - is a universal miraculous communication tool”, Ted Nelson [1, p. 17].

“It is the history of computer software and not of the computer itself that is at the heart of the larger story of the great computer revolution of the mid- to late twentieth century” emphasizes the historian Nathan Ensmenger in his recent study about programmers and computer users in the Digital Age [2, p. 6]. Especially in the banking sector the importance of software in the digital (r)evolutionFootnote 1 is striking, but nearly untold. Banks were not only early user of computers, but also of software services as the implementation of computers into their business processes. Through the lens of Software, this article aims to show how the liaison of computing and a financially powerful industry created a vast potential for change in the way banking was conducted in the 1960s and 70s, as well as the pitfalls of this development. With the example of East and West German savings banks, which had the largest customer-base of all banks throughout Europe, I am stressing the question: How was “the bank” represented in its software? Who wrote the code of banking, the programs, and the documentations? Following these central questions, it is interesting if there had been a specific socialist or capitalist way of deploying computers within banks and if one can distinguish between a capitalist and a socialist (banking) software. The comparison of the software uses and ways of production in East and West Germany presents a unique insight. Little is known, for instance, about the extent to which Eastern German banking officials had access to the technological and software developments made in West Germany. In fact, West German software products were copied and adapted to the needs of socialist banking. In this paper I’m showing in which way international knowledge transfer shaped the way banks where digitalized. It is critical how comparable institutions and their respective employees in different economic systems dealt with the new ways of intra-active data procession and the pitfalls of software production. That would have had an impact on how banking was represented inside the machine. After a short summary on what software actually was and who produced it for the banks, three use cases follow demonstrating the influence of software on the whole banking process.

The aim is not to replace a hardware perspective by looking only at software, but rather to place it in a Deleuzian assemblage. This assemblage contains technology, its users, the code and its execution in a broader understanding of the term software. Following Ensmenger and Haigh, the question how to define “the computer” in respect to software is striking. Since the 1970s there was a long debate about what a computer actually is. Especially the touring completeness of the computer, the question, what “stored-program” and “digital” meant for whom and the particular national interests made it so hard to decide [3]. A touring complete machine is a machine that can solve every solvable program given infinite time. That constitutes the universal character of every computer to possibly simulate every other machine of the past, present and future. Among others, this is the key feature of a computer that constitutes it as a general-purpose machine. The German media theorist Friedrich Kittler emphasized this forcefully in his media archaeology by defining the computer only by his programmability [4]. Not until the act of running a program, the general-purpose machine becomes specified, concrete and useful for the computer user. Thereby, it does not matter if the computer is analog, digital or even virtual. The software has the power to transform a super-fast calculating machine into every desired machine, be it a text automaton, a business machine, a passbook or a drawing device. It hints to the question how a computer was actually used by the historical actors. At the end of the 1980s, the founder of historical software studies, Michael S. Mahoney, already pointed out that a computer without software is as useless as a car without gasoline [5]. Software had become the intra-faceFootnote 2 between the computer and society in the course of computerization. Computerization I understand as the fundamental process of the widespread diffusion of digital information and communication technology and its penetration of nearly every aspect of life during the second half of the 20th Century [7–8, p. 227]. In contrast to this definition I understand digitalization as the electronic representation of objects in code, even though both terms are frequently used as synonyms nowadays [9, pp. 33–34]. Only through software the computer became the primary window to understand the world, the means for nearly every human to perceive, interpret and to express the world. Through software, the computer became the embodiment of the highest political, cultural and economic aspirations, as well as of regular daily business. And so Ensmenger concludes:

“when people talk about the larger process of the computerization of modern society, or speak of the computer revolution transforming the ways in which they work, live, consume, recreate, and engage in social and personal relationships, they are really talking about the history of software” [2].

But thinking of software as a product is misleading for analyzing the process of computerization. Software was far more than just an executable program that you buy on a data carrier or download like you purchase Microsoft Word for having a customizable word processor.Footnote 3 Therefore a conceptual history is necessary to understand the different layers of meaning that are encapsulated in the term software. At the same time, software history already tells a lot about the recent historical developments in a time of ongoing commodification.

1.1 A Conceptual History of Software

In the late 1950s and the 1960s, computer people – experts like programmers, system analysts, technicians or administrators – understood software in two different ways. On the one hand they understood it in a narrow sense describing programs to develop other programs and to control the hardware. On the other hand they understood it mainly as a strand of systems, services and support [10, pp. 5–6]. Programs were seen as universal mathematical solutions that nobody could own. Consequently, programs had no name. Software in the early period of computerization combined whole systems of machines, their instructions, the organization, programmers, users and processes. Therefore, software can be methodologically described as a Deleuzian assemblage combining independent elements within a temporal [11] liaison. The term software was first mentioned by the statistician John Tukey in 1958 as everything beyond the tubes, transistors and cables. The Oxford English Dictionary is enlisting the first use of the term for the year 1960 in the journal Communication of the ACM, whereby the author is describing COBOL as “software” [11, p. 69]. Its semantic change from a narrow to a broader, system oriented meaning bears to the height of system theory in the late 1960s. To give a concrete example: If a savings bank wanted to digitalize its transactions, the bank not only had to write millions of lines of code or to buy a fancy product. It had to analyze its business processes up to the single steps of action and had to fit the computer into it – or adapt the processes to the machine. The bank had to reorganize its personnel and its organizational structure, it had to train the users, buy the peripherals and write new instructions, manuals and documentations. In a nutshell: the result of the computerization was software.

For a bank, software in the 1950s and 1960 was more like hiring a consultancy than buying a product [12]. But the consultancies of choice in most of the cases were the huge hardware producers who offered software as a service together with their machines. Sales persons at IBM not only needed to understand the machines they were selling. They also had to analyze and understand the way their customers worked and had to offer solutions of how to optimize it. Seldom was this an easy task as it meant change to established hierarchies. Therefore, it is important to tell the story of the computerization of Germany not only as a success story of rapid diffusion of a superior technology. It was a conflictive process, in which software can be described as a Deleuzian assemblage per excellence. Its heterogeneous parts were fighting for power, sovereignty and authority [2, p. 7]. Whilst Nathan Ensmenger and Rob Kling are focusing on the new power of the programmer and the IT-departments within organizations, the historian of technology David Gugerli argues that standardization and strict rules of usage, language and education limited the creative freedom of the programmers severely [8, 13].

In this respect it is striking to look at the computerization of the former GDR and their socialist rule of language with a wider understanding of the term software. Computer people in the GDR were talking not about software but about “system documents” (“Systemunterlagen”) for a long time. The different denomination corresponded with the maxim of the party elite to use the German terms rather than the English ones in a battle against a perceived imperialist American influence through technology and language.Footnote 4 But at the same time they also distinguished themselves from the Russian usage of matematicheskoe obespechenie for Software, which meant as much as mathematical supply.Footnote 5 Systemunterlagen catches the initial understanding of computer usage in the 1960s much better than the term software, which is buried under the different layers of meaning that software carries today and that is bound to a binary separation of hard and soft. System not only meant the actual computer. Rather it described in a cybernetic way the whole environment of the computer, for example the division that ran it.

Not until the middle of the 1970s did the term “Soft-Ware” become established in the GDR written with a hyphen analog to the term “on-line”. According to Simon Donig this hints to the fact that completely new concepts like software as a product, the microchip or the wafer had been adapted by the engineers, whilst they kept well-established concepts like tubes (“Röhren”), interface (“Schnittstelle”) or input-output device (Eingabe-/Ausgabegerät) in their mother language [15, p. 93]. And even in 1981, the lemma “software” in the encyclopedia of economy of the GDR simply linked to “Systemunterlagen” which shows the persistence in the socialist use of language [16]. This is also probably due to the relatively strict embargos for high technology during the height of the Cold War that forced the GDR to self-production and also prevented a language import.

The hyphen in the later used “soft-ware” shows a development that began in the United States in the late 1960s. The media theorist described it in her book “Programmed Visions” as software becoming a thing, a [20] “ware” Wendy Chun. Beforehand, software was rather a service for the specific use of a computer within the company priced in labor cost per instruction. With the ongoing pervasion of the computer in business in the late 1960s a shift of meaning took place from “programing” as a verb to the noun “program” as a category. Software more and more became a product with a fixed price and branded, an all-in-one solution that was patentable, copy-able and standardized to be used in various different contexts without any big change [17]. On the contrary, in the GDR not only the way of thinking about software but also the bundling remained mainly unchanged until the mid-1980s. Even though Europe didn’t follow the US-example of patentability, the understanding of software as a product diffused with the data carriers that fed the demanding drives of the global PCs. It is a historical irony that while on a global scale the materialism experienced its ultimate failure with the end of the Soviet Union and the fall of the wall, it stroke back in the sphere of the digital [18]. While Reagan stated at the Lomonosov University in Moscow 1988 in respect to digitalization that “we’re breaking through the material conditions of existence to a world where man creates his own destiny” [19] these material conditions were set in the background. Judges in the US covering the question of software patentability in 1994 drew on the fact that the programs changed the material state of the computer in a temporary memory dump. This materialization of thought was then treated in the same way as every other material product [20, pp. 4–6]. In the mid-1990s the transformation from software as a service, to software as a product was accomplished by the interest of a grown up software industry.

Despite the semantic closure for the protagonists the term software somehow stayed hard to grasp. Michael S. Mahoney explains that with a hint to the active character of software in action. For him, software is “elusively intangible. In essence, it is the behaviour of the machines when running. It is what converts their architecture to action, and it is constructed with action in mind; the programmer aims to make something happen” [21, p. 122]. This purposeful component of software as active change makes it the perfect category for analyzing the computerization of German banks in a historical process – a process that is deeply coined by intra-action between technology and society. As a running computer never could be described in total, software also stayed something ephemeral, intricate, it was the chaotic and rhizomatic [22, pp. 3–28]. During the process of computerization, hardware supposedly only got faster, smaller and cheaper. Moore’s Law could be interpreted as the technological embodiment of the belief of progress that was so symbolic for the post war period up to the mid-1970s. It was the pendant to the West German “Law for the advancement and stability of growth in the economy”Footnote 6 of 1967 or the belief in the unstoppable progress of socialism in the East. By contrast software often reflected the dirty reality, broken dreams and stony paths of implementation. Shortly after the first commercial computers were sold, experts drew on the undersupply of usable applications for them. Thereafter in the 1960s the costs for the programming rose and the software grew more complex and unreliable. For Nathan Ensmenger the discussion of software crisis within a larger discourse of computerization is an astonishing constant of the history of computing. It began with the shortage of applications in the early stage of computerization. It continued with the complaint about the perceived lack of programmers, the unreliability of the solutions and the exploding costs of software production. The final reverberation of this is the outsourcing of programmers to lower developed countries and the recent discussions about algorithmic produced software through “artificial” intelligence. Therefore, Ensmenger comes to the conclusion that software history is a history of failure, abortive developments and contradictions in contrast to a smooth progress of hardware. In short: Moore’s Law did not apply for software. Software always had to be renegotiated. It had to be negotiated because of the unintended consequences for the companies who drove the computerization, not because it was “hard” as the famous computer scientist Donald Knuth stated [23]. This is an important point, even though Ensmenger underestimates the contradictions of hardware development. Recent studies of our research project are showing that the history of hardware and its diffusion was not at all smooth and gentle. Moore’s law finally came true, but more important is the point that it inspired the way developers, programmers and users on the whole globe thought about information technology and what you could do with it – also in the banking sector.

1.2 Banking Software

Looking at the use of software in the banking industry, the thesis by Ensmenger of software as a problematic factor in history has to be slightly adjusted.Footnote 7 The software story was by no means only one of failure, shortage and disappointment. First of all, the banks as customers demanded working software as the integration of computers from early on. Otherwise they chose another producer. Software sold hardware even if both tended to be unreliable in the beginning. Despite the delays in implementation and the fact that banks stuck to use computers in the very same way they used punch card technology, the basic applications worked productively after a short period of adjustments. Most of the time, these applications were so successful that they ran for several decades and on different computer generations. Often, on a new computer generation an emulated version of the old software ran. That, in return, caused a magnitude of possible errors and problems. Path dependency was even more the case in the GDR where the savings banks had to struggle on the one hand side with scarcer resources and a lower importance in the economic system. On the other hand they had to fight with the error prone hardware and the long delays by the state-owned combine Robotron. In banking, software could also be described as the constant against a fast changing hardware – not the other way round.

Let’s take a concrete example in the late 1960s to understand how computers were implemented into business processes: accounting. The primary focus of the planers in adjusting the system to the rising transaction and account numbers had not been computers. They were more interested in measuring how the current system worked, tried to understand it and to model its behaviour. Then they adapted this system to the requirements of computing. Therefore, other actors entered the stage: sales people, technicians and programmers. The initial design had then to be cast into a system architecture. This again necessitated the collaboration with several organization experts, users and technicians. Rooms had to be found and spatial ordering of people, machines and working processes had to be produced. The executives had to supervise the steps and made changes. The production of the code of banking becomes vividly graspable in the sources of the Municipal Savings Bank of Stuttgart. IBM Germany, located in the close proximity in Böblingen, not only sold them their machine. They analyzed exactly how the bank worked and optimized the processes [24]. After the programs were written using higher level programming languages or Assembler, they had to be tested and debugged. This again could change a lot of the initial plans and needed its space and machine time. In the GDR this scarce resource was highly contested so that often software was badly tested and had to be rearranged afterwards. The consecutive step then was to complete the documentation and to write a manual for the accountancy system. The employees that used the system had to be trained in how to use it what ranged from the high level executives down to the regular employees in accounting. Ian Martin has shown for Martins Bank in England, that in the beginning there was a strong continuity in employing women as machine users. They just were transferred from the machine room in the back-office and their work with the business machines to the computer centre of the bank [25, p. 325]. This pattern becomes visible as well in the Savings Bank of Stuttgart, where the punch card technology in Germany was far more widespread than in England. The first jobs that became obsolete in Stuttgart were those of the punch card division, primarily a female domain [26, p. 6].

Today it somehow sounds strange but the system itself had still to be operated, as sophisticated operation systems had not been developed, yet. The operators of the savings bank had to keep the different programs in the right running order, had to check if they ran properly and had to take over or archive the results. Finally, the software environment had to be maintained and adapted to changing usages. Altogether, this maintenance could eat up to 2/3 of the overall costs of the software [17, p. 118]. As Karl Ganzhorn, former developer at IBM Germany writes, the maintenance of the computing environment occupied so many programmers in the late 1950s that they had not much time left for new developments [27, pp. 51–58]. It is astonishing that the executive board of the savings banks on the one hand planed with the technology over long periods of time, more or less ten years in the beginning. The costs of computerization were calculated meticulously. On the other hand they seldom realized the hidden costs of software in the long run as they mainly hoped for rationalization wins. The user experiences with human-computer intra-action through software were important for this miscalculation.

In the early years of the digitalization of banking from 1954 to 1962, banking executives as well as employees first had to become familiar with the new technology. They relied heavily on the experiences they made with punch card technology and used computers as business machines. Punch card machines had been deployed in German Savings banks since the 1920s and were widespread in the post war period. But soon they had to realize that computers were more than fast calculators built of sheet metal and electron tubes. Inside the machine worked algorithms that soon became the core of banking. At the outside, working processes changed in intra-action of the computer-bank systems. For a longer period of time, digital processes didn’t replace analog ones but ran together in the asynchronous tact of the workflow.

Therefore, when a bank bought a new computer not only the technical facts were important. It was the integration of the machine through software that mattered in a technical environment of growing complexity. Software was needed that kept the machines up and running effectively. So it is no surprise that in 1967 Heinrich Fuchs, head of the organizational department of the Municipal Savings Bank of Stuttgart emphasized that “the performance of this equipment depends not only on its technical specifications but mainly on the quality of its programs” [28].

After the IBM 1401 that they bought in 1960 proved to be reliable, the Savings Bank of Stuttgart decided to upgrade their machines while moving into a new building. Large scale computing always was dependent of space. It was a close run between IBM and Siemens for the contract of a new data centre for the savings bank. IBM had huge problems designing their operating systems for the system/360 but succeed in presenting a preliminary version for testing. The software of its main competitor Siemens was in delay, so this was one of the main reasons why IBM got acceptance of the tender [28]. Software sold the hardware.

One telling example for the importance of software in bank computing since the very beginning of the computerization of Germany in the 1950s is the Zuse KG and its computer Z31. While Konrad Zuse as the inventor of one of the first digital computers is already well known, the fortune of his economic venture is not. The Zuse KG was in comparison to the huge producers like BULL, IBM or Remington Rand only a midsize company. Employing 1200 employees at the very height of their success, they built specialized computers which were state of the art in research and specialized usages. The Z31 was intended by the engineers to open up a new market base in the economy. As a smaller office computer automating routine jobs it was explicitly developed for the usage in banking and savings banks. Even though the hardware was fully developed and produced, the computer never had gone into sales because of missing software. Despite their rather sophisticated sales team and their programs to educate computer users and programmers the Zuse KG didn’t have the financial resources to develop a clear strategy of how to integrate the Z31 into the business processes of the bank in advance. They lacked the programmers to write the code and missed the analysts who understood banking [12, p. 70, 29]. Because hardware producers had to provide software or massively helped their customers to integrate the computer into their business, the Z31 failed at the market despite its state of the art hardware. Probably worst of all, the Zuse KG missed the international contacts to communities of invention to fill this gap. What an advantage this could have been showed the case of Heinz Nixdorf. With his company Nixdorf AG he was the founding father of specialized bank computing solutions. In the 1950s, Nixdorf realized a deal with EXACTA, a midsize business machine company who also had the license for BULL computers in Germany. In the end it worked out that BULL sold Nixdorf computers abroad. Nixdorf profited from the knowledge of BULL concerning the usage environment of computers. In the 1960s, Heinz Nixdorf succeeded in persuading Otto Müller, a German engineer of IBM Laboratories in Yorktown Heigh to come to Paderborn. The experiences of Müller at IBM in the US helped Nixdorf to produce the System Nixdorf 820 that was a huge success at the banking computer market [30, pp. 94–99].

Aside from the operating system the banks needed a wide range of sophisticated controller, monitoring and utility programs for running the machine. That did not necessarily mean application programs but a layer between the core of the machine and the application layer. Together with the operation system these programs built the layer or the “platform” on which the applications were based. As mentioned before, building up this platform and the applications on top of it was a huge challenge for the hardware producers. Out of their experience in the business machine market and a huge capital stock, IBM built up a specialized division for banking from early on. They provided customized solutions for their huge machines and helped massively to integrate them into the daily banking business. They gave courses and instructed the workforce and the technicians. Thousands of employees ran through those courses and their follow-ups within the companies. This was the dominant way computer knowledge spread in the early days in which Informatik was still in its formation phase. Often the producers even send their own employees into the banks for a period of time besides the basis technical service. Banks not only bought a machine in the 1950s. They bought a service. And this service was customized as far as possible.

A good example for that is Winfried Ferger of IBM Germany. He began there as Special Engineer in the division for customized solutions. IBM Germany was one of the most important offshoots of IBM, focusing especially on the production of mid-size hardware and the creation of software [31]. He describes a close collaboration between the customers and producers in the adaption of international produced hardware for regional and task specific needs. In an interview he recounts:

“During all of my life I only developed things who nobody developed before. I always adapted existing things to the requirements of banks or other clients. First I looked at the possibility for realizing a specific need of a customer. Then we developed it” [32].

Here it becomes clear that banks and especially the savings banks were the processors of the Digital Age that influenced the course of the technological evolution – also in software. Products they demanded often found widespread adoption in the whole industry and afterwards spilled over to other industries as well. Examples are encryption or data procession of information retrieval that were adapted to their needs.

1.3 The Producers of Software

Asking for the producers of banking software one encounters a multitude of different players. Not surprisingly, the regional computer centres of the savings banks played a crucial role in the digitalization of the banking system. This applies for both German states despite their different political and economic backgrounds. But the computer centres seldom produced their own programs. They rather defined the requirements for software service orders or adopted the software. They were especially important for the wide range of midsize and smaller institutions typical for a large share of savings banks. The several huge institutions in the urban centres were forerunners raising the general awareness for software solutions, but their requirements differed severely in scope and depth. Many of the programs came from large hardware producers who specialized on banking technology or from the late 1960s onwards from a growing software industry [27, pp. 51–58].

In the West, the German Savings Bank and Giro Association (DSGV) and the several federal state associations worked as distributors. They not only ordered the software solutions and made them available to the several savings banks. They also collected the experiences made by the institutions and presented them in aggregated form for example in the periodical “Betriebswirtschaftliche Blätter”. They coordinated the programming effort and presented best practice solutions. Many savings banks tried to get their systems implemented nationwide through the DSGV so it was also a tool of influence and a point of conflict. Its competence and means for existence always had to be renegotiated [33]. Using a wider software term, also in-house developments like the one of the Bavarian Savings and Giro Associations are coming into view. On a modular base, they tried to develop holistic solutions for all parts of the banking business especially for midsize and smaller institutions and distributed it openly.

In the GDR, the situation of software creation only differed slightly. First of all, the banks expected the combine Robotron or its precursors to deliver the basic software bundled with their rare computers. Concerning the applications, Robotron lacked the capacities, the resources as well as the knowledge about the different contexts of usage. Therefore there was a clear separation and Robotron never produced any banking programs for the East German banks, even though they cooperated with Siemens in the 1980s to build a system for international clearing [34]. Concerning system software there was a shortage despite a sophisticated theoretical level of the mathematical foundations of programing in science. Lacking workers in general, computer people in the GDR were a scarce resource and computer knowledge was not widespread. In 1966, the head of state Walter Ulbricht citied publicly this shortage on both sides as he stated: “We need more programmers! But also the managers in the party, in science and economy need a better knowledge of modern computing” [35, p. 3]. So it was no accident that in the in the GDR application field centred programing methods like SOPS was already developed in late 1960s. It should provide basic general solutions for process automation in various fields like SAP did successfully with its suite in West Germany in the late 1970s. But SOPS was mainly implemented in the industry, not in finance[36]. In charge for the distribution of the software solutions were the Ministry of Finance and the Central Bank. In most of the cases they ordered the software solutions at the “VEB Datenverarbeitung der Finanzorgane”, the equivalent to the computer centres of the Western German savings banks. But in comparison to the West German banks, it seems that there was a stronger knowledge transfer within the Eastern Block. In the course of the mutual coordination of computer production under the COMECON ESER-program,Footnote 8 banks of the Eastern Block exchanged their experiences on banking information technology on a regular base. They even agreed upon collaborative software creation [37, 38].

Looking at the GDR is also telling in respect of the concrete programs used. Lacking the foreign currency to license programs from the West and understanding software not as a product, institutions of the GDR tended to copy programs from the West under different names. This matches the strategy of hardware imitation used for example in the creation of the R300 as inspired by the IBM 1400-family, or the R40 as a IBM S/360 adaption – both computers were the most common ones used in the GDR up to the 1980s. In the 1960s, Robotron and his precursors concentrated mainly on providing system software. Basic software was not provided and the users had to develop them all by themselves. With the rise of the Digital Age - understood as the ongoing diffusion of small and midsize computers and the increasing knowledge of computer usage in the GDR - also the expectations of the computer users rose. They demanded specialized software solutions for the conditions under socialism, namely a state oriented, planned economy. Robotron reacted late but founded the “VEB Robotron-Projekt” in Dresden in 1984 as their software house. Suffering under the ever-severe resource shortages they mainly continued the strategy of renaming foreign products and deploying them. Reacting to the demands of the users, they also tried to develop some specialized products for a socialist economy. However, in the meantime Western products reached a huge diffusion and the users rejected the incompatible solutions of the “VEB Robotron-Projekt”. In result, these projects were abandoned thereafter, despite the large investments made and the goals that were already reached [39].

2 Information Systems

Banking information systems are a type of software that was developed in the late 1960s and reached a huge adoption afterwards. After defining the term information systems I am taking a closer look at the program system SODISFootnote 9 of the savings bank in Saarbrucken, TELDAS as the system of the Municipal Savings Bank of Stuttgart and finally at the information system of the state bank of the GDR to show the influence of software on the whole banking process.

As an “information system” Horst Stevenson, a widely received banking automation expert, understood in 1973 a “form of data organization […] realized with electronic data processing systems […] supporting certain operations and routines within information and communication processes” [40, p. 13]. First of all, this means that information systems in this understanding are necessarily computer based and binary-digital. Second, their means was to support, not to substitute the employees through providing the right set of information in the right amount at the right point in time. Information systems were a reaction to the perceived masses of data produced by the machines and the growing customer base since the early 1950s. The contemporaries had difficulties to extract the relevant data out of these masses. The context of this perception in the industrialized countries are the late 1960s as a time of apparently rising complexity and failing steering mechanisms in a globalizing world [41]. It is important to keep in mind though, that in all times people had to deal with large amounts of data and the complaint of drowning in data was not a new phenomenon even then [42, 43]. On the one hand information systems were closely related or based on technological developments like real-time accounting, on-line data transfer, databases and display technology. On the other hand they represented a method of integrated process engineering. They were the product of knowledge about the usage and the integration of the computer into banking.

Stevenson understood information systems as the dawning of a new era of computing replacing the process-oriented phase of data processing. Process oriented data processing meant the division between certain areas without or with little exchange of data between divisions. Managers and other employees only hardly could interconnect the data sets they possessed. Banks had therefore to record certain data several times. The problem of double recording applied even more for the savings banks of the GDR who had to fight longer against the problems of divided process chains between digital and analog – as well between different business areas as between whole institutions not yet computerized. For a long time they kept on specializing data integration to certain areas like the generation of statistics. The output of statistics was more or less useful for managerial demands but seldom for the daily business. Savings banks began to integrate their divisions into the information systems step by step then, beginning with the most important areas. Not until the early 1980s, total information systems were achieved capturing all parts constituting a bank. Even then, the cybernetic dreams of universality were never quite reached [44]. In a nutshell, information systems developed out of integrated data processing that was limited to a certain area [44, p. 27].

To look at information systems with a wider definition of software makes sense out of a double reason. In the first place information systems are composed of the “total of interconnected workers, machines and organizational institutions that are data processing or informational productive in the course of the managerial process of the enterprise” [45, p. 456]. Even though in this definition by Dahms and Haberlandt the data itself is hardly missing, information systems reached way further than just the lines of code it was written in or the machine it was run on. It rather described a rhizome like conglomeration that matches the initial understanding of a wider software term. In the second place, it had a clear focus on the user aspect and described rather a service or a solution to a daunting problem like software did. Besides these two points, there are some additions to be made. The term used in the 1970s was deeply shaped by cybernetic principals. It is important to keep that in mind while looking at the expectations banks projected onto the information systems but also while analyzing how these systems were marketed to them. Cybernetic models often suffered from an exaggerated universalization of their scope, especially in the case of social cybernetics where different elements were described with similar terms and afterwards appeared similar. The tendency for methodological overstretch applied for a range of areas of use when the different elements of information systems were unified under the language of information. The problem is clearly graspable in the use of the term information one can find in the sources. The idea that data got distilled to information within a socio-technological process prevailed. Information was seen more like a material resource than a constructed entity. It is important to avoid a teleological narrative of the savings banks on a path to ever-greater knowledge and control through technological advantages. Software as an ephemeral and problematic concept is helping to focus on the dirty reality of computerization. Information systems were also a factor for greater uncertainty, perceived disorder and confusing fragility. Viewed this way, the term of information systems under the auspices of software is a tool for applied data critics [46].

2.1 Applied Information Systems: SODIS and How the Bank Came into the Computer

In 1967, the Savings Bank of Saarbrucken, located in West Germany at the French boarder, proudly presented their internal software system SODIS to the public [47]. The institute, one of the most computerized institutes of the republic, decided to use the medium of the IBM bulletin to show their recent advancements. They stated that the main goals for the managers introducing this system were the rationalization and acceleration of every process inside the bank. In the mid-1960s, their account data was still recorded analog and then transferred to punch cards afterwards in the punch card division. With the help of an on-line system consisting of electronic business machines, a brand-new IBM S/370 and the data connection lines, data could be directly produced born-digital. This also meant that the account data was immediately up to date to speed up a whole range of processes. Parts of the bank were now accessible fully digital and in real-time. The project was located at the borderline of classic data processing within the divisions and the new information systems. The head of the organizational division Ingo Holtzmann stressed this transitional character of the system that “should not be misunderstood as a sophisticated information system in the classical sense of the term. It should rather provide precise criteria for decision in the context of immediate processing of transactions” [47, p. 44]. Only in a further step it should evolve into a full-fledged management information system. As Stevenson showed, the transition from integrated data procession to information systems was fluid.

The special role of software within computerization becomes clear in the project description of Holtzmann. He begins with an extensive description of the universal character of the computer. For him, universality was rather a disadvantage because the “business of savings banks demands specialized machines for the individual ways of procession” [47, p. 45]. The solution of choice in the 1960s still was a combination of hardware and software with specialized keys as the hardwired and static interface to the machine. The advantage of a flexible defined button realized through the interface was not graspable for the contemporaries yet. But the core of the solution was software. It transformed the problematic universalist computer into a specialized and useful device inside the savings bank business. So Holtzmann concludes, “the result of all organizational planning [of the bank] in programmed form is the SODIS program system” [47, p. 47].

It was produced through two teams of programmers that were separated into on-line recording and further procession. For the sake of interconnection, the planners insisted on “a precise definition of every process of business” [47, p. 48]. It becomes visible how the organizational department recorded every step of work inside the savings bank business, standardized it and made it machine readable to support it by information technology. In short: banking was depicted in software. Also the style of work of the programmers became part of this standardization process. The management saw their work as opaque and what they did for many spectators seemed more like a black art than actual work. This could cause a multitude of problems and delays as the rigid plans seldom left the freedom for the creative thinking that was necessary for a good systems design. In the end, the drive for standardization was also a way to confine the power of programmers in the process of writing the code of banking. Holtzmann: “Analysis was produced for every program. Regulations for programming were circulated internally. Detailed trainings and narrow introduction influenced positively code, text and completion of the programs” [47, pp. 48–49]. Not only the software environment but also the programmer himself should deliver expectable and increasingly standardized products. For the 1960s that still experienced a huge error rate in computing, this was a huge step forward. But at the same time it was the confinement of creativity in the struggle for organizational power. In the militarized words of the management oriented “Zeitschrift für das gesamte Kreditwesen” this struggle becomes visible: “The Chief Technology Officer and his reserve unit will grow in power, but the decisions had to be left in the hands of the management” [48, p. 978]. Therefore, they also had to acquire competences in EDP to direct the change, the article concludes.

The programs of SODIS were written directly in Assembler, a machine language. In comparison to higher programming languages this had the advantage of optimized usage of computer time and a lower usage of memory [12, p. 123]. Even though the engineers realized the daunting problem of writing code directly for a specific machine and tried to get independent, their solution of standardized input and output codes was only a transitional one. Writing for a specific machine always meant higher maintenance costs and a greater effort to migrate a coded solution to a new hardware environment [27, pp. 51–52, 47, p. 49]. So SODIS was a transitional solution in theory as well as in usage. But in the eyes of the management of the Savings Bank, the program proved useful to them and they expanded it to other fields and branches. At the 10th anniversary of SODIS, director Lehberg not only stressed the pioneer work his institute had carried out. He also pointed to the huge interaction between the business of banking and the system. “Besides the janitor, the new working process reached out into every division of the bank. The change was so strong that sometimes one could barely identify the old processes afterwards” [49].

What exactly did change? First of all, the direct procession led to a massive acceleration of payments and withdrawals at the counter. While beforehand transactions could take up to 15 min, now a single transaction only took 15 s – including the printing of a receipt [48, p. 977]. The account was up to date immediately, while transactions in the old system only were processed after the cut-off time, in most Savings Banks at 4 pm. The teller could see immediately the balance of the customer and if other transactions had taken place. Second, it also meant a huge acceleration in back office as the lavish sorting rounds of data sheets or punch cards became unnecessary. Third, information systems like SODIS meant a new possibility for the management to grasp the Savings Bank in the very moment of a request. The bank became visible to directors like Lehberg in (nearly) real time numbers and data streams. Or in the words of the before mentioned journal this meant “faster and further diversified balance sheets, stock overview but most importantly an overview of the cash-flow” [48, p. 978]. It is striking that here even conservative business experts began to dream about the possibility of getting an “insight into structural trends on national economies” [48, p. 978] given just enough data of different clients. These dreams never came true and in 1967 it still was a long way to go until the whole bank was integrated into the information systems. The trend towards a higher insight into banking can be seen in the light of the professionalization and scientization as writings of contemporary history are highlighting for the 1960s–1970s.

On the international stage, information systems like SODIS were an important topic of discussion, even though the cooperation was limited mainly on knowledge exchange. At the third international conference on automation in Vedbaek in 1967, delegates from 16 Western countries came together to discuss the recent trends in savings bank automation. Besides USA and Australia, all of the other delegates came from Europe. The German delegation showed a great interest in the question of software and mutual exchange. Director Claus of the Institute for Automation (IfA) described their mission in producing test cases of working processes and sample programs that should become freely distributed to reduce the burden of programming and asked for similar examples. The sources are indicating that European software exchange was developing with a core in Scandinavia [50]. In contrast, the US-delegate stated that the local savings banks still acted with great caution concerning the provision of programs. The conference protocol ends with a statement of Dr Richard Nowak from the German Savings Bank and Giro Association. He concludes that “leaders should acquire a straight approach to automation; personally they might be enthusiastic about the new technology or condemn it. But they cannot escape […] the development” [50]. It is telling that information technology at this point in time already was seen obligatory by certain banking elites – a rhetoric figure well known in the history of technology. In 1973 the International Institute of Savings Banks listed the efforts for mutual software exchange in their regular reports on international savings bank automation. For Germany, they noted that the different programs provided by the Institute for Automation were already installed in over 16 institutions. They even were willingly to provide them to other European Savings Banks – even though for a fee [51, p. 41].

All in all, SODIS developed in the context of early information systems still limited to certain areas. Systems like SODIS formed the base for further development of higher integration, like the next case of TELDAS shows.

2.2 TELDAS as Consultancy: The Making of Path Dependencies

A similar development experienced the already mentioned Municipal Savings Bank of Stuttgart, another forerunner of German computerization in using IT. After moving to their new main branch on Königsstraße 3 in 1967, they now had the space for purchasing a new mainframe computer. Similar to the purchase in 1960, as they acquired an IBM 1401, they sought IBM for an exhaustive report on banking automation at their institute. IBM delivered. As they proudly pronounced, “our report based on a exhaustive study our your institute” [24, 28]. Not surprisingly, the document sounded more like consultancy report than like an advertisement brochure for a computer system. The IBM consultants broke down the working processes into single steps, reordered them anew, measured the processes and compared them to the existent non-DP processes in respect to duration, efficiency and cost. While in the 1950s, the Municipal Savings Bank of Stuttgart had been a customer of the French Compagnie des Machines Bull, in the 1960s it had already switched to IBM machines after intense discussions. A strong argument was the close proximity of IBM Germany. They had opened their headquarters in Böblingen and not in Bonn or Berlin. IBM Germany profited from its status as a loyal customer of the savings bank who gave them credit – one example for Savings Banks as processors of computerization in Germany. But even more so IBM profited from their sophisticated sales team with expertise in banking automation.

But the report was only the beginning of the digitalization of the bank. On the two brand-new IBM Systems 360/40 their IT division ran the remote data procession system TELDAS, a system quite similar to SODIS. In the beginning, the system was used for the handling of savings transactions. The employees could now instantly book savings transactions “on-line” into the account of the customer through terminals connected with the mainframe. They also were now in the position to directly print on the savings book in same work process. Step after step the Savings Bank of Stuttgart integrated more and more divisions and branches into TELDAS. In 1971, giro traffic was integrated into the system by the DP division. In 1973, TELDAS also covered foreign currency, mortgages, securities and standing orders. On top of this database eventually the customer information system (KIS) was installed, provided by the Institute for Automation. With the customer information system it was possible for every bank employee to get a fast overview about every customer and to individualize the services offered to him. Missing possibilities were made visible by the machine suggesting new products. The deployment of the information systems took place in the strategic reorientation of the German Savings Banks towards a customer centred strategy [52].

Looking at this specific system installation over the period of only 6 years, software had gotten more and more important in respect to the effective functionality and it is striking how interchangeable hardware had become. TELDAS already did not run anymore on the initial IBM S360/40s but on an IBM S370/158. The hardware replacement changed not that much in respect to functionality. Banking had become code, not a machine. This is referring to “The Government Machine” by John Agar who had the thesis that the British state in the 20th Century had become a bureaucracy machine similar to the punch card systems it relied on [53]. For the banks it was the software, not the transistor and it was the integration of the data, not of the circuit that mattered.

In 1979, the Savings Bank of Stuttgart was integrated in total in TELDAS. In the annual report of the Savings Bank for the year 1979 it is simply said: “All customer related areas are fully organized within TELDAS” [54, pp. 48–50]. In the following year, all 250 branches were connected to TELDAS remotely and up to 420.000 transactions were realized through the system. But this did not mean that the bank was available to the management in total. The report of the International Institute for Savings Banks states that in Germany the high dreams of information system universality were buried underneath the details of daily business [55]. The story also is an example for how hard it was after the full integration to step outside the path dependency of one specific supplier. Even though on a higher organizational level, the banks tried not to get depended of one hardware producer, all competitors from now on had to build their systems compatible to TELDAS. Up and running, the software systems were productive for decades as they carried the code of banking. So software systems in Germany seldom changed and if they changed, then because banking itself was transformed in close intra-action to information technology.

2.3 Informational Socialism: The Information System of the Central Bank of the GDR

In comparison to the FDR, in the GDR the international community of invention was more important in building information systems. During the phase of intensified computerization in the years 1968-1972 under the rule of state driven cybernetics the project “open accounting, transaction clearing and accountancy” built the base for further integration. Upon this transaction data, the information system for internal bank data should provide primary information to the leading cadres for further use [56]. My thesis is that this generally implied a better control of the planned economy through knowledge about the currency flows in a political phase of new economic concepts under Walter Ulbricht and a loosening of direct control. In the eyes of the party elite, flows of current and flows of currency converged.

The State Bank of the GDR developed the information system on a modular base that at the same time “evoked integral effects of rationalization as well as the preparation of information for field specific and management tasks” [56]. The discussion and the development were very similar to that in Western Germany, even though it took place a bit later: After the first successful projects of computerization it was now a challenge for the leading personnel not to drown in all the data recorded. But at same moment it seemed necessary to interconnect more data of different fields for efficient planning. The goal for the planners was that the employees do not to lose track in a world that grew in complexity. The complaints about wrong or too much data were commonplace.

Referring to Western developments, the State Bank decided in 1974 to expand the information systems in scope through the implementation of remote data transmission. Like the Savings Bank of Stuttgart, they also ordered a report on data procession and transmission by their computer centre “VEB Datenverarbeitung der Finanzorgane” for defining the requirements. Based on that report, a nationwide transaction network had to be built transferring the data for an integrated information system in all banks called data collection system (DSS) – also in the Savings Banks [57]. There are two astonishing developments in respect to cross-border knowledge transfer between developers. First of all, the planers of the system had a very close look at the developments in the West. Horst Stevenson’s ideas are to be found word-by-word inside the reports, as well as the works of several other US-experts on banking automation. Besides rationalization, the argument of lagging behind the development in the capitalist countries should convince the state leaders of spending scarce resources in this project. As in the West, it was also the goal of the planners of the information system to record the data born digital. Through this the effort of data carrier transport and amount of the paper used should be reduced. Only in a second step, the recorded data should have been used for remote access in planning and control.

But, surprisingly enough, the data collection system was not developed only within the GDR. According to the before mentioned cooperation within the COMECON, the effort of developing the system was shared between socialist states on a bilateral basis. On the Budapest trade fair in 1975, representatives of the State Bank of the GDR and the Hungarian company VIDEOTON, a big producer of information and communications technology met for negotiations. They reached an agreement about the construction of multiplex controllers for data transmission, seminars on remote data transmission and last but not least the programming of core components of the data collection system of the GDR. All in all, they agreed on software services. In the following years, experts from VIDEOTON travelled to the GDR on a regular base. Following the sources at the DP division of the State Bank, their employees were fully aware of the pitfalls of international cooperation in software projects. That’s important because in general the COMECON is viewed as a failure. Head of division Uhlig stated that the quality of the Systemunterlagen depended upon coordination. He differentiated “The quality of the product depends on the skill of the programmer if he’s working alone. If three programmers are working together, the quality of the product depends on project management” [58, p. 4]. This is a very early example of software metrics as the measurement of software production quality the subordinate clause.

The international team of developers and planers faced three core challenges. First of all, it was necessary to establish an efficient project management. Therefore, the requirements had to be defined and the areas of competence had to be strictly assigned. The necessary effort of communication and coordination between the two countries was high, for example due to consultations. Program manager complained about the missing train and airplane connections from and to Budapest in the summer of 1976. Also the requirements tended to get out of hand. This caused Comrade Süßbier, head of the working group DSS, to change the requirements afterwards and he gave the order that “the requirements for the DSS are to be revised until the end of August. Everything that has nothing to do with the economic data collection system has to be thrown out. We need a clear line on that” [59]. Secondly, delays in the production and in documentation were commonplace. For of this reason, general director Geißler of the DP-division sent an unequivocal letter to the representatives of VIDEOTON in Berlin in 1976 demanding a proper documentation. But this was not only a problem of international cooperation. Also within the GDR delays occurred quite often. For example, for test reasons the State Bank of the GDR ordered from the combine Zentronik modern teletypes T800 with a special coding. But the production of the teletypes came into delay so that the DP-division complained about this officially. But Dr Geißler only stated with brief words that “up to this day the general director of the people-owned combine Zentronik has not reacted to our letter despite several reminders” [60, p. 3].

Thirdly, barriers of language had to be overcome. The programmers were united by one common language, the language of the machine. But despite this, the annotations as well as the knowledge of usage of the software were in very different languages. Software language depended on cultural styles, political contexts, historical paths, levels of development as well as on different believe systems. In the final code of the data collection system of the State Bank of the GDR, one can find five different languages. Most of the instructions were written in Assembler oriented towards English as the lingua franca of the Digital Age. This wasn’t changed by the politics of language of the GDR concerning imperialistic language. Besides English, many annotations are written in Hungarian, some others in German. Even French annotations are to be found. The French Compagnie des Machines Bull maintained good contacts into the Eastern Block. Adjacent to machine instructions like

stood annotations like

While translators helped the programmers to communicate, on the machine level translators were not always available. Programs and computers from very different manufacturers of the ESER program had to talk to each other through protocols. This applied to the hardware level between computers and teletypes, for example in regards to the different currents for reception [62]. But also peripherals had to be connected to different types of machines. Robotron therefore produced an ESER-adapter to connect their own peripherals to the foreign ESER-computers. But in total, this took way more effort because of the necessary conversion processes [63]. Also on the software level, the problem was daunting despite the planned compatibility of ESER. So the head of sector DP, comrade Uhlig, was happy that at least there existed a way to emulate the software of VIDEOTON on their mainframe computers R10 – R40 in FORTRAN [63]. This was necessary to test the programs on the Robotron computers beforehand.

Despite the huge obstacles it seems likely that the international cooperation succeeded. Based on the newly built data network, the State Bank of the GDR in 1981 began to implement the DSS in the savings banks. Thereby, they circulated a preliminary draft of the working instructions for the preparation and training of the bank employees. In the following years, the instructions were adapted and extended several times. Even though the system had a rocky start, it went productive in 1983 and was used intensively quite fast. In the savings banks of the region Berlin, in 1986 alone, they processed 122.409 receipts with the DSS [64]. The savings banks in the GDR ordered ever more Teletypes to get connected to the system. The main obstacle was the bad transmission quality of a data network that was very error prone. And also the minds of the savings banks employees had to be opened for the new technology. In 1981, the DP division of the State Bank complained in a long letter about the problems of software implementation. After praising their own successes in data bank usability they stated that “it isn’t always easy to get the new technology accepted. The change is about leaving behind traditional ways of work. Not always one can find the necessary openness to leave behind traditional behaviours” [65, p. 9]. The implementation of software took its time.

In parallel with the nationwide implementation of the information system the international consultations about these systems continued within COMECON [66, p. 2]. At a bilateral conference in 1981, the State Banks of the Soviet Union and the GDR exchanged their experiences about the use of information systems. The Soviet delegation was extremely interested in the developments inside the GDR. The very broad and unspecific terms the Soviet delegates used within these consultations seems to indicate that they had not reached a similar level yet. On the contrary, the GDR delegates had a deep insight into the technological developments of the USSR. They knew exactly which components they needed and named them openly as their main interest in a mutual exchange [67]. Eventually, ROBOTRON stuffed the computer center of the GOSBANK [34]. Information systems also were an important topic on the four working conferences on data processing of the State Banks of COMECON over the course of the 1980s. The first one took place in 1984, the second in Moscow in 1986, the third in Prague 1987 and the last one in Sofia in 1989. This went so far that after the third conference in Moscow the State Banks of Eastern Germany and the USSR agreed on a “proposal for the collaborative production and mutual exchange of software” [68]. This contained system software as well as applications. Even though both side came to the conclusion that the structure of their banking system differed widely in some areas, they saw overlapping use cases in human resources, documentation, back-office and control systems [68]. While both economic systems faced severe financial shortages at the end of the Cold War, the cooperative approach could be interpreted not only as rationalization of software production. Without doubt, it was a reaction to the widespread use of the Personal Computer at the work place that demanded a broader range of software. But it was also in the interest of the GDR to bind a USSR that withdrew its influence slowly under Gorbachev as it was confronted with an overstretch of power [68].

3 Conclusion

Answering the initial question of this article, the bank was represented in its information systems step by step, covering finally all of its processes. The computerization of banking took place in four stages. After the introduction of Electronic Data Processing within singular fields of banking, Savings Banks intensified the efforts for data integration within these fields. The rise of information systems bridged the gap between the individual divisions and their different databases. Accessible via remote data transfer, information systems corresponded with the needs of management and employees for a better overview and the provision of the right data at the right moment of time. But their implementation faced severe obstacles. Even though software as the implementation of computers in banks never fulfilled the high expectations they aroused, systems like TELDAS in Stuttgart or the DSS of the State Bank of the GDR were in productive use since at least the 1970s. They combined different elements of the bank ranging from the computers, the employees up to the working instructions. Therefore, they built a Deleuzian assemblage of those heterogeneous elements. During the course of the Cold War, the banks digitalized themselves as they finally in the 1980s depicted every one of their business processes in software. The Savings Banks now existed in the information system. That meant first of all a hardening of procedures. Processes and relations were defined by software that often ran for decades. Second, it made the bank visible and transparent to its management. Now it lay – within certain limits – open to them in real time what was going on inside the bank. Software was understood in a wider sense that included computer in action and their whole environment. In short: It was the code of banking that mattered.

As the whole project about the computerization of German Savings Banks is indicating, the plans of socialist countries often were even more ambitious and far reaching than in the West. That often meant that the GDR officials took the digitalization more serious out of different reasons. Apart from the demand for rationalization out of a severe resource shortage, it was mainly the desire for an efficient way of steering the economy under the imperative of a planned economy that drove the computerization in the banking sector. Or in a nutshell: The utopian character of socialism also showed itself in the digital (r)evolution. Obstacles were the huge delays in the production of information technology, the international cooperation and the poor quality of the data network provided by the Deutsche Post of the GDR. The information system of the State Bank finally was realized in 1981, the cybernetic plans for monitoring the economy were not. On the level of software development, the responsible leaders of the GDR took the COMECON serious. They placed their hopes on a socialist approach of cooperation within which the experiences of the computerization were shared. You can follow this up to the very code of the information system of the State Bank of the GDR that was written in five different languages. But like in West Germany the project suffered from severe shortages of software and programmers over the whole period of time. This caused again and again struggles of power and finally led to the strict standardization of the education and work of software engineers.

My final conclusion is that socialist software in general transformed from a service to a product later than in the capitalist West. This was also influenced by the strong cooperation on the international level within the COMECON. But also the Savings Banks in West Germany took a rather open approach to software out of their understanding as oriented towards the common good. While in the beginning of the computerization the banks expected the huge hardware producers to deliver the software with their products or were self-produced, the software industry became ever more diversified since the late 1960s. A wider term of software not limited to the actual program but to the whole system of the computer in action helps to understand this change.