Re-engineering Norwegian Research Libraries,
1970–1980

Ingeborg Torvik Sølvberg

► To cite this version:

Ingeborg Torvik Sølvberg. Re-engineering Norwegian Research Libraries, 1970–1980. 3rd History of Nordic Computing (HiNC), Oct 2010, Stockholm, Sweden. pp.43-55, 10.1007/978-3-642-23315-9_6 hal-01564625

HAL Id: hal-01564625

https://inria.hal.science/hal-01564625

Submitted on 19 Jul 2017

**HAL** is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
Re-engineering Norwegian Research Libraries, 1970–
1980

Ingeborg Torvik Sølvberg

Department of Computer and Information Science
Norwegian University of Science and Technology
7491 Trondheim, Norway
ingeborg.solvberg@idi.ntnu.no

**Abstract.** The Norwegian shared library system BIBSYS is in 2010 used by more than hundred university-, college-, and research libraries, including the Norwegian National Library. The BIBSYS project was initiated in 1970 and it led to a complete re-engineering of the Norwegian research libraries. The paper describes the project, how the system was initiated and discusses important decisions made during project development. The two most important factors for the success of BIBSYS are discussed. One is that the project started with a detailed information analysis prior to coding and data base design, using a good software tool. The other factor is that the potential users of the system, the librarians, were included in the project loop from the beginning.

**Keywords:** BIBSYS, information systems, library automation, re-engineering, systems design

# 1 Introduction

In 1970, a process started that resulted in a reorganization of the Norwegian research libraries. The advances in computer technology drove the change process. It was decided to start a "library automation" project at the Norwegian Institute of Technology, NTH, Norges Tekniske Høgskole. The project very quickly was expanded to the two other research libraries in Trondheim, and gradually to other research libraries to become a nationwide project.

The first operational data processing system, for acquisition of library documents, was operational from 1976. Other systems to cover all library work processes followed over the next few years. The system was called BIBSYS, and its successor is still operational in 2010, forty years after its conception [1]. The original information system design of BIBSYS has survived thirty-five years of computer technology development. The design process was based on the information systems development approach, which was pioneered by Langefors in the late 1960s [2]. Key elements were

* participatory design

* separating information aspects (infology) and data aspects (datology)

* developing detailed requirements prior to coding and data base design
BIBSYS embarked on a "business process re-engineering" project many years
before the phrase was coined and became fashionable. After the initial design and
implementation phases, the system became the basis for a nationwide re-organization
of the Norwegian research libraries. BIBSYS took over the operational
responsibilities for the computerized parts of the libraries' operations as well as the
responsibility for keeping up with advances in information technology.

The following paper gives an account of the first years of the BIBSYS project, as
well as a short analysis of its impact.

1.1 The BIBSYS Project – Initiated in 1970

Today's libraries use information technology for their internal routines as well as in order to give the public access to their collections. The Norwegian shared library system BIBSYS is used by all Norwegian university libraries, the National Library, a number of college libraries, and other research libraries, altogether more than hundred libraries. Currently the shared bibliographic database contains information about more than 5,000,000 unique titles and more than 15,000,000 physical objects, when copies are included. In 2009, the bibliographic search system handled 20,700,000 searches from all over the world [1].

*It all started in 1970.* The Director of SINTEF, Karl Stenstadvold, took an initiative to investigate how computers could be used in the daily routines of the Library at the Norwegian Institute of Technology (NTH). He was willing to use Sintef resources to get a project off the ground.

I was a young researcher at Regnesenteret NTH (later called RUNIT) interested in
exploring how we could use computers in new and exciting applications. The Head of
the NTH Library, Knut Thalberg, was interested in such a project; the same was my
superior, Director Karl G. Schjetne. This was a good match!

The first question that surfaced was: What is the status world wide of how libraries
use computers? The next question was: What should and could we do at our
university?

## 2 The Traditional Library in 1970s

The information objects in the traditional library were the physical objects such as
books, journals, reports, maps, patent-descriptions and others. The library objects
were mainly paper based, even if in the 1970s many libraries included music
recordings and movies on physical media in their collections. The objects were
catalogued and the catalogue records were printed, mainly on small catalogue cards,
which were filed in catalogue card cabinets according to specific rules. Hence,
information about objects could be found in many card catalogues serving different
purposes, and they were geographically distributed. Only one catalogue at the NTH
Library contained information about all the objects owned by the library; this was the
Main Catalogue located in the reading room of the Main Library. The Main Catalogue
was used by the library staff as well as by the public. The NTH library had several
branches on campus; each branch maintained a card catalogue of their own holdings.

