Those of you who have followed the threads in BPMS Watch on the BPMN-BPEL round-tripping problem -- keeping the business-oriented process model in sync with the executable implementation throughout the process lifecycle -- may have noticed a comment from Henry Yu of eClarus saying, essentially, we think we've solved this, check it out. So I did. Very interesting. Not solved yet, to my way of …
Virtually all the modeling notations and tools I know, including BPMN, as well as executable process design tools (both workflow-style and BPEL-based) follow the activity flow paradigm, i.e. like a flowchart or UML activity diagram, in which the flow is generally in one direction. Moreover, to create a valid executable process diagram, many (including the BPEL language itself) exclude arbitrarily …
BPM is about empowering people. It was co-opted by integration vendors, who took it down an IT-centric path. ? Connie Moore, Forrester. [Note: Forrester has separate analysts and ?waves? for human-centric and integration-centric BPM. Guess which is Connie?s?] The ultimate goal of BPM is self-aware processes that can recommend changes to process owners. ? Connie again. [Yeah, I hear businesses …
Don't ask me how, but Ismael turned the hubbub over BPM vs SOA into a discussion of top-down vs "middle-out." Both threads (including comments) are semi-instructive, but somehow in the course of things he challenged me to come up with proof that top-down (i.e. BPM implementation driven from the business model) has ever worked. The challenge came in the form of a double-dog dare, with the promise …
David Chappell, who long ago took the position that BPEL isn't portable so it doesn't matter, now amplifies it with the conclusion that portability should be at the design language level, not the execution language, and the best candidate for that is BPMN. I've come to the same conclusion myself, on both points. John Evdemon, BPEL TC co-chair, sealed point #1for me at Think Tank when he said …
You may recall my dinner bet with Ismael last month. He bet I couldn't find 3 BPM implementations that met the following criteria: Complex process (e.g., "more than 100 steps") Integration with transactional systems through WSDL Human workflow through web-based interfaces Modeling and skeleton design done by process analysts using BPMN Implementation done by IT people without writing code No …
I hate to learn BPM stuff by reading it in the newspaper, but that's what happened today when my copy of SD Times arrived in the mailbox. A Page 1 headline blared Could BPMN 2.0 Make BPEL a Moot Point? Humm, BPMN 2.0... draft reviewed by OMG last June with adoption expected in September. Wow, I spent 2 full days in May at OMG Think Tank and never heard the words "BPMN 2.0" once! In fact, what was …
Assaf Arkin guest-posts an impassioned love-hate note to BPMN on IT|Redux. I admit I only understood about half of it, and I think you'd need to have stayed awake through many a BPEL TC conference call to get most of the references. His first core assumption - that BPMN's deeper purpose is to provide process design portability, not just a drawing - is one I agree with (e.g. here and here and also …
When you're deep in a hole of your own creation, the usual advice is to stop digging. But Assaf Arkin is not a slave to such conventional wisdom. He took a sound hammering on the comment thread to his original IT|Redux post where he states that BPMN should just be the diagram for BPEL 2.0, but he continues to dig in hard and reaffirms that process portability demands a common execution language, …
Paul Harmon of BPTrends weighs in on a worthy topic, how many perspectives do we need to describe a business process? He acknowledges that while "alternative approaches" like Role Activity Diagrams or the Flores-Winograd interaction model used by Action Technologies are useful in special cases, most of the time it would be better to standardize on a more conventional workflow perspective such as …