What Possesses These Open Source Developers ?

Joe Walker desrcibes it in a very realistic way for me:

"
The funny thing about getting heavily involved in an open source project is the roller coaster ride you embark on. There's the buzz from seeing the hits to the web server and reading what people think of your project. There's the gnawing feeling of responsibility when you discover very large websites using your code, and you're worried about bugs you might have created. There's the total flat feeling when a friend tells you they're taking your code out of a project because they prefer an alternative; and there's the burnout when you just can't keep up with the volume of work, and realize that a huge percentage of what you do is not directly development related.

My experiences with open source have opened a huge number of doors. I've met people that I wouldn't have met otherwise and had job offers that I wouldn't have dreamed of before. There really is a magic buzz to open source.
"

Right on, Joe!

Process Modelling And Process Execution

Jim Sinur talks about a lesser known aspect in BPM and workflow: the interaction of process modeling with process execution. He walks through 5 use cases of BPM and explains which tools that apply best: modelling tools or a Business Process Management System (BPMS, aka runtime process engine).

The part of it that I think is not enough known is the differentiation between the modelling tools and the process engines. The aim of modelling tools is to let the analyst create a diagram to help with documenting business processes. On the other hand, the aim of the BPMS is to track the progress of process executions and to execute the automated parts of it on a computer system.

BPMSs offer modelling capabilities, but since those models need to be executed later on, there is more to it then just the diagram. The diagram of an executable process will be more restricted then a diagram of an analysis model. Also the diagram of the executable process will be tied to software execution so changes to the diagram lead to changes to software execution.

There are some good tools for process analysis and there are some good BPMSs that support a graphical diagram view onto their executable processes. But making the link between those two worlds is not handled by today's technologies.

BPEL is known as a BPM language. It's an executable process language. And because of its focus on WSDL and executability, it is not suitable to let a non technical business analyst model a business process.

BPMN is mostly known as a graphical notation for business process diagrams. It's a good language for the business analysts, but creating easy and maintainable bindings to executable process languages is not yet demonstrated. Especially the gap between BPMN and BPEL is too big to keep in sync with round tripping.

So this leads to a software development cycle for processes that is completely similar to any other software automation project. Non tech business analysts can create analysis models. From analysis models, implementation models can be distilled. After that translation, the business analyst will only be able to see the implementation models in read only mode. The analyst will still recognise the diagrams, which results in a common language between the business analysts and the development team. That is a big added value that BPMSs can bring.

XPDL and jPDL have already today are most suited for aligning the executable process model with the analysis model. While BPEL is very complementary technology on an ESB, it is still very problematic in making the link between analysis models and executable models.

With jPDL 4 that we are currently conceiving, it will be possible to just add technical details to the analysis model and keep the original diagram as-is for the executable process. That is quite an achievement as the analysis model will not have taken into account persistence, transaction demarcation and concurrency details. Making all of those technical details fit into any Java application architecture is something that we can be proud of. But let's not make this into a jPDL blog.

The main message of this blog was that the link between modelling tools and process execution engines is still not as good as most people assume. Especially not with the two technologies that are mostly known: BPMN and BPEL. While the link between BPMN and BPEL is broken, both technologies can still be very usefull on their own.

BPM, A Peel Of SOA And The CIO Filter Syndrome

Jim Sinur kicks an open door and expresses the current general ideas around BPM and SOA in "What is the Nature of the BPM/SOA Codependence?"

I think in many ways the views expressed in that post are too limited and I'll sketch where I would like to see a broader vision. Since the tenor of the post is very representative for todays generally accepted viewpoint, I'll discuss that general viewpoint, even when it goes a bit outside this post of Jim.

In the BPM section, he describes that a human task that doesn't require a lot of thinking can be considered a candidate for automation:

There is another class of work that revolves around human activity where the knowledge level is not as intense and revolves around workflow-like activities. This work has also eluded automation at the level that a service would be needed.

The fact that the word 'service' is used bothers me. As if there no other forms of automation then a service. This particular phrase is an example of a broader mistake that I see with business level people talking about software. Their view seems to be limited to BPM and SOA only.

