Morten Hatlinga, Eric Monteirob and Knut H. Sørensenc
SINTEF Virksomhetsutvikling, Strindveien 4, 7000 Trondheim,Norwaya
Dept. of Information and computer sciences, NTNU Lade, 7034 Trondheim, Norwayb
Science and Technology Studies, NTNU, 7055 Dragvoll, Norwayc
Abstract
Systems design has for quite some time been recognised to involve an array of different competences, that is, to have strong interdisciplinary elements. There exists a considerable body of literature about how to go about practising interdisciplinarity in systems design. These suggestions, however, are primarily of a normative character and are only poorly underpinned empirically.
We report from an empirical study of how interdisciplinarity is conceptualised and conceived of among scholars and practitioners in the field. A key obstacle to interdisciplinarity in systems design is the reluctance to form teams where also the non-technical receives a substantial influence.
Keywords: systems design, interdisciplinarity, empirical study, professional ideologies
In this paper, we will explore how systems designers cope with interdisciplinarity in their description of the discipline (that is, their disciplinary ideology) as well as in their accounts of their own practice. The problems that are analysed usually lead to a quest for better methods. New methods are then suggested as more efficient tools to cope with heterogeneity. However, to us, the emerging contradictions in the narratives of systems designers suggest the need to change the perception of interdisciplinarity and how it should be practiced.
The new sociology of technology has observed that all technologies are basically heterogeneous. Systems and artifacts are negotiated nature and culture (Latour 1987, Hughes 1987, Bijker, Pinch and Hughes 1987). This breaks in a fundamental way with the widespread understanding of technology as applied science. Successful innovation and design depends on the ability to integrate concern for users' needs as well as the possibilities and limitations of the material world. In this respect, systems design is no different from design in other technological fields.
Heterogeneity is not the same as interdisciplinarity, although it could be argued that the first presupposes the latter in some form. The historical development of engineering signifies a recognition of this fact through the emphasis on professional training as some composite of different subjects and disciplines. The education of engineers came early on to be based on a mixture of theoretical subjects and practical instruction, and the aim was to provide an ability to cope with a relatively wide range of technical problems. The professional engineer was supposed to be a general practitioner of technology, also coping with a wide range of managerial challenges. This ability was to emerge from a polytechnical education (Noble 1977).
The polytechnical ideal represents a particular form of interdisciplinarity, assumed to be functional in a situation that only to a small degree allowed for specialisation. Without going into details, we may note two important features of this ideal. First, it perceives of interdisciplinarity as something residing in the individual engineers. Thus, what counts as interdisciplinarity is in effect a kind of encyclopedic knowledge with Leonardo da Vinci as the ideal prototype. The challenge in providing a polytechnical curriculum is in deciding the relative specialisation and the amount of subjects to be taught as auxiliary and supporting the speciality.
The second important feature is the tendency to bring forward a kind of professional arrogance. The polytechnically trained engineer is educated in an environment that emphasises his (or her) ability to learn the knowledge and skills necessary to cope with most, if not any, practical situation which the engineer may encounter. If necessary, he (or she) may in a relatively short time learn what they need to know. Other professions play a subservient role in this system. They may possess useful knowledge, but it is the polytechnical engineers who decide what constitutes usefulness and how other knowledges and skills should be integrated into their practice.
Today, the polytechnical ideal has become less functional as an educational ideology. Increased specialisation, the dominance of team work as the organisation of engineering, and decreased professional autonomy are features of the late 20th century that implies the demise of the engineer as a general practitioner. The universities and institutes of technology may have problems in adjusting their educational ideology, but there is no doubt that their training is far more specialised today that it was 50 or even 20 years ago.
Systems design as a professional field has developed in this period of the demise of the polytechnical ideal. Thus, it could be expected that this ideology of education and practice to a lesser degree has impacted this profession. In the next sections of this paper, we explore whether SD has moved beyond the polytechnical ideal by analysing how interdisciplinarity is envisaged, both in theory and practice. We begin by looking at so-called alternative systems design that has been very concerned with issues of interdisciplinarity . Then, we compare this professional ideology with the ideology found among practitioners in the field in Norway. We end by providing a few concluding remarks.
Since observations of theory-practice or ideal/ reality splits are so widespread, this suggest that we face a problem that is fundamentally related to the modern professions and the modern efforts to make use of science to solve practical problems. The tension of theory-practice and ideal-reality may thus be productive in the sense that it brings forwards frustrations and efforts to improve current practices. Thus, such tensions and contradictions should be studied more carefully.
In the case of systems design, we find several discourses that are relevant to the understanding of this profession. Here, we will focus on the debate about methods which - to some extent - is a characteristic feature.
To do systems design is to do representation of processes of communication and work in a very fundamental way (Bansler and Bødker 1993). Ideally, the organisation for which a computer-based system is to be designed, should be carefully represented through the design process. Methods represent a standardised response to this challenge in order to make design feasible. The aim is not to make the best possible representation, but rather to have one that may be a satisfactory basis to make a system.
Representation is a very fundamental problem to all scientific work, and no less so in systems design. The discourse about methods reflects the fact that systems designers have acknowledged this fact and are sincerely engaged in finding ways to cope with it. The aspect of this effort which we want to emphasize in this paper, relates to the abilities and skills perceived as necessary to provide satisfactory representations. In a very fundamental way, this may be seen to define systems design as a profession and to provide us with a guide to the boundary objects (Star and Griesemer 1989, Suchman 1987) that allows the differentiation of those inside and outside this community. This is related to interdisciplinarity as well as division of labour in the continuously ongoing efforts to improve efficiency and quality of organisations.
Consequently, we are not concerned with the problem of representation as a methodological challenge. Rather, we shall analyse accounts of the tasks and skills needed to do representations.
As suggested above, development methods for computer systems is at the core of SE, even if they exist in a great variety. They share a few fundamental properties. They have a deeply normative character in the sense that they prescribe a sequence and set of steps to be followed. In general, there is little attention to the contexts which may make a method appropriate or not. Methods are assumed to apply universally.
Many of the techniques in SE are representational techniques. These include representational building blocks for clarifying, framing and exploring the specification of the computer system. In addition, there are various techniques for: generating test suites, estimating cost/ resources, validation and risk analysis. Tools support the production of the software in the various phases of its conception. Typical tools include: editors, debuggers, compilers, linkers, repositories, CASE tools and report generators.
There are several efforts to define what should be meant by critical or alternative SD. These do not represent any kind of well aligned approaches. Still, for the present purposes it is necessary to give a sketch of the underlying reasoning within key representatives of alternative SD.
Some link alternative SD to the so-called Scandinavian approach (Floyd et al.1989). Bansler (1989), for instance, portrays the critical tradition by the fact that it "rejects (...) the harmonious view of social relations in the workplace, which imbue the [other two schools]" (ibid., p. 15). This view amounts to recognising, Bansler explains, that `"s]ocial relations at work are characterized - not only by cooperation - but also by conflict and struggles between managers and employees, and among different groups of employees" (ibid., p. 15).
The relevant issue in the present context is the repercussions the views of alternative SD have on requirements for interdisciplinarity in SD. They are far-reaching according to Bansler. System developers are required to grasp not only the technical and organisational issues of developing, introducing and using IT. They are to grasp nothing less than most of modern society:
"While the other two research traditions restrict their analysis of systems development to the level of an individual company, the critical tradition places systems development in a broader social and economic context. The critical school offers a more encompassing understanding of systems development" (ibid., p. 16).
Lyytinen (1987) elaborates an alternative to mainstream SE methods based on speech act theory borrowed from the philosophy of language. Information systems have its users as one, overall system engaging in rule-governed language games. The task of SD, according to Lyytinen, is to analyse and design such language games as a
"creative, interpretive task that is based on the understanding of ordinary language communication. (...) [This] view concentrates on the nature of human communication and sense-making [as SD] is both a social and cultural change that is carried out in relation to introducing information technology" (ibid., p. 17).
Floyd (1987) argues for an alternative SD methods which she calls a process-oriented paradigm. It expands dramatically the relevant issues and concerns of SD. It views SD "in connection with human learning, work and communication, taking place in an evolving world with changing needs." (ibid., p. 194). Thus, systems designers need to master a wide set of interdisciplinary skills enabling them to grasp complex issues within an organisation including "qualification, motivation, training, work organization and traditions of use, together with the features of the product itself" (ibid., p. 200).
Dahlbom and Mathiassen (1997) for a radical reconceptualisation of the field of SD. They review recent suggestions for changes within the education, research and practice of SD and confronts this with the suggestion that
"in addition to the traditional technical competence of an engineer, a computer professional today needs more skills of a social, organizational, communicational nature. A vision of a new engineer with a dual competence is presented, in which what is needed in addition to the core engineering competence may vary: both engineer and manager, both engineer and salesperson, both engineer and organizational expert, an ethically, socially responsible engineering, and so on" (ibid, p. 85).
Dahlbom and Mathiassen argue that this is not nearly sufficient because "rather than envisioning a new engineer with social skills in addition to technical skills, we have to conceive of a change in what we think of as technical competence itself" (ibid., p. 12). Their vision is based on a focus on artefacts in use, "the role they play in our lives and how they play those roles" (ibid., p.12). Earlier changes to requirements of interdisciplinarity within the SD profession were modest compared to what we face today, the authors argue.
"The change that we have advocated here is more radical [than the earlier ones]. It means introducing a romantic use perspective into every aspect of teaching and practising in our profession. Mechanistic thinking, so powerful in producing and characterizing the machine, may actually hamper us when we are trying to put it to good use. "(ibid., p. 89).
Hirschheim, Klein and Lyytinen (1996) in a tour de force recaputalisation of SD research define SD to include that "all design activity takes place in a historical context under specific social influences" and hence that there is a need for "approaches that recognize the emergent, historically contingent, socially situated and politically loaded changes associated with [SD]" (ibid., pp. 7-8). They argue that to grasp the challenges in SD, researchers need to employ sophisticated social theories - they favour a combination of Habermas' critical social theory and Etzioni themselves - as a platform for analysing SD in a wider context, an analysis they "believe will lead to substantial improvements in dealing with the complex and confounding effects of [SD]" (ibid., p. 8).
Thus, there is substantial agreement that SD extends beyond the purley technical. It is programmatically stated that "[s]ystems development is organizational development" (Bjerknes and Dahlbom 1990, p. 1). When it comes to what is takes to engage in SD, at least one thing is sure: it "requires technical competence" (ibid., p. 1). Furthermore, this is not sufficient because "we need other types of competence as well" (ibid., p. 1). But this is about the only issues that are not debated. When it comes to specifying the extension of SD beyond its technical core, there is an abundance of suggestions and hardly any consensus. It is essentially open-ended in the sense that it is always possible (and it repeatedly gets done!) to throw in yet another suggestion for an additional competence. This is a one-way traffic as no one seems to bother to pose the question of whether something -- or, indeed, what -- then has to be thrown out in response to make room for the additions (Hirschheim, Klein and Lyytinen 1996, Lyytinen 1987, Stage 1990).
A problem with the assessment of this literature is the lack of a clear distinction between systems design as a multiprofessional task and systems design as a profession. The call for Interdisciplinarity is, at least on occasion, a call for teamwork to improve organisational efficiency. When team-work is not mentioned explicitly it is reasonable to interpret the required competences as individual requirements. Nevertheless, there is little doubt that the skills that are called for in systems designers are very broad and comprehensive. It is very clearly embedded in the polytechnical tradition, although the existence of this tradition is not reflected upon. The discourse on methods in the critical SD is very much a call for encyclopedic knowledge which makes it hard to see the defining quality of SD as a profession. It is difficult to see that there is any boundary objects that may be applied to delineate the profession.
In the simplified picture we are presenting, there are three distinct communities making up the profession of SD. These are proponents of the two archtypical approaches to SD outlined above (SE and alternative SD) in addition to the practitioners themselves.
As evident from the theoretical basis outlined above, alternative SD emphasises heavily a wide range of non-technical issues. This is mirrored in the accounts as well:
"SD is the conscious change of an organization with the use of IT. Possibly changing the way work is done. (...) [hence] it is clear that you should have some knowledge about context of use, about organizations and organizational development. And pedagogic and psychology." (aSD1).
More surprisingly is the fact that proponents of SE quite similarly emphasise this. One would expect some variation among the official, explicit accounts by these communities, most notably between SE and alternative SD. This, however, is not the case. The single most striking feature of these accounts is that they agree perfectly on the importance of the non-technical. Especially within alternative SD, SE is commonly characterised exactly for its lack of interest in the non-technical. They "fail to appreciate the social character of information in an organizational texture" (Lyytinen 1987, p. 12), "People are (...) seen as modules or program components (...) [and] disappear into the background" (Dahlbom and Mathiassen 1993, pp. 204-205) or they are "almost exclusively focussing on the technical problems" (Stage 1990, p. 85).
The description of SE by proponents of alternative SD misses completely the fact that the professional ideology of SE, mirrored in its explicit accounts of itself, emphasise strongly the importance of the non-technical. A fairly randomly selected, recent text-book in SE defines the subject as follows:
"Information systems analysis and design is a complex, challenging, and stimulating organizational process that a team of business and systems professionals uses to develop and maintain computer-based information systems. (...) Organizations can respond to and anticipate problems and opportunities through innovative uses of information technology. Information systems analysis and design is, therefor, an organizational improvement process. Systems are build and rebuild for organizational benefits" (Hoffer, George and Valachich 1996, p. 7).
Similarly, a professor from the most prestigious engineering institution -- the stronghold for focusing on the technical aspects of systems design -- in Norway points out that:
"what's special with information systems is that humans interact so that one can never implement an information system without having the technical and human aspects to function together.(...) hence one has to manage a process involving persons with different competences" (SE1).
Alternative SD does little, if anything, to underscore possible affinities with SE. On the contrary, the essential non-continuity between SE and alternative SD is emphasised (Hirschheim, Klein and Lyytinen 1996, Lyytinen 1987, Stage 1990). Clarity and dichotomies are obviously useful pedagogic vehicles. It is far less obvious that maintaining, reproducing and circulating these simplifications over years contribute to a firmer understanding of the problem. As opposed to what alternative SD tells us, there are striking similarities - at least on a rhetorical level between SE and critical SD. To get a deeper understanding of the real challenges of interdisciplinarity in SD, these aspects of SE need to be identified rather than neglected.
In exactly the same manner as SE and alternative SD define the subject as a broadly conceived activity encompassing but not restricted to the technical, practitioners also describe their field as interdisciplinary. We find that the account of SD as comprising non-technical issues shared by both SE and critical SD is equally pronounced among practitioners:
"SD includes organisational development. (...) Organisational development is necessarily a part of SD" (P3)
The non-technical issues are to occupy a steadily larger part of SD:
"SD used to be only technical. And still is, but I believe we are starting to realise that SD is really more of an organisational development tool. (...) In the project you are bound to get caught up in organisational development as well (...) [hence] it is very important that you also are able to grasp the how the organisation operates as a whole" (P4)
A different picture, however, emerges when inquiring into the practice of SD beyond the professional ideology. We show how all three communities of professional SD all back away from their ideology. They all, when getting down to business, again approach a polytechnical ideal by giving overriding priority to the technical. We describe in turn how the communities of alternative SD, SE and the practitioners exercise ideals of interdisciplinarity.
Proponents of alternative SD define their approach through their appraisal for the non-technical issues of SD. Still, also here proponents admit that at the bottom line the technical does -- and should -- have priority:
"Programming is the basis, I feel. It is the core" (aSD2).
This priority is not merely a vague feeling. By looking at what is taught at university institutions promoting alternative SD, the dominance of the technical is quite clear:
"Something that is very important in SD today is software development methods and models (...). [T]his is the only thing we teach our students here" (aSD2)
In principle, non-technical issues are emphasised, but not to the extent that they have an impact on the curriculum:
"If you think of the teaching in this institution, it's largely programming abilities" (aSD3)
"Finally, the most important for practitioners is [knowledge about] the technology" (aSD1)
The manner alternative SD underscores the importance of the non-technical while at the same time insisting that technical skills are of overruling importance, comes close to the polytechnical ideal. Even if some proponents of alternative SD mention the possibility of forming interdisciplinary groups, this is not a central issue. Team-work with professionals from other disciplined is not thematised explicitly. Implicitly, then, interdisciplinarity is conceived of as an individual ability. The inclusion of, say, sociologist or anthropologists in a project group is not viewed as viable in practice because such a person would not "really" take part. It would only generate new problems within the project group:
"I don't think it is realistic. Because you get a kind of a non-person. Someone who is to function as a medium. He doesn't take part, he is to function as a communication medium. (...) [I]f you mix persons with different expertise you get a terrible problem with terminology and a fear that you only end up creating a new problem" (aSD2)
The discrepancy between alternative SD's own definition of the kinds of skills that are taught does not seem to be bothering. If an understanding of organisational development is intrinsic to SD as they maintain themselves, how is this skill is to be developed when only traditional techniques receive attention? Implicitly, it is clear that systems designers are expected to cope also with the organisational issues despite their lacking background.
Proponents of SE have a clear strategy for interdisciplinarity. They quickly open up for a division of labour. The non-technical issues - which abound - are the responsibility of other disciplines represented within the project group:
"To be able to design a[n information] system, one needs a collection of persons with different expertise" (SE1)
"I think it is vital to have both [technical and non-technical] expertise represented in the project group. But I believe it is very difficult to develop a deep understanding in both areas in one person." (SE2)
SE quite explicitly adopts a specialisation strategy where they are to cooperate in teams with whatever other expertise is relevant. Accordingly, this position does not have the problem alternative SD has of being linked to a polytechnical ideal.
An interdisciplinary approach to SD appreciating the heterogeneous nature of SD has to move away from a situation where the technical apriori is at the core. Ideally, what should be at the core in any given project would be negotiated within the group in such a way that no type of expertise would be given priority per se. The polytechnical ideal, which we argue that alternative SD unwillingly comes close to, does not adhere to this. Viewed in this way, the position of SE with a clear division of labour is in fact a more promising platform for achieving it. We argue, then, that in principle the position of SD is better suited for an interdisciplinary, heterogeneous engineering approach to SD than alternative SD is.
But there is one problem with the position of SD, a problem which is shattering for the prospects of interdisciplinarity. The appeal by SE for team-work, cooperation and shared responsibility does in practice only apply to cooperation within a homogenous group of fellow SEs. A professor of SE explains how this ability of cooperation is developed:
"Q: So you teach and train students the skill to communicate [with others]?
A: Yes, I would say so. But not under an explicit heading (...) but through project work (...) [with] groups of 5-7 [SE] students" (SE1)
SE systematically neglects the issue of the scope of expertise possessed by systems designers. The discrepancy between what is said and what is done, which otherwise might develop into a kind of professional schizophrene, is fairly unproblematic to live through because any sense of one's own limitations is undermined. Rather than acquiring a sense of where one's own strengths diminish and others' pick up, SE effectively promotes a feeling of professional omnipotence.
Practitioners, despite their good intentions captured by their professional ideology, operate predominantly within what comes very close to a polytechnical regime. When asked about how central organisational issues really are when working in projects, one practitioner replies:
"According to the book, it certainly is important. But often it is not so in practise. (...) It should be more central than it usually is" (P1)
Non-technical issues are recognised to be "nice" but far from crucial, they are luxury concerns:
"[Knowledge about organisations] is not necessary, but I think you make better systems in the long run if you have it. (...) The information system you have to have. While the other stuff is not necessary." (P2)
"[T]o me the job is mainly technical. Of the time I'm involved in a project, I will say that about 60% is used to code and implement the system. Less time is used for specification and to elicitate information and persuade users. If I should guess, I would say 2/3 of the time is spent on coding and that sort of things" (P4)
The practitioners' explanations for giving the technical priority are seemingly pragmatic:
"The problems is that often it takes a bit of time to get a response [from the users] and that we begin to implement the system [quite early]" (P6)
There are few signs of a willingness to question this logic of the practicalities which "automatically" delegates the key role to the technical. Without anyone really noticing, it simply "happens" to end up with emphasising only the technical. The manner this takes place is versatile. There are many different mechanisms at play including: time and cost constrains, sequencing of the phases and the responsibility of delivering a actually working computer system.
One of the ways the technical issues get priority is that this is actually what the customer wants. The customer is interested in keeping it simple and equating SD with its most concrete witness, namely the information system itself:
"[The customer] provides time and resources to implement the information system (...) [but] is not interested in exploring the consequences for re-organising the work, hence I often feel the organisational development aspect of SD gets neglected" (P4)
Furthermore, the belief is that the economical benefits is linked to operating the information system itself. There is accordingly a significant pressure on time resources. The system needs to be in place as quickly as possible without worrying about too many other things:
"One is only doing short-term planning so that the information system has to make a profit and the profit should be produced fast" (P2)
A different kind of response is to leave the organisational issues to someone how knows better, namely management:
"Sure, SD influences the work routines and it influences the organisation(...) [but] we don't worry much about [organisational issues]. (...) I really believe it has to take place on a higher level." (P1)
As management seldom gets involved in the contents of projects, this kind of response in practice comes close to side-stepping the non-technical.
The heavy commercial rhetorics surrounding SD, filling the air with a steady supply of buzzards, also promotes an emphasis on the technical.
"The world today is partly spoiled by the belief that hardware and software products solve all problems (...) working with methods stuff and CASE tools and the like believing that this solves the real problems" (P7)
There is a, perhaps surprisingly, broad consensus among practitioners, alternative as well as SE about the need to make SD more interdisciplinary. Despite this agreement regarding the principal significance of non-technical issues, the majority of SD seems very reluctant to challenge the core of technical competence.
Several point out the need to work in project teams. But none seem to take seriously the fact that cooperation within a homogenous group is very different from cooperation with professionals with a background in social science or with users. This kind of cooperation requires a skill. And like most other professional skills, they have to taught, developed and trained. It is striking that this fairly obvious point is never mentioned by anyone. Alternative SD, which by never emphasising the need to develop this skill implicitly pursues a strategy of individual, encyclopedic interdisciplinary knowledge, is not a viable approach to interdisciplinarity. In but rare cases, it is unreasonable to expect this in any person. SE, by emphasising the need to train cooperation among themselves but never with others, implicitly contributes to a certain kind of professional arrogance in the sense that one never is faced with the problem of defining the limits of one's own competence.
The fact that the field of SD is poorly defined - there is no consensus on what makes up the profession, what the required skills should be - one might expect a kind of bargaining process among the different stakeholders. The technical, organisational, psychological etc. competences would somehow be molded into a new thing, namely SD expertise. This, perhaps naive, scenario is certainly not what actually takes place. By insisting that SD necessarily included substantial technical skills, computer scientists function as gatekeepers of an obligatory passing point (Latour 1987).
Computer scientists, the gatekeepers of SD, are reluctant to really open up for other kinds of expertise and skills, to let go of control. This is both understandable and defensible. It is a kind of a normal, professional reflex. Anyone would tend to avoid threatening situations. And it is defensible in the sense that computer scientists should not yield to the first social scientist or so who comes along. The competing disciplines should not be allowed to pass the gate before they document that their expertise is relevant, useful and operational (in some sense) to the problem at hand. They have to pass the test. But when they do, the same requirement apply to the computer scientist. It is not obvious- and it gets increasingly less so for every day - that their technical competence always plays a real as opposed to symbolic role in SD projects. A principle of symmetry should hold where no type of expertise is apriori assigned the driving seat. In some projects, the emphasis is on technical expertise, in others not. This implies that computer scientists would need to learn to let go of control and deal on equal terms with scholars from other disciplines who have proven their case.
Still, any approach to interdisciplinarity in SD needs understand and take seriously the many mechanisms referred to as the logic of practicalities illustrated earlier which "automatically", invisible and unnoticed delegate the key role to technical concerns.
Bansler, J. and Bødker, K. 1993..A reappraisal of structured analysis: design in an organizational context, ACM Transactions on Information Systems, 11(2):165-193
Bijker, W., Pinch, T. and Hughes, T. 1987. The social construction of technological systems. MIT Press.
Bjerknes, G. and Dahlbom, B. (Eds.) 1990. Organizational competence and systems development, Studentlitteratur, Lund.
Dahlbom, B. and Mathiassen, L. 1993. Computers in context. Basil Blackwell.
Dahlbom, B. and Mathiassen, L. (1997 The future of our profession, Comm. of the ACM., 40(6):80-89
Floyd, C. 1987. Outline of a paradigm change in software engineering, In Bjerknes, G., Ehn, P. and Kyng, M. (Eds.), Computers and democracy, Avebury.
Floyd, C. et al. 1989. Out of Scandinavia: alternative approaches to software design and system development, In Human-computer interaction, volume 4, Lawrence Erlbaum Assoc., pp. 253 - 350.
Hirschheim, R., Klein, H.K., and Lyytinen, K. 1996. Exploring the intellectual structures of information systems developement: a social action theoretical analysis, Accounting, Management & Information Technology, 6(1/2):1-64.
Hoffer, J.A., George, J.F. and Valachich, J.S. 1996. Modern systems analysis and design, The Benjamin/Cummings Publ. Comp.
Hughes, T.P. 1987. The evolution of large technical systems, In Bijker, W., Hughes, T.P. and Pinch, T. (Eds.), The social construction of technical systems, MIT Press.
Latour, B. 1987. Science in action, Open Univ. Press.
Lyytinen, K. 1987. Two views of information modelling, Information and management, 12(1):9-19.
Noble, D. 1977. America by design: science, technology, and the rise of corporate capitalism, NY: Alfred A. Knopf.
Pressman, R. 1992. Software engineering. A practioner's approach. McGraw-Hill.
Stage, J. 1990. Analysing organizations in system development. In Bjerknes, G. and Dahlbom, B. (Eds.) Organizational competence and systems development, Studentlitteratur, Lund, pp. 85 - 106.
Star, S.L. and Griesemer, J.R. 1989. Institutional ecology, 'Translations', and boundary objects: amateurs and professionals in Berkely's Museum of Vertebrate Zoology, Social studes of science, 19:387-420.
Suchman, L. 1987. Plans and situated action: the problem of human-machine interaction, Cambridge Univ. Press.