CHAPTER 3 Defining information infrastructures


An important part of the problem with information infrastructures (IIs) is exactly how to look at them: what kind of creatures are they really, what are the similarities and differences compared to other classes of information systems, how should IIs be characterised, is it possible to draw a clear line between IIs and other information systems or is this rather a matter of degree, perspective or, indeed, inclination? And assuming that it is reasonable to talk about IIs, why do they -- and should they, we want to argue -- attract attention from media, politicians and scholars? These are highly relevant, but difficult, questions we address in this chapter.

The term II has been widely used only during the last couple of years. It gains its rhetorical thrust from certain so-called visions. These visions were initiated by the Gore/Clinton plans and followed up by the European Union's plan for Pan-European II. The visions for an II are argued as a means for "blazing the trail (...) to launch the information society" (Bangemann et al. 1994, 23). The Bangemann commission proposed ten applications which this effort should be organised around within the European Union: teleworking, distance learning, university and research networks, telematics services for small and medium sized enterprises, road traffic management, air traffic control, health care networks, electronic tendering, trans-European public administration network and city information highways. The proposal is in line with the projects proposed by the Group of seven (G7) in Brussels in March 1995.

The Bangemann commission (ibid.) states that by building a European IIs we can expect

Less speculative than citing political manifestoes, it is fairly safe to expect that future II will consist of an elaboration, extension and combination of existing computer networks with associated services (Smarr and Catlett 1992). It is likely to consist of an inter-connected collection of computer networks, but with a heterogeneity, size and complexity extending beyond what exists today. New services will be established, for instance, by developing today's more experimentally motivated services for electronic commerce, video-on-demand and electronic publishing. These new services subsequently accumulate pressure for new development of the II to accommodate them.

There exist today a number of embryonic manifestations of the IIs. For many years, we have had application specific networks. Services provided include flight booking and bank networks supporting automatic teller machines and other economic transactions. Electronic data interchange (EDI), that is, electronic transmission of form-like business and trade information, is an illustration of an existing technology related to II (Graham et al. 1995; Webster 1995). The rapid diffusion of WorldWideWeb is the basis of a general II for information exchange as well as more specialised IIs implementing open electronic marketplaces where products may be ordered, paid for and possibly delivered (if they exist in electronic form like books, newspapers, software or stock marked information).

Basic data communication technology may be described as communication standards and the software and hardware implementing them. This technology is in many respects what comes closest to an existing, general purpose II. Two such basic communication technologies exist, Open Systems Interconnection (OSI) and Internet (Tanenbaum 1989). OSI is developed by the International Standardization Organization (ISO).

There is today no clear-cut conception of what an information infrastructure is and even less how to design one. We approach this in a somewhat indirect fashion. We trace the origin of the concept, discuss proposed definitions, compare it with other infrastructure technologies and outline the role and contents of standards.


The concept of II may be seen as a combination, or merge, of information and infrastructure technologies. IIs can be seen as a step in the development of information technologies as well as a step in the development and infrastructure technologies. IIs share a number of aspects with other kinds of information technologies while having some unique aspects making them different. The term "infrastructure" has been used in relation to information technology to denote basic support systems like operating systems, file servers, communication protocols, printers, etc. The term was introduced to separate between such underlying support services and the applications using them as the complexity of computing in organizations rose. The II examples mentioned above can also be seen as an evolution of computer networks, interorganizational systems and distributed information systems. IIs as envisioned are similar to examples of these concepts except that they are larger, more complex, more diversified, etc. It accordingly makes betters sense to talk about an information systems as having degrees of infrastructural aspects.

Various forms of infrastructure like railways, roads, telecommunication networks, electricity supply systems, water supply, etc. have been analysed under the label "large technical systems" (Mayntz and Hughes 1988, La Porte 1989, Summerton 1994). Some scholars have focused on what they find to be important characteristics of such technologies, talking about networking (David 1987, Mangematin and Callon 1995) and systemic technologies (Beckman 1994).

Our approach to the study of the characteristics of IIs is to focus on what is found to be the primary characteristics of other infrastructure technologies in general and analyse how these characteristics appear in IIs.

