One of the trends I detected at the Brainstorm BPM Conference in San Francisco this week is an effort to make BPM more engaging to users via Web 2.0 and Ajax. This dovetails with Ismael's suggestions about how to make BPM cool again. Adobe is now all over Flex and Flash technology to turn what we used to call "forms" into animated, engaging end user experiences (online or off) for, say, the applicant for a loan or potential purchaser of some good or service.
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.
I think I know quite a bit about BPM, and while I can't say the same about SOA yet, I'm trying hard to learn. Still, I already know enough to say that when a BPMS vendor talks about how his product is based on SOA, he's not talking about the same SOA that the real SOA guys are selling. Including things like loose coupling, supposedly a foundational SOA concept. Nobody talks about it, it blows my mind! And 99.9% of what is written about the intersection of BPM and SOA is either irrelevant or plain incorrect.
So out of the blue I stumble on a new blog from Jesper Joergensen, whom I know as the BEA Aqualogic BPM marketing guy, that just nails it... in a way that all those so-called SOA thought leaders have never been able to do.
You may recall my dinner bet with Ismael last month. He bet I couldn't find 3 BPM implementations that met the following criteria:
Forrester's Ken Vollmer takes issue with my inference that a BPMS truly layered on SOA must include an ESB in order to achieve the "loose coupling" promise. He writes: I guess the one point I would argue with you is that you seem to equate SOA with ESB?s and that is not a good way to think about it. SOA existed way before ESB?s in the form of CORBA and DCOM technology.
If, like me, you're still trying to work out how ESB fits in BPMS (or not), or even what the heck it is, you can look at the new Forrester Wave, courtesy of Cape Clear, the nominal winner. Here is the chart posted on their site, and you can download the whole report by registering with Cape Clear.
A frenzy of recent blogger activity around the question of whether the business people who do "modeling" can really build executable processes, by analogy with the spreadsheet. Keith Swenson says absolutely, David Ogren and Jesper Joergensen of BEA echo right on, and Phil Ayres is a lonely voice of dissent. I come down squarely on the Keith/David/Jesper side. A key point -- that with the right tool, business folks can do things we used to consign to programmers -- is accepted at some level by everyone.
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).
Oracle's Devesh Sharma has corrected my speculation yesterday that the ARIS deal is mostly focused on the dogfight between Oracle Fusion Apps and SAP/NetWeaver. That's one motivation, for sure, but Oracle plans to impact the mainstream BPMS market with the integration of ARIS and Fusion middleware (including BPEL Process Manager and Designer) in an offering intended to bridge the gap between business and IT. A key innovation, he says, is a unique integration concept based on metadata shared between ARIS (BPMN/EPC) and the SOA Suite (BPEL, workflow, rules, and BAM).