This is what I would call the CIO level filter. The CIO level filter only lets those parts of software development pass that can be understood by business people. BPM and SOA, but also rules fit into that category. Executable business processes and executable rules are in essence pieces of software. These languages try to create a representation that are understandable by non technical people. That is how they should be treated. All too often, non technical people tend to forget about the software nature of executable business processes and executable rule bases and discuss them in the plain english interpretation.

I believe many BPM folks miss insight on general application development to talk about software architectures. In my opinion, applications are developed in silos. Connectivity between application silos is enhanced with the typical SOA, WSDL, WS-* armoury. But BPM is much broader applicable then only on top of services.

There are many forms of process languages. Some of them like BPEL are only targetted at the services level. Others like jPDL are targetted to be used inside application development. So my point is that business processes, in the business sense of the word, translate over many layers of the software architecture, not only the services layer. Some business processes might be implemented on the services level only, in which case BPEL is a good candidate. While other business processes might be implemented as part of a Java application, in which case jPDL is a better option. Other business processes might be easier to implement in plain Java code.

Executable process languages come in different flavours and different habitats. The choice of executable process language should be a technical one. A company can manage their business processes better and more agile by leaving the choice for the process language to the technical team. All too often I see situations where the technology is selected upfront.

On Jim's SOA part, there is another occurence of what I would call the CIO filter syndrome:

The power of the SOA architectural approach is that it enables autonomous subsystems to be assembled into entities (SOA applications / processes ) that can be as cohesive externally as applications built with older architectural approaches (classic components, modularization, or object-oriented paradigm).

The benefit of SOAs over these older approaches is increased agility and greater tolerance for change throughout the life cycle of a system, especially compared with a system that assumes tight coupling and homogeneity across the subsystems.

I agree with the message that an SOA is all about increasing connectivity between loosely coupled components. The interoperability of WS-* infrastructure that is available today helps to simplify and speed up the connectivity problem. But that doesn't take away the applications at the end of the connectivity need to be build and developed. When building applications, tight coupling is a blessing. Without typesafety and refactoring, application development would take considerably longer. Without synchronous method invocations as in Java, applications would run infinitely slower.

So it's not new versus old. It's loosely coupled versus tightly coupled, knowing that inside an application silo, tightly coupling has great advantages. So I think that application development is as relevant as it was before, the only thing that was added recently is a set of standard technologies with which you can easily put a peel of SOA around your applications.

This still leaves the difficult task of the software architect to define what functionality is build in which application and what interfaces will be exposed to the SOA connectivity layer.

In summary, the CIO filter syndrome is that non technical business people try to come to conclusions about software architectures by only looking at the languages and parts of the architecture that they understand. Try to avoid it :-)

BPM Arrives Into Puberty

Bruce Silver is in a real interesting discussion with Marlon Dumas. They are discussing how to synchronize the analysis model of a business process with the executable implementation of a business process.

In my opinion, most BPM Suite products are still in childhood or kindergarten, even when they may have many bells and whistles. The root cause is that most BPM products still pursue the goal of letting non technical business create executable software. The idea is that with a graphical tool, non technical business analists can graphical design a process that is executable on a BPM System. <synical>In general, it's simply not a good idea to put software, produced by a non-technical person into production.</synical> The more realistic goal is that BPM tools try to improve the communication between non technical business analyst and developers and support the development cycle of that type of software.

I have been saying for a long time that analysis and implementation cannot be unified. So it's nice to see that leading industry experts like Bruce and Marlon are coming to the same conclusions. Although they still have different ideas about the implementation parts of the equation, at least, we all seem to be acknowledging the necessary separation between analysis models and executable models of business processes:

"No one is talking about removing IT from the BPM lifecycle. In fact I even agree with your 3 roles, although I would describe their function slightly differently. The business analyst creates process models in BPMN. The solution architect (IT) makes model activities and gateways executable by configuring them via point-click dialogs and wizards (no code). The developer creates business services using Java, BPEL or whatever, which can also be bound to model activities to make them executable. The developer may be working in the SOA tool, while the business analyst and solution architect are using the BPMS."

