We share the same dream (see link), although I haven’t looked carefully at your product. To be honest, I wasn’t aware of it, which is my loss, one which I hope to rectify. From what I can see, it looks nice. Cudos.

These ideas are not new. What we see now, that has allowed folks to dream, is the advent of new domain specific languages that bridge the gap between visual programming and declarative (C# and Java) programming. A number of large commercial products have been available for many years that attempt to make this same leap, including some open source packages. I’m glad to see another solid OSS member join the fray.

Beware of making the statement that visual programming eradicates defects. It does not. Logic defects still remain. Visual programming paradigms still allow humans to be creative, and creativity leaves room for flaws. By leaving room for mistakes, we leave room for intelligent and elegant solutions. We cannot have one without the other.

So in addition to an environment for coding visually, we also need environments for testing visually. I’m sure your environment includes testing, as you mention producing a very large process map for the Dutch Government. One area that is becoming more common these days is process simulation. Think of it as automated testing for BPEL.

Also, since we are attempting to allow process developers to do the work of coding, we need all of the tasks that declarative developers once did to move over, including deployment of the solution to a production environment, code control, and configuration management, to be part of the paradigm.

Visual programming doesn’t get rid of bugs. Oh, and the comment about defects per line of code being linear does not hold up when shifting paradigms. Your rate of defects will depend on your environment, and may be less than the average or greater, depending on how clear and simple your visual language and debugging tools are.

Process developers have not be trained in the fine art of debugging or deploying. That is a human change that may be the biggest challenge to full adoption of the paradigm. Making those tasks as simple and apparent as the programming itself will be a serious challenge for many years to come.

Good Luck and thank you for your efforts and contributions to moving all of us forward.

-Nick Malik, SOA and BPM Architect, Microsoft IT

We support them through graphical artifacts.

The dream became reality.

I agree with you. But take a look at Intalio. Most of the business logic can be generated without having to write code, and you can use it to build reusable services that way. Also, the skillset required for technical people is less than the one required for J2EE development.

In any case, however, we still need the coding done for individual services that are behind the steps and activities in a business process, or a composite application.

If the services are already available for re-use, then things get simpler. If not, best case you have to “generate” business logic and/or UI, to be plugged into the process, and worst case you have to write every line of code in Java, PL/SQL, ABAP, or what have you.

When we have access to a BPM tool that can generate 100% of the process logic (in BPEL let’s say since it’s the standard today), and have access to an unlimited repository of services, I think the concern would be, are the “business analysts” properly skilled to do development now? The best forms guys are not usually the best functions guys. So I think business-IT still need to sit together.

- Increasing Speed to market for software products.
- Decreasing Go-Live cycles for business software.
- General pace of IT accelerating with increasing levels of automation.

Cheers

So, when will BPEL/AJAX BPEL editors and universal, transparent native semantic data storage merge?…

Ismael Ghalimi on the advantage of BPMS that allow creating executable processes without coding…

I agree. BPEL is one such domain specific language, for business process automation and web service orchestration. You gain one order of magnitude going from Java to BPEL. Then an other one by using a BPMN designer that will produce the BPEL code for you. Two orders of magnitudes make for a very significant gain that should help us push the scalability boundaries far beyond what most customers need today.

You scale going from Assembly to C, from C to Java (with C++ in between), from static to dynamic. But eventually you hit the scalability wall. You just can’t make a better language, or a better API. Which is where we turn to meta-programming. It’s a generic name for a lot of different things, but the one we have most experience with are domain specific languages.

Domain specific languages don’t apply well to all problems, but they’re easier to use in one specific domain. And it turns out that people have a large number of problems that can be solved well by one specific language. You still need to learn that language, but domain specific languages happen to be simple so the learning curve is short. And you save so much in developing, testing, maintaining to break even on the first project and gain with any subsequent one.