engineering roles

Analyst

The analyst breaks things down into classes and categories, in order to understand them. For example, a data analyst breaks the world into objects (or entities), and then sorts them into categories (or entity types). Both acts are intelligent, in that they require judgement, and subjective, in that two analysts will always produce different results.

Indeed, it has been claimed that analysis is arbitrary. "A wit has said that one might divide mankind into officers, serving maids and chimney sweeps. To my mind this remark is not only witty but profound, and it would require a great speculative talent to devise a better classification. When a classification does not ideally exhaust its object, a haphazard classification is altogether preferable, because it sets imagination in motion."

But subjective and/or creative does not mean arbitrary. The value of analysis is that it provides a conceptual framework, which can be used for communication. If the analysis is obviously arbitrary, it will not aid communication.

The analyst is a spectator or observer. The business systems that have to be analyzed are plastic masses, sometimes not unlike a Baroque cathedral, where the spectator is forced to shift his position continuously in order to see the whole in constantly new aspects, as if it were in a state of perpetual transformation.

Architect

Princes in history prided themselves on their intellectual and cultural abilities and activities. Alas, the House of Windsor cannot compete with the Tudor, Medici or Mogul dynasties. All they can boast is two or three fashionable photographers, patronage of innumerable charities, and acquaintance with Sir Robert de Geldof. The Prince of Wales has however taken an interest in architecture. His pronouncements on particular design proposals (notably a projected extension to the National Gallery, which the Prince compared to a carbuncle) have received wide publicity. He has seen fit to comment on the methods of architecture as well as its styles, and has expressed a liking for ‘community architecture’.

The ‘community’ approach to design can be applied to information systems; the notion that systems should be designed by their users is widely accepted but little practised, perhaps because most IS professionals lack the techniques and skills for managing effective participation by non-professionals. (Possibly a small number of computer system users really are as stupid as the IS professionals believe them to be - but this is an unlikely and unsubstantiated hypothesis. See user.)

Let us look at architecture more closely. An architect designs buildings or clusters of buildings. (This is an simplification, but it is a suitable place to start.) The design depends on two things: technical feasibility (whether and under what conditions the building will fall down) and what the client wants (or is prepared to pay for). Prestige within the architectural profession may depend upon a third: æsthetic fashion.

Building buildings is a two-phase process: first design then construction. (These words are all ambiguous, applying both to the process and to the end-result.) The architect is responsible for the design, and may also be responsible (as project management) for the construction. The output from the design phase is of two kinds. A set of technical scale drawings and specifications is used to estimate costs and to plan the construction. A set of perspective drawings and/or 3D models is used to communicate to the client and other lay people, what the building will be like.

Sometimes the client for the design is not the same as the client for the construction. Sometimes the architect produces speculative designs, which may be offered to any suitable client. In any case, the architect must not only consider the expressed requirements of the client, but also the needs of the people that will use the building, either as permanent residents/staff or as occasional visitors.

Architects are becoming increasingly aware of the possibility - indeed in some complex situations the necessity - of postponing some design decisions until after construction. A recent example concerns the Rare Books Library at Newnham College, Cambridge. This was built without air-conditioning, its humidity was monitored for 14 months, and then a de-humidifier was added. The important point here is that this addition did not represent an oversight by the architects; the option to add an appropriate air-conditioning unit, after monitoring the behaviour of the building across all four seasons, had been written into the original contract and allowed for in the original design.

There are two approaches to designing a building. Some architects work outside-inwards, starting with the exterior and trying to fit the required rooms into the available space. Some work inside-outwards, starting with an arrangement of rooms, and trying to fit an elegant shell around it. It is usually possible for a knowledgeable critic to tell, from a completed building, what approach has been taken. (It is theoretically possible for two architects, following opposite approaches, to produce identical designs, but this outcome is extremely unlikely.)

"If there is one structure to which architect and engineer should agree to share a historical claim it is, most appropriately, the bridge."

Within Information Engineering, we make a distinction between an architect and a designer. An architect lays out the overall plan, and the designer works on one system or project within the plan or architecture. Arguably this distinction is merely one of scale.

Artesan

Also known as craftsman

Whereas most architects and designers create instructions (blueprints, models, prototypes are all acts of communication into a construction process), the artisan executes his/her own design. The blueprints or models may still exist, either to obtain agreement from the client, or to help the artisan visualize and improve the design, before using (and possibly wasting) any material. But these blueprints serve as sketches, rather than complete specifications.

