jPDL is a simple but powerful workflow language for the Java platform embeddable in both standard and enterpise applications. The new 3.2.GA we just released, adds enterprise, email support, a new webconsole. Also we significantly improved the POJO versions of the timer and message services.

jPDL is extremely lightweight. Whereas other BPM technologies heavily depend on web services and XML, jPDL is a natural extension to Java. The interface is a Java API, the process variables can be any POJO and including pieces of Java code into the process is peanuts. jPDL can run on plain Java platforms like a web application deployed on Tomcat or even a standalone application.

For enterprise support, there is now an out-of-the box configuration that shows how to configure jBPM in an enterprise deployment. Along with that, there are a set of EJB's that implement the services required by jBPM, leveraging the services on the enterprise Java platform like JMS and the EJB timer service. All the dependencies are on standard JEE technologies so it is easy to run jPDL on any application server.

For email support, you can now have an email node like this:

<mail-node name="send email" to="#{president}" subject="readmylips" text="nomoretaxes">
  <transition to="the next node" />
</mail-node>

But there is more. When writing a task node like the next, you can just add notification and reminder emails just with a single attribute:

<task-node name="wash"> 
  <task name="laundry" swimlane="grandma" notify="yes" >
    <reminder duedate="2 business days" repeat="2 business hours"/>
  </task>
  <transition to='b' />
</task-node>

The console went through a major update and is now based on JSF and Facelets. Especially facelets turned out to be a very good match with task forms. Task forms are now generated at design time with the graphical designer so that developers can customize the layout if they want. The forms are facelets documents (plain XHTML) that are included in the process archive.

The POJO implementations of message service and scheduler service were rewritten to provide better and more robust support for concurrent access. Basically, you can now run the complete POJO version of jPDL in a tomcat cluster if you want; multiple threads are allowed to execute the jobs at the same time.

Go check it out:

• JBoss jBPM Website
• jPDL Downloads
• Online user guide
• User Forum
• Wiki

The link between models and code is overdue on a serious revision. Hard core developers usually hate point-and-click IDE's. Managers make models that are not in sync with the software. The current perception that software artifacts is generated from models is seriously flawed.

This is my conclusion after several years of building the JBoss jBPM process engine, which targets business users *and* developers.

After messing with assembler, programming languages grew higher and higher level. Then UML went mainstream. In that context it was assumed that developing software would be done with models in a short future. This is the typical MDA vision.

Higher level abstract models improve communication with business users. But there is the tradeoff between flexibility and complexity. To be executable, software needs to be specified precise and with lots of details. Putting all these details in the model, makes the modelling language too complex for its purpose.

Models should be projections of software artifacts. This should replace the idea that software artifacts should be generated from models.

The argumention goes like this: First, we recognize that there are different types of authors involved in creating software: business users and developers. Business users can think along on the model level, but they don't know about the technical details. Developers are the power users. They can write the actual software artifacts and communicate through the models with the business users.

Also developers should be differentiated: Currently, developers are real powerusers. They type in straight Java code way faster then any point-and-click IDE could enable them. But i think that a whole bunch of less experiences technical people are impatiently waiting until they can use languages (or subsets of languages) that are less complex. They are willing to trade flexibility for simplicity.

If models are a projection of actual software artifacts, there is no need for the models to contain all the details. A very good example of this notion is the method implementation in UML class diagrams. In UML class diagrams, method implementations not available, which is good because that makes it possible to get the overview. The collapsable compartiments in class boxes are another illustration that sometimes you don't want to show all the details in your models.

Before 'markerless round trip engineering', we have been able to experience that keeping models and code in sync is not possible for the majority of software teams. So in this context, it also makes good sense to distill the models from the actual software artifacts. That way, they can't get out of sync. I'm not even close to a UML tooling connoisseur, but the best approach I have seen in UML class diagrams was the old Together IDE. In that tool, the models were generated from the code. The diagram file only contained the graphical information which was not part of the Java code.

So in my refined model software is composed of many software artifacts in various general purpose programming languages and a bunch of domain specific languages (DSLs). The value of models is that many of these deployable software artifacts --that contain great detail-- can be projected, resulting in a visual diagram that shows the higher level concepts without the details.

In the picture above, i have represented the actual software artifacts in the middle. These software artifacts are written in a general purpose programming language or a domain specific language. DSL artifacts are usually input for runtime frameworks. But the main point is that the software artifact layer contains all the details necessary that define an exect behaviour of a runtime environment.

