I spoke at the e-gov Enterprise Architecture Conference in Washington in September and was asked an intriguing question by a visitor.  We were talking about the relevance of BPMN, as well as quality of support for BPMN.  What distinguishes human work from what can be automated?  As a reference, I used a very simple two step process which I often use in my presentations – Account Application – which is essentially a two step process once you remove the automated activities.  The second step is a “Decide whether to Create Account”.  His response:  “Would that be represented by a decision node?”

I was stopped in my tracks.  In this case it is NOT a decision node, but why not?  Sometime a conditional branch gateway is called a “decision node” since the server “decides” whether to go one way or another.  In reality, those nodes don’t actually make decisions.  The real decisions are made long before you get to this gateway.  Why then do we call them decision nodes?

Determining whether to create an account is a real decision.  If it is important to select the people who hold accounts, if there is a reason that some people would not be suitable to hold an account, then you must have some sort of process to clear applicants, and someone must decide whether to give out the account or not.  The decision, in the extreme case is easy: a well known wealthy local resident is an easy decision; a criminal convicted multiple times for monetary fraud is another easy decision.  The easy decisions might be coded into rules, but the rules will not cover 100% of all cases.  So therefore ultimately there must be a person to fall back on to make the tough borderline decisions.

The node he was speaking of is also called a branch point gateway.  The process branches to one of a number of possible directions at that point based on information available.  The branch might depend upon rules, but is any real decision being “made” at this point?  Wasn’t the “decision” made long ago?  Consider an example like: “An applicant with credit ratings below a certain value will not be eligible for loans over a certain magnitude.”  Without getting deeply philosophical about it, wouldn’t you say the “decision” is made at the time that this rule is drawn up?  After that time, the execution of the rule simply branches the process based on that former parameterized decision in a completely mechanized way.  This calls into question the real meaning of “decide”.

Do we call them decision nodes because we anthropomorphize the computer system that is executing the process?   You can imagine the server playing a role in the process, and doing things on our behalf.  After all, when we get to that step that says to email all the participant, WHO is it that is doing the emailing?  It is the server doing the emailing, right?  Therefore the server is playing a role in the process as an actor, as if it were a stand-in for a human.  I would agree that it is carrying out tasks that it is instructed to do, but is it really making decisions for us?

I one heard someone make the point that military personnel are trained to understand their responsibility in making the decision to launch weapons.  The radar may say clearly that there is an enemy plane flying a dangerous route, but it is the commander who decides to strike.  There may be rules that identification of a particular threat dictates a particular response, and sensory equipment may indicate the presence of  such a threat, it still it is still the responsibility of a person to interpret that sensory data, and take action.  Business decisions, while never quite as final as some military combat decisions, are and should be the same way.

A real decision is the kind that is not easy to make.  A collection of information will be presented to a person who is responsible for the success of the business, and a decision is made based on many factors that are difficult to quantize.  In some cases, there may be a gut feel.  Malcom Gladwell wrote a great book titled “Blink” which talks about the “native intelligence” which can tap into so much additional information in parallel, and which our conscious stream of thought does not have time to be aware of.  An experienced account manager will be able to sum up a case relatively quickly, and decide whether it is worth risking extending an account to this person.  (Interestingly, this same person may then come up with an explanation for why they made the decision, but that explanation might or might not actually be the real reason, but I digress to far….)

Let’s wave the magic wand for a moment, and imagine what it would be like if we could reduce all decision making to rules.  Then we might have the “one button office”.  This is the idea that you go to work every day, and in the middle of your desk is a single button, and you press it, and the system does all your work for you.  This was the goal of the office automation movement in the late 70’s and early 80’s.  The problem is that as soon as you isolate all the rules, there is someone who figures out how to play those rules, and you have to go and adapt the rules for this change in the environment.  While rules are very important in relieving us from the tedium of routine case assessments, there will never at time in the future be a point where we can stop adjusting and modifying the rules, and there will always be edge cases for which it will be quicker and more efficient to have a person simply “decide”.

