Tom Baeyens has written "BPM: The Glue Between Analysis and Implementation," a response to Keith Swenson's "What BPM can learn from a Spreadsheet." He's addressing JBPM's graphical user interface, talking about how they merge analysis with implementation, allowing analysts to declare processes that haven't been defined yet. One of the interesting things he says is that he sees "the future of software development as mature [Domain Specific Languages], optionally embeddable in a general purpose programming language." This is an interesting idea, and possibly sheds light on the scripting engine support in Java. Do you think that Tom's vision is valid? Do you think Java adequately supports such an idea, or is Java going to be relegated to simply an implemenation of a platform that supports such embedding?

There are so many nice things you can do with BPM, and jBPM's Graph Oriented Programming approach... but some tooling is the icing on the cake as far as I'm concerned. I've found jBPM to be a wonderful "glue" between the users and the dev team. I want to give the analyst and business user something they can POTENTIALLY use to skeleton out a process, and then have a developer fill in the blanks - without having the developer's work go into the black box that keeps the analyst from seeing the process as it's being authored. If there are things in the tool that the analyst/user doesn't understand when the dev shows it to them, that's find, but I really need a tool that does both - shows them a visual they can see while not neutering the developer. They may not be able to fine tune the process and all its intricacies, but if they can SEE the process, tell a developer what's wrong, and the tool gives the power to change it on the spot - perfect. There may not be a visual change to the user that means anything, but a requirement was captured and implemented on the spot. Does it always work that well? Or course not. Frequently the changes they need are too large, but a good tool will let me put the stubs in for later development - still capturing the requirement in a way that is close to the implementation and rather close to its final form. Can you use jBPM to do some rather neat DSL things? For certain. I've added some nodes and done some other interesting things with the jBPM, and I'm looking forward to doing even more of that.... The JPDL language and the extensibility of jBPM offer the right mix of extensibility, authorability, and toolability (too many ilities...) but I digress into sounding like a pitch. I'm doing a series of blog posts on this covering the tool I developed for jBPM process authoring and how we're "expanding" (as Tom says) from the developer to the analyst. jBPM gui - a middle of the road approach

There are so many nice things you can do with BPM, and jBPM's Graph Oriented Programming approach... but some tooling is the icing on the cake as far as I'm concerned. I've found jBPM to be a wonderful "glue" between the users and the dev team.

I want to give the analyst and business user something they can POTENTIALLY use to skeleton out a process, and then have a developer fill in the blanks - without having the developer's work go into the black box that keeps the analyst from seeing the process as it's being authored. If there are things in the tool that the analyst/user doesn't understand when the dev shows it to them, that's find, but I really need a tool that does both - shows them a visual they can see while not neutering the developer. They may not be able to fine tune the process and all its intricacies, but if they can SEE the process, tell a developer what's wrong, and the tool gives the power to change it on the spot - perfect.

You definitely need to have a look at RUNA They have process designer that analyst can use and very nice web client to jBPM with extensible API. We are finishing our pilot project made upon runa, all works pretty fine. The only thing I don't like about runa is that it is too JBoss specific. PS They (runa) have online demo, but I don't remember it's address. Search their site or google for details.

We are finishing our pilot project made upon runa, all works pretty fine.

The only thing I don't like about runa is that it is too JBoss specific.

We use Hibernate, Struts, EJB Session Beans, Eclipse RCP,JCIFS,etc what do call JBoss specific? RUNA WFE doesn't depend on JBoss AS. Theoretically RUNA WFE can run in any standard J2EE container e.g. RUNA WFE was tested in SUN Application Server Platform Edition 8.2.

PS They (runa) have online demo, but I don't remember it's address. Search their site or google for details.

Here is the link to RUNA WFE Online Demo Regards, Vitaliy S

jBPM is a jar file; it could be run on a local desktop application. You are confusing it with many of the other BPM vendors that require servers, proxies etc.

jBPM is a jar file; it could be run on a local desktop application. You are confusing it with many of the other BPM vendors that require servers, proxies etc.

Excuse me, did you read my post? Where did I say that jbpm requires servers,proxies etc? I even didn't say that RUNA WFE uses jBPM ;-) Regards, Vitaliy S

I meant to reply to the first one, not yours. sorry

A line has to be drawn between BPM process absraction and implementation at the next level of abstraction with 3 GL e.g., java. This kind of wishful of thinking of analysts replacing programmers may only come true if we have reusable, pre built domain specific business logic components, implemented with 3GL, which is not realistic given the nuances of business logic. If such business components were available, analysts could simpy tie them to the graph oriented process definition. When and if that day arrives, most programmers won't ne needed any more. As a BPM designer and implementor in a recent project, I faced this kind of unrealistic expectation from the business analysts. New ideas often complement existing solutions and practices, instead of replacing them. Yet I we like to delude ourselves into thinking of a silver bullet, when a new idea comes along. BPM is no exception. Pranab Ghosh

very true... when it comes to "demoing", the analogy of BPM Tools with Excel sounds cool, but real life projects are far complex and it's difficult to come up with a 100% "business analyst friendly language" - just because every business has different rules and processes (although quite similar to each other). Perhaps there would be "templates" of predefined business processes and rules in future that would help grow the BPM Tools industry too... and analysts would pick the right template for their business model and tweak it based on their needs... But this would require a lot of effort both on the technical front (by BPM Vendors) and the Industry (the BPM Tools users)... -GT http://gautam_tandon.home.comcast.net

It could be that you are both right because there is a spectrum of BPM applications (the same way there is a spectrum of DB application (excel, access, SQL Server). -Edwin

I am new to business process "orchestration" and have questions regarding potency of BPM for creating applications as oppossed to orchestrating existing applications. I can see the following use case being implemented using whatever language you choose, and then orchestrated with other applications using BPM. What I don't understand is how the use case can be implemented (or optimized) using UI tools by an analyst who unfamiliar with IO and FTP routines. Thanks in advance for any insight. Use Case: Receive Electronic Data Enterchange Messages (EDI) from 2 franchise customers into one of 2 production servers with published ftp drop directory. Detect messages, determine message sender, store message for posterity, process message and ftp EDI response.