Article: Process Component Models: The Next Generation In Workflow?

Good choice is to use tool which can perfom both actions at one time. Then BPM Folks can model real actions and WS Folks can implement only some basic components.

We choose Logic Base Studio from Transparent Logic (currently part of Altiris) wich is brilliant and effecient solution.

Tom, there is another aspect of this diagram/implementation gap that is missing from BPM discussions. The gap you describe so well does capture how industry thinks about the problem and the fact that most pure-play BPM products 'over state' their ability to 'round-trip' design and implementation. The other aspect is that 'upper case' design has more-or-less disappeared. From Google's perpetually beta services to Ruby scripted web apps, design and implementation is interleaved. The idea that something can be designed by a 'non-technical' user and then later implemented, isn't efficient enough for today's business pressure-cooker.

This makes the design-impl gap even a bigger problem because the cross functional teams tasked with delivering new BPs can't get off the ground. If they can't continuously communicate through iteratively evolving notation of what's being built they are likely going to fail. They have to be able to start with a basic working model that is jointly improved; that all can interrogate and experience as it evolves.

In this mode of development, diagrams with loose to non-existent semantics don't play an important role. On the other hand, diagrams that capture a facet of an evolving prototype are very useful. If the development environment can't spit these out then it just complicates the process of development via iteration.

I agree with you. Probably I didn't state it clear.

In 'Process development process', I agree with you that round tripping between an analysis model and a technical model is basically not solvable. That gap is indeed too big. Therefore, I stated that the translation from an analysis model into a executable (=design) process model is a one-way translation.

But I didn't want to imply that the connection with the analyst is broken at that point. On the contrary, the better the process language (BPEL scores pretty bad at this target), the better the design diagram will match the analysis diagram and then the analysts will still recognize it. Then the diagram serves as the common language between analysts and developers. But since the executable process artifact is now software, it should not be updated by the analyst in e.g. a graphical designer tool at that stage. The input should be collected by the developers in meetings and they should apply the changes to the executable process.

In my presentation for JBossWorld next week in Orlando, I have put a picture to illustrate that reasoning.

While this is the only way that the pure play BPM vendors approach the problem, this is not the only one way of making valid use of BPM technology. By far, most BPM is done by documenting the business processes (with Visio, IDS Scheer's ARIS or a BPMN modelling tool) and then *never* make the processes executable on a BPMS. It's only a small fraction of BPM use cases that try to make the bridge between analysis and design models.

On the other hand, there is the technical approach. Where developers model the processes. In that case there is no analysis model. Only design process models.

I simply love your picture. This is something I've always tried to explain to everybody, customers and IT-experts alike.

I cannot but agree with the global message in Tom’s article. I definitely think that a process components model approach is the way to go when dealing with DSL based on processes.

BTW, I would like to highlight that The Process Virtual Machine technology is the result of collaboration between Jboss and Bull and so you must consider Bull workflow and BPM open source products as a major player in this domain next years. Indeed we are on the road of providing a new version of our open source solutions based on this technology: Bonita (The XPDL open source project) and Orchestra (The BPEL open source solution).

That said, I will also take the chance to disagree with some of the Tom’s arguments pointed out in the article. I have posted a dedicated item on this subject at BPM Corner community .

Regards,
Miguel Valdes
The BPEL open source project: orchestra.objectweb.org
The XPDL open source project: bonita.objectweb.org

I think it's high time we stopped going the pure-play BPM route and came to terms with the realities of delivering customer value. As Tom mentions, Business Process Re-engineering initiatives get too caught up in the 'as-is' & 'to-be' business worlds and pay less consideration to other core aspects such as:

- interacting with the domain model in an efficient manner (crafting lean payload exchanges).
- building service interfaces that deliver more value than being simple decorators to data back-ends.
- allocating time to translate their Process expressions to Process composites.

There just isn't enough discipline and time spent on those aspects. And the result is a multitude of implementations that give BPM/Workflow/Orchestration approaches a bad name.

A reasonable resolution at this point would be to stop pretending like the 'round-trip process engineering' technologies are delivering on their promises and focus on honing three technology areas to make it closer to reality:

1. Process Expression. Let's not get hung up on mapping models to BPEL. It's an impedance mismatch we'll just have to deal with. There are plenty of process expression suites that Business Analysts like to use. Let them work with what they are comfortable with.

2. Process Composition. There is opportunity here to allow a 'Technical Analyst' to begin the process of 'distilling' these expressions into re-usable blocks that properly delineate responsibility between processes, services, domain data & humans. A DSL for expressing process compositions is sorely missed (we have a rudimentary version of our own). Let's focus on expression first. Exchange later.

3. Process Implementation. Once you know the actual scope of the process vs. what the business analyst thought it would do - you can go ahead and define it in BPEL or use a simpler language abstraction like SimPEL (work in progress) for it.

I like to call the resulting solution for the customer an 'Intelligent Composite'. It works. We have happy customers to prove it :).

Cheers,

Zubin Wadia
CTO
www.imagework.com
"Business Acceleration through Process Automation."

Tom,
I liked your artice a lot and agree with the fact that BPEL (and the tools for it) is not suited for BPM. I would go even one step further and challenge the fact that a real business process is far more complex and event-driven and influenced by users and context that it's to my opinion NOT possible at all to model all possible variations to execute it. I guess we need an other mechanism (pattern matching, adaptive self learning systems, event driven) to be able to provide the business with goal driven automated processes.
I have wrote a short blog-item on it in analogy with a route planner.
see: www.gridshore.nl/2008/02/07/what-does-route-pla...

Tom, nice article!

I totally agree with the idea of a component activity framework. I think the idea behind can be used in general for defining domain specific languages.

I've worked it out with some scientific foundation in my blogpost: Combining general purpose and domain specific languages for Model-Driven Engineering

Your article starts very promising. However, I had to stop reading when entering the "Thoughts and comments on BPEL" part.




You write:

"A BPEL process doesn't have a notion of transitions."



Within a <flow> environment you can use <link>s to define the ordering of activities in BPEL. You can have links without transition condition or links with a transition condition which correspond to a BPMN sequence flow or conditional sequence flow respectively. So, in general, BPEL allows you to "to draw boxes and arrows" (arbitrary cycles are not supported).



You are a victim of the commom misperception that BPEL is block-structured. Of course BPEL provides for complex activities like <sequence> and <if>, which allow you defining a block-based process, but BPEL supports also graph-based modelling.



I know it's convenient to learn by reading other peoples articles/papers, but sometimes you guys should really consider taking a look to the specs...



I skipped the rest of your article I but was interested in your conclusion:


"BPEL is an executable process language, which [...] is not suited for supporting Business Process Management"


Then you say:


"By using only the intersection of what the analysis language and the executable process language offers, a common language can be created for the business analyst and the developers, based on one single diagram."



Well, why not taking the intersection of BPMN and BPEL, which is BPMN plus DPE (Dead Path Elemination) minus arbitrary cycles, or simply BPEL (maybe minus WSDL)? :-)

I think on of the common problems with BPEL,BPMN and all the other Business Process Standards/Languages is how BPM is marketed. Like so many technologies over the past 20 years it is portrayed as now you don't need to program. Of course they all have programming interfaces, and here is where these languages over sell and under deliver. The language of business process analysis is still English.

Craig

With BPMN 2.0 most of the things described
in this good article will change,
see www.omg.org/cgi-bin/doc?dtc/09-08-14

- it can be refined to be natively executable,
BPEL is build in
- it has a defined metamodel and own exchange format,
XPDL is no more needed.
- it fills the gap between business and IT using a
single model and common language, but of course business
only needs a subset