The part where I see different is the conversions between the analysis model and the executable developer model. After an analysis model is translated into an executable process, there should be only 1 single executable process. That executable process can still be seen by the non technical people in read only mode. Consider this a projection, where the non technical view hides the the implementation details like transaction demarcations and only shows the graphical part and the business level properties and textual descriptions.

I don't think that roundtripping between the analysis model in BPMN and the executable model BPEL is feasible. It would be similar to maintaining a separate UML class diagram for the analysis of a domain model and for the implementation model. That is in practice simply not done. In my opinion, the goal should be that the executable process languages impose the least possible restrictions to make an analysis model executable.

That is the problem of using BPEL for BPM. People have started to realize that BPEL didn't deliver on all its promises. When its used as a service orchestration language to script new services as a function of other services, I didn't hear many complaints yet. But when BPEL was used for Business Process Management, that's when I heard a lot of complaints. It imposes too many restrictions and hence it's hard for an analyst that produced an BPMN analysis model to recognize the process after it has been translated to BPEL. Other languages like jPDL and XPDL are much better suited to make analysis processes executable without touching the graphical view. For one because those languages are graph based. And in the case of jPDL, an extra capability is Actions, which allow developers to add pieces of programming logic to the execution of a process without changing the diagram.

So when we (the BPM industry) would abandon the goal to let the analysts create executable software and acknowledge that, even in BPM, analysis models are different from executable implementations, then it would be a clear sign that we're moving from childhood into puberty :-)

If I recall correctly from this presentation, Neal Ford made a similar comment in general about Domain Specific Languages at his keynote in TSS Barcelona. The idea was that DSL's are there to create languages that make sense to non technical people.

JavaPolis Sold Out

JavaPolis sold out completely. It's hot cause you can hear about hot Java technologies from the source. The moments I'm looking forward to are a mix of solid traditions and fresh ideas.

The solid tradition is the Belgian beer tap at the JBoss booth. Imagine that! Not only do you get our software for free, but even our beer. I'm still thinking on how we can do something special this year at our booth. Probably Bela Ban's beerathlon, can serve as inspiration. A beerathlon is a race where you have to run 7 kilometers and on the way drink a pint at every pub. Maybe we can do some kind of coding competition. You have to drink a pint before you get the next failing test, which you have to make succesful faster then your competitor. It would be nice if we could include extra beers if you generated too many failing attempts.

As a teaser for the people that were too late with registration, I'll point out my highlights :-)

The fresh idea I'm looking forward to is the unconference. It's a very informal and unprepared way of getting together with your peers to talk about a certain topic. It should be a great way to meet new people and learn different perspectives.

Also, I'm looking forward to the introduction of Parleys.com V2. Parleys is of course nice for those who can't come to the conference itself. But it has a potential to change the way we educate ourselves in this fast paced industry.

Another fresh idea is the Tools in Action track. It really boosts the value of the first two university days. For those that don't know yet, the university days have typically longer talks of 3 hours with a break inbetween. That way it's possible to cover topics a bit deeper then in the typical conference session. But the new Tools track, all kinds of development tools will be showcased on half an hour. Definitely check out RichFaces/Exadel/JSFUnit and Ivy.

SEAM in Action is another talk that I think is going to be great. I saw Peter Hilton give this presentation in Rotterdam last month and he did an excellent job of explaining how to get started with SEAM in very simple terms.

Hope to see you all next week in Antwerp !

Even Microsoft People Use jBPM

As Hannibal would say: "I love it when a plan comes together". With jBPM being a platform for process languages, we never really fitted into the general accepted approach to Model Driven Architecture (MDA). While we do share many of the same goals like creating a better communication between business people and developers. We always believed that generating code from models was not the challenge. Instead,we always saw integrating the different languages in IDE tooling plugins as the real challenge. Now it seems that strategy is starting to pay off.

Ferran Rodenas gives a very good description of Visual studio and Domain Specific Language (DSL) tools. He's one of the few that can mix and match Microsoft with Java and other technologies. What's nice to see is that he opted for a modified version of our graphical jPDL eclipse designer in favor of a "solution based on DSL tools".

