Any platform vendor knows that success (or failure) is a direct consequence of how well (or poorly) the platform is adopted by developers, which is the reason why Steve Ballmer keeps making appeals to them. Depending on who you talk to, BPM (or the BPMS) is either a business application, or a development platform. If it is to be the former, it really does not work, for no BPMS I know of can be used by business users alone. And if it is to be the later, BPM vendors — Intalio being first among them — failed miserably in their understanding of what developers need. This painful reality dawned on me when one of our senior developers (Matthieu Riou, of Apache ODE famed) made the case for a new product offering that would be directly targeted at developers. Let’s take a closer look at why such a product is needed, and how we are putting it together.

First, why did we (BPM vendors) fail? Two main reasons. One, the top-down BPM vendors (the ones selling BPM applications) worked hard to put IT out of the picture, and as a result did a pretty good job of alienating developers along the way. Their products could be used by business people to manage processes on their own (how cool is that?), and there was no need (nor desire) to get IT involved. Two, the so-called middle-out vendors (Intalio included) explained that Zero Code was the way to go, and developers felt left out (after all, their primary skill lies in developing good quality code). This pretty much left the field open to the bottoms-up guy, which is the reason why so many developers are using primitive libraries like jBPM to address their need for simple human workflow and basic service orchestration.

Truth be told, the idea for Zero Code is an extremely powerful one, but it should not prevent developers to write code if they really want to. It’s not a matter of either/or, but rather how the BPM engine can be leveraged in order to reduce the amount of unnecessary code to be written, allowing the developer to focus her effort on where she can add the most value.

In order to better understand this critical point, let’s take a look back at how the RDBMS (once again, let’s use this RDBMS|BPMS analogy) reduced the amount of code required for building data-driven applications (rather than removed the need for code altogether). Prior to the advent of SQL-powered Relational Database Management Systems, developers used to write a lot of code manually to store data directly onto the file system, index it on an ongoing basis, and process queries pre-defined by system analysts. This was massively unefficient, extremely error-prone, and, quite frankly, not that exciting, even for the most hardcore developers. When the RDBMS came out, it pretty much automated all these tasks, allowing developers to focus on the coding of higher-level business logic, typically embedded in triggers or stored procedures.

What the database vendors did very well back then (at least the few that survived) was to make the RDBMS very easy to use for developers, through the release of drivers that could be leveraged from virtually any development platform or external applications. These connectors let any developer use the database as a convenient utility that could be used easily to store virtually any kind of data, in a very structured way. It had a profound impact on the world of IT, and this openness was a critical success factor.

In a rather ironic way, BPM systems are quite open too, yet failed to capture the developers’ imagination (so far, and this is about to change). The reason for such a failure lies in how open BPM systems are, rather than whether they are open or not: BPM systems can connect to virtually any kind of system (databases included), but they do so as consumers of events (and data), not as providers of utility services that can be used by developers. As such, they provide large collections of adapters and connectors allowing them to consume all kinds of events, but very little in the way of APIs and utilities that can be leveraged by your average developer in order to automate simple workflows, coordinate a few services, and orchestrate transactions which patterns are a bit too complex for manual code development. To make a long story short: a BPMS needs drivers if it is to be used by developers.

If we were to give developers such convenient access to the BPMS, more and more processes would end up being managed on this platform, more and more components and services reused across applications, and more and more adoption driven across the enterprise. Business and IT would both benefit from such increased adoption, and the BPMS would establish itself as the platform of choice for developing virtually any enterprise application (as it rightfully deserves to).

With that in mind, what is Intalio doing to increase developer adoption?

First, we’re packaging an edition of our product that is specifically targeted at developers. This Developer Edition will be packaged without all the enterprise-level bells and whistles that developers don’t really care for, in order to make it lightweight and easy to use. Essentially, the core BPEL 2.0 engine, enhanced by carefully selected APIs (the aforementioned drivers) and utilities.

Second, we add SimPEL on top of BPEL, because as we discussed earlier, BPEL is a bit hard to use directly. We make it simple enough that most developers can learn it without too much effort, yet powerful enough that we can directly leverage most elements of BPEL’s extremely powerful semantics.

Third, we embrace the technologies that are the most popular within the development community. While our entire product is written in Java and there are about 2 million Java developers out there, there are twice as many PHP folks, and four times as many .Net guys and girls, not to mention the armies of students that are currently being trained to Python and Ruby. So, instead of trying to convince them to switch to Java (good luck!), we embrace their differences, and support multiple languages at once, starting with Java, PHP, and Ruby (JavaScript and .Net will come soon after). We do that by providing transparent binding between these languages and SimPEL.

Fourth, we use Web 2.0 technologies to integrate with third-party systems and develop some cool mashups. For example, REST replaces WSDL (nobody should complain), RSS is used in lieu of a workflow inbox, and ICAL is leverage for scheduling purposes. In other words, we keep it as simple, open, and lightweight as possible. And of course, we make it all Open Source. Sounds like fun? If so, tell me more about how you would use it, and I’ll make sure to forward your requirements to our development team.

First release coming soon…