Jesper Boeg on Priming Kanban
In this interview, Jesper Boeg, author of the new InfoQ book – Priming Kanban, discusses the keys to using Kanban effectively, and how to get started if you are currently using other approaches.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Article: Process Component Models: The Next Generation In Workflow?
Posted by Floyd Marinescu on Feb 11, 2008
Read Process Component Models: The Next Generation In Workflow?
Going into detail on separating the execution framework from the process framework, Tom explains:
A first observation is that multiple process languages can be implemented on top of the same activity component framework. Each process language is composed of a number of activity types. For each of those activity types, the runtime behaviour can be implemented in a general programming language like e.g. Java or C#. So an executable process language just becomes a set of activity type implementations. The most important part of such an activity component is the code that implements the runtime behaviour of the process constructs. But also the XML serialization, the designer forms to configure the process construct, persistence and many other aspects can potentially be included in a process construct component.The article has already been commented on by several other BPM framework providers including Sun's middleware & standards guru Mark Hapner.
- This article is part of a featured topic series on SOA
- See more SOA content at: http://www.infoq.com/soa
- Other recent content items in this topic
Make a good choice
by
Rafal Ziolkowski
Posted
Design diagrams that are 'input-only' are declining in value ...
by
Mark Hapner
Posted
Re: Design diagrams that are 'input-only' are declining in value ...
by
Tom Baeyens
Posted
Re: Design diagrams that are 'input-only' are declining in value ...
by
Jarkko Lietolahti
Posted
Process Component Model
by
Miguel Valdes Faura
Posted
Good one Tom...
by
Zubin Wadia
Posted
What does Route Planning has to do with Business Process Management?
by
Freddie van Rijswijk
Posted
Formalized DSL definition
by
Johan den Haan
Posted
Common misperception about BPEL's block-structured nature
by
Jörg Nitzsche
Posted
Business Process Analysis Language
by
Craig Cameron
Posted
BPMN 2.0
by
Norbert Weissenberg
Posted
-
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
11 comments
Watch Thread Reply