Don't mix models and realization?

Active Endpoints has long experience from process execution environments. In this post, Michael Rowley gives his response to the BPEL vs. BPMN debate. Michael is questioning the relationship between models and its realization. He makes a note about the tiny little details you need to add to your model for making it executable saying - "... and they can’t be fuzzy or imprecise" about the ability to express them in BPMN.

Model-driven design is a hot topic, not just in the BPM space but in all software development domains. Business people have been invited to the round tables when discussing software design, thanks to the modeling approach. Certainly there will be initiatives taking the model too far, but in a couple of years there will probably be a balance between model and realization and we could hopefully work together with a seamless model-to-realization process ;).

Zip-top bags, monkeys, and BPM

I attended and talked at a BPM conference last week, arranged by IDS Scheer in Stockholm. One of the keynote speakers was a guy talking about human behavior and how to step out of the box.

He talked about how we act in front of airport security, when asked to put liquid and gels in a plastic bag, even though we know that bag will not be safe when the bomb goes off. This story relates to all the brainless people and ass-kissers we are put up to cope with during the work hours.

The best story was the one about the monkeys and the bananas. It went like this ...

Start with a cage containing five monkeys.

Inside the cage, hang a banana on a string and place a set of stairs under it. Before long, a monkey will go to the stairs and start to climb towards the banana. As soon as he touches the stairs, spray all of the other monkeys with cold water.

After a while, another monkey makes an attempt with the same result - all the other monkeys are sprayed with cold water. Pretty soon, when another monkey tries to climb the stairs, the other monkeys will try to prevent it.

Now, put away the cold water. Remove one monkey from the cage and replace it with a new one. The new monkey sees the banana and wants to climb the stairs. To his surprise and horror, all of the other monkeys attack him.

After another attempt and attack, he knows that if he tries to climb the stairs, he will be assaulted.

Next, remove another of the original five monkeys and replace it with a new one. The newcomer goes to the stairs and is attacked. The previous newcomer takes part in the punishment with enthusiasm! Likewise, replace a third original monkey with a new one, then a fourth, then the fifth. Every time the newest monkey takes to the stairs, he is attacked.

Most of the monkeys that are beating him have no idea why they were not permitted to climb the stairs or why they are participating in the beating of the newest monkey.

After replacing all the original monkeys, none of the remaining monkeys have ever been sprayed with cold water. Nevertheless, no monkey ever again approaches the stairs to try for the banana. Why not? Because as far as they know that's the way it's always been done round here.

And that, my friends, is how company policies are made.

So how does the monkey story relate to BPM?

Don't beat up the guy trying to improve your business processes with the clear goal of rationalizing you and your collegues?