oturn home > Information Systems – Fundamentals and Issues: overview > Ch. 5: Information Systems Design

Information Systems – Fundamentals and Issues
©1990-2006 John Lindsay, Kingston University, School of Information Systems

Chapter 5: Information Systems Design

A search on a venerable library catalogue on the topic of design is likely to bring up MacPherson's venerable *get title, an elaboration of the argument of Acquinas, developed by Kant, on the proposition that the existence of God is made necessary by the need of the universe to have had a designer. A search on a less venerable catalogue will point you at a Black and Dekker drill, or a Braun shaver.

The word design seems to be one of those carpetbag expressions which at the basic level simply means getting things right. Any principle of engineering seems to boil down to giving the punter what he wanted, or was prepared to pay for: define what you are going to do, do it, stop. Rather too elementary a methodology to butter the parsnips. Christopher Jones he intellectual difficulty and fun from manufacture and give them to a new class of persons who makes the drawings" His picture of the cart with all the detail of context and purpose and material show the level of detail lost in the Fordism and Taylorism of a later stage of manufacturing.

He summarised his ideas in Design Methods[2]. Copy fig 1.2 and frontispiece. Now this doesn't look any different from a schema for project management from any of the structured methods. He also pulled together some quotes from the established literature:

and so forth.

By 1990 the British Secretary of State for Education and Science was suggesting a general method for teaching "technology" as part of the "National Curriculum" which put forward four attainment targets over ten levels from the ages 5 - 16 for identifying needs and opportunities, generating a design proposal, planning and making, and evaluating[6].

At the age of 5 pupils should be able to discriminate among artefacts (objects made by people), systems (sets of objects which perform a task) and environments (surroundings made, or developed, by people). This would not be unrecognisable on a degree course or an MBA. In other words there is a suggestion that the process of design and project management has certain principles which may simply be migrated upwards to encompass all design.

So "design" is a general method for seeing the world and approaching its problems.

One problem emerges immediately: there are two dominant traditions of design in English: the design of the engineer and that of the decorator. David Pye[7] defines the principles of design as follows *get quote. Christopher Jones[8] outlines them however *get quote. The basics of a spatial representation, of finding out what a client wants, of satisfying contradictory requirements seem to be common. But the "art" of design remains a black box.

This distinction between the design of engineering and of decoration might be further complicated by a distinction between the scientist and the novelist. The basis of design could be the application of a "few deep elegant inexorable laws", "utterly lacking in laws - the novelist's way" There could be here the dignity and purity of the Crystalline Mind or the dignity of ultimate mystery, the inexplicable Mind[9].

The position of the scientist might be further complicated by the debate on scientific method which divides the objectivist from the subjectivist. Kling and Hirschheim get rest[10]

Yet in the domain of information systems, there is an argument which is different from that of design as judgement and satisfying: the argument of "formal method", that something is right because it is provably so and cannot be other.

*need a couple of quotes here.

The literature on business systems does not help us here either. It is recognised that there is no relation between spending on information technology and "competitive advantage" or success.[11]. In fact the goal of the organisation is taken to be the maximisation of rates of return on capital employed, or per employee or on equity, or market share, or other definition. This means that the goal can not be reducible to a proven consequence of a particular level of investment or type of design.

*elaborate this with more quotes?

Now this dichotomy seems to need some solution. Either designing information systems is about making judgements, in which case we need to elaborate the grounds on which judgements are better or worse, right or wrong, good or bad; or it is about truths with are incontestable because they are proven so.

The information system designer however does not wish to have to master the history of philosophy of (at least)western Europe to be able to design. Yet if what I have argued in the first four chapters outline the domain of design, it is clear there are some issues. These I have called the seven design problems. I've called them design problems because they do not have answers which in and of themselves are right or wrong; they cannot be proven or disproven in and of themselves; they involve decisions which have to be made. If decisions are not made or at least the range of possible decision spaces modelled, then paralysis is the only result. Each I'll discuss in turn. The organisational consequences of using different methods for handling the process I'll come to in chapter six.

Seven Design Problems

Design problem 1: the Boundary problem

How do you decide on the boundary of a system? For a simple system with only one component, such as a pendulum with a metal weight it is easy. The definition of the system is the boundary of the range of possible problem spaces and solution spaces. For more complex problems the bounding of the problem becomes more and more a matter of design. Developments in technology I referred to in chapter four are increasing this complexity. Precisely because it is a design question which networks you interface, from which sources data is drawn, and to which outlets it flows and in which form. The modelling of the system at the strategic level has to be the level at which the boundary is defined by a set of protocols. But this is a definition based on design. It cannot be proven true or right in any formal way.

Sometimes the decision might be based on law: the system has a custom post or border control, a protocol, you do not have the right passport, a protocol, therefore you may not enter the system. Financial systems, after the removal of currency controls, or the movement of currencies electronically rather than a man in a tall black hat in a small boat, give examples of complexity: EDI, trader net, SWIFT, are organisational forms of this complexity.

The beginnings of a geographic information system I outlined in chapter two shows another example. Where spatially do you bound? At the administrative boundary of the urban area? The national boundary of the country? Yet telephone lines, water supply, the migration of people, don't obey these constraints. The joining of boundaries from different component subsystems requires the specification of protocols. However, the process of defining which might be so complex that the system becomes paralysed.

Design problem 2: the Scale problem

