Thus, with unintended irony, did our former president illustrate the consequences of low expectations in the debate over No Child Left Behind. No Child's insistence on achieving a minimum competence in reading and arithmetic was scorned by many as too demanding, even "elitist," even though we all know that without those things both the child and the nation as a whole will suffer.

Today, as BPMN 2.0 rumbles toward finalization, we're seeing the same bogus charge again from those who should know better. This time it's posts from assorted dead-enders saying that BPMN is too complicated for business analysts. Usually they have their own proprietary notation which they say is far superior. They invariably take comfort from the conclusion by Michael zur Muehlen and Jan Recker, based on their survey around a year ago, that "all the BPMN you need" is the part that is unchanged from 1990s-era swimlane flowcharts. The rest, they say, is overkill.What they are talking about is events. An event is a signal that something has happened. The customer calls to cancel the order. An SLA deadline is approaching. A fax just arrived. How should the process respond? These are things that the workflow diagrams of yesteryear couldn't describe. But BPMN can describe them, because BPMN puts event-triggered behavior front and center in the diagram.

Events are the language of exceptions, and BPMN lets you say in the diagram itself exactly what you want to happen if this or that event occurs, i.e., how to handle that exception. In the old paradigm, that wasn't part of the process diagram. It was buried in a book of business requirements or tossed over the wall to IT to figure out. BPMN gives business a way to put event handling in the diagram itself, so it is visible, not hidden. It can be discussed and debated, maybe even improved.

To say you can understand BPMN without events is mistaken. Just because a business analyst doesn't already know how to put them in the process diagram does not mean they cannot learn it. It requires training, with a methodology and a consistent approach to modeling style. It requires examples and hands-on practice, no different than learning English or algebra. I've trained hundreds of business analysts over the past two years, so I know it is not pie in the sky.

The teeth-gnashing is going to get worse when BPMN 2.0 comes out. The number of event types is about doubled from before. Soon it won't be enough to know black ones from white ones, single-border ones from double-border ones. You'll have to know dashed-border ones from solid-border ones, event subprocesses from boundary events. It sounds like a tangled mess but there are only a few patterns you need to know.

I've drafted a new version of my BPMessentials training based on BPMN 2.0, even though the standard won't be voted on until June, and today it takes a bit of finagling in Visio to get my tool to draw the new event styles. It's that much better than the old version based on BPMN 1.1. Also, it follows the approach of my upcoming book BPMN Method and Style: a step-by-step methodology that takes a business analyst from zero to full Level 2 modeling in two days. I'm going to shake it out in a class next week.

If business is going to actively collaborate with IT in the BPM rollout, we need to set high expectations for business analysts. The days of proprietary doodling are over. Let's get on with it.Thus, with unintended irony, did our former president illustrate the consequences of low expectations in the debate over No Child Left Behind. No Child's insistence on achieving a minimum competence in reading and arithmetic was scorned by many as too demanding... Today, we're seeing the same bogus charge from assorted dead-enders saying BPMN 2.0 is too complicated for business analysts.