This is the ninth edition of our weekly BPM 2.0 post. Today, I will try to explain why One Click Deploy matters. An executable business process is more than a pretty picture. To start, it might be made of multiple such pictures, which must be kept in sync. But behind the neat little boxes and arrows lie very many artifacts that need to be taken care of as well. If one is to make frequent changes to a business process — whatever the reasons for this might be — the underlying Business Process Management System (BPMS) has to make it very easy for such changes to be reflected at the execution level, and One Click Deploy is what makes it possible.

At a very high level — and assuming a BPEL deployment model — a process is made of flows, services, data transformations, business rules, workflow task definitions, and user interfaces. From a runtime standpoint, these lead to the generation of multiple files. Flows, services and transformations are expressed in BPEL, WSDL, and XPath or XSLT respectively. There is no standard for business rules yet, therefore they have to be expressed in a proprietary format for the time being. For workflow tasks, the BPEL4People model can be used, but no formal specification exists for it either, therefore proprietary deployment descriptors are needed. And as far as user interfaces are concerned, there are more options than I have fingers and toes on my hands and feet — and I have been lucky to keep all of them so far, therefore whatever goes there will be highly vendor-dependent. Intalio opted for the XForms standard, but I would not claim that it should be a requirement for BPM 2.0. At best, it’s a good candidate.

Problem is, with so many files, the deployment of a single process can quickly turn into a nightmare if each and every file needs to be manually deployed. And if you need to compile them, or provide specific deployment descriptor for them, the task becomes almost impossible for most. This is where One Click Deploy comes in handy. The idea is pretty simple: use a process design tool that supports a Zero Code development methodology and get all process artifacts automatically deployed on their respective runtimes in a single mouse click.

When we started talking about One Click Deploy, some experienced IT managers objected that it would break best practices that call for the use of a development server and a staging server before moving to a production server. They should not have been alarmed, for One Click Deploy also works that way, in the sense that you might need three steps to take a process from design to production, but each step should take no more than one click: one to push your design to a development runtime environment, an other to migrate it to a staging environment, and yet an other to upgrade your working set of artifacts to a real production system. If that sounds too simple to you, it should not come as a surprise, for a lot of engineering work goes into the development of a product that can support such a streamlined life cycle for executable processes developed in a Zero Code fashion. In other words, there is no magic pixie dust, just plain old blood, sweat and tears that software engineers developing BPM 2.0 products have shed so that you do not have to.

So next time you’re wondering what you should do with this BPEL file, where you should put this XSLT template that you need for transforming some piece of data, or what the command line is for compiling your neat little XForms code into JSP pages, just ask yourself whether things should be so complicated, or whether there could be a simpler solution. If you do come to the conclusion that you deserve better, give Intalio|BPMS a try. It supports Zero Code and One Click Deploy today, and a brand spanking new version is coming out at the end of the week. And did I mention that it’s absolutely free?