The sets of design principles which might be brought to bear on a problem depend on the scale of the problem. It is not possible to scale up a problem. Problems reach boundaries of scale above which they no longer continue to obey the "laws" of that type of system, but have to go through a revolutionary change. Evolutionary growth is possible within the bounds of a scale of problem, both up and down, but not across those boundaries.

A "Baconian" model of the range of scales might be that which I indicated in chapter 1 on page * We take the individual human being as the starting point, partly for ideological reasons, partly as a design issue. One individual human being processing information is in some sense a self contained system. She has a relation to the world, to the sources of financing, to a private life - housing, family, pleasure. She might be a wage labourer, an artisan, self employed, an employer. But that individual and the set of relations is capable of being modelled. The range of possible sources of information which might be required and produced can be modelled and costed. The types of technology required to perform certain tasks may be indicated. The possible channels of communication can be modelled and costed. To go into any one person in detail is to be involved in a fractal explosion of complexity. But each of us can do it for ourselves. This is why I am writing this book and you are reading it. *put in diagram or rich picture for a student?

As soon as we have two people, the system is difficult. The two of them are together, they are a "system" for some reason. They have a relation one to another - employer - employee; partners; lovers; they have a work pattern and a pattern for sharing information; they work out series of protocols to organise the work. They define protocols whereby meaning becomes negotiated between the two of them, which might be different from the meanings either of them would understand when involving communication outside "their group".

The spatial organisation of their relationship will in turn affect the processing of information - do they share the same room? Does the layout of the room communication their relationship? What sort of information do they have to communicate with one another, with the world outside? But at least when they talk to one another they both know something is happening

*Put in models showing possible relations

Now take three people. The model becomes different in that it is possible, or indeed likely, that one of them will always not be present when the other two are. Communication and the storage of information now always involves the possibility that one of them doesn't know about it. The definition of protocols can't be dependant on the chance meeting or conversation. A form of formality has to develop. The taking of notes, the minuting of meetings. The booking of diaries. The keeping of books.

With a fourth person this pattern of complexity is likely to increase. The range of personal relationships, the flows and patterns of communication, all will change. All will become more complex at one level, yet simpler at another. What needs to be formalisable in the system becomes a smaller and smaller part of the complexity of the total lives of each of the participants.

Grow the system up to ten or possibly even twenty people. It is still possible for them to know one another, to have affective relations, to drink together, to eat together. Yet the form that systematicity enters the growth of this system will in turn give form to (inform!) it[12].

As the system grows up towards the hundred, the organisational form will have to change again. More and more formal management structures will have to be put in place. More and more protocols will be required. Formal wage bargaining procedures, taxation, requirements, a vast range of new skills will be required simply to deal with a layer of bureaucracy which will come into place. Organisational charts, telephone directories, reporting structures, work manuals, codes of practices and customs and practices will all grow.

Then in the next order of magnitude an thereon upwards until eventually we might have the system comprising all possible people, the organisational form will from time to time have to go through upheaval.

Let us take another example: a railway system. With one line, up and down, and only one train, this is a most simple system involving little signalling and little complexity[13]. Introduce two trains, or a crossing; several trains and many crossings and the system complexity increases combinatorially. These systems cannot just grow, as London transport or British Rail proves. The boundary provided by an island however at least imposes a limit; the European rail system has no such boundary. The scale problem therefore provides a multilayered model of protocol complexity. The general solution appears to be considerable redundancy since the system is not competitive with a system based on roads and vehicles, though levels of subsidy make analysis difficult.

Attempts to subdivide the problem in order to reduce complexity or divide the problem into manageable parts merely reintroduces the boundary problem. Either one might settle for a spatial division, for example a return to regionalisation of the rail system, or a market segment, such as goods and passengers, but in either case the interfaces of these sub components produce management issues we'll return to in chapter 6. For the moment I merely wish to insist that these are design decisions and not in any sense ontological, scientific or provable.[14]

The scale problem also involves migration from system type to system type. For example a single motor car might be subdivided into components or subsystems, and motor cars might be compared with one another as systems, on price, performance or whatever. But it is not possible to migrate upwards from the characteristics of a motor car to the characteristics of a transport system in the way in which you could model trains up to rail systems. There is a change of state, a change from quantity into quality to move from one layer to the next. (Not sure I'm right here - trains might be like cars*)

Design problem 3: the Change problem

The scale problem has introduced the change problem - how do you model change into a system? There is a general proposition in systems theory about state transition and emergent properties. Yet as a property emerges, at what point or on the basis of what evidence does one recognise that "it is there", and as it becomes dominant, how does one model the point at which the system "flips over" into a new state with new properties about to emerge? Were these properties in the object from the "", did you define them into the system, at what point did they impinge on the consciousness of the observer, at which point did the system flip over, or is it you deciding that a change of state has occurred?

In very simple systems the change is defined into the system as a set of rules. For example in a banking system if I insert a card into an ATM and key in a PIN then withdraw [[sterling]]40, that amount will be deducted from my account and the balance will be reduced. In a more complex system, such as a pot of popcorn, it is not possible to predict which corn will pop first, no matter what I know about all the conditions, although I can model the general behaviour of the corn. In a more complex system still, I cannot model in any way that events in Eastern Europe would happen in 1989-90, though it could be modelled that they would occur[15]

Kling and Hirscheim make the point in[16] that it is never possible to model these properties therefore it is never possible to be certain that an entity relationship diagram will contain all the relevant information.

Perhaps the most interesting discussion of these issues is emerging in connectionism and neural networks, but this is not the place to discuss that one.

Design problem 4: the Proof problem

This leads us to the next layer of design issue: what sort of proof is legitimate for argument and that layer of system? The domination of the scientific or Descartian view of the world in many disciplines - the desire for something to be right when it is scientific, has lead to the use of words like "social science", or "human science". "Science" has become a universal good which legitimates an argument by its incantation.

Yet just as the engineering principles which make for the design of good motorcars aren't translatable to the design of a transport system (except at a level of generalisation to which I'll return later), the scientific laws which hold at one level of a system may not be scaled up to a higher level.

