Some regular readers of this blog seem to be surprised by the passion I am showing in promoting the BPMN+BPEL cause. For many, BPEL is just another execution language for processes, and what really matters is their notation. For me, it is the very embodiment of the vision I have been trying to realize for over nine years now. It has been a long and tortuous road, partially illustrated by this past article, and I need to shed some lights on some of its detours in order for outsiders to really appreciate why all this matters, to me and my team at the very least.

When I started Intalio back in 1999, I had a pretty clear vision for the platform I wanted to build, but I did not know what to call it. For lack of a better term, I described it as a Transactional Workflow System. In a nutshell, it would allow less-technical people to build transactional applications by drawing simple flow charts. I presented my vision to Intalio’s co-founder and CTO, Assaf Arkin, and he hated it, with a vengeance. We argued for about a year, sometimes intelligently, sometimes vehemently, always passionately. But no matter how convincing I would try to be, he would never cave in, and always resisted the idea of building yet another workflow product. The guy has integrity, I’ll give him that. But most importantly, he was right, I did not know it, and I certainly did not appreciate why. It all came down to one word: workflow.

One day, I called it a Business Process Management System, and he jumped on board.

Replacing the term “workflow” by the “process” moniker was all it took to convince him that what I wanted to build was very different from the workflow systems that existed back then, and had been available for a good fifteen years. Processes were different from workflows in many ways, but the most critical of them was in their ability to be distributed across different systems, and Assaf Arkin knew a thing or two about distributed systems. After all, he was the kind of guy who would build a transaction processing monitor in his free time, just because he could.

Once he said “yes” to my suggestion, he went on to learn everything that was to be learned in the area of mobile processes, became familiar with Pi-Calculus and its variations (among them ambient calculus, which is the real deal), and wrote the first draft for the Business Process Modeling Language (BPML). At the time, I did not understand all these subtle variations, and I kept advocating for something simpler, closer to the traditional workflow model. Assaf would have none of it, and I eventually stopped pushing my side of the argument when Jacques-Alexandre Gerber, an alumni of my engineering school, Intalio employee, personal friend, and all around smart guy convinced me that I had no idea of what I was talking about, and that I should just leave Assaf do his own thing. Since then, I developed a fair amount of respect for Jacques’ opinion.

At the time, one of Intalio’s investors was a small VC fund called Ridge Ventures, and one of their limited partners was Alain Rossmann, the guy who founded Unwired Planet, which created the WAP protocol and WML language for mobile phones. It later became Phone.com, went public, and made Alain a very wealthy individual. Learning from this example, I convinced myself and my team that we should develop a set of standards for BPM, and founded the Business Process Management Initiative (BPMI.org), following a seminal meeting with Howard Smith, CTO of CSC Europe. There, we developed the BPML specification, then invited Stephen White (at the time a SeeBeyond employee) to develop a graphical notation for it, which I called BPMN. We also proposed to develop a query language for processes called BPQL, and this third idea went nowhere.

As we were doing all this, we grew BPMI.org up to about 200 paying members, including most of the software companies that had something to contribute to the field, at the exception of IBM and Microsoft (fatal mistake). Among these, very many process modeling tool vendors who loved the idea of a standard notation for processes, and very many workflow vendors who hated the idea of a standard language for executing them. The former understood that they could provide a lot of value around the core process modeling tool. The later knew all too well that fragmentation of the market helped preserve the status quo and their little niche markets. They fought for a while, then retranched within the safer confines of the Workflow Management Coalition, an aptly named coalition of workflow vendors who agreed to focus on essentially useless and poorly supported standards that would preserve this all too valuable status quo.

BPML 1.0 was released in 2001, and it was a beautiful specification. Microsoft invited Assaf Arkin and I to discuss it with them in Redmond, WA, then turned silent. In the ensuing six months, IBM and Microsoft worked together on a competing specification to be called BPEL, then invited BEA for its initial release. For all intents and purposes, BPEL was very similar to BPML, especially with respect to the adoption of a block structure. But it was different in two ways: Number one, it relied on the newly-released WSDL specification, while BPML was based on a more abstracted model — back then, it was a smart move; today, I wish we did not have to carry this legacy forward. Number two, it did not offer support for distributed transactions, making it essentially useless in an enterprise context. There was a very good reason for it: neither IBM nor Microsoft had any product that could support such a feature back then, and the priority was to freeze the market long enough for their respective product lines to catch up. It worked beautifully.

In the meantime, Intalio went through its fair share of challenges, mainly due to the fact that our timing was way off. Having backed the wrong standard, our product quickly became obsolete. And having dropped our open source model, our competitive differentiation went away, and with it any hope of breaking away from the pack of BPM vendors that grew larger and larger by the day, making the delight of analyst firms that love nothing more than a very confused customer base. As a result, we stopped investing on the development of new specifications, reduced our involvement with standards bodies, and I gave the BPMI.org baton to Jeanne Baker, a true BPM expert and highly distinguished lady. That was back in 2004.

Intalio 2.0 was started in October 2005, and came back to the market with a brand new product in February 2006. But it took us two years to re-build the confidence we needed to really get back in the game and promote the kind of radical ideas that had been our trademark in the early days — BPM, Open Source, and all the rest of it. In this timeframe, we went from 12 customers to over 500, established the largest user base of any BPM vendor on the market (over 50,000 deployments to date), and proved that the mighty BPMN+BPEL couple really works. Granted, BPEL 2.0 is not as good as what BPML 2.0 could have been, but neither are suitable for human beings, so it really does not matter which one won eventually. What matters is that one standard was established, adopted by all major vendors (BEA, IBM, Microsoft, Oracle, SAP), and that the market eventually settled on it. All this is finally happening today, to the horror of most legacy workflow vendors, and this explains why the debate is heated as it is.

With all that going on, why do I care so much about BPEL? Well, for a very simple reason: if we do not fight for it today, we take the risk that the market forgets one of the very important lessons that was learned along the way, which is that standards matters, and that we need one for describing executable processes that can be distributed on top of a Service Oriented Architecture. Without it, all we are left with is a bunch of proprietary systems that will never interoperate with each others, and we will waste another ten years trying to make them work. So we’ll continue the fight, until we make our point.

But make no mistake: BPEL is not the end of it. BPEL is just one piece of the stack. For it to work, you need BPMN on top, and very smart BPMN to BPEL code generators, which is what Intalio made a profitable business out of. And because not everybody likes boxes and arrows, we also need a language that human beings (read developers) can use. This language should be built on top of BPEL and support its full semantic set, should have a syntax that is less verbose than XML (Ruby for example), and should leverage the REST model. Such a language is being developed today. It’s called SimPEL, and all the people who are making fun of BPEL today should really like it, for it’s a great deal simpler, hence its name — our guys think they’re so smart, it’s not even funny…

To conclude, and before anyone asks, I’d like to apologize to all the workflow vendors who feel threatened by this whole discussion. To them, I’d like to tell that I have nothing personal against them. They have to run a business as much as we do, and I wish them the best in whatever they are doing. I do not really care about their market, for it’s really small compared to the potential market for BPM 2.0. I’m plenty happy focusing on this new market, and all I am asking is that they focus on theirs, and do not bastardize the very definition of BPM that we fought so hard to establish. Processes are not workflow, and this is why something like BPEL is needed. All this matters a great deal, not only to me and my team, but to all the BPM practitioners whose job is to build the systems that will make business processes work.