The NTH Library, like most other large university libraries, used international cataloguing standards, with local adjustments. Cataloguing and classification were costly processes. A rule of thumb was that it was just as expensive to catalogue an object as to purchase the object. All libraries catalogued all the objects in their own collections.

During the late 1960s and early 1970s, a few projects involving computers were initiated in Europe and USA. Many of the first library automation projects produced local catalogues in the form of sorted lists or in book-form. The lists could easily be produced in many copies and they were distributed throughout the library and could even be sent to cooperating libraries. A drawback with the lists and books was that they were produced periodically, such as monthly or even annually, with smaller weekly or monthly additions for the new acquisitions. Hence, there were many lists to look through in order to find a specific object. In Europe, the university libraries in Bochum and in Bielefeld were well known for their computerized book catalogues. They were the European leaders in the emerging field of library automation. Soon microfilm was used instead of paper when distributing the catalogues. The microfilms were used by other libraries as a support to cataloguing and for locating specific documents. Other universities as the University of Southampton, UK, developed circulation systems based on punched cards. In the late 1960s and early 1970s, the Library of Congress (LC) developed the MARC standard (MARC: Machine Readable Cataloguing). The MARC format contains information describing the intellectual content of an object as well as administrative data. The MARC standards have been of great importance to the library community worldwide [3, 4]. The MARC format is described later in the paper.

### 3 The Library Automation Project

At NTH we agreed that the library could benefit by using computers, but there were no clear ideas of where to start. In 1970, I did some minor projects; I learned about the different library departments and their working routines, I produced various types of sorted lists, I looked into the possibility to reuse cataloguing records coming from MARC magnetic tapes from Library of Congress, USA (LC). In a report of November 1970, I gave a brief description of the workings of the library and presented some project ideas [5]. The number one recommendation was to conduct a user study in order to clarify the requirements of the library users: NTH's scientific personnel and students. If the project mainly should be aimed to have the librarians work more efficient there were interesting starting points in all of the library departments. I also proposed that the Library of Congress' MARC format should be used for the cataloguing work. It could be beneficial for the NTH Library to use MARC magnetic tapes from Library of Congress. Initially this proposal was deemed silly. However, not too long time afterwards did the library subscribe to MARC tapes.
RUNIT's library volunteered to be a pilot, if the NTH Library found a project to be too risky to self-serve as a pilot. At that point, the Library was not interested in a user study; they wanted to aim the project at supporting the internal processes in the library.

The organization of the university sector in Trondheim was restructured at this time. NTH was loosely coupled with two other scientific organizations in Trondheim under the UNIT "umbrella" (UNIT: Universitetet i Trondheim). UNIT had two university libraries, in addition to NTH Library there was the DKNVS Library (DKNVSB: Det Kongelige Norske Videnskabers Selskabs Bibliotek) which just had merged with the library at the other university college in Trondheim, the College of Arts and Letters (AVH). Early in 1971 DKNVSB's Head librarian, Sten Vedi, made contact and wanted his library to join the library automation project together with the NTH Library and RUNIT. This speeded up the process; the NTH Library suddenly had a competitor!

RUNIT was asked, "Is it possible to support the work processes in the two libraries with the same IT-system?" This was an interesting challenge. The NTH Head Librarian Knut Thalberg proposed the starting point for such a project to be the work process where information about the documents was registered in the library for the first time: the ordering department.

I made a proposal for a common project for the two university libraries: "A proposal for mechanization of the accession processes in two scientific libraries" [6]. In February 1972, the proposal was presented for the leaders of the two university libraries, Runit's director and a few other key persons, and it was decided to initiate a common project with an ambitious goal:

> The project's goal is to develop a system to automate ALL of the internal routines in the libraries; acquisition, cataloguing, circulation, search and serials control. The first departments to be automated are the two Acquisition departments.

BIBSYS was born, both as a project and an organization, even if the name BIBSYS was not invented at this point; this was still the "Library Automation Project."