Some (not all) of the software artifacts can be reprensented in models. These models can be generated from the actual software artifacts. Business processes are a great example of this.

So my conclusion is that models should be projections of software artifacts. Wether people use the model-editor or the text editor to author these artifacts doesn't matter. Of course, business users will more often use the model editors and developers (the power users) will use the text editors more often.

Another aspect that is highlighted here is that software is being build as a mixture of general purpose programming (e.g. Java) and a bunch of DSL's which serve as input for frameworks. So the thing that currently is mostly overlooked is refactoring over these language boundaries. The future IDE should be able to detect and execute refactorings over language barriers. That is when we'll get really agile development teams.

Note on relativity: I know I may sound like I just had a great innovative insight. It sure feels that way :-) But most probably, as with many things in life, this will be invented, described and analysed many times before in many different contexts... If that should be the case, I thing it was definitely worth bringing it again to your attention :-)

Regards,
Tom Baeyens
Founder and Lead of JBoss jBPM

On monday I spoke at the Open.BPM 2006 in Hamburg and exchanged ideas with a bunch of German academics. In contrast to typical Java conferences, ideas are challenged in amusing and heated debates. Great!

Overall, I was reinforced in my current perception of the BPM landscape:

• BPM vendors present process languages to the business users, but no runtime executional model, which causes great fragmentation in the market since no two BPM tools are similar.
• The academic approach is formal, but not very practical. Even while the constructs that they used are very simple, using petri nets or PI-calculus as a basis for process modelling is problematic. E.g. It took me 5 minuts to understand the basics of petri nets and it took me 20 minutes to understand the diagram that modelled a traffic light. That was a real masterpiece :-) But it indicates that creating and reading such models is not trivial.
• So the only way that these two worlds can come together is if they are able to define a rich set of business user constructs that can be translated into the formal semantics of PI-calculus, petri nets or something similar.
• For jBPM, process testability and refactoring over Java and process boundaries have higher priority then reasoning over process diagrams.

The most interesting discussion i had was with Frank Puhlmann of University in Potsdam. He's exploring PI calculus as a foundation for BPM modelling.

Exactly as stated above, Frank's vision is to define a set of coarse grained process constructs that are macro's made up of PI-calculus constructs. That way the coarse grained process constructs are intended for the business user and the translation to PI-calculus constructs can be used by the tools to calculate if the process is sane.

He considered PI calculus as better then petri nets because dynamic behaviour is added. Petri nets are static, whereas PI-calculus introduces a notion of reference that can be passed to other nodes in the graph. Then these references enable nodes to have dynamic bahaviour based on those references.

I think that his approach is challenging and I'm curious to see the results of that work. On the one hand, I would like to know what kind of business user constructs can be defined on top of PI-calculus constructs. Will the resulting process language be powerfull enough ? And on the other hand I'm curious what kind of information can be derived from algoritmic reasoning over PI-calculus constructs. Will it be worth while ? Will this information be interesting to the business user or the develop involved ?

If this approach turns out to be usefull in practice, it would fit really well with our Graph Oriented Programming approach. (Note that we're in the middle of reshaping this to a Process Virtual Machine) Basically what we define is a framework in which it becomes really easy to implement process constructs. So if your process language is made up of constructs that can be expressed in terms of PI-calculus, then all the reasoning could be enabled. Frank's work is based on pre- and postconditions. Which would imply that with each node implementation, the node developer could indicate the pre- and postconditions that are relevant for PI-calculus reasoning. That would make it easier for node implementors then translating their node into PI-calculus constructs.

For the jBPM foundations, testability and refactoring capabilities have a higher priority then reasoning over process models. I'm certain that the former two represent real value to developers that have to make the business processes executable. Also this makes process developement fit right into plain Java development. And reasoning still has to prove itself to be usefull in practice.

jBPM jPDL is a process language targetted for the Java platform. It includes a graphical designer, the runtime engine and a web console. Main focus of the process language is a clean integration with plain Java and task management. The jPDL runtime engine and database can be easily integrated within your project. Note that other process languages like e.g. BPEL are made available in the jBPM platform as a separate package.

The thing you just HAVE to try out is the new email integration. It took us quite a while to find a good template language that could mix static email content with dyncamic process variables content. After the integration of the JSF expression language, it was an obvious consequence that we would reuse that expression language for our email integration.

Step 1) -- Thou shall download and try out jBPM jPDL 3.2.Alpha1 --

