Back in April, I explained what is wrong with J2EE. Today, I will try to identify who cannot write J2EE code, with an interesting customer example, as part of our second BPM 2.0 weekly series.

The customer in case is the mid-sized ISV developing CRM applications for retail banks we wrote about last week in the post about Eclipse. The original application was developed about ten years ago on top of the Sybase RDBMS, using a traditional client-server model.

Because customers had very specific needs for the way the application would have to be deployed, the vendor developed a fairly sophisticated configuration tool that allowed consultants to tailor the application to the needs of customers, without having to write code. The Zero Code approach was justified in two main ways.

First, customizing the application’s code would have made it very difficult to install software upgrades over time — ask any SAP customer about it, they’ll know immediately what I am talking about.

Second, consultants would not be technical enough to write code that would be reliable, would scale, and would provide the appropriate level of security. Not that they would not be smart enough for it, but they just would not have enough time for such an exercise, and their profile offered a mix of technical abilities and communication skills that was appropriate for the job. These consultants are what we call process analysts today.

Within a client-server architecture and with Rapid Application Development (RAD) tools that existed ten years ago, developing such a framework was a reasonable endeavor. It was not easy, and the vendor made a business out of this capability, but it was doable, at a reasonable expense. It enabled a model-driven development approach, which supported what we call today in a slightly more fancy way Zero Code and One Click Deploy.

But within a J2EE environment, with requirements to support the emerging Service Oriented Architecture (SOA), the challenge became an order of magnitude more complex. Ask any J2EE experts whether they think they could do their job in a Zero Code and One Click Deploy manner, and you’ll get a condescending smile in return, at best. There is nothing fundamentally wrong with J2EE, but it’s just too complex for your average developer to be productive with it, and totally unsuited for process analysts. This was discussed in more details in this previous article.

Today, the vendor has to resort to custom J2EE developments in order to implement a significant part of the customizations required by customers. This increases deployment costs, creates significant challenges in terms of staffing, and makes it a lot more difficult to maintain applications over time.

Using the Intalio|BPMS, the vendor will be able to develop the most complex business processes without having to write code, leverage their existing service-oriented framework to develop custom components in a model-driven way, and revert to traditional code writing only in the most exotic cases. It’s too early to tell whether the new platform will be as easy to use — or even easier — as the previous one, but it’s the best solution they seem to have found so far.