The project needed persons with a variety of competences, in librarianship as well as information technology, in order to embark on a participative development where IT persons and Domain experts could work together following the so-called "Scandinavian approach" to Information System development.

The libraries approached the project with the opinion that the work could be done by data experts alone with minimal involvement from the libraries. RUNIT had to insist that librarians should be included in the project team; "no librarians - no project." Eventually we got a great team together with me as Project Leader and the main IT-person together with two part time librarians from each of the two libraries. They learned how to program and they got insight in what computers could do and not do. They participated in the development of the systems- and user requirements and were important intermediaries between the IT department and the libraries. After a while, RUNIT allocated one more IT person to the project.
Shortly after, in 1974, a formal Steering Committee was established, The University of Trondheim (UNIT) appointed Associate Professor Jørgen Løvset from the Physics department as the Steering Committee Leader. Jørgen Løvset did a great job. He realized the complexity of the project as well as the shortcoming of the available technology. From time to time, he had to stand up and defend the technical proposals from the project team. The user community did not always understand that there was not a straight way forward to develop such a complex system and that we were breaking new ground. Jørgen Løvset was of crucially importance for making the library automation project a success.

## 3.1 A Master Plan

It soon became obvious that all departments of the libraries would be influenced by the library automation project. We needed a Master Plan for establishing the information system for the whole library, which could also serve several autonomous libraries.

We defined the Universe of Discourse to have three main components; the Library, the Vendors, and the Users. The Library had three subsystems: Acquisition, Circulation, and Administration.

The central questions were: Which kinds of data are produced, used, changed, deleted – where and by whom? Who makes the decisions, e.g., about new acquisitions? What kind of information and messages are exchanged inside a library department, between the departments, and communicated with the outside world? These questions and many more needed to be answered.

In the Information Systems Group at RUNIT, the CASCADE research project was based on Börje Langefors' theories of Information Systems development. CASCADE offered computer-assistance for information analysis and information systems design. The tool produced graphical presentations of the information flow on all levels of the system description, systematic storage and presentation of information objects and information processing tasks, automatic testing of the system descriptions, and gave warnings about inconsistencies and broken links [7–9]. This was deemed an excellent tool for the analysis phase.

In 1972, we made a detailed system analysis of the Acquisition department and in 1973 of the Circulation department using CASCADE.
3.3 An Example from the Acquisition Subsystem

The Acquisition subsystem had two component systems: the Ordering Department and the Cataloguing Department [10]. Fig. 1 shows an original CASCADE diagram of the Ordering Department process. Because of low print quality, we have added additional identifiers to the original in order to make the figure readable.

<figure><img src="image_2.png" /><figcaption>**Fig. 1.** The Ordering department, *Receiving a Proposal for buying an object*.</figcaption></figure>

Legend:

Ver: Verification process; C: Control process, Prop: Proposal;

PropA: Accepted Proposal, PropR: Rejected proposal

Bibliographic Catalogues: **MK**: Main Catalogue; **O1**: AkseCat;

**O2**: Gjennomsynskat; **O3**: OrderingCat; **Bib**: bibliographies **B**: Budgets

In 1972, the Ordering department was responsible for the production and maintenance of three bibliographic card catalogues:

o The Ordering Catalogue contained everything that was ordered but not received, and in addition, claims and other information regarded to be of importance. ("Bestillings katalog")

o One catalogue contained information about the objects that had been received in the library and had been forwarded to the cataloguing department in order to be catalogued ("Akse Katalog")

o The library did often consult professors and university departments before buying an object. This information was kept in a special catalogue, "Gjennomsynskatalog"
The Ordering subsystem had two processes: Verification and Control. A process in the Ordering department was initiated when the department received a proposal for acquiring an object. The proposal came either from someone inside the library world, e.g., a professor, a student, a librarian, or it came from the outside, e.g., a publisher.

Fig. 1 shows what happened when the library received a proposal for buying an object. The incoming Proposal triggered the Verification process. The librarian consulted external bibliographic sources, bibliographies, to verify whether the proposed object existed, e.g. whether the proposed book was published or not. If ‘yes’ the verified proposal was sent to the Control Subsystem. The Main Card catalogue was accessed in order to check if the object already was in the library’s collection. If it was not, the three bibliographic card catalogues in the Ordering Department were searched. Finally, the budget files in the Administration Department had to be consulted in order to check whether there was money available for the scientific area of the proposed object.

