Article: The Seven Fallacies of Business Process Execution

Posted by Stefan Tilkov on Dec 05, 2007 02:23 PM

Community

SOA

Topics

Business Process Modeling,

Workflow / BPM

Tags

WS-BPEL,

BPEL4People,

BPMN,

BPEL,

WS-CDL,

Service Component Architecture

In a new InfoQ article, Jean-Jacques Dubray, InfoQ SOA editor and author of the InfoQ minibook "Composite Software Construction",  explores a new architecture blueprint for BPMSs that offers a cleaner alignment between SOA and BPM. Jean-Jacques argues that after  more than eight years of intense research, the promises of BPM have not materialized: we are still far from having the ability to use the business process models designed by business analysts to create complete executable solutions.

Jean-Jacques lists what he considers to be the main myths, the typical misconceptions with regards to BPM:

1. Business analysts model their processes from a system's point of view
2. Business users can easily learn BPMN and use all its features
3. Business analysts should be able to create executable solutions from process models
4. If we add a magical BPMS that create solutions directly from business analysts inputs we would not need to develop any of integration with existing systems nor to change existing systems of record nor to do any QA.
5. Business Process Execution must be centralized
6. Business Process Execution semantics can be derived easily from existing programming concepts
7. The collaborative implementation paradigm, in which executable design is layered on top of the BPMN model, is the way to go.

He addresses each of these in turn, explicitly detailing his own alternative vision with regards to #5.

Read the full article here.

1. Back to top

   A useful list of fallacies though light on the role of business rules

   Dec 4, 2007 3:16 PM by James Taylor

   I blogged about this article and discussed some of these fallacies as they relate to business rules and decision management. Some of them could be less true if BPM vendors/practitioners took decisions more seriously and some of them are great analogies for similar issues in the rules space. Check out the post here. JT The Smart (Enough) Systems blog My ebizQ blog Author of Smart (Enough) Systems

   Reply

2. Back to top

   Re: A useful list of fallacies though light on the role of business rules

   Dec 4, 2007 3:18 PM by James Taylor

   Link got broken. Here is is: http://www.ebizq.net/blogs/decision_management/2007/12/some_thoughts_on_the_fallacies.php

   Reply

