Looking askance 4
Looking askance 4
March 2004
1. Process software compared… again
In my last article, I showed a table that highlighted the differences among software for electronic document management, workflow automation and Business Process Management. Earl Sneeringer of Science Applications International Corporation (SAIC) kindly sent me some helpful suggestions for improving the table. I have incorporated those and a few from elsewhere. The resulting new table is more useful, I feel, and easier to read.
Rather than clutter Steve's pages with a repetition, I will happily send you a copy if you would care to email me, on rgw@office-futures.com. [The revised table appears in Askance 3.]
There'll be no spamming. Also, you will meet none of those endless questions that many companies feel entitled to ask when all you want is to download a brochure or white paper. (Thank heavens for Roboform.) A simple return email address is all I need. A cheery message would be nice, too.
2. Let's face the music and dance
I've been puzzling over two terms that occur increasingly often in the literature on BPM - orchestration and choreography. When I see a familiar term in an unfamiliar setting, I normally assume that it is being applied in its old way or something close to it. Most people do the same, I imagine. Doing so with these two words leads to an interesting result.
First, a little egg-sucking advice for elderly female relations. Orchestration is writing the detailed directions on how a (usually large) group of musicians should play a piece of music. There are different sets of instructions for each type of instrument, such as violins and flutes. These sets ('parts') usually all appear together in only one document. This is the full score, which the conductor sees but not the players.
Sometimes the orchestration is by the original composer of the work. At other times it is by someone else, occasionally called the arranger, hence such expressions as "Bach's Toccata and Fugue in D Minor, arranged for orchestra by Leopold Stokowski". (Not recommended for those of a refined disposition.)
Choreography is writing the directions for one or more dancers to perform a dance or a set ('suite') of dances. It also refers to the individual instruction a choreographer gives to dancers, who tend not to work from the written version but from the choreographer's oral instructions and example.
Both activities - orchestration and choreography - take place before the performance. During it, they act only as the basis for what the performers bring out in their interpretation of the work.
This notion of preliminary activity applies also to the everyday, metaphorical use of these words. "The current mass squat-in… was clearly orchestrated, presumably with the participation of the city's mayor", "The meeting between the two presidents had been carefully choreographed" and similar usages.
So far, so simple. In the world of 21st century computing that clarity is lost. As far as I can make out, orchestration becomes managing programs and services within the organization, and choreography is their management outside the organization. Both take place during the performance of the work.
How confusing. Perhaps there should be a logical function within BPM software called the "conductor" or, for Italianate products, "Maestro de concert".
3. Problems with problems
But one has to learn to listen at right angles to the discussion. That is to say, to listen not for the content of what people are saying but for the order of complexity of the ideas they are using, and to how they are mustering their arguments - the category of complexity they are using - within the broad order. (Elliott Jaques and Stephen Clement, Executive Leadership - A Practical Guide to Managing Complexity, Cason, Hall and Company, 1996.)
Here is a simple model, for you to agree with, argue against or dismiss, as you like. (As with any simple model, such as Zachman's framework or the Capability Maturity series, this is intended as an aid to thinking, not as a substitute for it.)
The model suggests there are four kinds of problem confronting any person or group of people:
1. Problems solvable with brute force, engineering cleverness or both. Examples of these are quarrying rock, building roads, putting a man on the moon and writing BPM software.
2. Problems soluble only with guile, patience, persistence and sometimes luck. Examples include organizational change, party politics and bringing up children.
3. Problems that are obvious but insoluble, that can at best be ameliorated. Examples here are the existence of pain, economic inequality, religious intolerance, and warfare.
4. Problems that are difficult to define and often scarcely recognized as problems. Examples of these are cultural norms, our dependence on technology (and not just information technology) and the medicalization of everyday life.
Not every problem occupies just one level. Some straddle two or more. Introducing a new computer system, for instance, normally embraces levels 1 and 2 as a minimum. Occasionally it edges into level 3, such as in medical computing. (As for level 4, it tends to make the problem worse not better.)
People do not all have the ability or time to diagnose and grade problems accurately. This ability varies with intelligence, education, sex, training, inclination, experience and personality. Some people might, for instance, classify a given situation as a level 2 problem where other people might see it as level 3.
Setting things too low is reductionism. People sometimes do this downgrading deliberately, as a stratagem. Norman (now Lord) Tebbit, a British Conservative politician, was an expert at this. He did it mainly to provoke. Some people do it to test their and other people's understanding of the issues. Other people do it because they simply do not see that an action impinges on a higher level.
This is not to say reductionism is bad. It is a sharp mental tool and is the basis of Western science. Reductionism is at its most useful when dealing with closed systems, such as machines and software. Here we must render unto engineers what is engineers'. However, in the real 'real world' - the one with people and other organizations in it - reductive thinking can be a hindrance. Divergent thinking is needed as well.
The reverse process, such as dressing up a level 2 problem as something higher, is mystification. Snake-oil salesmen have done this through the ages. They use people's suggestibility to get them believing that the simple answer is never the satisfactory one. These days they study the technique at business school.
When someone wrongly diagnoses the essence of a problem, his or her solution to it is usually inappropriate too. A few years ago, I was an active member of a network of organizational development (OD) practitioners. Most of them were sensible folk, with a pragmatic view of their abilities and of applicability of OD.
Some, on the other hand, were fey diviners of group gestalts, wafting along on waves of suggestibility. They would be mortified by the notion that what they did could ever be recorded in writing or, perish the thought, repeated or measured. These highly tuned 'facilitators' were much given to positioning questions - and their answers - at least one level above where they naturally belonged.
I had thought of reengineering the users
The opposite is often the case with people from engineering and engineering-like disciplines, such as computing and accounting. They are by nature and training inclined to diagnose problems in engineering terms and to offer reductive, deterministic solutions.
In computing, this tendency can result in misjudgements of the non-technical aspects of situations. These show themselves in rueful statements like:
"The system was fine but the users didn't like it"
"I crafted a really elegant solution but they messed it up"
"Politics got in the way", and
"Management didn't understand".

The truth is, of course, that it is the systems person who didn't understand. He or she failed to understand the complex nature of organizations or the limited applicability of the proposed system. Training, disposition, peer pressure and other forces inclined him or her to offer a level 1 answer to problems extending into other levels.
Dilute or concentrated?
Another symptom of dislocated thinking can be seen in computer and software companies' marketing. They laughably now nearly all label themselves "solutions providers" and their products as "solutions". How can these be solutions - the companies haven't even asked what the problem is yet.
It is also a source of wonder that whatever the problem might be, the 'solution' always turns out to comprise software, hardware, networking and a bit of consulting time. How often is the response a recommendation to examine recruiting methods or management succession planning or even to have less IT around the place? Exactly.
What we have here is a narrow range of potential remedies offered as solutions to an impossibly wide range of problems. Partly this is an understandable piece of salesmanship. You wouldn't, for example, expect a car salesman to turn you away, saying "I'd stick with what you've got, mate. It's good for another 50,000 miles before the repair bills get serious. Anyway, the first-year depreciation on a replacement would give you nightmares."
On the other hand, in Britain at least, car showrooms are not yet so far up themselves as to offer "transportation solutions" (but give it time).
It comes to something when one offers the denizens of a car showroom as beacons of honesty but in this instance it is a fact. In terms of matching the solution (a pricey lump of metal, glass and plastic) to the need (ego boost, penile extension, marital ransom or, once in a while, simply transport), car salespeople are as straight as a die. They are also honest with and about themselves.
Wouldn't it be luvverly if computer systems suppliers and practitioners were as honest? Imagine a reseller saying something like this:
"I'm afraid I can only offer you part of the answer. What we have will handle your machine-readable data superbly. It won't, though, solve the poor communications between engineering and marketing. That's a cultural and organizational matter. Also, unless that side of things is fixed, it will wipe out any gains you might make through using our system."
Most IT folk are unlikely to have even recognised the human communications problem. Even if they had, would they be similarly honest with themselves and their customers about the inability of their 'solution' to handle it? Pigs would take to the air first, I feel. Competitive pressures would make sure of that.
Sadly, you can see that the Red Farrows are grounded when looking at BPM and the way it is being marketed. This is simply a new(-ish) way of linking and using software, not the gateway to undreamt-of corporate performance. A bit less of the messianic fervour and a bit more honesty would be welcome.
BPM software is a level 1 solution to certain level 1 problems and, used sensibly, can also be an aid to solving some level 2 problems. That's all - but it's enough.
4. Are you a Petri dish or a cutie pi?
There is a debate in progress on the merits or otherwise of using pi calculus as a basis for writing BPM software. Actually, "debate" is too dignified a word for it - it has become a squabble. What's irritating people is not the substance of the proposition, which is testable. It is the way it is being promoted, as though using pi calculus were the only valid basis for making process software. Messianic fervour is in evidence here, too.
I won't go into more detail, for the sake of BPMG's sponsorships, but you can get an idea of the prevailing temperature from the forums that Michael zur Muehlen hosts on his Web site. (See http://www.workflow-research.de/Forums/index.php?act=ST&f=10&t=28 for the whole Megillah.)
Phil Wainewright had noted the gathering squall last November, in his Loosely Coupled blog  (http://www.looselycoupled.com/blog/2003_11_23_lc.htm#107015401001130588 ). The comments to it fill a further three pages.
The latest contribution comes from Wil van der Aalst. He has recently posted on his Web site a paper suggesting a number of practical tests to sort fact from fantasy. In the paper is this diagram of a sample Petri net:
Petri lattice
Wil says that, although this lattice contains only parallelism and no branching, process algebras like pi calculus have problems modelling it. If that is the case, they are clearly not the universal and essential ingredient they are being touted as.
No doubt the process algebraicists will disagree. I'll keep you posted.
5. The Great Cham has the last word
All this talk of nets brings to mind Samuel Johnson's definition of a network, from his dictionary of 1755:
Any thing reticulated or decussated, at equal distances, with interstices between the intersections.
Presumably tongue in cheek, Johnson helped matters along by defining reticulated thus: "made of network; formed with interstitial vacuities". (In case you're encountering a vacuity of the lexical kind, decussated means lying across, forming a figure like the letter X.)
In my next oblique look at the world of BPM, I shall be considering what Hieronymus Bosch and Diego Velázquez can tell us about systems.
Roger Whitehead