When an ordered object arrived in the library, this is not shown in the figure, the order record (of the library of 1972) was physically transferred from the Ordering Catalogue ("Bestillings katalog") to the "Akse Katalog" and new relevant information was added to the card. The order form resided in "Akse Katalog" in the Ordering Department until the Cataloguing Department sent a message, on paper, that the object has been catalogued and classified. Information about the object could now be found on catalogue cards in the Main Catalogue in the Main Reading Room.

In the analysis of the Ordering department, we described around three hundred objects. This description was used in the design phase when proposing processes, forms, and for describing the proposals for data and file structures.

# 4 Systems Design and Development

## 4.1 Systems Design

The information analysis described in detail the relations between work processes and the logical files (catalogues) and whether a process reads, modifies, generates or deletes a record or another data item. Based upon the analysis results we defined the logical file structure. Many of the existing catalogues were merged. The information analysis gave guidance when defining the search terms for the index files: author, title, ISBN, DOKID, vendor-identifier, vendor-name, a.o.

The systems analysis described processes in the information system. Some of these processes could be automated immediately, and we could develop computer programs right away, while other processes might be automated later when more mature technology would become available (such as decision support systems), some processes were completely dependent on human decision-making and could never be automated [11–14].

In designing the new system, much emphasis was put on that there should not be introduced limitations through unnecessary borders between the different processes. In the design of the computerized system, the border between ordering and
cataloguing of an object became blurred. An object is pre-catalogued when the order is registered; the cataloguing process is a continuation of the ordering process using the already recorded order information. In the manual system, bibliographic information was distributed over many bibliographic card catalogues. We proposed these catalogues to be merged so all descriptions about bibliographic objects should be stored in one catalogue/file only. A Status variable was added to the bibliographic record, the value of the Status could be *ordered, received, on the shelf, cataloguing-in-process, in circulation*, et cetera.

The bibliographic record should be updated when new information became available. Pre-cataloguing gave new responsibility to the persons in the Ordering Departments, as they had to register bibliographic data as correctly as possible. At this processing stage, however, only limited bibliographic data were usually available. A quality test was conducted to find if the proposed solution was viable. The bibliographic entries of approximately two hundred orders were compared to the final catalogue records of the same documents. Only 5 percent of the order records had needed to be modified. It was subsequently decided to merge the bibliographic catalogues in the Ordering Department with the Main Catalogue.

The Project team had been instructed by the libraries not to look into organizational or administrative matters. In spite of this, the libraries were restructured when the consequences of the computerization became apparent. The decision to pre-catalogue a document in the Ordering Department is just one example on how the automated system influenced the internal library organization.

A summary of the overall design objectives include the following.

* To create an online system with shared catalogues, for participating libraries; vertical integration within a library; horizontal integration between libraries. This required that routines and standards needed to be harmonized.

* The system must be accessible online and searchable for anyone; public as well as library personnel.

* Bibliographic data shall be written once; starting in the ordering department(s). The record shall be updated in later processes; verified, changed, expanded, or deleted.

* When there are more than one copy of a document, local information shall be added for each specific copy (e.g. physical location, classification).

* Each physical object shall have a unique identifier, a DOKID, to be used also in the circulation sub-system.

## 4.2. Representation and Communication of Bibliographic and Related Information

The central part of the system is the database containing the bibliographical records; the digital descriptions about the documents related to the libraries.

In the late 1960s and early 1970s, the Library of Congress (LC) developed the MARC standard (MARC: Machine Readable Cataloging). "*The MARC standards consist of the MARC formats which are standards for the representation and communication of bibliographic and related information in machine-readable form,*
and related documentation. It defines a bibliographic data format ... It provides the protocol by which computers exchange, use, and interprets bibliographic information" [3].

The MARC standard was originally developed as a format for interchange of Library of Congress cataloguing information using magnetic tapes – MARC-tapes. The tapes were originally intended to produce catalogue cards, but they were soon used for book catalogue production and a variety of listings, such as acquisitions lists. In April 1969, the Library of Congress began to distribute to other libraries its cataloging services on machine-readable magnetic tape [4].