A great example of a task that will never be automated is that of deciding which advertisement to run in the next promotion series.  More examples of non-automatable tasks include: the decision to merge two different companies together; the choice of which campaign slogan to use; the decision to hire or fire a team member; whether to run an article in a newspaper.  Let’s call these for a “Business Decisions” because they are the kind of real decisions that must be gotten right in order for the business or an organization to thrive.  Often business decisions depend upon a complex web of current events, legal and ethical constraints, as well as imperfectly known evidence.

Business Decisions are made at nodes which are activities which are assigned to humans.  A person need to perform the task of making this decision.  Those are the true decision nodes, not the branch gateways.

Let me take this a bit further: we know that there are at least two distinct “camps” in the BPM field: those that want to support human work (“Facilitators”), and those that want to automate work that was previously done by humans (“Automators”).  The Automators are always looking for example that can be completely automated.  For example, 30 years ago if I wanted to know my bank account balance, I would have gone to visit the bank and asked an attendant.  Now, of course, I access a web site, and it is 100% automated.  In that situation, all of the “decisions” that had been done by the attendant can be reduced to branch gateways, and you can think of gateway taking the place of the decision that the person used to do.  Facilitators, on the other hand, are looking for example processes which include tasks that can never be fully automated.  For example, a hiring process which includes deciding whether a particular person makes a good fit for the team.  The hiring decision is made by a person at an activity node, and this controls the flow later in the process.

The BPMN specification does in fact call branch gateways “decisions” and this term is in widespread use.   This shows that the BPMN is strongly grounded in the ideas of the Automators.  Facilitators will also use the term “decision” when talking about a conditional branch gateway, but a Facilitator will know that real Business Decisions are not actually made there.  At best, the conditional branch gateway is directing the flow of the process in response to a Business Decision made by a person in a previous step.  Perhaps there is clarity if the Facilitators would talk about a “Business Decision Activity” where a person is given the task of making a decision.  This also reflects on of the fundamental difference: Automators like to draw processes which describe what the computer will be doing, and Facilitators like to draw processes that describe what the people will be doing.  Both can be drawn with BPMN, but many of the current disagreements come from these different interpretations of the same symbols.

I will leave you today with a great quote from a presentation at the Gartner BPM conference by the Futurist Watts Walker:

Good decisions come from experience … and experience comes from bad decisions.

I have not written much about BPDM, the new metamodel specification from the OMG. It is a long spec, and it appears that lots of very good work has gone into it. Making a general metamodel to allow for interchange of all of the various types of process definitions that exist is both very important and also a very big challenge. So this effort deserves a lot of support.

One design choice though surprised me enough that I think it is worth a comment here. The BPDM 1.0 specification is designed to store process definitions in an XML file, but the layout of the process definition is not included at the current time. The “model” is stored (the nodes and relationships) but the positions of the nodes and the geometry of the lines connecting them are not stored at this time.

This is important. I have mentioned in the past that one of the goals of XPDL is to represent the diagram of the process so that these process diagrams can be exchanged between tools that people use in what we call the process design ecosystem. I have an example that may help illustrate the importance of preserving the layout.

Imagine that you want to travel on a subway train from station A to station B. In order to find your way, you need a subway map, which is a model of the subway system. At the very least, the model would need to include a representation of each station, and the trains that connect it to other stations. It is true, that this is all you need in order to calculate how to get from station A to station B. But imagine that you, as a person, look at the map, and every time you do, the stations are in displayed in different locations on the page! Such a map would be almost unusable because every time you would need to read the entire map. A lot of effort goes to making a subway map pleasing and easy to remember. As humans, we need things to appear in the same place every time. The layout of the map is a very important aspect of such a map.

I addressed a similar issue in a past post called “Thow Out The Diagram?” where I was surprised by discussions with people who felt it was right and proper to remove the layout information. Several people from the OMG working group assured me that this was not the case with them, and that layout information is simply delayed until the BPMN 2.0 spec (where BPMN and BPDM will be combined into a single spec) which is anticipated at the end of 2008. The reason is that there is already a proposal for including layout into an XMI format file, and that proposal was not mature enough to include at this time, but it is anticipated that OMG will be able to offer storage of layout in the near future. Nevertheless, and I can’t help feeling that this is a major limitation. If I use BPDM to convert my XPDL file to another format, it will lose a very important aspect of the process diagram.