The conceptual heritage of IIs

Defining II - identifying the aspects

We will now identify what we consider to be the key aspects of (information) infrastructures, and in particular what makes them different from information systems. These aspects will be identified by presenting and discussion a number of definitions proposed by others.

Enabling, shared and open

In Webster's dictionary infrastructure is defined as

"a substructure or underlying foundation; esp., the basic installations and facilities on which the continuance and growth of a community, state, etc. depends as roads, schools, power plants, transportation and communication systems, etc." (Guralnik 1970).

This definition is also in perfect harmony with how IIs are presented in the policy documents mentioned above. Some elements may be emphasized, leading to the identification of the first three core aspects:

Aspect 1: Infrastructures have a supporting or enabling function.

This means that an infrastructure is design to support a wide range of activities, not especially tailored to one. It is enabling in the sense that it is a technology intended to open up a field of new activities, not just improving or automating something existing. This is opposed to being especially design to support one way of working within a specific application field. This enabling feature of infrastructures plays important roles in policy documents like those mentioned above. The enabling and constraining character of II technologies will be discussed in chapter 7.

Aspect 2: An infrastructure is shared by a larger community (or collection of users and user groups).

An infrastructure is shared by the members of a community in the sense that it is the one and the same single object used by all of them (although it may appear differently). In this way infrastructures should be seen as irreducible, they cannot be split into separate parts being used by different groups independently. An e-mail infrastructure is one such shared irreducible unit, while various installation of a word processor may be used completely independently of each other. However, an infrastructure may of course be decomposed into separate units for analytical or design purposes.

The different elements of an infrastructure are integrated through standardized interfaces. Often it is argued that such standards are important because the alternative, bilateral arrangements, is all too expensive. As we see it, standards are not only economically important but also a necessary constituting element. If an "infrastructure" is built on the bases of bilateral arrangements only, this is no real infrastructure, but just a collection of independent connections. We return to this in the next chapter.

The shared and enabling aspects of infrastructures have made the concept increasingly popular the later years. Just as in the case of IIs the role of infrastructures is believed to be important as its enabling character points to what may be kept as a stable basis in an increasingly more complex and dynamic world. Håkon With-Andersen (1997) documents how the Norwegian ship building sector has stayed competitive through major changes from sailing ships, through steam boats and tankers to offshore oil drilling supply boats due to the crucial role of an infrastructure of competence centres and supporting institutions like shipbuilding research centres, a ship classification company and specialized financial institutions. In the same way, Ed Steinmueller (1996) illustrate how the shared character of infrastructures is used to help understand the growing importance of knowledge as public goods and infrastructure in societies where innovation and technological development is crucial for the economy. Different II standards and standardization processes will be presented in chapter 4. However, aspects of standards will be an underlying theme through the whole book.

Aspect 3: Infrastructures are open.

They are open in the sense that there is no limits for number of user, stakeholders, vendors involved, nodes in the network and other technological components, application areas or network operators. This defining characteristic does not necessarily imply the extreme position that absolutely everything is included in every II. However, it does imply that one cannot draw a strict border saying that there is one infrastructure for what is on one side of the border and others for the other side and that these infrastructures have no important or relevant connections.

This might be illustrated by an example form health care: A hospital is exchanging information with other medical institutions, even in other countries. It is exchanging information with social insurance offices and other public sector institutions and it is ordering gods from a wide range of companies. These companies are exchanging information with other companies and institutions etc. Hospital doctors might be involved in international research programmes. Accordingly, a hospital is sharing information with virtually any other sector in society. And the information exchanged among different partners is overlapping. Drawing a strict line between, for instance, a health care and an electronic commerce infrastructure is impossible. However wide an infrastructure's user groups, application ares, designers and manufacturers, network operators or service providers are defined, there will always be something outside which the infrastructure should be connected to.

Unlimited numbers of users, developers, stakeholders, components and use areas implies

In sum - all this implies heterogeneity

Unix systems and networks based on OSI protocols are closed according to this definition although they are declared open by their name. The openness of IIs will be discussed further in chapter 5.


