You could model an abstract process using a process modeling tool, then give the model to software engineers who will write a lot of code to get it implemented. That’s typically what a first-generation top-down approach for BPM leads to. Or you could give Intalio|Designer to business analysts and process analysts, and let them work together on an executable process.

Best regards
 -Ismael

Do you think maybe it’s time for experts such as yourselves to get together and establish a standard model for BPM 2.0 in simple, concise and hopefuly universally applicable terms that can be ported throughout various functions and industries?

My work is in the supply chain arena, where about 10-15 years ago there was a similar debate regarding what constitutes a supply chain, which business function was responsible for what portion of the chain, what were some characteristics unique to the supply chain, but standard enough that could be used across all industries, etc… you get my point.

On that background, a number of experts and major clients in the supply chain arena got together and formed the Supply Chain Council, with the mission of developing a standard model, performance metrics and best in class practice, which they called the Supply Chain Refernce Model, or SCOR.

This maybe be to a certain extent what BPM 2.0 needs — a standard model, the basic tenets of which all experts agree on. A model that is relevant to all parties (Business and IT), yet simple enough that it can be easily understood by all involved, so that its use is being promoted by the debate, and BPM’s adoption rapidly expanded.

SCOR is such a model in my area of expertise, and I can tell you that by its development and use modern supply chain concepts were easily and widely adopted by practitioners.

Just a thought.

Thanks! Much appreciated.

“BPM is SOA’s killer application, while SOA is BPM’s enabling infrastructure.”

You can separate modeling from design in your top-down approach if you want (the middle-out approach I advocate merges the two together though), but the whole thing, including implementation, must address integration with transactional systems through WSDL in order to qualify as SOA-compliant. Furthermore, the whole thing, including implementation and deployment, has to be done without support from the BPM vendor, without having to write any code. Also, with respect to the workflow component, customized layout and pageflow should be supported in a Zero Code manner as well.

Are you still on? If not, you might have to go to the timeshare pitch…

The reason you say “middle out” is your scenario starts from the middle, i.e. design, not the beginning, which is modeling. They’re not the same. The purpose of modeling is business-IT alignment, definition of the performance metrics, and projection of those metrics by simulation and analysis… before implementation begins.

In the model, activities are not specified in technical details; that’s layered on after in the design phase. IT calls that “abstract.” A better word is “descriptive.” We agree (I think), that BPMN can be used as a shared tool for both my notion of modeling and executable design.

So let’s take another look at your list:

- Significant-enough project (the process map has more than 100 steps)
 OK

- Integration with transactional systems through WSDL
Not part of modeling, but a downstream design function. Strike this one.

- Human workflow through web-based interfaces
OK. Some BPMS include basic task UI layout in the modeling phase, others put it in the downstream design, especially if it has customized layout, scripting, screenflow, etc.

- Process design done by pure business analysts using BPMN
I think you mean “modeling.” (Don’t you?)

- Implementation done by IT people without writing code
Of course!

- No technical support from the BPM vendor
To do the modeling? Of course none is needed!

Now about that trip to Hawaii. Do I have to go to the timeshare pitch?

Here is a challenge. Please identify three customers sharing this profile:

- Significant-enough project (the process map has more than 100 steps)
- Integration with transactional systems through WSDL
- Human workflow through web-based interfaces
- Process design done by pure business analysts using BPMN
- Implementation done by IT people without writing code
- No technical support from the BPM vendor

And let’s clarify our definition of a business analyst: the candidate cannot explain the difference between DO-WHILE, WHILE-DO, and FOR-EACH loops, even when promised a free trip to Hawaii with friends and family.

If you can point us to three such customers, I’ll gladly admit that a top-down approach could work. And if you cannot, I’ll spend some more time explaining why it does not, for I’m sure many would benefit from the clarification.

And I’ll throw a free trip to Hawaii for you and your loved ones as well.

Deal?

It’s funny how two people with basically similar outlook can view the same post so differently. I thought the Koch column was off-base and totally counterproductive. And you even say that BPM and SOA are 2 sides to the same coin. Hmmm…

Anyway, I’m totally with you on the value of BPMN as the shared tool/notation for modeling and implementation design, whether it’s done by one role (Process Analyst) or split between business and IT. But the methodology of getting it right being “middle out” makes no sense to me. It seems like that’s where top down should rule. When you say we all know top-down does not work, can you back that up? I guess I didn’t know that.