Paul Harmon of BPTrends weighs in on a worthy topic, how many perspectives do we need to describe a business process? He acknowledges that while “alternative approaches” like Role Activity Diagrams or the Flores-Winograd interaction model used by Action Technologies are useful in special cases, most of the time it would be better to standardize on a more conventional workflow perspective such as BPMN or UML Activity Diagrams. Sandy Kemsley expresses her agreement, while Derek Miers (in comments on BPMS Watch) has expressed the opposite view.
I come down strongly on the side of Paul and Sandy, and in fact go farther to say it should be BPMN not UML Activity Diagrams, and in fact it should be an improved BPMN that resolves the inherent conflicts between an anything-goes drawing notation and a “modeling language” with precise execution (and analytical) semantics.
I hope Paul doesn’t mind that I’m using a diagram from his article to illustrate the problem.
Here is an example of what he calls a “high-level BPMN diagram of a supply chain.” Well, it’s certainly a diagram with rectangles and arrows, I’ll grant that, but is it really BPMN? In BPMN, arrows like that are called Sequence Flows and they mean that the activity (which could be a subprocess) at the arrow head starts when the activity at the arrow tail ends. You don’t have to be a supply chain expert (and I’m not) to know that’s not how it works. Source, Make, Deliver, and Return are all in fact running concurrently, although there is communication between them. And BPMN can describe that concurrency (get rid of the sequence flows), and even describe the communication (“choreography”) between them (put each subprocess in a “pool” and interconnect them with message flows).
If BPMN is going to win in the standards game, it has to become more of a design language and less of a cocktail napkin.
Bruce,
Paul’s article focuses on comparing notations outside the scope of their corresponding methodologies, what in most cases makes not a lot of sense. Martyn Ould’s book describes a methodology (RIVA) that does not follow the traditional value-chain-based decomposition model, which is implied by Paul’s review. RIVA uses other notations (not RAD) for high-level process modeling and drills down until RAD. For his specific methodology, Martyn selected the best notations and artifacts, and you cannot judge them in the point of view of another methodology. It’s simply unfair.
Best regards,
Luis Bender
Bruce, I am entirely with you on the importance of BPMN, but my point is more about an important phase that both you and Paul seem to ignore, or sail straight past without seeing it.
That is the need for business people to be able to see their process for what it is … a sequence of steps (whether BPMN or UML) is only part of the picture. It is all about giving them a better understanding of what they do, not endlessly transforming one set of “true” models to the exclusion of all else.
It really comes down to what you think of as a process in the first place. If all you want to reflect is simple procedures, then UML, BPMN … they are both pretty powerful notations. If on the other hand you are looking to model degrees of empowerment, then you are facing the wrong way in the wind with those two methods.
Let me give you a challenge (seeing as how you liked Ismael’s). Next time you are with a group of business people do this little exercise to see if you end up agreeing with me. Before doing anything else, ask them to brainstorm what they want to model (what they want to capture on their models). You will find it is quite easy to fill a couple of whiteboards. So then you say to them “so you want all of that to appear on one model do you” … and watch the penny drop. You need multiple models to really capture the richness of “how things get done around here” – a far better description of process than the rudimentary input-output chains associated with flow diagrams. The problem with boxes and arrows is that, the more you look at them the less they mean.
I had been toying with a draft of a disparaging note to Paul on his tirade, but on balance decided it wouldnt achieve anything.
In the end, the Church of Process is pretty broad, and we all need evangelists, but what we dont need are fundamentalists. Fundamentalists can p%^& off potential parishioners.
BTW – I agree with Luis, these techniques are just not comparible to BPMN or UML. For instance, think about the semantic knots that BPMN has when trying to do a loop with complex joins … (a loop effectively means “travel back in time” on a flow diagram). On a RAD is just never occurs. It is a state model of the roles involved. … I could rant on for hours. Perhaps we should sort out this conundrum over a beer next time we are in the same conference.
Aha! Derek, I think I see your point, and also I think I see the root of the discrepancy. At the risk of overstating it, I guess for me the point of modeling and the “shared understanding” that it creates is not visualizing “degrees of empowerment” but rather specifying a process implementation with improved performance characteristics (also more agile, more visible, less filling, tastes great… with a BPMS).
No doubt that view may seem limiting or even pedestrian to many end users, and I’m sure one could build a nice consulting practice empowering users through improved understanding of how things get done. I don’t want to say “that’s not BPM,” just “that’s not the part of BPM I write (or care) about.”
I remember having a similar discussion in the early 90s with Rodrigo Flores, son of Fernando (of the Flores-Winograd model) and then an executive at Action Technologies. While his tool could (and still can) describe and execute human interaction patterns that conventional BPM could not, it remains the special case in terms of actual BPMS deployment.
My “one model” point is not entirely directed against these alternative mindsets. The bigger worry for me is the UML paradigm, where you need multiple diagrams to describe a process, each representing a different perspective. Better I think to put everything you need (to analyze and execute the process) in a single diagram (BPMN++) than spawn a bunch of orthogonal views of the “truth.”
Bruce,
Marvellous note about Action Technologies. I also met Rodrigo Flores in Toronto in the late 90’s when there were still regional Comdex shows — and Action Technologies had a booth. I recall noticing Rodrigo’s name tag and wondering if he was related to one of famous co-authors of “Understanding Computers and Cognition”; needless to say he was, and the discussion was enjoyable.
Coincidentally, you might be interested to note that there is a new book out this year (2011, MIT Press) about Prof. Fernando Flores “adventures” in Chile: “Cybernetic Revolutionaries: Technology and Politics in Allende’s Chile” http://www.amazon.com/gp/product/0262016494
John Morris