oturn home > Information Systems – Fundamentals and Issues: overview > Ch. 6: Information Management

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

Chapter 6: Information Management

Let us return briefly to the protozoonan slime. Or imagine yourself sitting quietly on a a twig, munching on a leaf, surveying all around you, when "zap" a toungue slurps you up!

The imagination and fear behind instability, of eat and be eaten, the survivial of the fittest all these metaphors have been with us for much time. The idea of having a secure job, of a wage coming in, of a mortgage, of a salary at the end of the month, of doing a certain activity on a Monday morning and on a Sunday night are quite rare.

The idea of the "cambrian revoluton", when in geological or astronomic time, from a limited range of life sources, "tens of millions" of species suddenly developed in "tens of millions" of years ( an explosion of compexity).

The idea of 4 billion people being born, living and dying, feeding themselves without sitting on a twig and being eaten; yet with the prospect of the police coming through the door, with the random change of the Guildford four, these are the games of today which the modern information systems designer has to face. Make up a model of your life - model your job security - your chance of still having a wage in one day's time, one month, one year, ten years? Yet you are trying to build systems with that sort of time frame in them.

What then are the general propositions of information management on which we might draw?

The concept of the project might be a useful starting point. There is a vast literature on project management. A project is a general relation between reources and goals. Who defines the resources and the goals is the boundary and the scale set in a fell swoop (as well as the power and probably the proof!)

The definition of the goal is the definition of the units of measurement by which its attainment will be realised. Some projects are simple: make a cup of coffee![1]. The goal is simple: a cup of coffee. The resources are simple: time, coffee, water, heat. (But this is simple in London when the water has been paid for and the power is available.) If the problem requries the level of the productivity of labour common in much of hte world then it turns into a taks involving such levels of human exertion that it will not occur.