So in summary, XPDL is still the choice for sharing process diagrams within a process ecosystem with over 60 process tools supporting the standard today.

Why is there all this concern about a single process standard? I was reminded of this while reading a recent article in “Viticulture Obscurant” about a similar situation in Elbonia with standardization of the broad range of wines, which I reproduce in full below:

——-

Elbonia – July 16, 2007 – Citizens and government officials of the republic of Elbonia have been up at arms, almost literally, about the bewilderingly large number of varieties of wine that are now available on the market. There is a growing movement to limit the number of varietals that can be sold in order to simplify the act of ordering dinner at the local restaurants. The diners’ complaint is that it is tremendously difficult to match the right wine with the right dinner because there is simply so many choices.

“The wine list at my favorite place has Cabernet Sauvignon, Merlot, Pinot Noir, Cabernet Franc, Grenache, Malbec, Montepulciano, Shiraz, Zinfandel, Petit Syrah, Sangiovese, Lambrusco, Dornfelder, Bovale Sardo, Schwarzriesling, Ruby Cabernet, Tinta Barroca, and Preto de Mortágua and that is just on the red list.” says the town Mayor Harrison. “It is difficult enough to pick from all these in the first place, but it gets worse when you consider vintages. You have to keep track of which years are good for which regions. What we need is a single wine that everyone can have for every occasion.”

This sentiment is reflected in a new standardization efforts on multiple fronts. One such group produced the Border Practice Multi-Index to define the way that a wine should look, smell, and taste, even though this group does not actually produce any wine. A representative commented: “We did not want to show favoritism to any particular variety so we took the best qualities of all wines, and came up with standardized descriptions. So when someone says that the wine has a ‘musty nose’ or that the ‘bouquet includes blackcurrants, eucalyptus, chocolate, tobacco’ we will all know exactly what they mean.”

The index however has been criticized because it still allows multiple varieties of wine to exist. One restaurant critic complained, “I thought the index was supposed to define the qualities of the perfect wine. A vineyard would then simply create a wine with all the correct qualities and you would have a wine for all occasions. If a vineyard produced a wine with some of the qualities, and not others, consumers could simply boycott that wine until it got the required components. That way all wine would be perfect for any occasion.” There is disagreement about whether this was the goal of the index in the first place.

A different group represented by the two largest grape growing regions got together to form the Basque Puncheon Evaluation League and decided that “Chardonnay” would be the single official wine in the industry. “I have had many many good meals with Chardonnay, and they all have turned out great! I really have never had any reason to drink any other wine. Besides, all those other flavors really confuse me and I find it easier to stick with a wine I know.”

Since that time, an entire sub industry has grown up offering “Chardonnay-only” wines, and producing recipe books that feature the varietal in cooking and serving of all kinds of cuisines. Wine masters have written well-received books saying that ‘the perfect meal starts with a layer of Chardonnay as the foundation.’ It seems almost as if nothing can go wrong as long as it has Chardonnay in it. When local diners ask their sommelier why Chardonnay was the chosen varietal, the answer given, after a brief look of vague hopelessness, is “because the two largest grape growing regions chose it, so we know it is going to be successful.”

While clearly simplifying the wine lists, this move is not without its detractors. One buvionist, speaking under conditions of anonymity said “The problem is that even though all these wines say they are Chardonnay, the don’t taste the same! Each vintner makes the wine in a different way, putting their own special enhancements to it, and the result is that each Chardonnay has a distinct taste. The original point was to have a single wine for all occasions. How is this achieved if they are all different?”