Most MARC fields contain several related pieces of data. Each type of data within the field is called a subfield, and each subfield is preceded by a subfield code. The field, or tag, “100” is used for a person as author, subfield “$a” is used for the author’s name, “$d” is used for the author’s birth and death year. The field (or tag) “245” title statement, for example, contains the title and the statement of responsibility area of a bibliographic record, where “$a” denotes the title proper, “$b” the reminder of the title (“sub-title”), and “$c” other title information such as statement(s) of responsibility. Tag “240” is used for the document’s original title.

The libraries have different kinds of materials in their collections: monographs, serials, maps, movies, photos, and others. Already from the beginning did the MARC format identify data common to different types of material with the same content designators (fields or tag), while unique fields (tags) are assigned for data elements peculiar to any one format of material. As an example, the four kinds of information objects Monographs, Serials, Maps, and Movies all use tag “245” for title statement while tag “255” is used only when describing Maps such as “255 $a Scale 1:12.500”.

BIBSYS developed its own variant of the MARC format, there taking into account the Norwegian cataloguing rules and local practice. From the basic MARC format, different presentation formats can be generated.

As an example a search for “A doll’s house” and author “Henrik Ibsen” in BIBSYS of 2010 gives seventy-four matches, one of them is:

Title: A doll's house / by Henrik Ibsen; translated by William Archer; with an introduction by M. Yassin El-Ayouty

Author: Ibsen, Henrik 1828-1906

Year: [1957]

Printed: Cairo: Anglo-Egyptian Bookshop

Pages: 122 s.

This is generated from a record in the BIBSYS MARC-format:

100 $a Ibsen, Henrik $d 1828-1906

240 $a Et dukkehjem

245 $a A doll's house $c by Henrik Ibsen; translated by William Archer; with an introduction by M. Yassin El-Ayouty

260 $a Cairo $b Anglo-Egyptian Bookshop $c [1957]

300 $a 122 s.
The University Library at Oslo University started around 1971 to develop a Norwegian version of the MARC format, NORMARC, and the BIBSYS Cataloguing User Group defined UNITMARC (later called BIBSYS-MARC), taking into account the need for future cooperation [15]. The University Library at Oslo University did not originally participate in the BIBSYS project. A special branch of the University of Oslo's Library acted as National Library until 1989, when the National Library of Norway was established.

## 4.3 Database Structure

It was decided to use the MARC format in the bibliographic descriptions. This MARC structure was a perfect match for a database system, which was under development at RUNIT: the randomized file system RA1. This was a win-win situation both for the library automation project and for the Database group. We were able to use RA1 and gave feedback and new requirement for the Database group's next database system, RA2, which the BIBSYS project also used for some years [16].

## 4.4 Expert User Groups

The participative development approach included the users of the system, the librarians. Several Expert User Groups were established as early as possible, starting with the Expert User Group on Cataloguing and the Expert User Group on Acquisition. The participants in the Groups were experts in their fields and represented their libraries. The groups' main objectives were to develop the user requirements for the subsystems, harmonizing rules and work procedures inside as well as between the libraries, and later in the process, to test the system prototypes and prepare instructions for their use within the libraries.

In the early years, 1970–75, when talking with representatives from the libraries we were met with phrases like “of course we want to cooperate with other departments and libraries, but *my* department is very special.” However, when the representatives from the different libraries had met a few times they realized that they had similar problems and challenges and that working with colleagues from other organizations was fun!

The sizes of the user groups increased as the number of participating libraries increased, because all participating libraries should be represented in every group. The User Groups' influence on the planning, development, testing, operation, and, not least, the acceptance – of BIBSYS cannot be over-estimated.

Including the librarians in the project team and in the User Groups eased the introduction of computers in the libraries. There were many small as well as a number of large problems when introducing such dramatic changes in the working environments. The librarians had ownership to the system and they were eager to find solutions.

As more and more libraries became users of BIBSYS, User Groups developed de-facto standards for the Norwegian university- and research libraries. They became major actors in the reorganization of the Norwegian library community.
## 4.5 Immature Technology, Possible Stumbling Blocks

During the system design phase we made some bold, someone would say naïve, decisions on proposing solutions that were ahead of the technological state-of-the-art:

* Only upper case letters were available in the 1970s on our equipment, e.g. on the printers and the input terminals. This was insufficient for our libraries, and we developed an interim solution for upper- and lowercase letters. Multikey strokes had to be widely used.

