it is with BPM, or any other language/implementation area). I think it may only be confusing to someone who is only thinking process plans and not about how the software behind "process plans" would be implemented, and whether that requires new software category or software that process professionals are already quite comfortable and familiar with. Now that we're in agreement on that minor conceded point (misleading or not, it wasn't intended to be), I can go back to implementing stuff you would call ACM in my little BPM/BPMN world Despite the fact that they're apparently completely different and unrelated. I think the differences are more like stick shift or automatic, rather than boat and car. Stick shift- you're going to have to change gears on your own and tell the car what you want it to do. Automatic : someone has to build in the gear shifting apparatus for you ahead of time. You just hit the gas and it picks the gear for you. Why would you use BPMN when you don't express the business processes in BPMN? That has never been clear to me. Someone else did this recently, and if I get the chance I will write a post on that. But somehow, it seems like inappropriate technology. Why not use a real programming language like Java or C++? For a process guy, BPMN is a real programming "language" -- just like UML and other techniques are. If it expresses the solution to the problem efficiently, and