3. Back to top

   GRAFCET and resource management

   Dec 7, 2007 3:35 AM by Azrul Hasni MADISA

   I blog aout how GRAFCET can be used to do resource state management [ http://azrulhasni.blogspot.com/2007/12/grafcet-and-resource-state-management.html ] do take a look

   Reply

4. Back to top

   Business-IT alignment should still be an aim

   Dec 7, 2007 6:12 AM by Marlon Dumas

   Jean-Jacques I can not but agree with many of the opinions you share here. However, you seem to be overly pessimistic regarding the possibility of aligning IT systems with business operations by bridging analyst-level process models (e.g. BPMN) with executable process models. Granted, there is no magic button that will bridge the two. However, sound methods and wisely chosen tool support can go a long way in this direction. For example, if we align BPMN models with BPEL process definitions, we can at least partly elucidate the impact that business-level changes have at the implementation level. Oracle BPA, for example, is a modest step in this direction. Clearly, it's not a silver bullet, it won't magically solve the business-IT alignment equation, but still, it shows that something can be done to keep business models and code in sync. The question of how "task-centric" should process models be is valid, but perhaps orthogonal to the BPMN round-tripping debate. I mean, we can argue if BPMN's task-centricity is the way to go for process modeling (at various levels of abstraction), but that's a separate point.

   Reply

5. Back to top

   Re: A useful list of fallacies though light on the role of business rules

   Dec 7, 2007 9:14 AM by Jean-Jacques Dubray

   James: BRMS are definitely my area of expertize and I second many of your comments. Just a couple of precisions: >>There is no reason why this information systems cannot also decide how to act Actually I totally agree, I thought this was conveyed by "advance.. the state", but I am glad you made it clearer. >> I do think that collaboration is key - business users and analysts must be able to collaborate with IT to define processes and decisions I think the question is really focused on "collaborate" vs "communicate". I would argue that "communicate" is a better value proposition than "collaborate". Collaborate implies for me long joint sessions, communicate conveys a better separation of work and clean handoff. You collaborate because you can't reach the point where this hand off is possible.

   Reply

6. Back to top

   Re: GRAFCET and resource management

   Dec 7, 2007 9:22 AM by Jean-Jacques Dubray

   Azrul: thank you so much for bringing back so many memories. I used the GRAFCET in the early 1990s as I was building (industrial) process control systems for the semi-conductor industry (using Objective-C and NeXT on the front-end). I had actually tried in 1999 to discuss these concepts with the team I was working with at eXcelon so I do believe the concepts are good but I also believe that BPEL can do the job just fine. It is not perfect, but I can live with it, compared to starting over, I'd rather fix a few things in BPEL. If you read about "wsper" you will also realize that the core of the wsper programming language is very close to the GRAFCET. I had not looked at the language in almost 10 years, so I can't claim this was a conscious decision, but I argue I can compile this language in BPEL.

   Reply

7. Back to top

   Re: Business-IT alignment should still be an aim

   Dec 7, 2007 9:44 AM by Jean-Jacques Dubray

   Marlon: thanks for your comments. I am very impressed by how far your team has been able to go. It means that BPEL as a language is pretty well designed, considering the fact that you are imposing the constraint of generating readable BPEL code. I am actually not "pessimistic" about aligning BPMN with executable process semantics, I am simply saying that I am a bit surprised that this is the direction some people are looking at because it negates the existence of the "resource" as a key ingredient of the process. Now it does not mean that your work is not useful at all, as you mention understanding the impact of changes at the process definition level is a key benefit. I am pretty sure also that you could go in the other direction and provide a view of the "process definition" once the BPEL code has been implemented, such that business users would have automatically the "as-is" view of the process should they be looking at improving the process at a later stage (this has tremendous value because analysts spend a lot of time just understanding what is the current state). Finally, another area of interest could be "verification" that the process implementation (based on an assembly of BPEL definitions) actually implements the process definition. >> we can argue if BPMN's task-centricity is the way to go for >> process modeling (at various levels of abstraction), but that's >> a separate point. The key question is whether you want to take the point of view: "A process is the collection of activities that advance the state of resources as they are transformed or consumed", this is a 100% task centric proposition (automated -james, this where decision services would fit, or human tasks). If you take the point of view that a process owns everything between the presentation layer and the data access layer, then I would say you are driven towards the kind of approach that you are exploring, and therefore you are faced to have developers to tweek the BPEL code, or business analysts to use BPMN in a way that write the correct BPEL. My proposal is quite different, it starts from the resource / business entity level and assume their lifecycle to be fairly stable (and unbreakable, meaning a process cannot change the lifecycle of a resource once it has been defined). From that point the process is simply an assembly of resource lifecycles and "activities", there is much less code to write, the BPEL code has been written once and is reused in any process the resource is involved. I was actually quite amazed to see Dominique Vauquier comme to the same conclusion but coming from a pure methodology angle, trying to improve the way business analysts improve processes. I can only encourage you to read his article that I translated from French and that will be published on BPTrends next month. The problem of your approach is that you can never be sure that a process will not lead to unwanted transitions in the lifecycle of the resource.

   Reply

8. Back to top

   A team of researchers at IBM Research in Zurich is working on this topic.

   Dec 10, 2007 9:55 AM by Jean-Jacques Dubray

   Marlon Dumas was kind enough to send me the link for the home page of Ksenia Ryndina which contains many articles that explains their research (which is very applied since they have already built some prototypes with WebSphere Business Modeler). I have exchanged an email with Ksenia who confirmed the relationship between her work and this article. She recommends reading a couple of references available on her home page:

   • Generation of Business Process Models for Object Life Cycle Compliance
   • A Tool for Integrating Object Life Cycle and Business Process Modeling

   Reply

9. Back to top

   Good taxonomy and ontology for modeling data, service, process, human-wf

   Dec 18, 2007 8:33 AM by Kjell-Sverre Jerijærvi

   You describe exactly how many misses out how important "resources" (domain objects) are in SOA. People are too fixated on the business processes when modeling their services and orchestrations, and thus forgets to create and govern a semantic canonical data model (or equivalent semantic transformations). This is what David Linthicum, Jack van Hoof, Nick Malik, you, me, and others blogged about this july. I have commented 'fallacy #5 Business Process Execution' and related it to the CDM discussion and service taxonomy (processes vs orchestrations) discussions in my blog: http://kjellsj.blogspot.com/2007/12/business-model-taxonomy-ontology-domain.html

   Reply

10. Back to top

    Interesting article, but we still need executable business processes

    Dec 30, 2007 2:21 PM by Alexander Samarin

    I blogged about this article - see http://improving-bpm-systems.blogspot.com/2007/12/this-blog-posting-is-reply-to.html My comments on this article are based on my experience as an seasoned IT specialist; they are also expressed in my forthcoming book “Improving business process management systems” (see http://www.improving-bpm-systems.com/)

    Reply

11. Back to top

    What about using the Process Virtual Machine ?

    Jan 12, 2008 4:48 AM by Miguel Valdes Faura

    Hi Jean Jacques, Find hereafter my last post on the BPM Corner community on how the Process Virtual Machine could be consider as a core technology to implement most of the containers and modules required in the architecture your propose to handle business process. best regards, Miguel Valdes BPM Corner, http://www.bpmcorner.org

    Reply

12. Back to top

    repeating patterns...

    Jun 6, 2008 7:19 AM by Shaun Forgie

    Firstly congratulations on what is one of the most lucid and well written process modelling articles I have every read. Believe me I read a lot...:-) Historically the progression from procedural programming languages to object oriented programming languages has allowed us [humans] to build systems significantly more complex by establishing an appropriate set of conceptual and language related aparatus with which to manage this complexity with. Objects encapsulate data and behaviour that relates to a small piece of a much more complicated working system. This bigger composite solution is made easier to understand due to the fact that we can progressively dismantle it into smaller pieces. Thus complexity generally is managed through a recursive process of division and dismantling a big thing into smaller pieces that are individually easier to understand. The fact that resources can exist independently of a process and the fact that they can participate in more than one process means that the need to understand and model them as separate entities is an important conclusion. A workflow process therefore can be viewed as a resource [state machine] co-ordinator responsible for transitioning one or more resources through one or more transitions. The complexity has always been in trying to understand and describe a process environment where the triggers responsible for firing these resource transitions can originate indeterminately from either a human and/or system generated event. This problem has been compounded with the introduction of Business Rules and Scheduling sub-systems. In my mind process models can be viewed as structural relationships between input and output resources where the relationships between resources can be defined as transition tables and valid process execution sequences of transitions contained with process resources.

    Reply

13. Back to top

    Re: repeating patterns...

    Jun 6, 2008 7:22 AM by Shaun Forgie

    I guess in the end its the recursive application of state machine semantics to progressively smaller and more detailed descriptions of a workflow / orchestration or process. The notion of a task container is really just another way of understanding how transition events get trigger.

    Reply

• Older >