Step 2) If you still didn't click and install the download, put on your hypnotizing-voice, do some magical handwaiving and goto step 1.

The process modeling versus implementation debate continues:

• On Spreadsheets, Clean Handoffs, and a Dinner Bet

Other posts in this discussion:

• What BPM can learn from a Spreadsheet
• The Promise of Unified Process Modeling and Implementation
• BPM modeling as easy as a spreadsheet
• http://www.ebizq.net/blogs/bpmblog/2006/07/spreadsheets_and_bpm_part_i_de.php
• BPM: The Glue Between Analysis and Implementation

The clean handoff says business does modeling, IT does design, and anything that blurs that separation is inherently dangerous. (In fact, even directly creating skeleton design from the model is somewhat distasteful, but don’t worry, IT can change it later…) The collaborative vision says the line between modeling and design is a fine one and blurring rapidly. ... Ogren sums it up in one line: “The process model is the implementation.”

The difficulty in getting concensus in this discussion is that there are various skill levels of business people. Some just barely know how to use a word processor, while others are able to do some minimal coding.

As you put it nicely, we are in the "the clean-handoff vision" camp. But I don't think that the two visions are that far apart. I would like to refine our position and show where I see the touch point.

The clean-handoff vision doesn't imply you need IT to make it executable. Even in the clean-handoff vision you can strive for good coverage of process langauge constructs. The more constructs the better. But there is a fundamental tradeoff: A process language with a process construct for everything that a business person ever might want to express in a process diagram box will become too complex. The more coverage of the process language, the more complex it will be. The simpler the process language, the simpler the GUI will be and the lower the entry barrier for less technical business people. This implies that we are not looking for the ultimate process language. We can think of many process languages that make sense, I would even include Keith's spreadsheet as one of them.

So that is why it is hard to agree upon a specific process language: there is a whole range of process languages on the spectrum. A process language targetted to have non-technical business people create executable business processes will be very different from a process language that tries to have a broad coverage.

In my opinion, the process only 'is the implementation' in case the used process constructs are covered by the (always limited) process language. I would like to rephrase this as 'The process can always be a projection of the implementation'.

In this context, I see 2 features missing in most of todays BPMS solutions:

1. Pluggability of process constructs: Most languages offer a fixed set of process constructs. The bridge to a general purpose programming language has to be natural in such a way that a developer can code the process construct if it is not available out of the box. In jBPM (based on graph oriented programming) and windows workflow foundation this is key. I see the article by Daniel Rubio on Winfows Workflow Foundation as one the first signs that this idea is being picked up.

    

   One of the nice implications is that you will have a kind of empty process engine with a default set of process constructs that come out of the box. The process constructs will be deployed in the engine in a packaged format. A process construct package includes the runtime implementation, and optionally a description of the configuration parameters, an icon, a UI form for the configuration parameters, a projection that filters the design time information from the runtime information to be used during process deployment,...

2. Hidden actions: A developer has to be able to add technical details invisibly so that the business people can remain in control of the graphical representation of the process. This can be realized with some kind of event mechanism in which general purpose programming code can be associated with events in the process without the requirement of representing this visually.

OK, so here's my prediction of two movements that will be happening in the BPM arena. Please, interpret this overstatement as a challenge and motivation to write your response down :-)

1) The quest for the ultimate process language will be replaced with embracing a model like windows workflow foundation or graph oriented programming. These are actually models that define the interface between the process engine and the process constructs thereby making them pluggable.

And 2) More emphasis will be on the individual process constructs and less on complete process languages. That is much more feasible then trying to come up with a complete process language. This will result in node packages that you can drop in a kind of deployment directory in our generic engine. Once the interface between the engine and the node packages is defined clearly, this can create a similar component model as with e.g. JSF-components.

To conclude: I see the clean handoff vision as an extension to the collaborative vision. In the collaborative vision, business people model the process and the process is the implementation. It is certainly possible to have business people create executable processes in some scenarios. Depending on how complex your process language is (or how many simple process languages you combine), and the technical skills of your business people, the scope of this kind of process automation will vary. I subscribe to the above and see the clean-handoff as an addition. A technical developer should be able to easily integrate programming logic in case the business person cannot express an activity with the process constructs offered by the process language.

Comments can be posted here in the jboss forums.

regards, tom.