I think this really hits a potential problem with the current generation of Language Workbenches. They focus on building tools on top of a grammar. But more important and more difficult is the integration between all the different Domain Specific Languages (DSL) and general purpose programming languages. For example, think of a jPDL workflow process that refers to your class as a command. Then it would be really helpful if the class renaming refactoring propagated to the process. I'm not sure for all of them, but languages workbenches seem to be focussed more on building new languages and less on integrating the editors that result from that work.

For now, that is why we anticipate that the choice of the actually IDE technology platform (like eclipse) will be much more relevant then the choice of a language workbench. And that's why we keep on focussing to make the jBPM designer reusable and tweakable for all these kind of use cases.

Workflow In Java *Is* Sexy !

Ever since Marc Fleury started to wiggle with the foundations of the software industry, most people know that open source software doesn't just fall out of the sky. A good idea is not enough. It takes passionate people who believe they can make a difference. A project may start out as a hobby, but combining a day time job with after hours hobby rarely is sustainable for a longer period of time. That is in summary the idea behind Professional Open Source.

With the JBoss jBPM project, we are now having a kind of a luxury problem: The rate at which we can hire people from our community is greater then the number of contributors that join the project. Last night I talked about it to Stephan Janssen, the BeJUG chairman. Stephan suggested that maybe workflow is not sexy compared to hot technologies like Rich Internet Application (RIA) technologies and scripting languages.

That reminded me that BPM and orchestration still have a bad reputation in the developer community. Looking at all the other workflow technologies out there, I can't really argue with that perception. But in case of JBoss jBPM, it should be fairly easy to to show that our project is steaming hot and sexy! Especially when looking forward to what is coming in the next major version.

I'll start with the nittypittylittlelightest form of workflow ever and then build up to pure play BPM product features. In essence, the core of JBoss jBPM is a simple Java library to define and execute state machines. That is called the Process Virtual Machine. This already enables the simplest form of workflow in plain Java like this:

ProcessDefinition processDefinition = new ProcessFactory()
 .initial().behaviour(new WaitState())
   .transition().to("a")
 .node("a").behaviour(new SomeAutomaticActivity())
   .transition().to("b")
 .node("b").behaviour(new SomeHumanTask())
   .transition().to("c")
 .node("c").behaviour(new WaitState())
 .processDefinition();

Execution execution = processDefinition.startExecution();

What is really cool and sexy about our new PVM is that we have extracted the programming model for the nodes in a workflow in a NodeBehaviour interface. The NodeBehaviour interface looks something like this

public interface NodeBehaviour {

 /** called when an execution arrives in a node. */
 void execute(ExecutionController execution);

 /** called when an execution, positioned in this node
 * receives an external trigger. */
 void signal(ExecutionController execution, String signal);
}

With this API it becomes childsplay to implement any kind of state machine behaviour for your specific use case. Furthermore, you'll be able to create custom extensions to process languages like jPDL, BPEL or XPDL this way.

At the next level, XML parsing is added. I admit, this is the least sexy of all, but the point I'll make is that the XML parsing is also pluggable for each node. That is still a little bit sexy, no ? Each process language needs it's own parser. The parsers we build for the process languages are based on JAXP so there are no extra library dependencies introduced outside of the Java 5 JVM. Each process language will have it's parser that walks the main structure of the process XML document. Then to parse the nodes, a Binding interface is used like this:

public interface Binding {
 Object parse(Element element, Parse parse, Parser parser);
}

A node type now is made up of the runtime behaviour and the binding parser.

(btw, I hope that the language workbenches become mature soon on the Java platform. Instead of XML, I would much rather use a custom syntax language that has the look and feel of the Java programming language. But currently, that turns out to be harder for the graphical designer and the node pluggability)

Next is persistence. The sexy thing about our persistence is that in the PVM we'll support all forms of process persistence. As you saw above, processes can be created and executed without any relation to persistence.

Alternatively, you can read the process from an XML resource and save the state in your domain model object like for example an Order. A hibernate custom type that we supply takes care of converting the Execution field value into a state string, corresponding to the current node name. This is limited to a single path of execution, but it avoids the complete workflow database. The state is actually saved into your own domain model.