* In the very early days, BIBSYS was a one-user system. The operating systems were not designed for multi-using. An ad-hoc solution was developed and used until multiuser facilities were included in the standard software of time-shared computers. The ad-hoc solution permitted five to ten simultaneous users.

* Due to limitations of the data nets, only one library at a time could use the system during the first year (1976). The two participating libraries in Trondheim each used the system two days a week, and half day Friday! The multiuser solution permitted the librarians to use the system in parallel.

* We wanted full screen terminals to be used when ordering and cataloguing objects. Only tele-type terminals were available the first years. We bought a few screen terminals, UNISCOPE-100, in 1974. According to the vendor, they were the first of their kind in Norway. UNISCOPE-100 was expensive, NOK 50,000 apiece, comparable to an average annual wage.

## 4.5 Operational System Modules

As the first acquisition and search modules became operational, the NTH Library registered the first real document using the acquisition module in March of 1976. More modules were added to the system; cataloguing pre-testing began in 1978 and became operational in 1980 with circulation control and Online Public Access (OPAC) in 1983. The last module was serials control, which was added in 1994.

During the first years, we used RUNIT's main computer, UNIVAC 1108, the programming language FORTRAN and tele-type terminals. Today BIBSYS has its own IBM computer.

# 5 Discussion

## 5.1 Going from a Dynamic Developing Environment to an Operational and Service Environment

The project became well known in the Norwegian library community and abroad. The number of research libraries participating in the project increased quickly and the size of the project team and the expert user groups became larger. So did the steering committee and the project budget.
When the steering committee obtained new members, the first question usually was, “Why don’t we just buy a library automation system? There must be hundreds of suitable systems on the market.” Several surveys, investigations, and visits were made, but the result was always negative; commercial systems that covered certain functions like circulation or catalogue productions existed, but no system was found that could give all the functionality and flexibility that our libraries demanded.

Large resources are required for developing and operating a system of BIBSYS kind so there is a substantial shift in the use and distribution of the organizations’ budgets. During the first ten years, the BIBSYS staff grew from a handful to twenty persons.

It can be hard to accept that new technology requires continuously technological development – which consequently results in continuous change and budget redistribution. The administrative leadership of the participating organizations wanted of course to increase their influence on the further development of BIBSYS. Administrative leaders became members of the steering committees. In many ways, this was beneficial to the project, but it did also hamper development both because “change” can be scary, but also because change initially costs money.

The resistance to change was always felt and had to be continuously combated. There were some tense situations over the years. My first report [5] became so controversial and radical that key persons in the library declared that this report had better disappear from the surface of the earth. This may be due to “cultural” differences. I am educated as a physicist and may have used a different vocabulary and described procedures in the library differently than the librarians were used to. Another example: In the very early years there was a formal meeting at the university where we discussed some proposals I had made without having received any feedback. A leading person in the university administration mentioned these proposals and said that more time was needed before a conclusion could be made. I was enthusiastic and proud because I could tell *the good news*: “We have already completed that part!” The administrative leader became furious and shouted back: “You are a galloping elephant!” For me, this comment was a compliment I appreciated – and I do so more and more. Over the years, I have stumbled into bureaucracy several times; in a bureaucratic world, maybe more “galloping elephants” are needed?

BIBSYS was in a good shape in the early 1980s. The computerized system was in front worldwide. We had a great project team with competent, enthusiastic and dedicated persons. We were part of an excellent IT community at RUNIT and the university. The necessary developments for the nearest years were planned.

The steering committee focused increasingly on minor additions required by the users, and day-to-day operation filled the days. I proposed a couple of times that we should look into new challenges and technological opportunities for the library community, for example, to use some resources for including full-text documents in the library information system, or to make it possible to have information exchange with other online information systems. Some of the prominent leaders of the organizations said that they did not want to be in front of the technological development and use; “let the others do research, develop, use, and think, and we may follow later” was one phrase. The libraries were pleased with the situation and wanted to consolidate.
In many ways, this is easy to understand. The libraries had been through dramatic
re-engineering over a relatively short time. They had been very courageous during the
changing times, they had been eager to change, learn and to include new technology
into their daily work. Now they had an operational system: No more changes for a
while! Further change would cost more money. To propose inclusion of full text
electronic documents was perhaps overdoing the level of ambition when remembering
that a few years before we could only handle capital letters!

## 5.2 What Did We Learn?

