Information Systems Design Issues

The word design seems to be one of those carpet bag expressions which at the basic level
simply means getting things right. Any principle of engineering seems to boil down for 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 summarized his ideas in Design Methods. 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:
•Finding the right physical components of a physical structure.
•Decision making, in the face of uncertainty, with high penalties for error.
•Engineering design is the use of scientific principles, technical information and imagination in
the definition of a mechanical structure, machine or system to perform pre specified functions
with the maximum economy and efficiency and so forth.
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. 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.

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 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 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 boundariesit for ourselves.
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. Kling and
Hirscheim make the point 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,
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.
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.

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

As now recognize 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 Clap ham 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.