www.btinternet.com/~adrian.larner/review/spurr

Software Assistance for Business Re-Engineering
Kathy Spurr, Paul Layzell, Leslie Jennison, and Neil Richards (Eds)

John Wiley & Sons, 1993, 224pp, hardbound, £26.95

ISBN 0 471 94240 5

A Review by Adrian Larner for the Computer Journal

 

Also on this webpage (below) is my later review of Spurr et al. (Eds) Business Objects: Software Solutions

This book comprises the papers presented at the British Computer Society CASE specialist group seminar of 29th June 1993. Like all conference proceedings, it is a curate’s egg. Business (Process) (Re-)engineering – its practitioners cannot agree on its syntax, let alone its semantics – takes up the baton of corporate data base and enterprise analysis. Not that B(P)(R)E is confined to IT, of course: it encompasses the entire enterprise and subsumes total quality management. It is nothing, many of the contributors tell us, if not holistic (so there’s goodness for you).

 

Between three papers of introduction to the subject, and two that address how the approach can be made to work, come six on proprietary methods and tools. But the best introduction is probably the final paper, by Linda Hickman. The six central papers are much what we would expect: generally well written, with enough information to tempt and tease, but not enough to allow the reader any real understanding. They are, in a word, exercises in selling, some more blatant than others. One contributor lists seven selection criteria for process modelling tools and concludes: Few process modelling tools in present use match up to these demanding requirements. The remainder of this paper discusses one tool ... which scores highly under every one of the issues discussed above. Surprise surprise. The products range from mundane, but probably useful, tools for recording process analyses, to a process simulator that is object oriented (of course) and AI-based: just the sort of tool you would trust in a fundamental remodelling of your entire business.

 

 

Well, that got off lightly! CASE and BPRE: I guess if you couldn’t jump on two bandwagons at once you wouldn’t join the conference circus.
 

The first of the selling exercises, by Julian Watts, briefly mentions the option of piecemeal process engineering – which cautious souls might favour – and gives a good account of the analysis of value streams (value-adding sequences of processes). Chris Haynes’ introductory paper, the third and shortest, describes a somewhat different and rather promising value-based approach. But such nuggets are small, and few, and far between; the subject is new, its notions vague, and some of its verbiage makes one think that re-engineering has been applied to our mother tongue. Skip straight to Haynes’ paper to avoid: in the onrushing face of change ... Business Process Redesign as a concept is contained within the overall domain of change.... All this adds up to mean that the change is transformational ... New ways of working mean a change to the status quo ... rollout is the formal implementation and institutionalisation of the innovation within the organisational mainstream.

 

SITE HOME PAGE

 

THE REVIEWS

Another review ...

 

 

Business Objects: Software Solutions
Kathy Spurr, Paul Layzell, Leslie Jennison, and Neil Richards (Eds)

John Wiley & Sons, 1994, 233pp, hardbound, £29.95

ISBN 0 471 95187 0

A Review by Adrian Larner for the Computer Journal

 

 

Object-oriented (OO) programming is characterised by (1) multi-function routines that retain state data between invocations; (2) all data being the state data of such routines, so that an “object” is effectively a (perhaps complex) variable, along with such a routine, often globally accessible; and (3) asymmetry of CALLs, which are sent, as “messages”, to one of their parameter objects. Other parameters are passed as parameters proper, and may themselves then be “sent a message” by the invoked “method”, i.e. the function named in the original message and being “the responsibility of” the receiving object. The origins of the approach lie in simulation, and it serves very well for the simulation of (actual or conceivable) hardware devices, e.g. to implement the virtual printers used in spooling systems, or windows and other graphical interface components. For general purpose programming, however, it presents serious problems: processing two complex objects together is peculiarly difficult; automatic optimisation is almost impossible because the CALL has to be implemented “in” the object to which the message is sent (no matter where it might be on a distributed network – in effect, OO systems are data access dependent); and, as we would expect of a simulation or of any system with a lot of global data and processing, verification after any change is an exceedingly complex task.

While the programmers struggle with these (probably insuperable) problems of their latest fad, its principles are being applied at earlier stages in the software development lifecycle: witness this latest (fifth) publication in the series of BCS CASE group seminar proceedings, whose price, incidentally, seems to be inflating at about 10 percent per annum. If you are looking for a much-needed, hard, critical – indeed radical – appraisal of OO analysis: look elsewhere.

The selling point of OO systems is reuse, although we still spot, here and there, the shadows of dubious claims of improved quality and productivity. In an interesting paper on Hewlett Packard’s “Fusion” method, Howard Ricketts recommends “defer[ring] the assignment of responsibilities”, i.e. enforcing asymmetry on CALLs, “as late as possible.” (Perhaps sine die would be best.) Fusion also delays “establishing inheritance”, i.e. copying methods from one sort of object to another, “until well into design”. This is excellent: let us always postpone complexity. But it is hardly OO.

Ricketts’ paper is one of four discussing methods and tools: all informative, but – sorry to be so sceptical – do we want OO analysis at all? In the section on Architectures for Reuse, Stuart Frost tells us that “[a] rapid convergence on object technology is occurring ... We will not be able to take advantage of the latest computing technology ... unless our software uses an [OO] architecture.” It may not be that bad: Tim Boreham's paper, “Re-use in OO Analysis”, is quite an elegant exercise in data analysis; but it could be rephrased entirely in terms of old-fashioned entity analysis. Perhaps we could get by if we treated “OO” merely as the latest general adjective of approbation. Only such a semantic shift could justify the wild optimism of the two papers on “Managing the Transition”.

The editors have, wisely, decided to include some explanatory front matter. Unfortunately, the tutorial on OO analysis is error-ridden (even ignoring the macabre J Smith of 10 Downing Street); and the preface and introduction are ill-considered. Is it true that the “approaches [that] separated data from procedure suffered from an inability to deal with ... change”? What then of data independence? Is “one order processing system ... much like another”? Even if the one is for pre-invoicing and the other for post-invoicing? Is analysis merely “the process of obtaining and clarifying our understanding of the problem”? Whither the functional specification of our solution? Is “[t]he concept of an Object ... intuitive”? If so, why did we not intuit it long ago? (Actually it is very like Chen's concept of an entity, and almost as limpid.)

Prophetic, or what?
 

Amazingly, the editors compare the OO approach with the old “craft culture”, which they say is “reaching the end of its days”. But presumably it is still a good enough beast to be beaten with the very latest stick. The dear old craft culture surely now works only in reviewing. We just pick up the books on the latest fashion, shake our hoary heads, and utter the words our nannies taught us: you’re getting over-excited, there’ll be tears before the day’s out.

 

SITE HOME PAGE

 

THE REVIEWS

Another review ...

 

Copyright © 1994, 1995, 2001 Adrian Larner. The author asserts all moral rights.

The decorative image of a key (cc004239.gif) used on this page was obtained from IMSI's MasterClips/MasterPhotos© Collection, 1895 Francisco Blvd East, San Rafael, CA 94901-5506, USA.