In case you do want the full workflow database to store the processes and executions, then we can easily link between your domain model objects (like e.g. an Order, Account or Customer) persisted with Hibernate and the process Execution.

For the process languages we support out of the box, we'll have hibernate mappings that store the process definitions and executions. But another sexy thing about the new PVM persistence is that you'll be able to add a new node with parser and complex configuration properties and keep the database schema stable.

Do you see it coming ? We're working towards easy customization of process languages. Development teams will rarely build a complete process language from scratch. But with the new PVM, they'll be able to take for example jPDL and extend it with their own custom node types very easily, without any deployment hassle.

Supporting this whole range of persistence options is IMO the most sexy of all! This is the main reason why BPM, workflow, orchestration and pageflow now all have different runtime engines. So with the new PVM, we'll be able to support the full deployment axis. This includes the different forms of persistence in both standard java and enterprise java. Apart from the deployment axis, there is the process language axis. So that gives some background into why this multitude of languages and runtime engines exist and how we're going to consolidate that.

Then on top of the XML and persistence, we're building out the usual BPM tooling like designers, web & administration consoles, business activity monitoring and so on. Since those tools are typically the only interface offered to developers, I can understand the bad reputation that BPM still has with developers. I hope that this post showed you that workflow can be sexy also for Java developers.

I can understand that in 5 years from now, workflow systems will be as boring as database systems. But in the meantime, building out the concepts and techniques behind those indispensable systems is ultimately sexy for clever developers.

So if you're looking for a sexy project to contribute to, look no further. JBoss jBPM is it !

Unifying Processes And Rules

In "A Vision for Unified Rules and Processes", Mark Proctor, lead of the Drools rules engine describes how he sees the further integration between rules and processes.

I believe that any company that isn't able to truly unify rules and processes into a single modelling system, how PegaSystems have done, will not be in a suitable position for the future. ... rules and processes must exist as first class citizens within the modelling and execution environment ... we need to make sure that we unify these models and allow it to go to much greater depths. Once rules and processes are fully integrated that modelling environment will benefit from any other declarative systems added, such as our plans to add Complex Event Processing (CEP) to the engine and language - this means we can have rules monitoring streams of data and triggering process milestones.

From a product point of view, I totally agree with Mark. In fact, I met him last week and I was impressed with the productization ideas they had for creating in integrated processes and rules environment.

For instance the Business Rules Management System (BRMS) manages the full lifecycle of rules from sources, over packaging to runtime deployment. The model and tooling that they have layed out would fit perfectly with jPDL processes. Futhermore, it supports both the developer use cases as well as the business user use cases. The drools vision in that respect is fully applicable to jPDL processes.

Similar for the business user test scenarios. Drools has a web UI for creating test scenarios on a business level. While this will not replace software testing based on something like JUnit, it does allow for business users to express basic scenarios. For non complex processes, this vision is also applicable to jPDL processes.

So if you look at it from a product point of view, we agree. The way I see this unification is a drools-jPDL integration is a single download that just can be unzipped to be installed. Integrated BRMS, console and designer. Drools has this approach and jPDL has the same appraoch with the suite distribution package.

But I see the componentization underneath the product quite differently. First of all I think that ruleflow should be merged with jPDL. They fit together and complement each other perfectly. I don't think that ruleflow should be a separate language from jPDL. Ruleflow could be build as a set of nodes build on top of the PVM. These nodes could be added to jPDL. Whenever you use them, you get a dependency on the drools.jar. This is just like with e.g. the beanshell based script node that we have now in jPDL.

Secondly, I don't think we need to integrate jar packages. IMO, "truly unify rules and processes" as Mark Proctor refers to, should be in the productized package that integrates jPDL (incl ruleflow) and drools. There is no need for the jars to merge in order to realize the vision as Mark Proctor describes it.

Yahoo Pipes, PVM and language-oriented programming

Paul Gallagher's blog "Pipes - Web 2.0 Wake-up Call for BPEL?" gives a very example nicely what we call a graph based execution language. And the best part is that he puts the Yahoo Pipes langauge in perspective with BPEL, paving the way for me to explain why its crucial for future workflow engines like our JBoss jBPM to support multiple process languages.