With the design of IS, the so-called analyst programmer is an artisan. Someone who builds a spreadsheet for his/her own use is also an artisan, although we might hesitate to use the term unless the spreadsheet were exceptionally complex or elegant.

Another difference between IS and other crafts: the only material used up in the construction is time. Knowledge and skill is used, data may be used, but not used up; only time (elapsed time or resource time) can be wasted.

There are two ways of building things. One is an craftsmanlike, unselfconscious way, based on tradition and common sense. The other is a professional, selfconscious way, based on scientific and technical knowledge. To illustrate this, let us compare an igloo with a geodesic dome. The Eskimo builds an igloo the way his people have always built igloos. The form has evolved over many generations, and it is now a very good solution to the original design problem: how to make a tent out of snow. In contrast, the inventor of the geodesic dome, Buckminster Fuller, was an architect and engineer, who calculated the form and construction of his dome using formulas of applied mathematics. Although bearing a superficial resemblance to previous domes, Fuller’s structure was wholly new.

The Eskimo cannot afford the risk of deviating from tradition, or he may be buried under a mound of snow. It is impossible to be confident that a wholly new structure will be stable, without using the engineering knowledge that distinguishes the amateur from the professional. But it is impossible to arrive at wholly new structures by just following tradition.

Automator

Also known as tool-maker

Man is described as homo sapiens, homo ludens, homo faber. Man the knower, man the player, man the tool-maker.

Productivity is enhanced by tools. There are several kinds.

	Performance tools	Tools acting as levers or amplifiers, enabling a worker to handle more material with the same effort, and/or in the same time. Tools that can perform entire sub-tasks with a minimum of effort from a human worker.
	Communication tools	Tools involved in the coordination or instruction of workers.
	Control tools	Measuring tools, to improve accuracy and reliability. Tools that guide and monitor the worker, and help impose some form of discipline.

Computer technology itself is usually regarded as a productivity tool. It has been used to achieve:

1. Control and coordination of complex military, industrial, organizational, technical and social processes.
2. Improved reliability of critical processes (by reducing/eliminating human error).
3. Automation of repetitive processes.

The business benefits of automation can be of several kinds.

Designer

A designer is one who designs, or one who has designs. God designed the world; the Devil has designs on the world; both are designers. This dichotomy reflects the fact that plans and blueprints can go awry, either by misfortune or by intentional evil. A plan can be a plot; a coordinated effort can be a conspiracy. This fact is important; it highlights the potential moral content of every design act; which places not only a technical but also a moral responsibility upon the designer, to get things right.

The traditional image of the designer is of a man who makes preliminary sketches for a work of art (such as the decoration or carving on a building or harpsichord), who makes the prototype for a craftwork (such as a patterned piece of porcelain, which lesser workers can copy), or who makes scale drawings for a machine. Artistic performances are dependent upon a variety of designers, for costumes, sets, lighting and programmes.

In many fields of design, part of the traditional skill of a designer or draughtsman was the ability to imagine what the end-product would look like, and how it would work in practice. This conceptualization skill is now often redundant, as computer systems can now simulate the end-product for you. For example, in interior design, when all the surfaces, colours, shapes and light sources have been specified, the computer can simulate how a room will look from any point. This allows the design to be shown to the client, more realistically and less laboriously than with hand-drawn pictures, before any furniture, paint or wallpaper has been bought. It also allows a greater number of options to be offered to the client.

(However, even these computer-generated pictures of the end-product are only representations of reality, and can distort in subtle ways. Architects can choose a perspective point from which their proposed building appears most elegant and/or unobtrusive, and the client or layman may not be able to challenge this perspective, unless s/he has been specifically trained to explore alternative perspectives. The same opportunities for bias are available in software prototypes.)

Computer systems can also help the designer in another way. Since the design of a complex structure or system involves the bringing together of a large number of variables, and involves making trade-off decisions between conflicting qualities of the end-product (for example, in motor car design, speed versus fuel economy, or luxury versus cost), the computer can help to manage these variables and qualities.

Clothing can be given added value by the name of the designer, and a number of consumer goods are referred to as ‘designer’ this or that, which does not just mean that they have been designed, but indicates that they are targetted at a certain kind of consumer, the consumer that is attracted by good design, or believes him/herself able to appreciate good design. Thus a popular brand of mineral water is known as ‘designer water’, a two-day beard is known as ‘designer stubble’, and the new policies of the Labour Party are known as ‘designer socialism’.

So the designer has become associated with good, albeit expensive taste. Alternatively, the designer can be associated with unnecessary expense (in 1976, Mrs Jimmy Carter was quoted in the Washington Post as "rejecting anything she feels inflated by designer labels").

