More BPMN vs. BPEL
Was pointed to this post by Keith Harrison-Broninski: BPMN will kill BPEL, will it kill BPM, too? It has one or two factual errors (BPMN doesn't come with built-in BPEL mappings, for example), but the conclusion is pretty much spot-on.
The world is moving away (albeit slowly, so far) from code-based representations, and toward rich object models, able to be graphically expressed. These advances make the strategic adoption of specific implementation languages (like BPEL or, for that matter, Java and C#) less relevant over time. As an engineer I work with said: "Let's do with Java what we did with Assembler." This is true for any language-specific implementation, whether code or rules.
The real breakthrough of BPM is the embedding of technology into the business... it's not in simple "alignment" of business and IT, it's in the complete transparency of the business's use of technology, so that understanding is shared and implementations are business-driven (although not business-performed). This will occur by moving toward model-driven environments, and, therefore, away from programmatic or rules-driven environments.
BPEL is expressive, it just is too little, too late. Stick with Java and C# for the short-term, and move to a truly services-oriented representation strategically. This will result in the quickest move to the next-gen architecture, and the lowest cost, most scalable implementations in the short run.
Subscribe
To be precise, it must be pointed out that the mapping from BPMN to BPEL described in the BPMN spec is incomplete (this BTW is acknowledged in the list of open issues of the BPMN spec). The mapping presented in the BPMN spec focuses on models that have a structured topology (e.g. every parallel split gateway has a corresponding join gateway, every decision gateway has a corresponding merge gateway, etc.). This restriction is formulated in the BPMN spec as follows: "A Sequence Flow may not have a specific mapping to a BPEL4WS in most situations. However, when there is a section of the Diagram that contains parallel activities, then Sequence Flow may map to the link element. Details of this mapping are TBD." The BPMN spec shows how to address this issue for some (but not all forms) of unstructured diagrams. Lifting this restriction in the general case is the subject of ongoing research (http://tinyurl.com/lfyvk).
Posted by: Marlon Dumas | March 13, 2006 at 09:34 PM
Hi Phil
I still see things differently to you, but appreciate what you are saying and think we should leave it for now! We agree on conclusions (though I will be interested in your response to my next few postings, which follow this line of reasoning a stage further) - and blog comments are probably not the best forum for an extended philosophical debate on the nature of metamodels :-)
All the best
Keith
Posted by: Keith Harrison-Broninski | March 07, 2006 at 02:59 PM
Keith,
Yep, we're in agreement (about the conclusion anyway!). See my post on BPElephant. The answer is a MOF-based metamodel.
I say that BPMN doesn't map well to BPEL because it doesn't map well... you can represent things in either paradigm that cannot be easily transferred to the other without additional metadata not supported in the host "model." I say they are orthogonal because your use of one neither precludes nor enhances your prospects of success by using the other. Both of these are reasons for Bruce's comments, I suspect (I haven't pinged him on this... so don't want to put words in his mouth), and yours and mine.
However, I believe you're wrong about BPEL and BPMN... the BPMN specification is closer to having an implicit metamodel than the BPEL specification, regardless of google search results. While there are historical reasons for it, the spec is not thematically consistent and it therefore becomes difficult to divine a true, consistent model.
We both agree that either way you go (today's BPMN or BPEL specs) the metamodel is implicit and it needs to be made explicit. As participants on the BPMN group, and as submitters to the BPDM spec, discussions of metamodel are something we have quite a bit of insight into. In fact, we've proposed a reference implementation of an explicit BPMN metamodel to the OMG for use in evaluating its application to either the BPMN (2.0) spec or the BPDM spec. We would like to see a reference implementation of the serialization of the BPMN-based metamodel into BPDM as a part of the BPDM spec.
Some in the BPEL community have done the same, but in addition to rationalizing that spec's semantics, their metamodels lack the MOF backing I would expect in any future-embracing scheme. Further, because BPEL is an implementation language, it doesn't really fit well into an MDA future, where multiple implementation methods should be made available to the modeler.
Cheers,
Phil
Posted by: Phil | March 07, 2006 at 12:05 PM
Yes and no ...
I assume that when you say "BPMN doesn't map well to BPEL4WS" and "BPMN and BPEL are orthogonal" you are referring to BPMN being more expressive than BPEL, since it is also intended for translation to (for example) XPDL. Hence, though BPMN was designed from the ground up to map directly onto BPEL - in fact, to permit such mappings to be automated by tools - this won't work unless you use the right BPMN elements, in the right way.
If this *is* what you meant, then yes I agree - it is another reason why using BPMN as a front-end to BPEL is not a good long-term strategy. Bruce Silver described some practical problems with using BPMN and BPEL together in his blog [http://tinyurl.com/fm9ga] and in my blog I described some current issues with BPEL extensions [http://www.ebizq.net/blogs/it_directions/archives/2006/02/bpmn_will_kill.php]. In due course, this sort of thing will become a major headache for BP practitioners.
However, you've got it the wrong way round re metamodels. It is BPEL, not BPMN, that currently has the implicit metamodel - you can find any number of representations of it on the Web by academics and vendors (Google "BPEL metamodel"). The designers of BPEL actually set out to make it quite formal in its semantics, though many people would question how successful this effort was. BPMN, on the other hand, doesn't have a metamodel yet, implicit or explicit - though the OMG are busy defining an explicit one at the moment in the form of BPDM.
What I was arguing in my blog is that the step change will come when the OMG issue BPDM. Once BPMN is defined via an OMG MOF metamodel, it will gain an XMI representation that effectively makes BPEL obsolete - and I think we *do* agree on this!
Keith
Posted by: Keith Harrison-Broninski | March 07, 2006 at 09:29 AM
Keith,
Yes, I should have been more accurate, and said that BPMN doesn't map well to BPEL4WS, although reference mappings for many BPMN elements do exist. They are actually contained in chapter 11 of the most current draft (http://www.bpmn.org).
The main problem is that neither spec contains an explicit metamodel, although BPMN certainly has an implicit one. It's this model that gives BPMN its mastery over BPEL. Fundamentally, it's the metamodel that provides the power and, ultimately, the portability we're all desiring.
(I should say here, for the record, that BPMN and BPEL are orthogonal in actuality. See my post BPElephant. As an implementation language, BPEL is A choice, not necessarily THE choice for executing a process. However, BPMN is THE choice for describing a process in a rich, accessible, portable manner.)
OMG is addressing this by defining the reference process metamodel in the upcoming BPDM specification, and I think you'll also see BPMN (as well as upcoming BPRI) move toward the explicit expression of the metamodel in specs to come.
All the best,
Phil
Posted by: Phil | March 07, 2006 at 07:14 AM
Hi Phil
As you know we are in agreement on these issues. I feel, however, I should stand up for myself with respect to the "factual errors" in my blog. BPMN *does* come with BPEL mappings. The BPMN specification (v1.0 of 3 May 2004) (which one must take as the definition of the language) details exactly how to convert BPMN to BPEL, both in the general case (chapter 6) and for specific examples (chapter 7).
--
All the best
Keith
Posted by: Keith Harrison-Broninski | March 07, 2006 at 04:19 AM