The only languages often associated with workflow, BPM and orchestration are BPEL, XPDL and BPMN. Of those, only BPEL defines exact execution semantics and hence it is called an executable process language. jPDL is another executable process langauge. Where BPEL is targetted to a web services / ESB environment, jPDL is targetted at a standard Java environment.

Similar to Java being referred to as a general purpose programming language, I refer to BPEL and jPDL as a general purpose process languages. But over the last years, with the more widespread adoption of jPDL, we get a lot of requests to create limited dialects of jPDL for specific purposes. For example approvals in a document management system or tracing of laboratorium experiments.

JBoss jBPM is designed as a platform for process languages. After we had put BPEL, jPDL and SEAM pageflow on one base framework called The Process Virtual Machine, we realized that we could build all these kind of languages on the same base technology. The componentization that we introduced supports this very well already.

As such, Yahoo Pipes are another nice example of a graphical process langauge.

Martin Fowler and Neal Ford recently introduced the notion of Language-oriented programming. The idea is to "build software around a set of domain specific languages”.
The more we realize how big the category of graph based execution languages actually is, the more excited that we get. With our new Process Virtual Machine technology underway, we are not far from building out a complete language workbench focussed only on graph based execution languages.

More concrete, based on the Process Virtual Machine we're building a complete software development kit for developing your own graph based execution language, including runtime, console and designer. You'll be able to code the runtime behaviour of process constructs in plain Java. Also included will be a mechanism to add designer forms, XML serialization and persistence of the process constructs. We see a lot of use cases for easy customization of general purpose process languages like jPDL.

Typically I don't really know how to start explaining the concept of how jBPM is becoming a language workbench for graph based execution languages. Thanks, Paul for providing this example and giving me an opportunity to explain the strategic direction of JBoss jBPM.

jBPM jPDL 3.2.2 released

jPDL is a simple workflow language targetted for the Java platform. We just released version 3.2.2, which fixes a number of bugs and minor (but crucial) enhancements. The detailed list of issues can be found in the jira changelog.

The suite and the runtime can be downloaded from sourceforge. Enjoy!

Great Book About JBoss jBPM

Last weekend I finally came around to reading "Business Process Management with JBoss jBPM". A brandnew book written by Matt Cumberlidge. It fills a gap in the jBPM offerings. Another milestone for the project.

The book targets architects, analysts and developers that want to get started with jBPM. Matt succeeded in bringing great value for all three target groups. It starts with a fresh look at the value of BPM and practical guidelines on how to start a BPM project. Installation of every required piece of software is explained in detail. Even less technical people will have no problems to get the software up and running with these very simple step by step instructions.

The ordering of chapters captures the full jBPM learning curve. After installation, a prototype business process is build in two iterations. Then, the more technical details are explained to transition from prototype to implementation. And finally a chapter on process improvement explains how the processes can be measured and analysed to find optimizations.

jBPM beginners can use this book as an easy to read tutorial to get jumpstarted with jBPM. The available documentation in jBPM itself is sometimes a bit too concise and basics are on the same level as advanced topics. Matt made a good distinction between the basics and advanced topics. The basics are explained in detail and the advanced topics are explained more briefly and referenced. It will lower the treshold for the learning jBPM significantly.

Also, I really like the structure of the book. It adds another dimension. Throughout the book, the link is made with the overall software development methodology and how BPM fits into that picture. It shows the value of BPM from the developer's point of view, which is much more interesting then the typical empty BPM promises on a management level.

Congratulations, Matt! Well done.

You can get the book at Amazon or directly at Packt publishing.

jPDL Webinar With Awsome Demo

Your last chance to register for the jPDL webinar that will include an introduction by me and a long demo by Micah Modell.

It's next Wednesday 11am EDT. Your boss is probably on holiday's while you're working hard. So it's not more then fair if you take the liberty to listen in on this cool webinar. On top fo that, you'll be impressing your boss when he gets back as you'll know the meaning behind the workflow buzzwords.

Don't miss it and register here.

Try out the new jBPM release 3.2.1 of jPDL