In the Clinton/Gore report, the envisioned NII is meant to include more than just the physical facilities used to transmit, store, process, and display voice, data, and images. It is considered to encompass:

It is said that every component of the information infrastructure must be developed and integrated if America is to capture the promise of the Information Age.

The Bangemann report does not contain any definition. However, the report is by and large a European response to - or rather a copy of - the US NII report. It seems to share all its basic assumptions, and accordingly we can say that it implicitly also use the same II definition.

This definition also sees infrastructures as enabling, shared and open. Further, it points to some other crucial features we now will turn to. Infrastructures are heterogeneous phenomena. They are so along many different dimensions.

Aspect 4: IIs are more than "pure" technology, they are rather socio-technical networks.

Infrastructures are heterogeneous concerning the qualities of their constituencies. They encompass technological components, humans, organizations, and institutions. This fact is most clearly expressed in the last bullet paragraph above. This is true for information technologies in general, as they will not work without support people. An information system does not work either if not the users are using it properly. For instance, flight booking systems do not work unless all booked seats are registered in the systems.

The socio-technical aspects of IIs will be explored and discussed in chapter 6 and chapter 7.

Aspect 5: Infrastructures are connected and interrelated, constituting ecologies of networks.

They are so different in different ways. For instance, different technologies are brought together as illustrated in the NII definitions. Here we will concentrate on different ways (sub-)infrastructures are connected into ecologies of infrastructures. Infrastructures are

Infrastructures are layered upon each other just as software components are layered upon each other in all kinds of information systems. This is an important aspect of infrastructures, but one that is easily grasped as it is so well known.

Infrastructures are also heterogeneous in the sense that the same logical function might be implemented in several different ways. We will discuss heterogeneity being caused by two forms of infrastructure development:

  1. When one standardized part (protocol) of an infrastructure is being replaced over time by a new one. In such transition periods, an infrastructure will consist of two interconnected networks running different versions. A paradigm example of this phenomena is the transition of Internet from IPv4 to IPv6 (Hanseth, Monteiro and Hatling, 1996, Monteiro 1998, chapter 10).
  2. Larger infrastructures will often be developed by interconnecting two existing different ones, as typically has happened when networks like America Online and Prodigy have been connected to Internet through gateways.

The third form of heterogeneity we are addressing is what happens when larger components or infrastructures are built based on existing smaller, independent components. When these components are brought together into a larger unit, they become interdependent. When one of them is change for whatever reason, this will often require the others to be changed as well. Examples of this phenomena are various formats for representing text, video, sound, image and graphical representations are brought together and put into MIME to enable transfer of multimedia information on the Web/Internet.

Different networks -- some compatible and closely aligned, others incompatible and poorly aligned -- are superimposed, one on top of the other, to produce an ecology of networks. The collection of the different, superimposed communication infrastructures in a city provides a vivid illustration of the situation: the different telephone operators, the mobile phones, data communication, the cable-TV networks have to a lesser or larger extent evolved independently but are getting more and more entagled (REF BYPLAN BOKA). We return to and elaborate on this aspect of an II in chapter 11.

While heterogeneity is indeed present in the NII definition of II, this seems not to be the case in mere engineering inspired definitions. We see the following definition proposed by McGarty (1992, p. 235-236) to be representative for communities designing computer communication technologies. He says that an infrastructure resource is