There is an important distinction between design as process and design as end-product. So do you judge the designer by what s/he does, or by what s/he ends up with?

Potter divides design into three broad areas: product design (things), environment design (places) and communication design (messages). The conventional way of thinking about software design is to regard the software as a product. But sometimes, it is more useful to think of software as defining a space, within which a user or group of users can perform some function. (This is particularly valuable in the context of decision support systems, which may create a decision space for the decision-makers).

"Designers inevitably bring certain organizing principles to a problem at the outset. Even when severe problems are encountered, a considerable effort is made to make the initial idea work, rather than to stand back and adopt a fresh point of departure."

"When a person is faced with an act of design, he does not have time to think about it from scratch. He is faced with the need to act, he has to act fast; and the only way of acting fast is to rely on the various rules of thumb which he has accumulated in his mind."

The organizing principles or rules of thumb, together with what Rowe calls ‘enabling prejudices’, may be partially provided by a design methodology.

The designer as full-time job. Many people earn their living by design; most others carry out design as part of their lives, perhaps without even calling it design. (Like the French character who found he had been speaking prose all his life.) In the most general terms, design is the creation of a Means to achieve a given End, which is the common thread behind all rational behaviour.

Engineer

Engineering is the application of technology to solve problems.

But if technology is used piecemeal, it may not work. Cars which are designed to be aerodynamically stable at 120mph, drive through New York at 6.2 mph. (At the turn of the century, when vehicles were horse-drawn, the average speed was 11 mph.) It takes longer to get a letter from Washington to New York than it did in the days of the stage coach.

Therefore, the engineer must be concerned with the application of technology in a systems context, must be pragmatic, must coordinate those things that must work or fit together.

Engineering is not science. The point is not to understand the world, but to change it, as Marx said in another context. But engineering is expected to apply scientific knowledge, to give itself scientific respectability.

The word engineering is usually associated with the ‘hard’ way of solving problems (where the problem itself is taken as given), as opposed to the ‘soft’ way, (where the definition, even the existence of the problem(s) causes more trouble that the solution).

Engineering also implies automation: construction of machines and tools; construction by or with machines and tools. (See automator).

It is interesting to compare the status of engineers in different countries or cultures, and the attitudes of other people towards engineers. In Germany or Japan, they have a very high status. Businesses are driven by engineers. In the UK, where business is driven by bankers and accountants, the engineer is regarded as one who has a second-rate education, and can safely be restricted to technical issues. Although it has long been reorganized into comprehensive schools, people still think of secondary education as divided into an elitist ‘grammar’ stream - whose pupils go on to university and then careers in banks and the civil service - and an inferior ‘technical’ stream - whose pupils go on to read sandwich courses at polytechnics. (Compare this with the high status accorded to graduates of the French Polytechniques !) Even scientists with university education are denied access to the top jobs. (Margaret Thatcher, although a research chemist, trained as a lawyer before entering politics.) Meanwhile, the US maintains a curiously ambivalent attitude towards engineers, respecting them inordinately if they become rich, but ignoring them otherwise.

Methodologue

Former arch methodologue Alexander has now turned against methodology, and now accuses the methodologue of pretentiousness. "If you call it ‘It’s a Good Idea to Do’, I like it very much; if you call it a ‘Method’, I like it but I’m beginning to get turned off; if you call it a ‘Methodology’, I just don’t want to talk about it."

There are two views on what a methodology is.

One view regards the methodology as a skeleton, on which a project can be hung. As a follower of the methodology, you flesh it out, apply the techniques suggested by it, make your own decisions prompted by it, produce some of the deliverables dictated by it. How strictly you adhere to the methodology depends on the project goals, and on your own common sense. On this view, a methodology is judged by its usefulness, in guiding an analyst or designer of a given background and ability, to work effectively in a given situation.

The other view regards the methodology as a full body of tasks, tools and techniques. Whereas on the first view, the methodology supports a project, on this view it constrains it. Whatever the methodology omits, you omit. The project task structure is prescribed by the methodology. On this view, any gap in the methodology is a serious flaw.

It doesn’t matter which view is true. But the first view happens to be more useful than the second. We can regard a methodology as a generalized description of the activities of a series of design projects, together with a theory that explains why those projects were successful. A methodology is usually presented not as a description but as a prescription - a recommendation that projects should follow the generalized task structure.