The put only enough water in the kettle as you will need (silly boiling more than you want it wastes energy [ though you might want to do something elese at the same time thus doubling up on the heating of the water { a degree of complexity we'll leave out in order to progress the tale}]). Put the kettle on first, because you know it takes the longest and you can do other things at the same time (the glories of GANTT and PERT in one swoop!). Take down the coffee beans ("eh what" I hear a voice at the back proclaim "What's them?"). Well there is no point in using coffee power for you still have to wait for the water to boil so let us proceed.

Take down the coffee grinder, put in enough coffee, wash a coffee cup and saucer (come on, we're doing this properly: it is a design exercise!). Grind the coffee. (This takes about ten seconds thanks to the developments in the forces of production which now cost about [[sterling]]8, but save hours of grinding manually - perhaps a whole earther will object to this using of trivial consumer objects, but I said management was about design).

Take down the funnel thingy that doesn't have a name, and a filter paper. (Oh yes there is the Gucci expresso maker than james Bond uses, but I said this was about design!). Place the filer paper in the funnel, place over the cup, and at this time the water will have boiled. (Almost to the second, I've trialled this for years.) (In fact I've gone further and turned on the grill before putting on the water, put the croissants into the oven, then forgotten about them, had the oven at the wrong temperature, mucked up making the coffee while rescuing the burning croissant packet from the grill [but if you don't wrap them in paper then tops burn!]) In other words moments emerge when the combination of goals and resourcees becomes too complex for the span of control of the manager, and which point you take the design decision of partitioning the problem. The consequence is that the first cup of coffee is drunk before the croissants are ready. This is either a triumph or a defeat for your elegance as a designer, or you rationalise it away and slowly it becomes the way you really wanted things anyhow.

Note also that this is a solitary operation for the self indulgent pleasure of one person. If performed for two people then complexity of how conversation, last night's hangover, was it all worth while, is it all worth while and so forth all impinge on the model such that it is no onger possible to describe. There is an explostion of complexity that would require a novel for every moment. Thus the point I made about the scale problem (ch 4 pn 2).

For more than two and making a cup of coffee becomes as complex a management exercise as any: cups, water, boiling, timing, quantities, serving order - engineering complexity more than social complexity. So for one person it is modellable, for two people it is predominantly a social activity, as the number increases it becomes engineering and the social diminishes.

Note also that the scale was itself bounded. The process of filling the kettle could have been elaborated beyond the boundaries of your patience by describing turning on the tap, taking the top off the kettle, or grasping the kettle by moving your fingers in a certain way. In other words the complete information to describe any event is never present. It is our intelligence which enables us to span gaps. But our "common sense" only in a world of relative certainty. If the washer suddenly gives, then a critical success factor has been invoked: no water; if you suffer rheumatism or MS then the operation of filling the kettle might turn into a task of organisational complexity or require assistance that you cannot do it on your own.

You could run through the same scale of description (if blessed with considerable patience) on a range of other problems, but jump to one which has substance inyou might - cleaning up the environment, pollution, starvation in the third world, nuclear war in the Gulf. This becomes a problem about which the scope paralyses you. If you think of goals you don't have the resources to do anything about them so you take the bottles to the bottle bank in order to maintain stability in your world.

In other words we have mechanisms built in so that we make the goals and the resources meet and proper unto themselves. This process is so much a part of our daily experience that we seldom think about it, nor would we generally call it management or design. Yet this process of scaling and bounding is one we do continually.

However the world of "work" is different from the world of the "private life"! It produces the resources to enable the enjoying of the coffee, but in return, for most of us, produces the alienation, the loss of self, which is a consequence of selling our power to labour to another, surrendering our freedom to the arbitrary [2]

While even in the family there is a degree of negotiation in the relationship between self and others, in the workplace it is all much more complex. The three types of organisation I described in chapter four might be enough to steer us through this chapter, however should that model be insufficiently complex then build a more elaborate one. The only important point is that the goals and resources to the project at hand are now not yours to define, and in the process of defining them someone else "the manager" might act in such a way as to threaten your "life enhancing opportunties", while your failure to perform threatens his. The closer the organisation is to the bottom line, the greater the tension and pressure is. In workplaces where redundancies are common, where there is none of the job security of the white collar worker inthe public sector, other devices are built up to minimise uncertainty, but it would be taking us too far from our thread to follow those. All that is to be said that the project must fit into a duopoly of possible and probable. Whether you think the project is doable will determine your opinion. The consequence of your opinion is whether you will perform. How you relate collectively with the people around you will determine whether you think it is doable. In other words the subjective and the objective are synthesised in the form of political organisation of which you are part.

So your intersubjectivity becomes the process of formation of the possible. The process of planning forms the process of doing, and doing informs planning. This division in our minds into duopolies - subjective - objective; plan - do; possible - probable; uncertain - certain[3] is a characteristic of our current way of thinking and provides an opportunity for mind exercises to adjust project management methods (an invocation of the abstrsaction problem from chapter 5 - if any general principle is elaborated it becomes so trivial that it is no use to anyone or is self evident.)

There exist a number of techniques, which might be enhanced with the title methods, for enabling the management of more complex projects, such as PERT, GANTT, Risk analysis, and many of these have been written into software such that the primitives and protocols are encoded. Whether such an aid will be used in managing this general project is itself a design decision.[4]. Each method in turn grows a school to prove it right, show its weaknesses, elaborate the mathematics (all involving the proof problem. Much of the early work was in the construction industry and in process engineering, where the goals, measurables, deliverables were all failrly constant. Evidence of project management technqiues in information systems design have been less successful. They have concentrated on two areas: the budgeting/ tendering cycle, and the software engineer management issue.

The first founders on the shift in bargaining power between the company trying to get the contract who beforehand is the weaker power of the company gaving the contract (though as most contracts in US and Brtiain are public sector and most of those military related the philosophical propositions of the management handbook don't apply quite as the free marketeers would have us believe) and after winning the contract the balance of power has shifted and he becomes the more powerful player

.

The second founders on the inability to manage the productivity of white collar workers by the traditional methods of blue collar management (though some of us would argue that never worked in factories either.) The prusuit of software engineering is controlling the work process yet it is written up as mathematics. Ford meets Fortran![5] Yet every bar discussion always shows the complexity of the organisational form. Why then the endless pursuit of the chimera?

However this is not to say that projects are not managable or that problems do not get solved, or budgets do not get spent. But how they are managed owes little to the textbook.

However the problem needs now to be made more complicated. Projects very seldom start on green fields. Every project exists in an organisation, and grows with that organisation. This means that the people, buildings, spaces, equipment, procuedurs, methods, are all inplace already. The more the movement to "formal" methods or relatively formalised methdods, or house styles, the more[6] the process of training and inculcation, the more the "getting the method right become important over solving the problem.

The bulk of the information alredy exists in the organisation too. Some parts will be formalised into datasets - payroll but not the telephone directory. There will be an organisational chart, showing divisions and rooms and managers and managed, hierarchies and budgets and spans of control[7].

Yet evidence seems to indicate that organisations are in practice very poor at getting this corporate information management into place. If highly centralised, such as a military institution, then it becomes very slow to move and informal systems develope in the interstices; if decentralised then boundary disputes and dis-co-ordinations emerge. If distributed then new protocols must be established for what each of these primitives actually means. When does someone get a phone number?

Let me elaborate this further by looking at the X.500 protocol, not from a technical but an organisational point of view.

The X.500 is a set of standards and often demonstrate software implementations for the building of an object directory server. An object directory server is the idea that somehow or other you can build and store collections of metadata about the directories which in turn contain data about objects - the most obvious object is of course a person. The standards of the software of course is extremely simple in comparison with trying to build these into an information system. To start off with the most obvious attribute of a person is that a person has a name. But fairly predictably there is not only the difficulty of deciding what somebody's surname and somebody's first name, somebody's family name and somebody's given name might be, but people in turn have a variety of nicknames, people's surnames are spelt in a variety of ways and even with some sort of soundex or fuzzy matching algorithm, trying to be able to decide who somebody in particular is, is extremely difficult. Most people fairly predictably, have telephone numbers, the building of an organisation's telephone directory must be one of the most basic of all of an organisation's information requirements and yet investigating how this is done indicates that very infrequently can you say that it is as part of a structured information system. In addition, people not only have home telephone numbers, which means there is a break between the public life and the private life, but according to the structure of different organisations, people are prepared to give out or not to give out their home numbers, their work phone numbers are extensions, extensions of different exchanges which change as people move offices or move around in organisations. People will not only have a telephone number in terms of a phone on the desk but they are also likely to have fax numbers, probably or possibly mobile car phones, so the very concept of a telephone number itself becomes quite complex. To go a stage further than that and recognise that organisations are increasingly making use of electronic mail but the electronic mail is managed in the organisation from somewhere quite different from the telephone and therefore it is probable that you will find that the building of a directory, which involves the organisation's telephone structures and their computer structures, are so different that trying to produce a directory that links these together is extremely difficult. Thirdly, organisations have varying layers and depths of structure where you might simply expect to move from organisation to department and you would build a directory service agent and a directory user agent at each of these levels, in practice organisation structures are much too complicated. Another characteristic of the organisation is that people will have responsibilities to the organisational structure. A simple form is to say that some people manage and other people are managed by, some people function as secretaries, some people are serviced by, so the possibility of building an organisational structure relating everyone to that organisational structure and then mapping the telephone, the room number, possibly organisational responsibilities, specialities and then the building in of the project management responsibilities which change over time, show the possibilty for building an object directory server which links in with the component of organisational management, project management and the movement of people through organisations and across structures. So these two examples, starting from a project and moving up to the detail of project management and starting from a person and moving towards the complexity of the production of a telephone directory, indicate to us that once information is digitized and then can flow like a fluid through a system, being capable of being drawn off according to a variety of purposes, yet still remaining there for access by other people, provides us with a series of management issues which are far from trivial and which are by and large not resolvable in terms of software implementations, or in terms of technology. In other words these are social, human and management issues, not by and large technical or financial problems.

What then can we say about information management which is in some sense different from management in general? Or do we simply collapse the category and say that we are talking about management in general? One cant in any level of detail go into general theories of management, but it might be profitable to look at an organisation in terms of a set of standard forms and structures that it has and look at each of the managers in terms of the way that they are managing information. So it will now be fairly normal for an organisation of any size at all to have, for example, a personnel manager. The personnel manager will maintain a series of databases about the people in the organisation, and will be responsible, possibly for the operating of the payroll system. It seems therefore obvious that the personal data to fill the object directory server it most likely to come from the personnel department. However, experience seems to indicate that the personnel department is reluctant to recognise that the data it holds about people is in some sense or other actually a property of the organisation as a whole. It is possible that something like the Data Protection Act might be used as a defence mechanism to prevent access. If the personnel department is then operating payroll responsibility, it is clear that there is a relationship between the personnel department and the finance department. In most organisation the finance departments largest expenditure is payroll and so the management of the financial system means that at one level the same data is being drawn upon as that which is required by the personnel department. So without having to build a very complex model of an organisation, without having to go to anything specific at all, we have already been able to sketch out that there is a general layer of management information which is flowing across an organisation which is the responsibility of different owners or different agents where that data is shared amongst different departments and where to try and then talk about any individual manager being an owner of a particular set of data means that the matrix responsibilities that are built up are going to require a different structure from the way in which most organisations appear to be formed at the moment, and different from the way in which management are rewarded for performing particular duties. If we go a stage beyond simply managing information and say that our central concern is the attempt ot build information systems, then the design of an information system means that not only are we handling the managed information within the organisation but we are attempting to systemitise processes. Some of these systemitized processes will be already of long tradition in the organisation, the mechanism whereby a member of staff is appointed, the process whereby the primary data about new members of staff is recorded, that is in organisation which are generally fairly structured, but the processes are predominantly paper based and moving those into computerised information systems is going to mean a considerable change in an organisation.

We can then begin to say something general about information management as it intersects with the design of information systems. But the process of designing an information system is the process of dragging a problem or an opportunity from the general and uncertain into the certain and specific - see the diagram. This is a generic model for a problem which is as simple and as trivial as the input output feedback loop for the definition of any process. If we start off by a relatively unstructured and relatively uncertain and inspecific example of a problem, the process of designing an information system is the turning it into a specific and a certain process. In other words if you take the way in which a member of staff is appointed in the informal and unstructured way that it would happen in a relatively small organisation and then build a process in order to structure it, you can see fairly easily what that means in terms of the building of a computerised information system. As you model the information flows across an organisation you can see that wherever information about people is needed, the object person, you build up the attributes of the object person and the potential users of any of those attributes become partial owners, but that then takes you to the problem of the people who are going to have read access to that data and the people who are going to have write access to that data. So the building of the object directory server requires not only the entity attribute relationships but the building of the owner structures that are going to sit at the level of the metadata.

LONG GAP IN TAPE

If I suggested in the examination of information it means that the ontological properties of the information object are in turn going to specify the range of capacities of any particular organisation it means that in the information network product and service structure it is then the bargaining power of buyer and supplier which determines the capacity of a particular organisation to manage the nature of the information object. This can be seen in a fairly simple way, that the attributes of particular entities are physically, spacially and temporally located in a real world. And its the relationship between the information properties of these objects and the physical properties of these objects which determine their behaviour types. Fairly obviously, a newspaper has from the moment of its printing through its distribution to its retailing possibly at most a twelve hour cycle. A vegetable growing on a plant has a life cycle which is very much longer than the vegetable cut off the plant. So the bargaining power of buyer and supplier talked about as one of the strategic devices in Chapter 1 has now to be modified to recognise that the ontological properties of the object are going to be one of the characteristics that shift that bargaining power. One particular object is then clearly the market in the information itself. Another particular type of market is in the bargaining power amongst people and this relationship between the bargaining power amongst people in organisations and the information over which they have ownership is clearly the layer of complexity which the building of digitised computer based information systems is now introducing. The spacially and temporally fixed paper based information systems presented us with none of these opportunities. These technical changes are taking place in a period of recession in the world economy where the competitive pressures amongst organisations are much sharper than they otherwise would have been. The consequence of this is that the relationship amongst components of an organisation or the inter-industry relationships across the value chain means that the process of competition produces a set of contracts and tenders which are open for competition within the organisation and across organisation boundaries. These contracts or tenders in turn produce service level agreements which are in turn capable of being monitored and evaluated and then the process of negotiation, the implementation of service level agreement becomes part of the shift in bargaining power between buyer and supplier. The process of getting a contract is a process of being able to turn the numbers that the tender document require into the capacityto generate a profit out of the tender. Clearly although all processes are going to have a financial element built into them, because the only universal commodity signifier which allows for the setting of a service level and the monitoring of that service level against performance, means that the pricing, costing, charging, paying and funding for these services has to be disentangled. The operation of these processes is then going to vary enormously according to the type of organisation. Most of our experience so far is probably in large construction projects, and most of the practitioners are going to be those from the accounting professions means that if we are talking about information systems design, we've got to bring back the complexity of the information objects that we have been talking about so far. How do you then build the pricing, costing, charging, funding and paying structures into more complex information objects provides us with an interesting challenge.

Notes

[1]refer back to the British National Curriculum on how the most trivial and the most complex range the same set of tasks!

[2]get quote from the oxford bloke from THES

[3]presumably there is nothing original here - find who has referred to it - couple of quites or citations. maybe the ISTP conference 1990.

[4]see for example Harvard Total Project Manager, the manual of which is a very good introduction to project management, or Levine *get citation or a couple of others.

[5]Bravarman's remains the best discussion of the general work experience of the white colar worker *get citation.

[6]do I want to discuss a variety of the well developed house styles such as Hoskyns, the Arthurs? some detail here might be helpful just as I did methods for strategy in ch 1

.

[7]at least for the more permananet organisations - refer to my scale point in chapter 5 for how organisations grow revolutionarily from one scale to another.

Copyright1999–2007: John Lindsay Impressum—Imprint