Revised position paper for Information Systems Foundations: Practice and Ontology Workshop Macquarie University, Sydney Australia, 29 September, 1999.
Information Systems Founded on Practice
Robert M. Colomb Department of Computer Science and Electrical Engineering The University of Queensland QLD 4072 Australia colomb@csee.uq.edu.au
Abstract
We worry about foundations out of a fear that our practice might collapse. However, the success of a system must validate the method of building it. Practice can be profitably problematised, though, since it can be discussed, must be taught, and can be improved. The theoretical concepts used to do this do not refer to underlying reality, but are metaphors, limited interpretations of a complex whole. The foundation of practice is practice itself. We can discuss, teach and improve practice by metaphor, but the metaphor is never definitive. We can get as much certainty as it is possible to have, but we can never be certain we understand what we are doing, even though what we do might be effective.
Keywords: IB02 Research frameworks, AI0802 Epistemology - Interpretivist perspective
- 1. Introduction - why do we want to worry about foundations?
- 2. Certainty in a social system
- 3. Practice is its own foundation in information systems
- 4. Why then do we need to worry about information systems design and development practice?
- 5. What questions of foundations remain?
- 6. Ultimate building blocks for texts?
- 7. The reality of objects designated by theoretical concepts
- 8. How can we think holistically?
- 9. How does holistic discourse work?
- 10. Is the hypothesis of discourse as interpretation of complex reality viable?
- 11. So What?
- References
1. Introduction - why do we want to worry about foundations?
This workshop has to do with foundations of information systems. I would like to first consider why we would worry about foundations in information systems.
Other fields worry about foundations. Civil engineers worry because a physical structure will collapse unless built on secure foundation. Here the foundation is a secure base on which a complex structure rests.
Information systems are not physical structures, but the analogous foundation are the communication, computing and interface devices and procedures with which the system is implemented, which must be sufficiently reliable for an information system to operate. These technological foundations are not generally considered problematic in information systems research.
Mathematicians worry about the foundations of mathematics - consistent axioms and consistency-preserving inference rules are needed to protect against the risk of inconsistency and consequent non-sense. Information systems involve language, but are not built from fixed axioms and rigid inference rules. They are complex systems typically involving many people, which are intended to perform tasks in what are essentially social domains. Formal concepts of inconsistency generally do not apply to social domains.
I submit that one of the worries leading to concerns about the foundations of information systems is that something might somehow invalidate the practice of information systems design and development. Huge amounts of effort go into design and implementation of information systems. It would be catastrophic if something were learned or happened to invalidate them, so that they no longer served their purposes.
We have already established that the foundation issue here is not the technological substrate of particular systems, nor the risk of formal inconsistency. What we seem to be looking for is some sort of certainty in the process of developing information systems.
2. Certainty in a social system
If an information system, and especially the process of developing it, is essentially a social system, and we are looking for certainty, we can look at certainty in other social systems that are better understood.
For example, how is a father certain that a child is his? Certainty of paternity is a possible problem since in a promiscuous society there is no immediately visible and unmistakable connection between a particular act of sexual intercourse and a birth. Certainty can be achieved only by designating certain women as wives of certain men, and preventing wives having sexual access to other men. This has been attempted in many ways, involving complex behaviour norms, trust, society-wide expectations, sanctions and so on. Yet these social control structures are often fooled, since a single lapse is all that is needed. Paternity is often challenged.
In the last few years, technological advances have made possible a more direct means of testing paternity - DNA testing. However, DNA testing also involves complex social structures, behaviour norms and record keeping (see for example Latour and Woolgar, 1986 ), and can fail. Forensic evidence is open to challenge in court, and can fail, sometimes spectacularly as in the recent US FBI forensic lab failure (Kelly and Wearne, 1998).
So even with best efforts, certainty of paternity is not very certain.
We now look at another, closely related, example - how does a mother know a certain child is hers? This is almost a silly question - she just knows. It is possible for a mother to be fooled there are occasional cases of baby switching - but maternity is very rarely called into question. Maternity is much more certain in practice than paternity, even though it lacks the complex social systems intended to achieve paternal certainty.
The certainty of maternity is pre-human. Consider cows and ewes, which can tell their own calf or lamb in a large herd. More extreme are certain penguins, which are able to reliably find their own chicks in a constantly moving mass of ten thousand in the dark of an Antarctic winter.
This sort of certainty arises in behavioural practice, which is shaped by reproductive success which depends on physical survival. Maternity is certain because without reliable identification of progeny there would be no new generation. The practice is self-verifying.
Arguments about the certainty of paternity or maternity are
not in themselves pertinent to information systems. However, they
suggest that some practice is very reliable without much need
for assurance, and that some practice which requires complex structures
for achieving certainty is very unstable, and in the end much
less likely to produce successful outcomes.
This argument leads to the suggestion that the practice of developing
information systems be assessed directly on the outcome of the
practice as perceived. The alternative being rejected is assessment
based on the artefacts and methods of the development process.
Quality assurance is no guarantee of a successful outcome. It
only provides accountability for failure.
If the system works within the social, economic and environment constraints placed apon it, it works and the practice of development is deemed successful. The practice of development is assessed by the practice of use.
That is, practice is its own foundation. Practice is irreducible - there is no deeper, more primitive archetypal concept that can be constituted to describe practice.
3. Practice is its own foundation in information systems
The thesis is that in information systems, practice is its own foundation. In other words, if a system is built which works successfully, the design and construction practice that built it can never be invalidated. In Aristotelian terms, the significant cause for an information system is its final cause, the purpose for which it exists, not its efficient cause, the process by which it comes to exist.
Whether a person who kills another is guilty of murder depends on their intention, not on the weapon used. Whether a bridge can carry traffic across a river does not depend on whether it was built stone by stone within an elaborate matrix of scaffolding later removed or whether it was assembled from steel in a factory and lowered onto the site by helicopter. Once the bridge is in place, if traffic can cross, then traffic can cross.
In this light, if an information system serves the purpose for which it is used, then its validity is unassailable, and the process by which it is constructed is irrelevant to its validity.
4. Why then do we need to worry about information systems design and development practice?
The thesis that information systems practice is its own foundation and that therefore practice can take care of itself does not imply that there is no need be concerned about practice.
- Practice can be improved one would like to be able to build systems at lower cost, in shorter time, for them to be more cheaply maintained, and for them to be more reliably suitable for their purpose.
- Practice must be taught, if new practitioners are to be recruited.
- Tools can be developed to automate aspects of practice.
Even though we have conjectured, based on empirical observation, that there is no point in seeking a deeper certainty, there is a need for discourse about practice and foundations.
5. What questions of foundations remain?
In the physical sciences and technologies, foundations are the ultimate building blocks from which structures are made. Foundations of chemistry are objects and ideas such as atoms, valencies etc. In this sense the foundations of computer programming are the instruction sets of the computers and peripheral devices, and the machines which execute the instructions according to their specifications. In these fields, the foundations are well-understood objects which allow the reliable assembly of complex systems.
Information systems are not physical, nor do they necessarily
have anything to do with particular technologies. Checkland and
Howell (1998) present as an example the
very successful information system used by the British air defence
system during the Battle of Britain in World War II, before the
invention of computers, where nearly all the operations were performed
manually by large teams of trained people.
We have argued elsewhere (Colomb and Weber, 1998) that an information system can be seen as a text (able to be read by computers as well as humans) which is a record of speech acts.
Following Weber (1997) we accept that the purpose of an information system is to represent another system. If we look for foundations as defining the ultimate building blocks, then for information systems themselves we are looking for ultimate building blocks which represent speech acts.
Similarly a procedure for building information systems accorrding to a particular practice is also a text, which can be read or spoken by humans. If we accept ultimate building blocks as constituting foundations, we should be looking for ultimate building blocks of procedures.
6. Ultimate building blocks for texts?
If information systems and the procedures for building them are texts, then if we want ultimate building blocks for them, we must have ultimate building blocks for texts not all possible texts of course, but for some genres of texts. The texts are not necessarily in English it is reasonable to expect to be able to describe the procedure for building an information system in Telugu as well as English.
So at one level, the ultimate building blocks for texts are the members of the collections of semiotic elements of various languages from which the texts are constructed. This level is not satisfactory, since for one thing there are far too many elements, and for another it is too easy to create new ones every paper introduces some new terminology.
What we would like to see is a system of concepts of reasonably small complexity, for example the Bunge-Wand-Weber ontology described in Weber (1997) based on things, properties, systems, laws, and so forth.
There is a tendency to want to see these conceptual systems as foundational in the same sort of way that instruction sets and processing units are foundational to computer programming, or that atoms, valencies, charges etc. are foundational to chemistry. That is to say that the concepts have meanings, which is taken to entail that the concepts designate objects which are real in some sense. These real designated objects would be the foundations sought.
7. The reality of objects designated by theoretical concepts
The idea that theoretical concepts designate objects which are real in a way analogous to the way words like 'apple' and 'table' designate real objects is very ancient and widespread in our culture, going back to Pythagoras and Plato at least.
The difficulty with this idea is that it does not stand up to scrutiny.
Many philosophers in the past century or so have tried to understand how the concepts of theories in the physical sciences have meaning and what sorts of things they designate, mostly under the rubric of the philosophy of science (eg Popper 1972). Although the issue is hardly settled, there are very strong arguments that the theoretical concepts we think of as referring to ultimate building blocks of natural phenomena do not necessarily designate real objects, and if they actually do, we will never be able to know that they do. There is serious doubt that the terms 'atom', 'valency' and 'charge' designate real objects. A fortiori, there must be serious doubt as to whether 'thing', 'property', 'system' or 'law' designate real objects.
It would seem that it is more useful to think of reality as not built up from atomic concepts, but that the conceptual structures of our theories are used to interpret a complex reality that complex experience is primary. This way of thinking is consistent with the primacy of practice advocated above. That is to say organisational reality is interpreted by our theories about it and by the information systems we build as part of this organisational reality; and the methods of information systems design are interpretations of the complex social and technological processes used in the construction of information systems. The approach advocated, of taking complex reality as primary, can be called holistic.
Thinking in holistic terms is difficult, however, because most of our intellectual traditions are foundational. We lack holistic models.
Tarnas (1991), for example, provides philosophical argument for this assertion. Tarnas asserts that our intellectual traditions are based on an archetypal world view (Tarnas p 3) originating with the Greek philosophers:-
- "the Greek Universe was ordered by a plurality of timeless essences which underlay concrete reality, giving it form and meaning."
8. How can we think holistically?
There is a tradition of thought developed over the past century or so in what is loosely called continental philosophy which begins to show us how to think with complex reality as primary. Key thinkers include Martin Heidegger (1962), Emmanuel Levinas (1991), and Jean-Francois Lyotard (1993). In their work, complex reality is not mystical and unanalysable, but is studied by metaphor - taking a technological or conceptual construct and saying that the real object behaves in some respects like the construct. It is not necessary to claim that the metaphor exhausts the real object - the real object always exhibits behaviour that the metaphor does not interpret. Further, it is not necessary to claim that there is a unique or even best metaphor.
A view much like this is in fact very common among physical scientists to interpret their use of mathematics - in particular Eugene Wigner's famous essay "The unreasonable effectiveness of mathematics in the natural sciences" (Wigner, 1979). Wigner argues that mathematical structures are used to interpret physical phenomena, and that the structures are often able to be adapted to very different theories about the same sort of phenomena. All that is necessary is that the mathematical formulations permit calculations which are interpreted as predictions that are sufficiently accurate for particular purposes.
9. How does holistic discourse work?
We discuss practice. The discussion requires a terminology, which we argue is a complex metaphor, which is tested by matching it against experience. The discussion so far has been pretty abstract, so in this section we illustrate this view with an interpretation of a complex example, in which the difficulty of reaching atomic foundations is illustrated.
Consider two information systems developments. A is implemented in COBOL/IDMS and runs in batch mode. It was designed using Bachman Diagrams and the Hierarchical Input/Process/Output method. The design was top-down, using the waterfall model, with requirements, design, implementation, unit testing, systems testing, commissioning and maintenance phases. B is implemented using Oracle Designer/Developer 2000 on top of the Oracle relational database. The design was based on progressive prototyping and partial implementation, using the Entity-Relationship method and data flow diagrams. However, both A and B implement the same application, derive data from the same forms, and produce the same reports. Further, A and B are both running on the same computer system.
Some of the terminology used to discuss these is the division into aspects of implementation platforms (COBOL/IDMS vs Oracle/ Relational), design tools (Bachman diagrams, HIPO diagrams vs ERA modelling, Data Flow), and engineering methods (Top-Down vs prototype/ progressive implementation). Where do we find foundations?
The implementation platforms ultimately result in instructions from the same instruction set on the same computer. However, the sets of instructions implementing a particular report can be very different. Further, in both cases the translation from the implementation platform to the instruction sets loses much information. This is why the decompilation/ reverse engineering problem is so difficult. In any case, the system could easily have been translated into entirely different instruction sets on entirely different computers. The information systems discipline abstracts away from computer systems in much the same way that civil engineering abstracts away from building materials.
The foundations, if any, of the implementation platforms must be in their underlying structures. However, the different platforms require different implementation decisions. A CODASYL database requires designation of sets as owners or members, and permits sets to be information bearing or not. These decisions need not be made in a relational implementation, since a relational database makes navigation decisions dynamically based on particular queries. On the other hand, the relational database permits identification of keys, foreign keys, and integrity constraints, since some of the updates and queries are provided as primitive operations by the platform whereas in the CODASYL database, application programs must implement them. It is certainly impossible to translate one data design into the other, but in order to be able to have a data design platform subsuming both, design decisions for both platforms would have to be made, many of them unnecessary. To search for foundations here is not promising.
The design model aspect is no better for foundation. Bachman diagrams are closely tied to the CODASYL implementation - they are essentially a graphical representation of the CODASYL Data Description Language. An ERA diagram can be automatically translated into a relational data schema (although with some additional decisions, a CODASYL data description can be created). The relationship of one to the other is essentially the same as the relationship of the two implementation data models, and as unlikely to lead to foundations.
One might argue that the data elements and relationships constituting the two designs must be able to be translated one to the other, since they are designs for the same application. Search for foundation in this direction is similar in concept to search in the machine implementation direction. Any data elements and relationships which are not working data or temporary results must reflect the application in order for the application to work at all. That both data models can represent the application is simply a statement that the two data models are linguistically complete, in that they can represent the results of all possible speech acts (see Colomb and Weber, 1998). The profession of information systems development must be abstracted from any specific problem, in the same way that any professional must be prepared to accept any appropriate problem presented by a client.
Does the if not impossibility at least extreme difficulty of finding foundations for information systems make a difference to the discourse surrounding the practice? I would argue not. A discussion of the relative cost and time taken to develop the two systems is cast in what amounts to economic terms. One can compare economic aspects of the effort devoted to different phases of the respective designs. A discussion of the relative throughput and response times of the two systems is cast in what amounts to technological terms - these depend ultimately on the capabilities of the machines on which the systems are executed. Maintainability is economic, performance is technological.
Regarding the descriptions of the systems development as interpretations is adequate for understanding the discourse. If one wanted to compare the effort and time expended on say design in the two systems, one might start with the effort allocated to the design phase of system A. That this effort is an interpretation is attested by the well-known fact that the design is influenced by many implementation considerations, and that it often happens that problems occur quite deep in the implementation process that require substantial redesign - hence the issue of risk reduction in some design practice. In other words, some development activity is called design for some purposes and not others, in keeping with the notion that a system development process is an interpretation of requirements and purpose some of which is presumed from context.
System B does not have a statutory design phase at all - the activity corresponding to design in system B includes much activity that would be maintenance or systems assurance, or even implementation in system A. Still, a determined student could construct an interpretation of a fine-grained record of system B's development process to come up with an estimate which might be grossly comparable to the estimate of the design effort from system A, at least for the purpose of the study.
In short, regarding the practice of information systems design as its own foundation makes it plausible to interpret the process of discourse about practice as a process of interpreting the complex reality of practice. Each interpretation is constructed to be adequate to its purpose, and the generality of results depends on the ability of other people to interpret the interpretations in other contexts as adequate to their further purposes.
10. Is the hypothesis of discourse as interpretation of complex reality viable?
We can teach practice. It is a commonplace in teaching of any complex skill that the student must learn simpler skills first. The student then learns more complex skills by engaging in more complex activities which integrates and reorganises the more elementary skills, but in such a way that the elementary skills lose their elemental status - the mark of a master is smooth, effortless-appearing practice. The elementary skills named by the terminology are a sort of scaffolding or training harness, which is removed when the apprentice becomes a journeyman. The interpretation of the process of learning the skills of information systems practice as a process based on interpretation provides an adequate discourse of for the practice of training. A foundation other than for training and systems building practice itself is not required here either.
We can improve practice. In discussion about practice we can problematise certain aspects and suggest different approaches. We might have an environment where systems design and construction is based on the waterfall model as was system A. We might notice that organisations employing the prototyping/ phased development approach as was system B produce systems which are better accepted in the organisation, and have a better fit with the organisation's methods of operation. Just because practice is its own foundation is no indication that a working practice is in any sense optimal. The evolutionary metaphor used in the discussion of maternity does not imply optimality, only survival.
The problem then becomes how the organisation can break the design and development activity into small feasible chunks corresponding to the incremental prototypes. This interpretation of the problem as breaking a large development into many smaller ones might lead to workable and better systems, but perhaps at much greater cost. If cost is taken as the problem, one might discover that the system B organisation relied on the much faster development time for both prototypes and solid implementations offered by the Oracle Designer/ Developer environment. Greatly reducing the human effort required increased cost of development environment and resulted in less efficient use of computing power. The consequence was a need for increased power for the same throughput.
Introducing a new development environment might increase instead of reduce the human cost of development and the time taken to produce prototypes and incremental applications. Treating this new phenomenon as a prpoblem, one might discover that the development staff require substantial training, or perhaps selective replacement in order to make the expected use of the new development environment.
This hypothetical tale of tribulation is a good argument for the various problematisiations to be thought of as interpretations of aspects of the development processes in both organisations, rather than regarding the aspects isolated as being somehow 'real' in themselves. This provides another kind of argument against foundationalism.
By changing the scaffolding, we can alter the practice taught. We can observe that one tradition of practice gives better results in some respects than another. By finding common ways of interpreting aspects of both traditions (metaphors) we can isolate aspects in which the practices differ, and attempt to modify the scaffolding of one to improve it. The metaphor can suggest possible improvements. The fact that these attempts at improvement often fail or have unexpected consequences is evidence that the theory is not definitive.
In conclusion, I have argued that the foundation of practice is practice itself. We can discuss, teach and improve practice by metaphor, but the metaphor is never definitive. We can get as much certainty as it is possible to have, but we can never be certain we understand what we are doing.
The question remains 'does this view of the foundations of information systems make any difference to what we do?' I submit that it implies at least:
- An information systems project is evaluated on a cost-benefit basis what its value is to the organisation using it compared to what resources went into building and maintaining it. The rejected alternative is evaluation based on the methods used in construction, as is common in organisations taking an extreme view of quality assurance.
- Following this, a methodological innovation is evaluated on the basis of improvements in the cost-benefit ratio of the projects on which it is intended to be used (consistency of cost-benefit might be a subsidiary value). The rejected alternative is treating methods as normative.
- Methods themselves are evaluated both as tools for producing cost-effective systems or as training aids to cost-effective development of practitioners capable of producing cost-effective systems.
- Theories about systems, the systems-building process, and the situations in which systems are used are treated as tentative and evaluated on the basis of productive insights. The rejected alternative is to treat the theories as definitive. In particular, we do not seek the ultimate theory. If, for example, there are rival ontologies, eg the Bunge-Wand-Weber (Weber, 1997) and Chisholm (1992, 1996), we do not worry if they seem to be incompatible. The issue is how much they help improve cost-effective practice.
References
Checkland, Peter and Howell, Sue (1998) Information, Systems and Information Systems Wiley.
Chisholm, R.M. (1992) In K. Mulligan, ed)Language, Truth and Ontology Kluwer Academic Publishers
Chisholm, R.M. (1996) A Realistic Theory of Categories An Essay on Ontology Cambridge University Press.
Colomb, R.M. and Weber, R. (1998) "Completeness and Quality of an Ontology for an Information System" in N. Guarino (ed.) Formal Ontology in Information Systems (International Conference on Formal Ontology in Information Systems - FOIS'98 - Trento, Italy, 6-8 June, 1998). IOS-Press (Amsterdam, Oxford, Tokyo, Washington, DC) 207-217.
Heidegger, Martin (1962) Being and Time Blackwell
Kelly, John and Wearne, Philip (1998) Tainting Evidence: Behind the Scandals at the FBI Crime Lab Simon and Schuster
Latour, Bruno and Woolgar, Steve (1986) Laboratory life : the construction of scientific facts Princeton, N.J. : Princeton University Press.
Levinas, Emmanuel (1991) Totality and infinity : an essay on exteriority Dordrecht, Netherlands ; Boston, Mass. : Kluwer Academic Publishers.
Lyotard, Jean-Francois (1993) Libidinal Economy Indiana University Press
Popper Karl R.. (1972) The logic of scientific discovery London : Hutchinson.
Tarnas, Richard (1991) The Passion of the Western Mind: Understanding the Ideas that Have Shaped Our World View Ballantine Books New York
Weber, R. (1997) Ontological foundations of information systems Coopers and Lybrand.
Wigner, Eugene (1979) "The unreasonable effectiveness of mathematics in the natural sciences", in Symmetries and Reflections Ox Bow Press.