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 thinking, but I'd agree with Henry that eClarus leads the pack.
The company is a small startup in the Seattle area. Their mission statement is refreshingly encouraging: "Easy, productive collaboration among business analysts and IT architects for agile, well-governed development and integration." Their product is a BPMN modeling tool that generates BPEL, and can also take BPEL and generate BPMN. The latter piece, obviously central to the round-tripping idea, has been described by other vendors I talked to as "too hard" or "huh?", but according to eClarus, BPEL to BPMN is easy. It's the BPMN to BPEL that's hard, because -- as I've written before re my ITP-Commerce experience -- it's easy to draw things that don't map easily to BPEL.
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 looping back to previous steps in the diagram.
But for many real-world processes, particularly those characterized as "event-driven", that no-loopback rule doesn't work. They are better modeled as "business state machines," similar to a UML statechart diagram. Nodes in the diagram are not process activities but states of the process instance. In each state, the process listens for various events, which trigger a specified action (process activity) and transition to a new state (or back to the same state). The triggering can also be conditioned by a rule. This event-condition-action (ECA) paradigm is the hallmark of event-driven processes. UML provides a diagram to let system architects model them, but I don't know of any tools for process analysts to model them. Maybe the concept is too "complicated"?
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 asking for that all the time.] Portability of process templates was never a goal of BPEL, just interoperability [i.
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 of a trip to Hawaii tacked on if I could come up with 3 top-down implementations that met his "
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 portability is not, and never was, a goal of BPEL. A look at Cordys, Lombardi, and Intalio offerings -- all of which use BPMN as a notation for executable design -- convinced me of point #2.
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 vendor support through executable design and deployment. [He doesn?t say into production, just deployment.]
The BPMN part kind of narrows down the field, but I was pretty sure Lombardi, Cordys, BEA, and Savvion would be able to provide me 3 at least! I haven't heard back yet from BEA and Savvion, but Lombardi and Cordys have provided 4, which I present below. Let's see Ismael try to wriggle out of this one!!
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 presented suggested that just providing BPMN a schema and metamodel, submerged under OMG's broader BPDM effort, would be bogged down by "choreography" issues for many months at least. Well, whatever.
I was quoted in the article as saying that shoring up the BPMN standard would make it the de facto notation for executable process design, and even BPEL design tools would migrate to it. And I still believe that, but with a big IF...
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 here).
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, BPEL 2.
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 BPMN or UML Activity Diagrams. Sandy Kemsley expresses her agreement, while Derek Miers (in comments on BPMS Watch) has expressed the opposite view.
