Finally, an interesting online discussion about BPM workflow and orchestration ! :-) This is a reply on Keith Swenson's What BPM can learn from a Spreadsheet. For a long time I was jealous at the Aspect Oriented Programming (AOP) community with their lively and high quality online debates which actually helped to get extremely fast mindshare in that field. I can only hope we can reproduce such speed of discussions in BPM, workflow and orchestration.

First of all, apologies if my writing style would suggest in any way that i know things better. I know that I get interpreted sometimes that way. It's unintended cause after all these years, I really still feel like a beginner. I can only assume that all of us (in BPM) are in this exploration of how to create and use BPM technology to the fullest of its potential.

Now for my response: Yes, I'm in the camp that think that 3GL will be necessary in certain environments. Note the nuance 'in certain environments'. I don't believe in BPM becoming a graphical 4thGL for developing software. For each recurring problem in Java and other general purpose programming languages, little computer languages are created called Domain Specific Languages (DSLs). Of course, this is not a new phenomenon. I see the future of software development as mature DSLs, optionally embeddable in a general purpose programming langauge.

Currently, many of the DSL's are hosted in XML because of the easy syntax, parsing and tools support. First generation of language workbenches are on their way to promote DSLs to first class citicens of software development. But there still is quite a road ahead in that direction, I believe.

The point I make is that a process language DSL needs to be embeddable in a 3GL general purpose programming langauge. So that you can use em stand alone but also integrated into a programming environment if you need the extra flexibility.

An example of a stand alone use case of BPM technology is the typical hello-world-bpm-demo-look-ma-no-code. In those demo's a new process is created from scratch. A few clicks in a graphical designer and instant deployment to a runtime environment. Voila, no code written and we have a new application. I DO think that this is a viable software development strategy in some limited number of environments. But i HATE the marketing pitch that usually comes with these demos like "You can get rid of your expensive, stubborn developers and replace them with business aware analysts".

The process diagram is just 1 aspect of a typical application. In some limited number of cases, you can stay within the boundaries of what the tool offers with forms around the graphical diagram. But this can never be taken to the level of flexibility to implement a comple typical project. In such a project, there are a bunch of requirements. And in most project's, only a part of the requirements will be covered by what you can do with a BPM DSL. In some projects that part will be big, in others it will be small. So We focus on a clean integration between those two worlds, rather then trying to expand the BPM DSL to cover every thing.

Main research is not how far can we take BPM process languages, but how can we raise the bar so that it becomes a new ubiquitous paradigm in software development. In that context, we defined 'Graph Oriented Programming' (very similar to M$ workflow foundation). In essence this is a technoque on how to bind pieces of programming code to a graph and how to execute it. On top of this technique, you can build process languages and complete BPM Suites, orchestration engines and other process languages.

In our experience, we have found that the easiest language to support BPM is a language that has fairly rich semantics, meaning that you have a large pallette of workflow constructs out of the box. Those constructs can then be used and configured without coding. But 'Graph Oriented Programming' is a very extensible foundation. It's very easy to include custom node- (or activity-) types and also to include pieces of code that are hidden from the process diagram. Those features are key in creating a clean bridge between the BPM Suites world and the programming world. So my main point is that I believe BPM Suites approach can be used IN COMBINATION with plain programming. They don't need to exclude each other. Note that with 'in combination' I mean a nice and clean integration. Not a bridge that shows it 'is possible' to get the two worlds to talk to each other.

So we currently have a limited number of functional constructs out-of-the-box (e.g. an email-node is on its way). We know that is an area we have to work on. But users appreciate the fact that a developer can just revert to the java API in case it's necessary. So the business analyst that draws the diagram doesn't have to be concerned with checking if there is a process construct available for what he/she is about to draw.

As an alternative to BPMN, i want to position our current graphical approach. By no means we claim that our approach is better. It's just different in the sense that it's simpler and more informal. So we present nodes as rectangles and inbetween nodes you can draw transitions as arrows. Out-of-the box node constructs can have an icon that is shown inside of the rectangle to indicate the type of behaviour. We envision some graphical decorations, but not much. All of this to lower the entry barrier for business analysts. Formal analysis languages like BPMN have the advantage that they're more expressive. But the downside is that you have take the learning curve in order to take advantage of the extra expressiveness. I still have an open mind wether the ubiquitous BPM language of the future should be like our simple approach, BPMN, something inbetween or both.

Hmmmm. the '2 lines of introduction to my answers' have turned into a bit more i see. Sorry for that. But the good part is that we'll have a good basis for explaining my answers :-)

Consider how Excel has allowed people to directly construct the application. They put in a few numbers, then a few formulas. Before too long, they have a spreadsheet where numbers can be entered in one place, adn answer appear in other places.

A spreadsheet is a very good example. It's a simple DSL.

Some people are able to fill in fields. Others are able to create simple formulas and the pro's are able to define nice graphics and include VB script. The more tech savvy you are the more flexibility you can get from it and the wider the coverage of use cases.

Another aspect that can be shown with spreadsheets is that the more you want to coverage with your language, the more complex it will be. E.G. Overall, spreadsheets do a fantastic job of putting the simple things in your face while keeping the advanced features on the background. Which is very important and a lot less obvious in text based language design. In our jPDL process language we have spend a fair amount of energy on creating and selecting the right defaults.

But by definition, a DSL will never be a general purpose programming language. And so the two will be used together and the DSL has to be embeddable into a general purpose programming language in a nice and clean way.

I disagree. Consider how Excel has allowed people to directly construct the application. They put in a few numbers, then a few formulas. Before too long, they have a spreadsheet where numbers can be entered in one place, adn answer appear in other places. The “searching for how things work” (which is what Tom defines analysis as) is completely integrated in the implementation of the final application.

Integrating the analysis environment into the implementation environment can indeed be very helpfull. This has been our focus for BPM and process flows.

Why can’t the same be true for BPM? Why can’t we simply draw a sequence of step, describe them in English, assign them to people with simple formulas, define a number of variables to hold values in, and have a working application? Will it be any possible application? No. But this type of programming could cover a wide range of applications that are needed today.

Integrating the analysis with the implementation is what led us to our simple graphical notation. That is how close we could take modeling to the analyst without loosing executability, which is our primary goal. Focus is on giving the analyst freedom of the diagram and the ability to document in free format text. I believe that it is impossible to integrate analysis and implementation environments with more formal languages like e.g. BPMN. Especially if the ties with the executability are kept in place. Things become different when looking at pure analysis languages like in IDS-Sheers ARIS. That's a language that is primarily targetted at writing down an analysis. Making these analysis models executable is not straight forward. While they claim a link with SAP's NetWeaver as an implementation platform, they add that this link will never be automatic and transparant because the primary focus of the ARIS language is analysis.

There is a strong business need to take BPM out of the software development lab.

If you replace 'take out' with 'expand to the analysts', we agree :-)

But just like those users who got tired of waiting for R&D to code up those reports turned instead to VisiCalc to do it themselves in 1980, so also will the business users turn to BPM tools that allow them to implement the application directly, without traditional programming.

You can make BPM languages that can be operated by business people. But in my opinion, they always must be embeddable in to plain programming for extra flexibility when you need it. 'When you need it' depends on the skills of the BA's, the complexity of the language and the requirements.

In conclusion I do not think that our vision is mutually exclusive with Keith's. I see exactly the same use cases for BPM technology as Keith does. The only aspect that i would like to add to the picture is that BPM process langauges can and should be made embeddable in a general purpose programming language like e.g. Java.

regards, tom.