Can workflow or BPM simplify the way that software is being build ? Yes and no. Yes, it can improve the way that requirements are being translated into software. No, it will not enable business analysts to write software. BPM technology walks the edge between requirements and implementation. BPM vendors suggest the miracle that drawing a graphical process in their BPM tool will unify analysis, requirements and implementation. I guess it makes sense when you put it like this. But regrettably, many BPM vendors have a poor story on the bigger picture.

This post will address the two main problems i have with current thinking around BPM and workflow:

1. BPM vendors often overpromise by hinting that BPM tools can unify analysis with implementation
2. Lack of integration between processes and plain general purpose programming language

Analysis and implementation cannot be unified

Wether software development though a programming language like Java or wether it is developed through processes in an executable process language doesn't change the fact that a translation has to be made from the analysis over software requirements to an executable software model. The fact that it is graphical doesn't change a whole lot in that respect. A process developer has a set of process language constructs and needs to come up with a process that is a solution for the software requirements.

For the sake of this post, I'll define analyzing, as trying to understand the problem domain and creating a description of the problem domain. And let's define creating an implemention as creating software artifacts that are executable by a computer system. My main point is this: "You can analyze or you can implement, but you can't do both at the same time." This will have far reaching consequences and it was an important factor during conception of our jPDL process language.

Analyzing means searching for the way things work. You're concerned with understanding the problem domain and describing it as good as possible. Creating an implementation means that you are creating an algorithm in terms of primitive constructs. Executable process languages provide a different set of primitive constructs than a plain programming language like Java. But if the process language is executable it implies that you're building an algorithm.

Keith Swenson and David Chappell have been arguing that BPMN is (going to be?) the analysis model and that BPEL is to be seen as the runtime model. They triggered me in formulating these ideas. Consider the following as my comments on the bigger picture of their statements.

The more formal an analysis language, the easier it is to make the result executable, but the harder it will be to use it for analysis purposes. E.g. a text processor like "Word" and a drawing sketch will always be flexible enough to describe your problem domain. But that doesn't translate automatically into executable software. On the other hand, when using e.g. BPEL to describe your problem domain, --which is an executable process language-- you will be specifying an algorithm and forced to think in terms of how the computer system will execute your process. An executable process language is already executable, but it is less flexible to be used for analysis purposes.

The relation between BPM and Business Process Management Systems (BPMS) is often misunderstood. Even by many of the BPMS vendors. They often make it look like their graphical process designer tool enables to analyse the problem domain (in terms of processes), distill the software requirements and create an implementation in one go.

To illustrate our point of view, we'll show two separate chains and we'll discuss them in both directions.

Analysis Chain People and systems working together in an organisation /\ || || \/ Informal description of people and system working together in e.g. natural language or a sketch /\ || || \/ Formal description in a strictly formal analysis language

Implementation Chain Informal description of an algorithm /\ || || \/ Formal description in e.g. general purpose programming language or an executable process language /\ || || \/ Creation of the runtime artifacts. E.g. compilation. /\ || || \/ Deployment of the executable process into a runtime environment /\ || || \/ Runtime execution of the process

First of all let me make the remark that this list is only intended to illustrate the direction concept and the difference between analysis and implementation. It's does not intend to show that all of these stages need to be done in sequence. In practice, these stages can be skipped and executed in any order analogue to the iterative software development model.

The analysis chain shows that there are various levels of formality in which you can describe your target domain: Ranging from pure english text to a formal analysis method. As an example in this domain, IDS Sheer's ARIS is a good tool to write down your analysis in a formal language.

Separating the two chains represents the fact that we believe there is no natural link between the result of analysis and creating an implementation for software requirements. The direction we're taking in our jPDL process language is that we try to enhance the process with free format annotations and decorations such that it can accomodate some parts of the analysis domain. In many cases that might just be sufficient. But that doesn't change the fact that we're showing an implementation model.

Also the way we conceived the jPDL language was to be an executable process language (an implementation model) but with features so that it can accommodate parts of the analysis model. Of course, never in the pretension that we can replace an analysis model. In essence, the jPDL language defines how a graph can be specified, executed and how java code can linked in that graph.

jPDL comes out-of-the-box with a set of preimplemented node constructs (as like any other process language). But a developer can write code and link this code as the implementation of the behaviour for a node in the graph. This means that a business analyst can draw a node visually and describe the behaviour in plain english. Then the developer can write the java code to implement the description.

Also jPDL contains a mechanism for inserting pieces of Java code in the process without changing the diagram. This is necessary to give the developer enough freedom to make the process executable without messing with the business analyst's diagram. No other process languages I know of has a similar feature. And yet, it seems crucial to me to have some sort of separation between the diagram, owned by the business analyst, and making the process executable, a responsibility of the developer.