BIBSYS has been in operation for many decades. The design principles from the
1970s are still valid. The computer programs have been re-written, adjusted and
expanded several times over the years to fit with the continuously changing
technology.

Looking back I find that one important factor to the success is that we started with
a pioneer approach. We were able to work without a large bureaucracy during the first
years. We were not bothered with people who wanted to lead without understanding
what they were leading. This gave us flexibility, and flexibility is important for a
pioneer project.

In addition, there were two other crucial success factors:

1. The project started with a detailed information analysis, analyzing the whole library information structure, developing detailed requirements prior to coding and data base design. The master plan and detailed systems analysis occurred before programming (the “think first – program later” approach). We had a good tool at hand assisting in the information analysis and design

2. Participatory design people, potential users of the system, and librarians were included in the project loop from the beginning, in the project group and in the expert user groups. However, we must realize that the participants come from different “cultures.” The terminology is different, so is the problem solving approach, sometimes even the human values. The different cultures must respect the differences and trust each other if the project shall succeed. In the BIBSYS project, we were lucky enough to have this mutual respect for each other.

## References

1. BIBSYS, http://www.bibsys.no/english/pages/index.php

2. Langefors, B.: Theoretical Analysis of Information Systems. Studentlitteratur, Lund (1966)

3. MARC Standards. http://en.wikipedia.org/wiki/MARC_standards

4. Kilgour, F.: OCLC. Summary of Marc. 1970. http://www.ideals.illinois.edu/bitstream/handle/2142/858/Kilgour.pdf?sequence=2

5. Sølvberg, I: En grov beskrivelse av Hovedbiblioteket NTNU. Biblioteksautomatisering. Arbeidsnotat 1. SINTEF, Trondheim (1970)

6. Sølvberg, I.: Forslag til mekanisering av aksesjon ved to vitenskapelige bibliotek. Biblioteksautomatisering, Arbeidsnotat 2. SINTEF, Trondheim (1972)
7. Sølvberg, A.: Experimenter med Nyere Metoder i Systemarbeidet. In: Bubenko, J.A., Jr, Källhammar, O., Langefors, B., Lundeberg, M., Sølvberg, A. (eds.) Systemering 70. Studentlitteratur, Lund (1970)

8. Aanstad, P., Skylstad, G., Sølvberg, A.: CASCADE – A Computer-based Documentation System. In: Bubenko, J.A., Jr., Langefors, B., Sølvberg, A. Computer-aided Information Analysis and Design, pp. 93–118. Studentlitteratur, Lund (1971)

9. CASCADE: SINTEF Årsmelding 1972, http://www.idi.ntnu.no/datamuseum/dokumentasjonssenter/aarsmeldinger/sintef-aarsmelding-1972.pdf

10. Sølvberg, I.: Informasjonsanalyse av tilvekstsystemet. Biblioteksautomatisering. Arbeidsnotat 3. SINTEF, Trondheim (1972)

11. Sølvberg, I.: Systemforslag for tilveksten ved bibliotekene tilknyttet Universitetet i Trondheim. Biblioteksautomatisering. Arbeidsnotat 4. Trondheim, Sintef (1972)

12. Sølvberg, I.: Oversiktsrapport om biblioteksautomatisering ved UNIT. Biblioteksautomatisering, Arbeidsnotat 7. RUNIT, Trondheim (1973)

13. Bibliotekautomatisering (BIBSYS): RUNIT Årsmelding 1974, p.14 http://www.idi.ntnu.no/datamuseum/dokumentasjonssenter/aarsmeldinger/runit-aarsberetning-1974.pdf

14. Bibliotekautomatisering (BIBSYS): RUNIT Årsmelding 1978, pp. 23–24 http://www.idi.ntnu.no/datamuseum/dokumentasjonssenter/aarsmeldinger/runit-aarsberetning-1978.pdf

15. Sølvberg, I., Aas, G., Vikan, M.: Katalogavdelingene ved bibliotekene tilknyttet Universitetet i Trondheim, Bibliotekautomatisering, Arbeidsnotat 8. RUNIT, Trondheim (1973)

16. RA1: RUNIT Årsmelding 1974, p.16, http://www.idi.ntnu.no/datamuseum/dokumentasjonssenter/aarsmeldinger/runit-aarsberetning-1974.pdf