Infrastructures corresponding to this definition will to a large extent embody the three first infrastructure aspects mentioned above. Shareable and common in McGarty's definition is literally the same as shared in ours, scale is close to openness. There is, however, one important difference between our definitions: McGarty's defines infrastructure as largely homogenous. There is no non-technical elements involved, and even the technology is required to homogeneous. This is connected to his notion of "physical embodiment of architecture." The requirement that the whole infrastructure should be based on one architecture is an expression of traditional engineering design ideals like uniformity, simplicity, consistency. (These ideals are also underlying McGarty's requirements about how an II should scale.) If it is a requirement that an II is based on one single architecture, it would be impossible to make a larger II by linking together two existing ones through a gateway if they are based upon different architectures (which different II regularly will be) even though doing this should be desirable as well as feasible. This requirement implies a form of homogeneity being in direct conflict with the essential heterogeneous nature of infrastructures. It implies a strategy for making closed systems. In this way, this definition is only open as far as one uniform coherent architecture is applicable and acceptable. It is the main argument of this book that this closed world thinking inherent in virtually all engineering activity (at least as presented in text books) is a main obstacle for successfully developing the II visions in documents like the US NII plan and the Bangemann report, an issue we now will turn to. The situation may be illustrated graphically as in figure xxx.


The ecology of networks which give IIs their non-homogenous character

The ecologies of infrastructures will be explored further in chapters 8 and 11.

Installed base

Building large infrastructures takes time. All elements are connected. As time passes, new requirements appear which the infrastructure has to adapt to. The whole infrastructure cannot be change instantly - the new has to be connected to the old. The new version must be designed in a way making the old and the new linked together and "interoperable" in one way or another. In this way the old - the installed base - heavily influence how the new can be designed.

Aspect 6: Infrastructures develops through extending and improving the installed base .

The focus on infrastructure as "installed base" implies that infrastructures are considered as always already existing, they are NEVER developed from scratch. When "designing" a "new" infrastructure, it will always be integrated into or replacing a part of a later one. This has been the case in the building of all transport infrastructures: Every single road - even the first one if it make sense to speak about a such - has been built in this way; when air traffic infrastructures have been built, they have been tightly interwoven with road and railway networks - one needed these other infrastructures to travel between airports and the travels' end points.Further, powerful telecommunications infrastructures are required to operate the air traffic infrastructure safely. Pure air traffic infrastructures can only be used for one part of a travel, and without infrastructures supporting the rest, isolated air traffic infrastructures would be useless.

In McGarty's definition, his notion of enduring includes the requirement that infrastructures has to change incrementally to meet the changes of the environment. Such changes will be very, very modest if they always have to take place within the constrains of the original architecture. So we think it is fair to say that McGarty does not pay any attention to the importance of the installed base whatsoever.

The same kind of engineering ideals as found in McGarty's definition played an important role in the development of the OSI suite of protocols. This effort failed - according to Einar Stefferud and Marshal T. Rose (ref.) due to the protocols' "installed base hostility." All protocols were designed without any consideration of how an OSI network should interoperate with others. It was assumed that OSI protocols would replace all others. However, as there was an installed base of other communication protocols, the OSI ones were never adopted as they could not (easily enough) be linked to these.

The notion of installed base does to a large extent include all aspects of infrastructure mentioned above - an infrastructure is an evolving shared, open, and heterogeneous installed base .

Star and Ruhleder (1996, p. 113) give a definition sharing some of the features of McGarty's and the NII one. However, in their definition Star and Ruhleder put more emphasis on the social relations constituting infrastructures. They characterize II by holding that it is "fundamentally and always a relation," and that "infrastructure emerge with the following dimensions:"

The configuration of these dimensions forms "an infrastructure," which is without absolute boundary on a priori definition (ibid.).

Opposed to McGarty, this definition stresses the heterogeneous character of infrastructures as expressed in the notions of embeddedness as well as its socio-technical nature in forms by being linked to conventions of practice. Although the importance of the installed base is emphasised, Star and Ruhleder do not address design related issues or implications. Further, learned as part of membership and links with conventions of practice have important implications: IIs must support today's conventions at the same time as they must stimulate to their change if significant benefits is to be gained. These aspects of infrastructures also mean that although IIs are enabling and generic, they are not completely independent of their use. The interdependencies and possible co-evolution of IIs and conventions of practice will be explored in chapter yy.

Although having much in common, an interesting difference between the two definitions given by Star and Ruhleder and McGarty respectively is the fact that the first stresses the importance of the installed base and its inertia while the latter requires that an infrastructure must have the capability of being incrementally changed to meet new needs, and that this change must be transparent to users. The combination of - or tension between - these two elements is the core of IIs as seen in this article: understanding the nature of the installed base and how to cultivate it.

Seeing II and II development as "installed base cultivation" captures most aspects of (information) infrastructures as described above. IIs are larger and more complex systems, involving large numbers of independent actors as developers as well as users. This fact makes standards a crucial part of IIs. Further, IIs grow and develop over a long period of time, new parts are added to what exists and existing parts are replaced by improved ones. An II is built through extensions and improvements of what exists - never from scratch. It is open in the sense that any project, independent of how big it is, will just cover a part of an II. The rest exits already and will be developed by others being out of reach for the project and its control. What is developed by a defined closed activity will have to be hooked into an existing II. What exists has significant influence on the design of the new. In sum: IIs are developed through the cultivation of the installed base.

IIs and II development may to a large extent be described as specification and implementation of standards. Cultivating IIs may, accordingly, be considered as cultivating standards.

The role of the installed base in the development of infrastructures and standardized technologies will be discussed in chapter 9, while design strategies for infrastructures having the characteristics presented above will be the theme of chapters 10 and 11.

Sliding boundaries

The focus on IIs as open systems raises some questions - among these: Are the borders between open (IIs) and closed (I) systems absolute and predetermined in some sense? Is the crucial role played by the installed base a unique feature of infrastructure and systemic technologies or is it a more general one? Focusing on IIs as an open installed base means that IIs are never developed from scratch - they always already exist . If so - when and how is an II born?

Seeing IIs as an open installed base focuses on what makes them different from ISs. The latter may be described as closed in the sense that one project or defined activity may design and control the development of all its parts. Whether ISs should be considered as open or closed systems depends on the time frame chosen. Considering their life from initial design and development throughout the whole maintenance phase, no IS can properly be understood as closed (Kling and Iacono 1984).

Whether a system is open or closed is not always an a priori aspect of the system. It depends on the perspective chosen. Whether an open or closed perspective is most appropriate in a specific situation is often not an easy question. And whether choosing an open or closed perspective deals with our basic conception of reality. Each perspective is linked to a wide range of other perspectives, theories, tools and techniques, etc. The complexity and difficulties related to this issue can be illustrated by "discussions" and disagreements between Popper and Feyerabend about the nature of science and proper scientific work, and fights between positions like positivism and dialectics. This issue has also been involved in discussions about the approaches followed by OSI and Internet standardization efforts. Einar Stefferud (1994) summarizes the "religious war" (Drake 1993) as a discussions between two competing and incommensurable paradigms, one being an open internetworking paradigm, the other being a closed networking one.

ISs and IIs are not totally disjunct - there is a border area. An IS, e.g. an interorganizational system (IOS) or distributed IS (DIS), may "travel" through this area and change and become an II. IIs are born when

  1. new and independent actors become involved in the development of an IOS or DIS so that the development is not controlled by one actor any more;
  2. existing IOSs are linked together and the development of the linked networks is not controlled by one actor;
  3. an IOS/DIS may be considered an II when the goal is that it shall grow an become an II (or part of) in the future and this is an important design objective.

Where to draw the borderline between for instance an IOS and an II also depends on which aspect of an infrastructure definition is emphasized. Taking flight booking systems as an example, they may be considered infrastructure as they are large, complex and shared by a large user community. However, they are specialized applications rather than generic, enabling substructures.

Installed base is not a unique II feature. In general the issue is the importance of history, the history's imprint on the future. History is everywhere, in IS design as well as II cultivation. However, the issue needs to be dealt with in another sense when building II. In the social sciences, similar issues is studied under the label "new institutionalism" (Scott 1995, North 1990, Powell and DiMaggio 1991, March and Olsen 1989), and in philosophy by Heidegger in his Being and Time.

State of the art

The growing interest for information infrastructure has produced a rich variety of studies and analyses of information infrastructures. There do not, surprisingly enough, exist many studies about the Internet which try to spell out in some detail how the design process actually takes place. There exist several overviews of the historical development of Internet but they contain little or no evidence of how or why various design decisions came about (see for instance Hauben and Hauben 1006; LoC 1996). Abbate (1994) represents an exception. Here the underlying design visions of two competing alternatives for networking, namely IP and the one developed within the telecommunication community (called X.25 by the CCITT 1 ), are uncovered. Hanseth, Monteiro and Hatling (1996) discuss the structure of the tension between change and stability in information infrastructures with illustrations from Internet and the Open Systems Interconnection (OSI) of the International Standardisation Organisation (ISO). Hanseth (1996) analyses the nature of the installed base through illustrations of a variety of cases, including Internet. A highly relevant area of research regarding Internet is to unwrap the design culture within Internet. This, however, seems to be a completely neglected area. The few studies related to cultural aspects of Internet focus on others than the designers, for instance, Turkle (1995) on MUD users, Baym (1995) on Usenet users.

Our approach to the study of standardisation resembles those applied by Marc Berg, Geoffrey Bowker, Leigh Star and Stefan Timmermans (Bowker and Star 1994; Bowker, Timmermans, and Star 1995; Star and Ruhleder 1996, Timmermans and Berg 1997). In their studies of classification schemes and infrastructures Bowker and Star identify a number of issues which are closely related to those we are focusing on. In a study of the evolution of the classification of diseases maintained by the World Health Organisation, they illustrate how coding and classification -- essential tasks in the establishment of an information infrastructure -- is anything but neutral. Interests are inscribed into coding schemes (Bowker and Star 1994). Bowker, Timmermans, and Star (1995) study how some aspects of work is made more visible than other by inscribing them into a classification scheme. Star and Ruhleder (1996) discuss key characteristics of infrastructure based on a study of the introduction and use of an information infrastructure.

Within the field of social studies of technology, there are some contributions relevant to a study of information infrastructure standardisation. Some focus on conceptual issues, for instance, the work by Fujimura (1992) on standardising procedures and interpretations across geographical distances. Others explore empirically how universal standards are appropriated to local contexts (Berg 1995) or how the interplay between stability and change is played out (Hanseth, Monteiro and Hatling 1996). Similarly, Jewett and Kling (1991) develop a notion of infrastructure which is to capture the many hidden resources which need to be mobilised to get an information system to actually be used.

Other studies of the standardisation process of information infrastructure tend to focus issues rather different from ours and those mentioned above. These include the economical significance of standards (David 1987; OECD 1991), technical challenges (Rose 1992), the use of information infrastructures (Ciborra 1992), the political nature of standardisation bodies (Webster 1995) or cultural differences (Trauth, Derksen and Mevissen 1993). The predominant view on information infrastructure standardisation is that it is straightforward. An exception to this is (Williams 1997). Standardisation is commonly portrayed either as (i) a fairly unproblematic application of mainstream techniques for solving the technical difficulties of software engineering or (ii) it is simply glossed over or taken as given (Ciborra 1992; David 1987; OECD 1991). Those involved in the design of information infrastructure have so far been very close to (i). These studies shed little light on the socio-technical complexity of establishing an information infrastructure.

Lehr (1992) points to the bureaucratic and procedural differences in the way standardisation bodies organise their work. These are argued to play an important role for the outcome, namely the standards. For instance, the OSI effort represents a clear-cut alternative to the evolutionary approach underlying an emphasis on transition strategies. OSI is designed monolithically from scratch, that is, with a total disregard for existing information infrastructures, the installed base. It has been fiercely criticised for exactly this (Hanseth, Monteiro and Hatling 1996; Rose 1992).

The literature on large technical systems is illuminating in describing how infrastructures are established but tend to bypass how to facilitate changes (Summerton 1994). A particularly relevant contribution is (Hughes 1983) which gives an historical account of the electrification of the Western world around the turn of the century. Hughes' work is important but it does not address the dilemmas of scaling explicitly. It provides, however, a rich empirical material containing lots of illustrations of transition strategies, the role of the installed base and gateway technologies, etc.

Recently, there has been attention to development strategies suitable for information infrastructures (Kahin and Abbate 1995). These strategies do not deal with scaling but address issues such as the role of government intervention and industrial consortia.

Grindley (1995) argues for the importance of the installed base of products. This emphasises the need for products to be backwards compatible, that is, that they interoperate with earlier versions of the product. In other words, this protects the installed base of earlier versions of the product. Backward compatibility plays the same role for products as transition strategies for information infrastructures (Hinden 1996).

1. CCITT is the international standardisation body for standards within telecommunication.

Go to Main Go to Previous Go to Next