Without this feature, process creation always boils down to visual programming. First of all because other process languages restrict the process designer to use a fixed set of process constructs. Each process construct has a runtime behaviour so an analyst needs to think in terms of runtime execution rather then the process that needs to be expressed. Also because no hidden code can be inserted, every little detail needs to be represented in the diagram, even if the business analyst is not even slightly interested. The interest of the business analyst should be the discriminator: IF the BA is interested, it should show up in the diagram, otherwise it should be hidden.

Going back to the direction from informal to executable, you can now see that a business analyst can start modelling a process with nodes (rectangular boxes) and transitions (arrows). As long as there is undefined pieces in the process, it's not executable. Sometimes the business analyst already might pick the right node types from the pallette and configure them properly depending on his/her skills level. But most often, there will have to be some custom code tied to the process either as node behaviour or as actions which are hidden from the graphical diagram. Only when that is complete, the process becomes executable.

As a side note, we believe that it is bad practice to overload the graphical representation with massive amount of decorations to try and express every little technical detail of the process. But the most important point is that you can create a common language between the technical developer, who is responsible for making the process executable and the business analyst, who is responsible for coimmunicating the requirements. Having these discussions around a graphical diagram is extremely helpfull. That is why we created the simplest possible graphical representation for our processes: boxes and arrows. Only an optional icon and the stereotype in the box can give a hint to the actual runtime behaviour.

In the other way round, developers can start extracting and centralizing state management from their application logic and create processes to speed up development of a plain java application. Then, they can use a graphical print of the process in meetings with stakeholders. Note that the graphical diagram does not have to be kept in sync with round-trip engineering. The graphical diagram is in fact a projection of your runtime artifact. It's just 2 different views upon the same process.

BPM automation requires easy integration of programming logic

If you compare all software artifacts being created in a today's software development project, typically the largest portion of that will be written in a general purpose programming language like Java. Apart from that you have e.g. ant build scripts, hibernate mappings, deployment descriptors and various configuration files. In all of the BPM world, there is a complete LACK of vision on how processes fit in there. Processes are always considered separate.

While on the one hand, we try to accommodate analysis data in our jPDL process language, on the other hand, we made sure for a very clean integration with Java. In fact, the Graph Oriented Programming principles, which form the basis for jPDL can be applied to any other object oriented programming language.

In practice, this means that programming logic (Java code in case of jPDL) must be easily integratable into a process. Also processes must be accessible and executable via a simple Java API. And last but not least the API must integrate with the transactions and other services in the overall application environment in which the process is used.

Without a simple and clean integration with a general purpose programming language, a process language is not really suited for automating business processes. Take BPEL for example. While it's an excellent integration technology with great value, it's not very well suited for automating business processes. To include a piece of programming logic, you need to write a piece of code, expose it as a WSDL service and invoke that service from your process. Even without the XML/object conversion that would be a pain.

Process languages have 2 key features which are not available in programming languages like Java: support for wait states to express long running executions and a graphical view of the execution flow. Process languages targetted at simplifying BPM automation should focus on those two key features and leverage plain programming languages for what they are good for. Looking at most process languages, the process constructs are mostly configurable versions of some API usage where the API offers more flexibility.

Conclusion

Despite the suggestion by most of the BPM tooling, analysis and implementation cannot be unified. However it is possible to add features for analysis to an executable process language. But that doesn't change the fact that it's implementing and cannot replace an analysis model.

Currently BPM is associated with BPEL and integration. We believe that BPM is much better served with a process language that integrates nicely with a general purpose programming language such as Java. That doesn't imply that BPEL is bad. On the contrary, BPEL is a great integration technology. We simply want to pinpoint that the association between BPEL and BPM is inappropriate. For making the automation of business processes easier focus should be on creating clean integrations between process language and programming language such as we did with the jPDL process language.

Comments can be posted on this topic in the JBoss jBPM user forum.

I suspect that the first person to associate BPEL (Business Process Execution Language) with BPM (Business Process Management) was a great mind in marketing from some PR agency and never read the actual BPEL specification. The specification is not that easy to read. So i guess that is why this marketing buzz spreads itself much faster and further then then the knowledge of the specification.

How's BPEL different from BPM

