ericm@idi.ntnu.no

oleha@ifi.uio.no

1. Introduction

In an effort to boost their strategic capabilities, large, internationally oriented companies are struggling to establish a working information infrastructure. In the espoused version, this is portrayed as a more or less planned "roll-out" of the infrastructure [2] and basically a technical endavour [5].

Drawing on illustrations from two case studies, we argue that such an approach seriously underestimates the underlying socio-technical negotiations that go into this process. Our aim is to high-light important characteristics of the process of establishing a working corporate infrastructure and, furthermore, to spell out implications for international standardization.

We focus primarily on the process of de facto standardization in two large corporations, but link this to different, but related, processes of international standardization. More specifically, we emphasize characteristic elements of the process of this de facto standardization that we believe have relevance to international standardization. This, of course, does not imply that there are not important differences between de facto and international standardization in terms of contents, procedures and actors [6, 8]. It merely implies that there are vital elements that are common and which tend to get down-played.

There are especially two characteristics we high-light. Firstly, we analyze how the exact definition and contents of the infrastructure evolve over time. There is no clear-cut conception of what it is supposed to be, and it changes over time. This implies that talk about "diffusion" of the infrastructure needs to be recognized as a covenient short-hand for the continuous socio-techical process of re-appropriating the infrastructure. Secondly, we describe how episodes of improvization need to be aligned and bundled with during the process of mobilization. This gives rise to an appearant "drifting" of the infrastructure [1, 3].

Our illustrations are drawn from case studies in two Norwegian based but internationally oriented companies, Statoil and Norsk Hydro. Fuller accounts are found elsewhere [4, 7].

The oil company Statoil is young. Founded in 1972 with only one employee, it has since grown to a 5 billion NOK operations profit enterprise with over 17.000 employees in 25 countries. Still, the major activities are located in Scandinavia and Northern Europe.

Norsk Hydro was established in 1905. Fertilizer (and related products like ammonia) was the only business area until the 1950s, when Hydro started its expansion - moving first into light metals (magnesium and later aluminum) and later oil and gas. During the period 1972 - 1986 Hydro was growing rapidly, the income raised from 1 to 60 billion NOK. The growth took place as acquisitions in agriculture (fertilizer) and light metals, and by building up brand new activities within oil and gas.

2. Continuous re-appropriation

March 1996 marks a point the process of building up robustness and strength of the Lotus Notes infrastructure in Statoil. SData, the IT department, had decided to upgrade Notes from version 3 to 4. The diffusion strategy of SData, as it has been all along, was one of alignment. More specifically, they framed this upgrading as one aimed at strengthening the position of Notes by making as few changes as possible.

The way SData translated the upgrading as one of strengthening the position of Notes was basically one of making their own Notes administration more efficient. By March 1996, there existed about 3500 Notes data bases in Statoil which generated a considerable amount of administration for SData. These applications were poorly aligned with work practises. Aligned with the upgrading to version 4 of Notes, SData trimmed this jungle of data bases by forcing owners of data bases to identify the ones they wanted to migrate to the new version of Notes. SData simultaneously tightened the requirements connected to Notes applications by ensuring that all applications had an owner and a brief description of functionality. This cleansing paid off. The number of Notes data bases shrinked from 3500 to about 1200.

A key strategy in constructing the robustness of an infrastructure is the continuous process of alignment. The upgrading to Notes version 4 was no exception. To illustrate, we list a few of these to get a feeling for the kind of ongoing reconfirmation that is required. They are always small, grey and non-glamorous but are the life blood of a working infrastructure. Without the constant work, the infrastructure simply would not "diffuse".

The alignment of Notes e-mail and services for electronic archiving that was fuelled by the pressure for ISO 9001 was attempted met with the new version. Specifically, the e-mail window was equipped with an additional button (besides the ones for "send", "reply", "print" and so forth) that was for "archiving". In this way, e-mail was aligned with archiving and quality standards. Similarly, in response to a growing concern with facilitating communication with the outside world, the address book that already was aligned with e-mail was extended to incorporate also external addresses and X.400 addresses. A final example is the way the colour codes of e-mail is changes to make it easier to differentiate between the e-mails where you appear in the To: header from those where you only appear in the Cc:.

3. Improvization

The step following the formal approval of the (first version of the) so-called Bridge standard in Norsk Hydro was its implementation into a "product" (Lotus Notes, various office applications and communication). As the standard specified only a set of commercial products to be used, this might seem unnecessary. That was far form being the case. Products like those involved here might be installed and configured in many different ways. To obtain the benefits in terms of less costly installation, maintenance and support of these products, they had to be installed on all computers coherently. Such a coherent installation is also crucial for establishing a transparent infrastructure where information may smoothly be exchanged between all users. Reaching these objectives, a considerable development task had to be carried out. The task included primarily bundling work in forms of developing configuration and installation scripts. Developing these scripts was quite a challenge. Lots of unforeseen problems popped up, implying that the initial staffing was all to low and the members of the development team felt the problems were overwhelming in relation to their capacity. As the project did not get new resources, the project team was close to giving up several times. However, the implementation of the first Bridge version of the desktop applications package was declared finished by the 1st of January 1995. When the product was launched, it was, however, far from being free of errors.

Until the product implementation project started, Bridge had been seen (or at least treated) as a self-contained package. During the product development it was "discovered" that that was definitely not the case. To work as a shared infrastructure, it required an extensive underlying and supporting infrastructure. In general, smooth implementation of a standard at one level requires a standardized infrastructure at the level below. However, the infrastructure underlying Bridge was far from standardized within the company. The major problems during the product development project can be seen as caused by the lack of standardization of this infrastructure. The problems were tried solved by standardizing each layer as they were uncovered.

The first and immediately underlying layer being "discovered" was the operating system. Virtually all PCs were running DOS or Windows, so agreeing on Windows as the OS standard was not controversial.

A large part of the PCs were running in local area networks running LAN software and possibly a networking operating system. This "layer" had to be standardized as well because most Bridge applications would be installed on a file server and not on each individual PC, the applications (users) were storing their files on such servers, and using other shared resources like printers, etc. On this level, a standard based on Novel’s LAN products was specified. This included a specific design of LAN topology to be implemented everywhere.

 

4. Conclusion: Implications for standardization