12/05/09 :: [BPM] BPM, the next decade [permalink]
No other debate better represents the rift between the business and the geeks as "BPMN vs BPEL". No other debate better represents how far away the geeks are from what they are supposed to deliver, no other debate better represents how little the geeks care about their customers.
I started to work on BPM at Sapient (a consulting company), in late 1997. Then as a young consultant, I became intrigued at the idea that people were hand coding business processes in C++ (and were failing to do so). I quickly moved on and built my first BPM engine with a small team at the end of 98 at NEC Labs in Boston. NEC killed that project in the spring of 1999 (not because it failed but because it did not want to enter that market) and continued that work at eXcelon (now Progress Software). I actually worked with Michael Rowley, back then, who thought UML Activity diagrams were "the" model for Business Process Definitions. When it did not work, he moved on to the State Machine diagram (the kinds that Jim and Savas think are process definitions). When that did not work, he moved on to something else, but I lost sight. Needless to say that Michael does not really have a strong track record of figuring out the right semantics of Business Process Models, executable or otherwise. He is a great software engineer and we can see that through his work on OQL and SCA for instance, but BPM is different. I thought that Michael had finally made some progress this fall when he talked about BPEL outside the context of BPM (in his latest book on SCA):
Ignore, for the time being, the concept of business processes. If you were going to design a language from scratch that was designed for use with asynchronous web services, there is a good chance you would design something very similar to BPEL.
Yes, Michael, that's the right way to look at it. But, no, we are back to the BPMN vs BPEL debate.
What does Michael has in mind when he pushes BPEL (again)?
portability – primarily portability of skills but also portability of code and interoperability of tools.Basically, [we] are looking for an ecosystem around the language.
Michael, who cares about portability and interoperability when you don't even have the beginning of a foundation that works? The business can't care less about interoperability and portability. The business cares about agility and visibility. The business does not care about an "ecosystem around the language".
Of course, another key figure of BPM stepped in this new iteration of the debate, Frank Leymann. Could somebody be more wrong for such a long time?
BPEL focuses on providing a language for specifying business processes and provides a precise operational semantics for executing processes specified in this language.
You can specify business processes with BPEL? Have you ever tried yourself? for a start Frank, where are the users? Second, look at the metamodel of BPEL and tell me if your average business analyst can master ReapeatUntil, While or ForEach activities? How well will they handle variables and correlation sets? Handlers? As Michael used to tell me at eXcelon "this is Turing complete", that's all you need.
Frank does acknowledge that BPMN took the lead and hence there is a need for a solution to map BPMN to BPEL because:
Because of the wide-spread support of BPEL by middleware vendors the use of BPEL engines for BPMN execution is an obvious choice. To enable the execution of BPMN process models in BPEL engines, the transformation of BPMN process models to BPEL process models is needed.
But unfortunately:
But the metamodel underlying BPMN and the metamodel underlying BPEL are not identical [you bet, they have nothing in common]; in fact they are quite different. Thus, the transformation is not straightforward and sometimes requires complex mappings resulting in a BPEL process model that look quite different from the original BPMN process model (quite a number of publications exist that dive deep into this).
So what does Frank (and Michael) propose? Two solutions:
a) standardize a visual representation for BPEL
b) make transforming BPMN process models to BPEL much easier... [i.e.] a subset of BPMN 2.0 that is naturally supported by BPEL
Not clear enough? Frank suggests to use:
A subset of BPMN 2.0 is “isomorphic” to BPEL
Yes, ladies and gentlemen, these posts from Michael and Frank give you a rare insight on how vendors think and how well it lines up with the need of their customers. All they focus their energy on is for BPEL to rule. BPEL (and BPML), the "orchestration" language that single-handedly killed BPM, must rule. The geeks must win, the business analysts must become programmers. Why? Because all the "middleware" vendors built "orchestration" engines (BPEL based or not). Yeah, you heard it right, it does not matter if the vendors got it right or wrong, you must use their crappy products, simply because they built them. Frank, this is rock solid Nobel quality logic. I am, therefore I think.
And of course, this BPMN/BPEL salsa has to happen outside a rigorous Model Driven Engineering framework? Right. I nearly forgot, no relationship to SOA either... The reality is that the geeks like Michael, Frank and others like Assaf can't stand the idea that their corny views about Turing completeness cannot solve a problem that they think is procedural (and forever, they will think it is procedural). Orchestration is an important programming paradigm, yes, BPEL and the like are programming languages, not a Business Process thingy.
So I repeat what I said a couple of weeks ago: it does not matter how much you pay for your ELA, it does not matter how much money these company make. These "Computing Scientists" will never listen to their customers. They will choose interoperability and portability over agility and visibility. They will always isomorphically map their stupid ideas and products to your needs. Let's give them a round of applause, after a decade, it is still the same people, doing the same thing and you guessed it, we will get the same results in 2020 (sight).
Note, that I did try to engage the "analyst" side as well. They are just as stubborn. Bruce Silver and Sandy Kemsley have refused the dialog, all they can think of is holding on to BPMN and shoot BPEL. This is unfortunate because the solution is quite simple. There is a real articulation between BPEL and BPMN that I have suggested here. This article has been one of the most successful articles of InfoQ with many readers praising the views that I developed. After writing this article, Marlon Dumas introduced me to the remarkable work of Ksenia (Ryndina) Whaler, from IBM Zurich Research Lab (yes IBM), which suggested a similar approach with a strong theoretical foundation. This approach, which at the core, uses the concept of Business Entity Lifecycles, has the merit of creating a very strong articulation (not mapping) between BPMN (the business process model notation) and BPEL (the implementation language of BELs). But, no that would be too easy. The BPMN people, like Bruce or Sandy, are upset about this approach because it introduces a new business concept, the business entity lifecycle, and the BPEL people are upset because BPEL is no longer the "business process execution language" but the BEL implementation language. BELs have the merit of reusing all the investments made by BPEL engine vendors and allow enough freedom to the BPMN people. We could even articulate most of the REST principles into this framework. But, no, that would be way too easy, a win-win-win situation would make way too much sense in a society that has lost any of its senses and is always looking for "the" winner smashing the loser.
After 10 years or so, we keep using the same arguments year after year after year. Everybody claims that he or she is right without ever looking at the flaws of their approaches. In the mean time, IT and the business are hurting, but these guys don't care. They actually can't care less.
It will be very interesting in the coming years to answer the question of what happened in this decade. Why stupidity became the prevalent currency after so much progress and such an accumulation of knowledge (and wealth). Which turn did we take that lead to this kind of situation. Some could say that all this must be a product of the Western society's Teaching structures (I highly recommend that you read this article). I don't know, I personally think that this is more the product of a totalitarian management culture, where there has to be one decision maker (business or technical) who thinks for everyone else and everyone else must follow through. Our (democratic) societies have organized themselves with a top-tier command and control structures. If the top is right great, if the top is wrong, there is no check and balances that can stop the course and make corrections. We have 6+ billion brains but humanity is using a few 10s of thousands at the most.
So I would like to extend my thanks to the "BPM" people: Michael, Frank, Bruce and Sandy, not to forget Assaf and Ismael or John, let alone Dave, Conrad, Antoine, Cory and Fred, yes, thank you for a decade of incredible achievements. I am blown away by how strong BPM is and how easy it is today to take a business process definition and make it executable (not to mention change it). You can be absolutely proud of your achievements and I can only encourage you to continue the course on a job well done. Indeed, our industry has invented the perpetual motion at the speed of zero. Ten years from today, the same people will be talking about the same corny and stupid ideas they struggle with today and wonder why in 20 years nothing has happened. Thank you again.