BPEL is a web services programming language. You can write new web services as a function of other web services. Interface to a BPEL process is XML based (WSDL to be pore precise) and the variables inside of a BPEL process are XML snippets.

Oracle is currently the only force pushing BPEL in the marketplace. I got a Google alert on 'BPEL' and rougly 7 out of 10 items are from them. Recently launched Oracle Fusion. That is their new ERP platform that combines all their purchased products. In their Fusion vision, they put BPEL as the integration glue between all those applications. I think that makes sense. That is using BPEL as an integration technology. But they still associate all this integration with BPM. I consider this a legacy misunderstanding.

The goal of BPM is to make an organisation run more efficiently by carefully managing the core procedures and operations. Information technology can be a big factor in making it happen. But most often the inertia of software can't keep track with the changes in the business processes. That is what all the BPM software products are aiming for. Creating an information technology that supports easy automation and easy maintenance of software for supporting the core business processes of an organisation. Little concensus about the foundations of such a technology have been established and hence this still is a highly fragmented market.

Agility is key... also in BPM

Achieving this goal requires software agility. Also Phil Gilbert, the CTO of Lombardi has got it right on in his blog 'BPElephant". Congrats to Phil for standing out in the crowd. It made me realize that i got tired of fighting the BPEL-BPM misconception. Thanks Phil, for sparking my fire again :-)

Agility in software development means removing all overhead from the software development process. The effort spent on software updates because of changing requirements should be minimized. Test Driven Development has been proven a crucial factor in this. So in our vision, a business processes should be developed exactly the same way. For each process, there should be a number of test scenarios with assertions that verify if the process does what it is supposed to do. Only with an extensive test suite (also for your business processes) you can implement changing requirements efficiently. Integration technologies like BPEL are *very* hard to unit test. And concequently it will never lead to an agile organisation when all of your business processes are modelled in BPEL.

Actually, this shouldn't be interpreted as if we (JBoss jBPM) are against BPEL in any way. On the contrary, we think it is a great *integration* technology. We just want to fight the perception that it is also a good BPM technology. We have not always said that clear enough. So to make that really clear: BPEL is one of the process languages in the jBPM suite and it's got half of our resources dedicated to it.

So what's the alternative

Now that you know that BPEL is not a BPM technology, what's the alternative. I wish that we could claim something like: "Look at tech X, it's stable, mature and it's backed by a broadly supported standard" We're not there yet, but there are already some very interesting products that can get you a long way.

IMHO, two products take a different perspective and are leading the way to consensus in how BPM software should look like: JBoss jBPM and Microsoft's Windows Workflow Foundation. The goal of traditional BPM products is to create the ultimate process language The best process language ever ! JBoss jBPM and Microsoft's Windows Workflow Foundation support multiple process languages. Different environments require different process langauges.

For the first time in the BPM market place, two individual (at least to my knowledge:-) developed products look very similar. For Microsoft, this may have been a pragmatic approach, because they have multiple workflow and other graph based execution languages. So it makes sense for them to create a reusable base framework for all of these languages.

We started with Graph Oriented Programming 4 years ago. That is the simple and solid foundation for building graph based execution languages. In my future view, a limited number of process languages will be built on top of this technology. BPEL is one, but also a process language that cleanly integrates with the Java language is necessary. I can forsee a few other languages as well, but not a big number.

Knowing Graph Oriented Programming helps to understand BPM concepts in general. It's similar like the knowledge about tables, tuples, foreign keys and transactions in the world of database systems. In the broad BPM market, such a common foundation is completely lacking and has resulted in fragmented BPM marketspace we have.

Conclusion

BPEL is a good integration technology, but it is a clumsy way of supporting your business processes. We need an alternative. The most interesting alternative is the approach taken by JBoss jBPM, called Graph Oriented Programming and Microsoft's Windows Workflow Foundation. These are base frameworks on top of which graph based execution languages can be built. That approach is in my opinion a very good candidate for improving agility in automating Business Process Mangagement (BPM). IMHO, 2 things should happen with the highest priority:

1. All technical architects should be prepared ! Have a look at what BPEL *really* is. So that they can tackle the misunderstandings their business managers make when reading marketing materials about BPEL.
2. BPM vendors should challenge Graph Oriented Programming and the (similar) concepts of Microsoft's Windows Workflow Foundation. We should take the community of AOP (Aspect Oriente Programming) as an example. In the past year and a half, a public debate has lead to concensus and a great leap forward. My biggest wish is that we can duplicate such a story in the BPM community.

regards, tom.