A methodology describes not how today’s software projects actually proceed, but how their managers think they ought to proceed. The waterfall model, for example, can be understood as a series of instructions or procedures that a project officially attempts to follow. It is an optimistic model, since it assumes things are correct first time. But experienced software developers covertly disobey the waterfall model (either self-consciously or not) in order to overcome its optimism and other shortcomings. Some are made to feel guilty about this, so they try to conceal the complications, and artfully use the waterfall model to explain and justify their results.

Let’s have an analogy, to explain the difference between description and prescription. You can watch a person bake a cake, measure the amount of sugar actually used, or the amount of energy the oven actually burns. Or you can read the recipe, and calculate the amount of sugar or energy that ought to be used. The first is a descriptive model, the second is a normative or prescriptive model. There is a complex relationship between them: - if I give a new recipe to an experienced cook, I cannot predict how much s/he will deviate from the recipe. I can compare two recipes for costs or quality (using one or many cooks), or I can compare two cooks (using one or many recipes), but it doesn’t make sense to compare this recipe with that cook.

Some methodologues go further, and insist that success depend on the adoption of the methodology for all the projects of a particular type across an organization. These methodologies thus contain idealized descriptions of the coordination between projects, as well as the management of individual projects.

(Analogy: just as some socialists believe you cannot implement socialism in a single country; so some methodologues believe you cannot implement a methodology in a single project.)

Any methodology is a combination of practical knowledge and ideology. Information Engineering is based partly on distillation from experience, partly on beliefs about what is worth copying from other fields of engineering, and partly on beliefs about what businessmen want.

But if a methodology is to be more than a hypothesis, if it is to have real empirical content, it should be tested by experience on real projects. (Unfortunately, since a real project uses at most one methodology - although this methodology may be a hybrid merger of two or more other methodologies - such tests cannot compare two methodologies directly.) But this is difficult.

To judge a methodology from a single project that fails may be unfair, for two reasons. First, it is never certain that the methodology has been fully and correctly applied on a given project, so a failure can always be attributed to deviations from the methodology, rather than to the methodology itself. Second, a methodology may not be able to completely eliminate risk (although it should substantially reduce it), so a failure can always be attributed to bad luck. And it is also unfair to judge a methodology from a single project that succeeds even though it ignores or disobeys all of the methodology’s principles, since this may also be luck.

Of course, recurrence of such counter-examples - that fail when they ought to succeed, or vice versa - will seriously dent the credibility and reputation of a methodology, especially if similar results are found in different organizations. But such results are hard to come by. Facts are difficult to obtain, and more difficult still to interpret. And when accumulated experience does indicate problems in a given methodology (or class of similar methodologies) it is very difficult to trace the faulty component. There can be no equivalent of Richard Feynmann’s brilliant demonstration: that the Space Shuttle explosion was due to the effect of cold on an elastic O-ring.

Both the theory and the practice of methodologies require some other way of looking at them. Practitioners (including users) can act more intelligently on projects if they understand how the methodology fits together. They need to understand a methodology from the inside, to know where short-cuts may be possible on a given project, without excessive risk. (This requires that the methodology be a visible system.) Researchers also need such an understanding, in order to explain (and if possible, predict) success and failure of projects, and to analyse the strengths and weakness of methodologies (and if possible, improve them).

A methodology may be a doctrine, but it need not be a dogma. In other words, a good methodologue is open to empirical evidence that would modify his doctrine. A dogmatic (qv) would be a bad methodologue.

But because a methodology is ‘meta’, refutations are a matter of conflicting interpretations. It is very difficult to find examples of methodologues who have accepted defeat, or abandoned any part of their doctrine (except perhaps trivial portions).

Planner

"Meton, the surveyor and planner whom Aristophanes jibes at in The Birds is in fact the archetypal planner, from Hippodamos to Haussman: regimenters of human functions and urban space."

"Baroque planners tacitly assumed that their order was eternal. They not merely regimented space but they sought to congeal time. Their ruthlessness in clearing out the old was equalled only by their stubbornness in opposing the new: for only one order could harmonize with their kind of plan - namely more of their own."

"In the making of an actual plan, the analytic, the synthetic, and the educative functions proceeed together, and each influences the other. A novel way to overcome one constraint makes relevant new costs and benefits and may change both the situation and the issue. In this dialectic process, the policy maker and the planner are indissolubly linked. The policy maker cannot make his often agonizing choice between alternative plans until he knows what mixes of value he can realise with the resources available. The planner cannot engage in his effort to synthesize what seem incompatible values without at least distinguishing those that matter most to his client. And even these may change in relative value as the search proceeds."

References