Sceptical of Chardonnay’s ability to meet the needs of every meal, an irrepressable band of vintners continue to produce red wines in the traditional ways. In spite of the desire for a single wine for all occasions, people have continued to enjoy red wines as well as other varieties of white wines. This has not gone completely unnoticed, and in a surprising move a number of Chardonnay vendors have acquired significant holdings in red-grape vinyards, clearly with the intent to enhance their line to include both white and red wines.

Even more suprising is the announcement from a group known as Winesap Blue for People who have announced a new varietal called “Chardonnay Dark” which is based on Chardonnay (and therefore the perfect ingredient for any meal) but includes many of the features of a fine red wine. The acolytes praise this move to finally provide a single wine that is good for all occasions. A prominent Elbonian wine enthusiast had this to say: “I tried the new Chardonnay Dark, and I really liked it. In the bouquet I detected hints of blackcurrants, eucalyptus, chocolate, and, yes, even tobacco! I expect to be drinking this with every meal in the future.” Unfortunately the wine will not be available for a few more years.

At the same time, and probably unrelated, is a new development called the “Omni-grape” from the Borg Province Dept of Metamagic. The omni-grape is a variety of grape that contains all flavors of all possible grapes. “With a vinyard full of these grape vines, you can decide at harvest time what kind of wine you want.” The technical literature about the grape only includes instructions for making Chardonnay, but we have been assured that all other wines can be readily produced, as soon as representative of those other varietals get around to defining the mappings. While this is clearly an important development, it has been criticized for not actually simplifying the final wine list.

So the situation is far from resolved. Every evening, Elbonians continue to face a daunting task to determine their libation. While some restaurants now offer the simplified Chardonnay-only list, it does not seem to have the overall effect that was promised. However there is hope that new standardization efforts are continuing so that one day, in the not too distant future, diners will be able to sit down to a satisfying meal without ever looking at a wine list.

—————–

It struck me that there are some surprising parallels between this situation and the one we find ourselves in the area of Business Process Management. By drawing this parallel, I do not mean to say that there should be as many process languages as there are varieties of wine. But I do mean to draw attention to how questionable it is to be hunting for a single process language for all situations. Different process languages are fit for different purposes. Work in an office space is complex. There are no simple solutions for that complexity, but still people yearn for a simple solution. We should instead focus how well a particular language worked in a particular situation.

Going to be at BPM Think Tank? I will. Maybe we can discuss this over a glass of something-that-is-not-Chardonnay.

Queensland University of Technology is doing a survey on BPMN Usage. Anyone that uses BPMN to create process models for whatever purpose is welcome and encouraged to participate. These guy in general are doing a lot of good work for BPM, so I assume this is another worthwhile endeavor. Here is the info:

BPMN is gaining momentum in practitioner communities, up to a point that even those vendors who were initially reluctant to adopt it, can no longer completely ignore it. But what exactly are the factors that drive this acceptance? How satisfied are end users of BPMN with the notation? Do user experiences on BPMN match those by BPA tool vendors?

Jan Recker from the BPM Research Group at Queensland University of Technology is undertaking a worldwide survey on the use of BPMN by process modellers to shed light into this question. You can help Jan by completing the survey available here:

http://www.bpm.fit.qut.edu.au/projects/acceptance/survey/BPMN/

The best way to contact Jan is via email: j.recker@qut.edu.au

The next BPM event will be happening May 21 through 24 in the Washington DC area at the Transformations and Innovation conference.

It starts with one day workshop on May 21 on “BPM in Practice: Understanding and Implementing Workflow and Business Process Management” given by key members of WfMC. To be covered are:

• BPM 101
• BPM and Enterprise Architecture
• Human BPM compared to EAI Processes
• Business Process Analytics
• BPMN overview
• XPDL overview
• BPEL overview
• Wf-XML overview
• Summary and open questions

It is designed to be a comprehensive overview of the BPM space for those new to the subject and wanting to get their bearings, and also for those familiar with the subject who want to big a bit deeper through direct interactions with the people who have been working on the standards. See the brochure.

Also BPM Focus will be there with a session on Enterprise Architecture.

I just got my copy of the 2007 issue of the Workflow Handbook, and this looks to be the best issue yet.