Ever tried a simple Java workflow engine ? This is the time to do it! Last week, we released jPDL 3.2.1. jPDL is the process language for writing statemachines in Java. jPDL is build in such a way that it supports Business Process Management (BPM), workflow and orchestration in standard as well as enterprise Java environments.

Download it from sourceforge and and check it out.

If you download and unzip the suite package, you get the full documentation, a graphical designer plugin for eclipse, the runtime engine preconfigured in a JBoss app server (jPDL also runs without an app server or on any other app server), and a web console. All preconfigured so that you don't have a hassle to get started and evaluate the process language.

Is BPMN The Solution For All Process Languages ?

I would like to start this freely available answer with "It depends...", the typical answer of expensive consultants :)

BPMN is clearly a great language for non tech analysts. But the approach that BPMN has to map BPMN to all the executable process languages is sometimes misinterpreted. The Process Virtual Machine describes how multiple process languages can be supported by one single runtime engine.

The text below started off as an explanation of how we can replicate that approach in a graphical process designer. But it also contains a no-so-traditional-but-nonetheless-realistic view on how business analysts and developers can jointly work together on the automation of business processes.

A component model for nodes
On the tooling end, the base framework should be able to display nodes and transitions. Like e.g. in BPMN, but ignore the decorations and the properties for a minute.

Then a process construct should be a plugin. The plugin contributes the following to the base plugin:

- shape: the tool could predefine the 4 BPMN shapes, but a node-plugin should be able to self-define it's shape with its own figure.

- configuration: the plugin should contribute a properties form to enter the configuration information for that node type. to enable this, the internal model of the process graph must have a dynamic set of properties.

- constraints: the plugin should be able to specify constraints like: this type of node can only have 1 outgoing transition. or: outgoing transitions from this node type can only be connected with node type z.

- decorations: which decorations are supported. maybe this could be done with icons so that apart from the BPMN decorations, node implementors can supply a graphical colourful icon.

The whole idea is that you should separate all the node type specifics from the basic process designer container.

Guidance for process languages
BPMN recognizes multiple process languages. But it has suggested a problematic approach to handle that.

BPMN defines a mechanism of bidirectional mappings from BPMN to executable process languages. This suggests that you could model in BPMN and then translate to any executable language. IMO, that is a unidirectional translation.

When an (non-tech) analyst starts to model a process, this has to be done in free modelling language like BPMN, visio or IDS Scheer's ARIS notation. Of course, those models only contain graphical information intended for human-to-human communication and they are not executable.

Executable processes exists of graphical structure and technical details to make a process executable. The graphical picture is the common language between analysts and developers. An executable process is human to system communication in the sense that it specifies to the computer system what it has to do.

The translation from a modelling process (graph only) to an executable process (graph and tech details) is a big one. First of all, the analyst may have modelled steps in the model that are not to be automated by the computer system. Second, the developer makes a selection as to which process language best fits his technical environment. It will most likely not be possible to keep the original process model as-is for the executable process because of the executable language specific constraints.

After the translation to an executable process, analyst and developers have a common language in the graphical part of the executable process. But now, the analyst lost his freedom to change anything he wants since that implies software changes.

This is why I come to the following conclusion: A process designer tool should support each process language individually. BPMN is one of those languages/notation. This is the free modelling tool. Then BPMN diagram can be converted (1 time translation) to executable process languages like BPEL, XPDL and jPDL. This translation should generate a new file.

For modelling an XPDL process for instance, the designer tool should present itself as a straight XPDL editor. All the parts that XPDL specifies should be exposed by the tool with their proper names (properties and node types). But where XPDL is undefined (like in the graphical notation), that is where BPMN can be used to complement. Same story for other executable process languages.

There is a big change going on lately

"There is a big change going on lately. A year ago, all BPM and workflow was centered around BPEL and around web service orchestration. And that was the way to go, that was the single process language that's going to make it. At that time we were already long time working on our multi-language approach."

After noisy attempts at the moscone, inbetween ringing phones of the labs crew, an eager housecleaning lady and an apologising hotel manager we managed to shoot an interview in San Fransisco at JavaOne this year.