Translate this model back to the description in the discussion of the scale problem above and the legitimacy or otherwise of the use of scientific proof becomes clear. The proposition that the scientific method requires an hypothesis, an experiment, deduction, replicability or refutation has been the source of considerable debate, the best rehearsed is that of Popper and Kuhn, and needs no discussion here[17]

The illegitimacy of applying the scientific methods and derived laws of the physical systems to biological or social systems is similarly well rehearsed. However the ideological desire for certainty gives a legitimacy to physics as the most pure of the sciences to which state the social scientist still appears to aspire. That social systems do not evidence behaviour which can be reduced to the laws of Newton hasn't stopped systems designers chasing the Grail.

There is a particular deviation marked by those who would argue that an information systems is a physical or mathematical system only, that it does not involve people, and therefore its specification and description is provable within the universe of mathematics or formal methods. With those people we shall simply have to agree to differ, comfortable that they have never yet designed a system and never will.

However if we lack the proof paradigm of physics how may we say that we have proven whether we have designed a system well or not? If we can define the requirements of the system, like the three metal balls, that we may say it is deterministic, then the laws of physics will hold. If we may specify its behaviour to be probabilistic, stochastic *check others, and the client commissioning the system is happy with the definition of all primitives and protocols that the system is complete, then we may still survive.

Design problem 5: the Power problem

After the previous section this one is simple: it is to assert that all social systems are about the distribution of power within those systems, and that the design of an information system is a shift in the relative balance of power of some of the parties. Unless the designer recognises this and consciously takes it into account, there is no possibility of a good design[18].

In chapter 1, I discussed some of the methods for modelling the political factors likely to influence design and the process of identifying major stockholders. How you design, in the sense of what you say to others and how you fit your understanding into your design, what you remain quiet about, and finally, the ethical question, the point at which you withdraw from the project and forego the fee, are personal design issues which it is probably not proper to delve into further[19].

Design problem 6: the Uneven problem

This design issue deals with a phenomenon quite well understood in general systems theory - that a disturbance in one part of a system will simply redistribute "bottleneck" characteristics to another point in the system. Building new roads cheapens the cost of making a journey and therefore encourages travel, thereby encouraging greater traffic jams.

Design problem 7: the Abstraction problem

The reader of this chapter will by now recognise this design issue. It is the defining of a problem at the wrong level of abstraction, thus rendering it intractable to the user. The old general systems joke of knowing nothing about everything or everything about nothing are the bounds of the problem. Much of this chapter might be at too abstract a level for engineers not accustomed to discussions of this nature and at too trivial a level for those who have studied any scientific method at all. Producing data flow diagrams or entity relationships with only three primitives or diagrams which look like a Clapham junction signal box would be other examples. To get the level of description, of detail and of generality right, both for the purpose of analysis and explication is a design problem.

Some tricks of the trade

Having outlined a section on design questions, we are not entirely without some guidelines on how they might be tackled. These guidelines are not in any order, but might be useful in modelling outline solutions, for the trouble with design problems is that they have to be solved, not in a kludged way, but in a way which is elegant, economic and functional.

In each case these models are only metaphors, guides to thinking about a topic. If you can fit a problem into a model it might make it easier to grasp. I'm deliberately not considering here formally developed methods, for they are not about solving design problems, they are about engineering solutions once the design issues have been sorted out.[20]

First comes a simple matrix of subjective and objective against specific and complex. See diag 3, Can the problem you are attempting to solve be described as subjective and general, for example how you might price the value of higher education or the service of the National Health, or is it specific and objective - how much money is there in my bank account today. The process of designing an information system is to shift a problem from the subjective and general towards the specific and objective.

There are of course "laws" about the "objective" - "If something can be measured then that is what will be". Because machines can measure the amount of data transmitted, the traffic becomes what is measured, even if that is not a worthwhile unit of measurement.

Or "There is an inverse relation between the certainty of the information and the triviality of the decisions based upon it".

Another model was developed by George Rzevski and Mike Wing[21], the fuzzy complex model (see diag 4). This requires modelling the information problem on an axis of fuzziness - uncertainty about meaning, and complexity, either on scale or quantity over time. A problem might be very complex but quite straight forward, or very fuzzy, but quite simple. Their argument is that problems in the bottom right corner are amenable to transaction processing solutions, in the top left not amenable to automated processing at all, and around the centre to artificial intelligence. I would suggest that the process of design is to move the fuzzy and complex to the clear and simple.

Another is the use of metaphor for defining a problem. I discussed metaphor in chapter two, but want to indicate here how it might help designers to understand their problems and potential users to see how the complexity of information and technology approaches the solution of problems by explanation in terms of other experiences which the user already knows.

A simple example is the metaphor of the desktop, produced at Alto Parc, exhibited on the Lisa in 1982 and marketed by Apple on the Macintosh since, initially an alternative to the command line, but increasingly through Xopen and Xwindows, an emerging standard for all human access to computers. The metaphor is simple - imagine your computer terminal screen to be like a desktop. There is a rubbish bin (or trashcan just to show standards and internationalism doesn't get too far.) There are filing cabinets, folders and documents. You can take out a pocket calculator, put a clock on the desk, open a file, take out a document, all in terms that any office worker could understand. It is now hard to imagine the enthusiasm or excitement which must have accompanied the process of first grasping the metaphor and then discussing how it might be implemented. It is a pity we cannot relive the discovery.

I remember hearing the man who invented the idea of the word processor describing how he separated the striking of the key from the impact on the sheet of paper. Now obvious, but to think of it for the first time!

What will be the next metaphor. Negraponte, Director of the MIT Media lab has suggested the metaphor of a theatre with actors and stage settings[22] as the next great breakthrough. This seems to me already too complicated, to be attempting to repeat the success of the desktop but by repeating it just at a higher level of imagination. I think rather that it is a matter of thinking about metaphors of metaphors. That one which explains an idea will jump to be the explanation of that idea. This is the trouble with linear descriptive spoken language. The metaphor takes so long to explain that by the time it is explained the reason for introducing it has been forgotten. That it is advantage of the cartoon - the idea is immediate and non- linear. This is the advantage of multimedia. It will free us from the detail of explanation.

The metaphor which has been widely accepted is that of architecture (vide my chapter four). Information architecture's or systems architecture's are widely talked about. But this is an attempt to talk about the work an information system designer does in language that others will understand, (while inflating the activity - no one calls himself an information brickie!)

Yet the concept of a project stacking up, of requirements specification, of budget, of project management all fit, while there is an attraction to the idea of design. Three problems follow - there is none of the history or tradition of the aesthetic of architectural design, no concept of the Frank Lloyd Wright, of the economy, effectiveness and elegance or the form follows function; there is not yet a recognition that it is not the individual project but the urban shape which is significant; and not yet the tradition of the consequences of failure to comply. The law translated from Hamurabi's pillar reads "if the house falls down and kills the son of the house, then the son of the builder shall be killed." I'm prepared to accept that doesn't happen to enough architects, but the metaphor hasn't stretched to information systems designers.

*Can I put stuff on classification here? Why not?body, leg, etc.? Perhaps the simplest starting point is with the elements of classification. If the system can be modelled in the form of objects as I indicate in chapter 2 such that the inheritance of every higher level object is clear, and all objects about which anything is known is modelled, with metrics as an integral protocol to the object, then the model may be costed against the budget.

I would like to tackle this issue by suggesting that what we need are a set of design decision points in which decisions are neither in and of themselves right or wrong, they are simply that: "design decisions". They are arguable, their consistency is debatable, they are unlikely to be refutable or irrefutable in the future as the environment will have changed, that are not open to empirical examination as they change the environment by the very process of being taken.

The relation between the business case and the proof problem

I'd like to suggest therefore that the information architecture which I discussed in chapter four in terms of software types to be processed on machines now needs elaboration.

The process of conducting a business analysis in order to specify the goals of the organisation referred to in chapter one, defines a set of operations which need to be performed. Whichever of the techniques used, a form of business systems analysis to understand what the organisation should be doing, or a structured systems analysis to determine what it is doing, with or without CASE tools is needed (chapter four section n*?) (*further note - do I need to make continual cross reference to where connecting parts are discussed or should I make more use of maps?) Forms of top down or bottom up or middle out, operational, tactical or strategic? All of these will define data sets, events and processes in which information has operations performed upon it, some in a formal and structured way, some in an informal and unstructured way.

Part of the analysis is of the internal operations of the organisation which defines the datasets on the basis of which the operations are performed, some require external data sets against which measurement will occur. There is in some sense a very simple model for describing this *diag ch5,2 - us, them, market. But the definition of what is needed is clear. Whether the information may be made available in a form required is a question I'll return to.[23].

[Primitives]

But this exercise however conducted provides us with a set of primitives which are the first set of design decisions we are taking.

[Definition of entities]

By a primitive, I mean the definition of a data item, an entity, which is proper for that analysis in that situation. It has no ontological property of primitiveness apart from being right. Let us take an obvious example: staff. People are part of every organisation, therefore some sort of payroll system which involves staff is going to be a component of almost every system. Now the entity staff will probably have an attribute name. So names might be primitives. But the names are composed of letters of the alphabet, which have different filing orders according to whether you use AACR2, ASCII or the order preferred by British Telecom for the telephone directory. What comprises a surname or family name also has a wide variety of conventions. But letters of the alphabet are axiomatic so those must be primitives? Not necessarily, if handling an OCR engine what actually comprises the shape of a letter A might be extremely arguable so the primitive might actually be the dots on the page. In chapter two I discussed these points in some detail.

This takes us to the scale problem and the boundary problem I described earlier. What is to be a primitive for staff moving up the scale might not be people as individuals with names, but headcount, staff per department, or staff budget mapped to wages over the organisation, to total staff expenditure. So the definition of the primitive, the entity, is a design question which is the consequence of the exercise of analysis which is the consequence of the definition of the problem or the information deficiency which the organisation is tackling.

Whether the primitive defined is part of the system or outside the system, the boundary problem, is in turn part of the business argument and not simply a data flow or software construction project management issue. The process of defining the business goal to handle the shifting of bargaining power between buyer and supplier which I outlined in chapter one would create shifts in the boundary which would create new primitives.

If these primitives are captured in the data dictionary so that the whereabouts of the datasets and the necessary and sufficient meta information is available, then the system becomes a more tactical and possibly more strategic one. To this I'll return later. But to emphasise: a primitive is a design decision. That a primitive is a primitive is axiomatic. It has no proof other than that design decision.

[Protocols]

The process of defining a primitive leads us to the second level of design decision, that of protocols. Protocols were also discussed in chapter two, but now going beyond the protocol which defines alphabetical order, or the form of the date of the month[24], I want to make the point that it is by protocol that staff are paid monthly, or on the last Thursday of the month, by protocol that settlements on the Stock market are made the way they are (until Taurus!), or bank accounts or airline tickets, or bills of lading, or invoices, or any other function of the environment.

I want to emphasise the protocolity of the operation in order to return to the proof problem. It is not by any law of nature or science that these things as are they are, though it might from time to time be by law of man. Which means that if staff do not understand the conventionality of the decisions they will render unchangeable that which might well be changed[25].

The data dictionary therefore needs to capture not just the protocol, but the convention which populated it with authority. The advantage of the data dictionary is that it might be populated with meaning by a larger population than the one office or the one designer, but that takes us back to the boundary problem.

[Rules]

More rigorous than a protocol is a rule. In many circumstances a rule is simply a protocol, but rather than the convention of convenience, it must have some authority which gives it a greater significance or legitimacy. The rules of grammar are simply protocols, but changing beyond the poetic makes for mutual incomprehension. The rules of the highway code are simply rules, drive on the left, drive on the right, but they are still conventions.

But the point remains that the rule has to exist for a reason and it has to be opaque. It needs to be defined in the data dictionary for the rules are what determines the functioning of the state transitions of the information system. To recognise the proof protocol for their legitimacy or their existence, to recognise that which might be changed and that which might not is part of the questioning which the design process involves.

[Models]

At the level above the rules are the models which populate the rules with meaning. Rules make sense only because they function in a model. That model might be the harmonious family so you make a rule about all having a meal together or not talking with your mouth full or using the spoon the funny way round when eating soup, but the model might also be the performance of the organisation in the market or the shift of the price of the dollar against sterling, or the movement of vehicles through a one way system.

The construction of models is not my concern here, simply to recognise them in the data dictionary in terms of the primitives which populate them with information and the protocols and rules which populate them with meaning. But the design issue I wish to elaborate is again the design decisions which are involved in their construction and formulation: in other words the proof problem.

In what sense is the model true or real? In what sense is it right? When there are many ways of seeing the world and many ways of doing business, the model is a convention in some paradigms, but as certainly a part of reality as any.

Let us elaborate a few simple models to see the way the design decisions influence us. Imagine one metal pendulum swinging above a magnet. No matter its initial condition, the stable condition, all other factors being equal, is determinable: it will be suspended directly above the magnet.

Now imagine two magnets. Depending on whether the initial condition of perturbation is orthogonal to or on the long axis of the two magnets, although the pendulum will behave unpredictably, its rest condition, presuming the strength of the magnets is equal, will be equidistant from the magnets. And presuming I have defined the necessary and sufficient conditions.

But imagine three magnets placed as an equilateral triangle. What now will be the behaviour? Completely unpredictable within that micro-system, though if I placed a nib on the bottom of the pendulum, and placed the pendulum in a hemispherical cup such that it always touched the paper, after many cycles there would be a regular pattern. In other words at a higher boundary level, or at a higher level of abstraction, the system returns to predictability.

So too if what the model is modelling is the relation between exchange rate, interest rate and inflation rate.[26]. I'll return in chapter six to some of the information management problems of modelling.

So our model cannot in the business world be in any sense true. It cannot be empirically verifiable, for we cannot know whether the construction of the model was the process whereby the reality was changed such that it ceased to be true, or whether some factor which was not a component of the model should have been. Necessary and sufficient conditionality are design issues, not proofs.

How models are captured and manipulated in machine form too I'll return to.

The range above models is the range of principles. These are much stronger, they are not a matter of convenience. They guide the organisation such that changing them is changing the organisation. They define the business in which you are. It is possible that their proof is the consequence of continually testing a model, such that they operationally become true. It might be that breaking them will have consequences of strategic significance to the organisation. But which principles you hold to be relevant and the authority you give them is again a design decision. They cannot be proven to be more true than the convention they are given.

Above a principle is a theory. A theory is a set of principles and models such that those who hold it consider it to explain the world more effectively than countervailing theories. The theory contains within itself the proof protocols by which it is legitimated. It cannot be proven or refuted from without itself.[27]

It seems that information systems designers become somewhat coy when trying to make their auspices apparent. There is a reluctance to talk of the legitimacy of the paradigms in which operations occur. The Mumford[28] debate and the Checkland[29] debate on the nature of systems is a contribution. Certainly the debate between Olle and Nijssen[30] was paradigmatic, but neither camp seems to me to make explicit the nature of the epistemological argument. Given the general recognition of the problem of delivering systems on time, on budget and which do what the customer wants and what the designer said, this seems strange I will be arguing in chapter eight what I consider the issues. (*see that I do)

Above the theory lies the law. There are two meanings here. There are the scientific laws, which we have to accept must constrain our systems design unless we wish to engage in a paradigm overthrow of epochal dimensions. There are the human laws, obedience to which is in turn a design issue. But they act like axioms. It is not possible to decide whether to comply or not as a design decision within the system, only by moving outside it. Their proof criteria stand within themselves, within their existence.

This section then has attempted to deal with the range of design decisions which by identifying the data items and the operations which might be performed on them encompasses and tried to emphasise that they are just that: design decisions, not immutable truths.

The range of an information system

What then is the range of components of an information system. Most of the literature uses the term system or information system to talk generally either about a piece of software, or a piece of technology, or a set of data being processed in a particular way. I've already defended the significance I've given to the technology in chapter four, while spending chapters two and three discussing the nature of information as an historic and social phenomenon.

I'd like to suggest that an information system has eight parts, which might be imagined as a wheel or cake. See diag 1. (*insert ch5diag1 here.) The significance of this is that it gives equal weight to the organisation, the person, the decisions, the actions, the models, the information, the software and the hardware.

The hardware is clearly the technology architecture, referred to in chapter four, priced, amortised, performing at defined speeds, performing without fail, or with the failure rate written into the requirement specification and as such a part of the design process. It is the part which used to be most laboured over in the writing of the specification document, the tender, the contract, which was once a capital item of gargantuan proportions, but which will currently deliver (*put in chart here showing relation between staff wages and 3M or in CH 4?)

The software is currently the point of greatest angst in the information technology industry. That is where the heat of CASE, of software engineering, of industry concern is to be found.[31]

It is the information which I have chosen to emphasise for that seems to me to be the area which needs most elaboration. This is partly because the bulk of people now involved in information systems design might come from a background where the world of the database and of computing is paramount. They do not yet seen that text, and probably images, video, sound, will become as important.

Decision, models and action are not yet seen as being part of the information system. To make that argument is partly the role of this book. I am arguing that the only process of design is to recognise that within an organisation attempting to reach a goal, information deficiencies are identified, as a result of which information systems are designed in order to rectify those deficiencies. The way in which it is possible to know that there is a deficiency is because of the incapacity to take decisions. The incapacity to take a decision is manifested by the inability to undertake actions, or to be uncertain of the probability of a proposed action. Thus the information system reduces the uncertainty or makes explicit the risks of engaging in a range of actions. To remove the actions and the decisions upon which they are consequent from the system is to remove the basis for being able to design what is and what is not part of the system. But actions and decisions don't exist in a vacuum if they are to be seen as part of a system, therefore the models which populate them with meaning must in turn be part of the system.

The people in the organisation are less a problem as part of the system for writers in the information systems rather than in the software engineering tradition. There is much on HCI, soft systems, user needs, end user computing and so forth. But the human bit tends to stand separately from the real engineering bit, either tacked in here and there, or in separate works entirely. The so called split between the warm and cuddlies and the cold and crunchies can be synthesised, I would argue, only if the actions, decisions, frame is placed within the system. It is the people, making decisions and taking actions which provide the existence of the organisation.

This means that the organisational form and its appropriateness to the goals of the organisation might legitimately be argued to be part of the information system. While recognising both the internal political issue of tails wagging dogs and the epistemological problem of ending up with a classification scheme which includes everything in one category, it will be an argument of this work that the relationship of information and technology which I am calling an information system will in fact call into question the organisational forms and conceivably necessitate changes. This is part of the design. If those changes cannot be delivered as a consequence of lack of political will or political power then that is either a design question, residing in the power component of the design problems I referred to earlier or a system failure.[32]

Processors, communication and storage

In chapter 4 I followed a conventional division of the technology but in the process distorted the relationship that exists among them. It is the combination of the changes in technology which gives a balance and a design to the technology architecture so that processors, storage media and communication devices have to be planned like the legs of a three legged stool. To develop any one out of balance is to tip the stool over.

What then are the factors which must influence this process?

[geographic spread]

I've already identified the problem of defining the "users" of a system - the client, the skilled workers actually handling the terminals, all possible customers, all consumers, all citizens. Their skill levels, their access to technology and their access to communication routes - in other words the geographic spread of the system therefore becomes a significant design issue. No major system has really broken into the mass domestic consumer market yet, so the terminal in the home, the hope of the combination of the telephone and the television set hasn't happened. (Though the French government has invested heavily in the Mintel system.).

Banking is probably the most widely available geographic system with ATMs widely distributed and often used to establish a new network where the physical branch infrastructure doesn't exist. Still occupying national patches predominantly, the European experience of integrating networks so that magnetic stripe cards are usable in a wide range of machines indicates that a range of agglomerations of banks is likely in the run up to 1992. American Express has shown how it can function as a bank outside the US simply on the basis of the card, and Marks & Spencer's has shown how the loyalty card can be converted into a financial instrument potentially sharpening the danger for banks.

The banking SWIFT system is world wide, involving communications into every country in the world and the electronic transfer of information across the globe. However to the extent that it survives, it will be a collaborative process from which the competitive shakeout for the various players has not yet occurred. I think I want to distinguish between design and stumbling through. SWIFT 2 doesn't appear to have appeared.[33]

Airlines and the computerised ticket reservation systems provide another example of a world wide network with widely distributed users and a range of skill levels. The competitive advantage of tying travel agents into the relationship is well documented, as is the role of different geographic spreads of markets in giving competitive advantage.[34]

So geographic spread is the first design issue which involves predominantly the boundary problem and the scale problem.

[temporal logic]

The second broad area is what I'll call temporal logic - the role of time in the design process. What rate is information changing over what time frame? From chapter four the capacities of the different technologies will have been clear. It is then possible to build a matrix of data capture, storage, retrieval, processing and communication, against quantity, rate of change, speed of change, number of transaction, and model appropriate architecture's. High change at fast speed probably rules out CD-ROM. Absence of functioning telecommunications rules out on-line.

The timing measurement has to include the speed of writing a record, the speed of retrieving one record, specifically and sequentially, the speed of changing a record, and records here don't just mean relational database management systems type records, but the widest range of data definition types I gave earlier.

Security, I want to argue, is a design matter. What I mean by this is shown by the banking ATMs I referred to earlier. They are as secure as an unstolen cash card. But the loss engendered by one lost card is low in comparison with the number of transactions, and the availability of the mass market was a precondition for success, so a relatively open system at the level of the external access to the ATM was decided upon. Inside the system though, there are risks of high loss through corruption which lead to high levels of encryption and security. So design decisions are taken at two levels[35].

Progress in smart cards relative to their cost would be an example of how the technical would possibly change the design formula. Shifting the cost of insurance onto the user would be an example of bargaining power (do I need to give lots of these examples or is everything fairly clear?)

Legality is the issue of the provability of the transaction over what time period. Title to ownership of land has to be proven to be true over a very long period of time. Trades on automated stock markets might require the proof that the best trade was made at a particular moment in time. Attendance at a course, receiving a degree, all these require long time frames and high levels of proof. This means the keeping goal of the data has to be high. Paper has historically been the most reliable medium for this. But paper from the middle of the nineteenth century is acidic and degrades quickly. It is bulky, it requires storage devices to protect it from fire and damp. Special standards have had to be developed for paper which is to last. Microfilm is disintegrating, but it doesn't take as much space, magnetic tape requires special storage conditions, optical disks have not been around long enough to know how they will handle time. The proof of electronic documents is not yet established in law, where paper is.

(is this the place to put this or is it better in chapter four? The point remains that these choices are design questions)

Compatibility is a design question. To what extent is it necessary? Islands of automation are attacked, but if the cost of ensuring compatibility is higher than the process justifies then is it worth it? Particularly as data is in all sorts of media across organisations, there might be no argument for retrospective conversion.

Standards too is a design question. Rather than being a general good, which standards you comply with is a consequence of the cost of compliance versus the cost of non- compliance, and whether there is a market opportunity for non- compliance. There is also the question of deciding on the standards and the level they have which become part of the market definition. To the issue of standards I'll return in chapter 8.

The issue of pricing, charging, costing and funding, and the function of internal and external markets I'll come to in chapter six, but clearly the regimens determining the functioning of these markets are design decisions involving the boundary, scale and the power design issues.

Notes

[1]Jones op cit. p 22

[2]Jones, J.Christopher. Design methods: seeds of human futures. New York: John Wiley, 1980.

[3]Alexander, Christopher. The determinants of components for an Indian village in Conference on design methods. Oxford: Pergamon Press, 1963

[4]Asimow, M. Introduction to design. New York: Prentice Hall, 1962.

[5]Fielden, G.B.R. Engineering design, London: HMSO, 1963.

[6]Technology 5 - 16 in the national curriculum. A report to the Secretary of State for Education and Science on the statutory consultation for attainment targets and programmes of study in technology. York: National Curriculum Council, 1989.

[7,8,9] The words for expressing this distinction are taken from Daniel Dennett's comments in When philosophers encounter artificial intelligence, in Graubard, Stephen R. Ed The artificial intelligence debate. Ca,Mass: MIT Press, 1988 p285-6.

[10]Kling, R. Defining the boundaries of computing across complex organisations. In Boland, R. and Hirschheim, R. (Eds). Critical Issues in Information Systems Research, 1987. Wiley, New York.

[11]Kearney report, Kobler unit report. Hochstrasser, B. and Griffiths, C. Regaining Control of IT Investment - A Handbook for Senior UK Management. (1990). Kosler Unit.

[12]This is not the place to discuss in detail group theory. For a discussion of the management issues see**. There is less in the literature however on the design issues *is this true?

[13]Someone must have discussed this sort of thing?

[14]See for example the strategic study done for British Rail in *get citation. Long Range Planning. In the notes on design workshops I'll suggest how the M25 case study in chapter 1 and this text might be linked.

[15]as for example Cliff, T. did in State Capitalism I Russia. 1948 (get *citation)

[16]same paper as elsewhere

[17]As outlined in Young, Michael. Knowledge and Control. Milton Keynes: Open University, 19? and in particular in Jeff Esland's paper, the significance for education and systems design becomes clear.

[18]This topic is little discussed in the literature. The clearest discussions are a couple of case studies in O'Brien, Rita Cruise. Information, economics and power. London: Hodder & Stoughton, 1983*, in particular that of *get citation. The naiveté of writers on this topic might be more clearly cited, for example Herbert Simon's reference to the state as a "big raisin" in his Science of the artificial *get citation or the bliss ignorance of Major-General G.R.Oehlers in his Information technology and defence decision- making (in good company with the other contributors) in Plant, Raymond et al eds Information technology: the public issues (Fulbright Papers v.5). Manchester: MUP, 1988. Marcus' case study also, (see Chapter 1) Willcocks and Marks case study.

[19]If in the teaching environment it is felt wise to pursue this further you might look at a quite a well known experiment conducted in the US in which students were under the impression they were administering punishment to subjects *get citation. The limits of tolerance of systems designers might be explored by modelling the extermination systems of concentration camps or discussing information retrieval requirements for the British Army in Northern Ireland.

[20]The borderline is probably Checkland's soft systems method or CATWOE and the PEST- SWOT discussed in chapter 1. SSADM, described thoroughly in * and Goodland (get citation) seems to me to duck all the issues I'm discussing here or in chapter 1. JMA claim that IEF handles these sorts of questions but I dispute that. SSADM - Application and Context. Downs, E. et al. Prentice-Hall. 1988, Hemel Hempstead.

[21]get citation.

[22]described at a lecture at Imperial College. See Stuart Bland's The Media Lab * get citation, for a description to the work of this research institution.

[23]see Channon, Derek *See Chapter 1 net. 22 for citation for a detailed discussion of the information requirements of competitor analysis. There is much less discussion in the literature of how these are implemented in practice. I'll discuss this, executive information systems and decision support in chapter 6* - check I have

[24]without delving into technical detail it is worth thinking for a moment on something as simple as the complexity of the date form. That we are saddled with a combination of assyrian and roman dates which the French Revolution didn't have the courage to disperse, so that bases 60, 24, 7, and combinations of 28, 29, 30 and 31 all function gives a nice elaboration to information processing. That the standard for US date definition and British (sometimes European) and all sorts of lovely other ones such as Hebrew or Muslim is so varied makes the world a richer place. And there are times when the day of the month is more useful than the month then the day. Which means the building of objects such that date based operations may become more sophisticated will be a point to which I'll return.

[25]It has long struck me as strange that when the price of money is as high as it is, companies pay all the staff on one day of the month rather than staggering it. While I might or might not prefer to be paid monthly, annually, daily or weekly, and would need to think about it, I certainly don't need to be paid on the last Thursday of the month. For one thousand people all to be paid on that day probably stems from the days of payment in sovereigns, or from batch processing payroll systems, but I can imagine treasurers preferring a more gentle cash flow.

[26]It is worth examining Christopher Alexander's essay I referred to earlier, not in that it deals with information systems at all, but that he tried to model an Indian village in terms of its spatial dynamics. He soon identified 600 variables: in other words the simple becomes so quickly so complex that nothing may be gained form it.

[27]There is a substantial debate in epistemology on the proposition founded by Popper on the legitimacy of a theory, and the refutation of Kuhn who argues that theories are much more social things. See his The Structure of scientific revolutions, 2nd edition University of Chicago press, Chicago, and Young, Michael, ed. Knowledge and control. Milton Keynes: Open University, 19* if you'd like to pursue this argument.

[28]see Mumford, Enid *get citation Fitzgerald, G. Hirschheim, R.A. Mumford, E & Wood Harper, A.T. Information Systems Record methodology : An Introduction to the defate In Research Methods in Information Systems. (Ed. Mumford, E. et al.) 1985. Elsevier Science Puslirlere.

[29]see Checkland Peter, Systems thinking, systems practice. Chichester: John Wiley, 1981, though I have substantial disagreements with his epistemology and method. see chapter eight.

[30]for those interested in the lacunae of information systems design, this was the work of IFIP WG 8.1 which resulted in a book, Olle et al, *get citation, and an alternative by Nijssen *ditto. At the guts of it, the argue is about design versus mathematical truth so not distant from the topics of this book. Olle, T.W. Sol, H.G. and Tully, C.J. (Eds). (1983). Info Systems design methodologies. IFIP WG8.1. York, 5-7 July 1983. Amsterdam: North Holland.

[31]don't know if this needs elaborating. see for example the BCS IEEE software engineering study * get citation.

[32]A variety of recent books have made this point in a variety of ways. See for example Peters, Tom. Thriving on chaos. *get citation. Symnot, William. The information weapon ditto. Much of the detail of information management will revolve around organisational form, but I know of few case studies so far in which the design of the information system specified a change in organisational form such that the IS was determinant. There have been of course many organisations which have now appointed board level directors of information systems or chief information officers (CEOs). The role of consultancies, particularly from an accountancy background deserves study. *does anyone know of any?

[33]design question here about the book - the extent to which I just make passing references here, what I wrote up as case studies in chapter seven and what I refer to as issues in chapter eight. Also the question of giving design exercises at the end of every chapter. Also the question of the extent to which these sorts of examples have to be properly cited. Also the issue of the extent to which I should provide a guide to the [[section]] information, for example Post News on charge cards and smart cards

[34]as too is the result of a US Department of Transportation investigation and a House of Commons Select Committee. See Adams, Ralph *get citation. Journal of Information Scientists for an interesting study.

[35]there isn't scope here for a full discussion of security. See Shain, Michael* get citation.

Copyright1999–2007: John Lindsay Impressum—Imprint