In a recent article published by Intelligent Enterprise, my friend Bruce Silver laments that BPDM is essentially useless, and that the BPM industry badly needs an XML schema for BPMN. I could not agree more with him, and I am happy to report that Intalio recently donated such a schema to the Eclipse Foundation, complemented by a ridiculously-good-looking object model for it. Not only did we give the schema away for free, but we also donated a complete implementation for it.

BPDM, currently developed by the OMG, is presented by its promoters as a universal interchange format for business processes. In reality, it’s an utterly confusing metamodel that brings very little to the table, and is used by legacy workflow vendors as a way to fight against the upcoming dominance of the BPMN+BPEL standard combo. Workflow vendors like nothing more than to protect their respective little niches, and have done a phenomenal job over the past fifteen years of ensuring that no useful standard would ever be developed in the space.

Over time, smarter vendors grew tired of playing such games, and developed BPMN and BPEL. Unfortunately, a semantic gap exists between the two, and BPEL cannot be used as an interchange format for processes modeled in BPMN. Instead, an XML schema for BPMN is needed, and this is what Intalio has made available through the STP Project managed by the Eclipse Foundation.

This schema is focused on the semantics of process models, rather than the presentation of process diagrams. For the later, extensions can be developed by vendors, and the need to standardize them is not entirely clear. An interchange format for BPMN processes should focus on the process semantics, and this is what this schema does, in a very straightforward, unambiguous manner.

As anything developed by the Eclipse Foundation, this schema is “open-source”, in the sense that anyone can use it for free, as is or in a modified version. But because a schema is not of much use to most people, we also made sure to provide a complete implementation for it, in the form of a collection of plug-ins for the Eclipse development environment. The STP BPMN Modeler developed by Intalio is a complete implementation of the BPMN standard, built using Eclipse’s latest technologies, including an EMF object model bound to a graphical notation via the GMF project.

For business analysts, this modeler supports the development of standard BPMN process models. For developers, it allows the creation of BPMN diagrams, the generation of org.eclipse.stp.bpmn EMF objects that can be traversed, annotated, and transformed to generate BPEL or other process execution code, and the extension of the editor to support other application-specific usage.

So here we are — as of today, you have no excuses for not sharing your BPMN models.

“It’s always more fun to share with everyone.”

Assuming that everything goes as planned, the WS-BPEL 2.0 specification will be approved by OASIS later this month. This will mark the end of a four year long process for taking the BPEL specification to a level where it can be used in production for managing virtually any kind of business process. Intalio is a co-author of the specification, and has been supporting early drafts since February 2006, giving us some invaluable experience regarding its use within the most demanding production environments (Cf. performance numbers). But because the development of this specification was a collaborative effort, it’s time to share the love, and I could not think of a better recipient for it than one of our competitors—Oracle.

Back in October, the good folks at Oracle (Manoj Das and Alex Yiu), wrote a very good white paper on WS-BPEL 2.0, and its use for process orchestration. Of course, we compete directly with Oracle BPEL Process Manager, but let’s put that aside for a moment, and focus on the things that Intalio and Oracle have in common, among them our true belief in the value of standards.

Most legacy workflow vendors and first-generation BPM vendors have largely ignored BPEL, or paid lip-service to it by implementing useless import mechanisms that they believe will fool customers in checking the BPEL box. Problem is, BPEL is not something you can fake, much like SQL, and Oracle knows that better than any other company in the industry. In the late 80’s, when SQL started to get some traction, some legacy database vendors that had hierarchical database or network database products tried to catch the SQL wave by implementing SQL interpreters on top of their proprietary database engine. Of course, it did not work, and none of these vendors are in business anymore today. The same will happen with BPEL, and vendors that decide to ignore it today are just accelerating their path toward obsolescence and irrelevance.

One thing I liked with Oracle’s white paper was their support for not only BPEL, but also BPEL4People. Granted, the original document authored by IBM and SAP is far from a specification, but the model works, and it’s quite refreshing to see Oracle finally adopting it as well. I would expect a full fledged specification to be released for it sometime later this year, and this will once and for all close this FUD-infused debate around BPEL and its wrongly-assumed lack of support for human workflow. Human workflow is nothing more than a specific process pattern, and BPEL is largely sufficient to support it. Anyone telling you that BPEL does not support workflow is lying to you, and the best evidence for it are Intalio’s and Oracle’s products.

If you need some external validation that BPEL won, here are some analyst quotes:

“BPEL will emerge as the leading industry standard for Web services flow composition (0.8 probability).”
—David Smith, Gartner

“BPEL is the future of the integration space in my view… Why? Because the value is so much higher when you provide not only a way to integrate applications, but also a way to create services from them and put them into business processes.”
—John Rymer, Vice President, Forrester Research

Now, don’t let this fool you into thinking that BPEL is only for integration or orchestration. Again, this is what legacy workflow vendors and first-generation BPM vendors would like you to believe when trying to sell you proprietary process execution engines, or pie-in-the-sky architectures that take you from BPMN to BPDM to XPDL to BPEL—who on Earth could dream up such a monster? If you want to make sure that you can never change your processes once deployed, this might be a good approach, and surely as effective as hard-coding your processes into JavaScript code. But if you want Zero Code and One Click Deploy, the only acronym soup that has been proven to work is the combination of BPMN and BPEL. Design your processes in BPMN, then let the tool generate the BPEL code for you. This is available today, it works, it’s being used by close to 10,000 companies around the world, and you can get it for free.

BPMN is where Intalio and Oracle differ. In Oracle’s case, they do not have their own process modeler, and had to license IDS Scheer ARIS. Problem is, ARIS is not fully integrated with Oracle BPEL Process Manager, hence a lot of code has to be written manually. So if you want BPMN and BPEL—and you should—but do not want to write code, give Intalio a try.

You know that a standard works when you can go from one implementation to another, without too much effort. BPEL has been promising such interoperability for quite some time, but to the extent of my knowledge, it has never been demonstrated at a large scale in a production environment. Until now. Over the weekend, Coghead went from one BPEL engine to another, and it worked without a glitch. Today, we can safely say that as an industry standard, BPEL really works.

Coghead has developed one of the most innovative Web 2.0 development tools, architected on top of a SQL database and a BPEL engine. For the later, they originally started with the product of one of our competitors, then decided to migrate to Intalio|Server for performance reasons. One of the performance issues they were facing was that they had to manage very many different process models—up to 100,000 on a single server. And with so many models to manage, re-starting the server was taking longer and longer—up to 6 hours for 20,000 process models. Eventually, it became unmanageable, and they started working with Intalio.

We initially did some benchmarking, then made some modifications to our engine in order to support the lazy loading of process models, and finally prepared everything for a migration that would take the processes of thousands of users from one engine to another. We completed the migration over the week-end, and it worked. Restarting the server now takes 7 seconds, down from 6 hours…

In their blog, the good folks at Coghead described this exercise as brain surgery. Being a pilot myself, I would compare it to changing the engine of an airplane in mid-flight. However you look at it though, this success story demonstrates that BPEL is ready for prime time, can be used to build very large process systems, and is available from multiple vendors with near-perfect interoperability. Finally…

Congratulations to the Coghead team and to Matthieu for an amazing achievement!

Earlier today, I participated in a lively ebizQ panel organized by Sandy Kemsley, with Phil Larson, Director of Product Strategy for Appian Corporation, and Phil Gilbert, Executive Vice President and CTO for Lombardi Software. We discussed about BPM and Enterprise 2.0, and had lots of fun arguing whether it was important for a process modeling tool to be web-based or not. But what I will remember from this call is the epiphany I got about BPM 2.0, and what makes Intalio’s vision for BPM so different from the one of our competitors, Lombardi first among them.

If you read Phil Gilbert’s report on the panel, you quickly realize that his approach to BPM is not very far from the Business Process Reengineering (BPR) school of thought that was so popular in the early 90’s. It’s radically top-down, exclusively driven by abstract process models, and inescapably tied to a traditional software engineering process, whereby a lot of code has to be written to make the whole thing work.

When looking at Lombardi’s recently released Blueprint, I cannot help but think about SAP Solution Manager, a tool originally developed in partnership with IDS Scheer. With it, business consultants can design abstract processes, then let technical experts write a bunch of ABAP code to make the processes executable. While this may sound straightforward, it’s actually a receipe for long-term disaster, for it bakes the process into code, and makes it virtually impossible to change over time. Changing the picture is easy, changing the underlying code is not. SAP understands this problem very well, which is the reason why they have been trying to develop a BPM solution for so many years. Why they failed is another story, but they are still at it today.

Well, Lombardi’s BPM solution works very much the same way. Business folks use Blueprint to design non executable processes, from which a process skeleton is created. Then, Lombardi technical consultants extend the high-level process model by adding boxes and arrows that are necessary, but not sufficient, to make the process executable. Finally, even more technical Lombardi consultants write a bunch of JavaScript code—yes, you read well, JavaScript, of all languages—behind each box and arrow in order to make the process fully executable. How you could ever ensure roundtrip engineering through this three-step waterfall implementation process is beyond me, but savvy marketing will make you believe that they can.

When I look at such a model, all I see is a complex platform for the industrialization of top-down Business Process Reengineering efforts. I am sure that some customers will be seduced by the idea, but I also believe that most customers know better. They’ve been there before, and they know that the reason why BPR projects failed in most instances is not because we did not have the right technology back then. It’s because the approach was fundamentally flawed, mainly from a life cycle standpoint. If you rely on a waterfall implementation process to support the development of new processes, you will never get the agility that was promised to you in the marketing brochure. Ever.

This is precisely the reason why BPM 2.0 advocates a Zero Code, One Click Deploy model, whereby there is only one process model, and you do not need to write code to make it executable. This approach is neither top-down no bottom-up, it’s middle-out, and contrary to what Phil would like you to believe, it works for both small organizations as well as larger one. In fact, the largest BPM system ever deployed was built with it. It manages a process that has over 250,000 steps, 250,000,000 instances, runs over 5 years, and is used by 100,000 people daily, in order to manage 25,000,000 farm animals. Zero Code is not a gadget, it’s what makes BPM 2.0 work. Big time.

Having said all that, please don’t get me wrong Phil, I really like what you’re doing. Your tool is pretty sexy, and for simple processes that do not require integration with third-party systems, it seems to be working fairly well, much like Appian’s does by the way. But as you and I know, most processes require such integration points, and you won’t be able to support them with the proper lifecycle without using proven technologies such as BPEL. JavaScript is cool for AJAX widgets, but it won’t scale the way BPEL and Java can. We happen to have a fairly good BPEL implementation, and it’s available under an open-source license. So, if you ever decide to change your mind about BPEL, we would love to help you integrate our process engine into your product. You, us, and your customers would all benefit from it.

Two weeks ago, a couple of independent BPM vendors announced plans for the release of BPM platforms to be offered as a service. This got the BPM digerati all excited, and for a day or two, the most enthusiastic commentators were raving about the prospect of getting BPM on tap, directly from their web browsers. Then, some cared to read the small prints, and quickly realized that they would have to wait a little bit more for their newfound dreams to come true.

Indeed, and upon closer inspection, what had been announced back then was nothing more than a wizard-driven diagramming tool for ultra-primitive models on one hand, and the hosting of a complex software stack without native support for multi-tenancy on the other. Hardly the stuff of ground-breaking news, but there is nothing like a good marketing spin to spice things up a bit.

The first is heralded as a process discovery tool that would allow business analysts to model high-level processes, then generate a skeleton that technical people would turn into executable processes. There are three problems with such an approach:

1. If you're serious about abstract process modeling, why not use a full-fledged tool like IDS Scheer ARIS or Casewise Corporate Modeler? If the only answer is that they cannot run in a web browser, then I would just look for an Office 2.0 alternative to Microsoft Visio, such as Gliffy or ajaxSketch. It will be a lot cheaper (if not free), and should provide much greater flexibility in letting the business folks model what they want.

2. By giving different tools to different people, you're not helping to bridge the business-IT divide, you're making it wider. Using two completely different sets of tools that rely on fundamentally different semantics for describing business processes will simply ensure that roundrip engineering from one to the other is forever impossible in a production environment. Your nice web-based process sketching tool will just be a way to feed the pre-sales efforts conducted by the software vendor, and you will never use it again once the process has been put in production. To make a long story short: it's a waste of time, and a distraction that takes you down the wrong path.

3. By raising the abstraction level even higher, the BPM vendor gains a sexy tool that is great for sales presentations, but makes it even more difficult upon its professional services resources—remember, customers rarely implement processes themselves, as described in this past article—to actually implement executable business processes. Where you already had two levels (graphical notation and code), you now have three (graphical notation for business analysts, graphical notation for technical people, code). Synchronization and dependence tracking is hard enough with two levels, and that's the reason why Intalio opted for a Zero Code, single level approach. Three makes it just impossible. Newton's three laws of motion work well with one or two bodies, but as soon as you get three, you end up having to solve complex differential equations that are best handled by chaos theory. Well, BPM follows similar rules, and when you get from one, to two, then three levels of abstractions, everything falls apart.

The second very much felt like a reactionary move to the first, and is nothing more than the vendor's on-premise software being hosted by the vendor and sold on tap. Multi-tenant architecture? Forget about it. Dedicated user interface? Not until next release. Rationale for the move? Just because we can.

Problem is, unless what you call BPM is nothing more than a workflow application, BPM is a platform, a piece of middleware, and selling it as a service has been notoriously difficult—remember GrandCentral? When your process requires interactions with human beings as well as transactions with back-office systems, the on-demand model makes everything a lot more difficult. Of course, there are some scenarios where all you need is a couple of manual approval steps, and a call to a stock ticker web service. But for these, Yahoo! Pipes might really do the trick. And if you need more, it's likely that you will want it with a totally different user interface, because, whether you like it or not, today's BPM solutions remain fairly complex pieces of middleware technology that require some advanced training, and it's not likely to change anytime soon. If did not for the RDBMS, and I cannot see why it would be any different for the BPMS.

To be honest, I am as much a sucker for anything SaaS as any of my competitors, and the reason why Intalio does not have a BPM SaaS offering today has nothing to do with lack of interest on our part or on the part of our customers. Instead, it's a direct result of what is possible, and what is not, no matter how much marketing you put to work. From this realization, our SaaS strategy has been radically different from the one of our competitors: instead of announcing half-baked solutions, we are enabling partners that are delivering tangible value using our software, today. I will mention two of them:

The first one is a company called Coghead, which was founded by a guy who knows a thing or two about processes: Greg Olsen, founder of Extricity, the company that first introduced the concepts for public processes and private processes. Greg and his team have developed what's akin to the first BPMS natively built for the web. It allows you to graphically design complex processes and data objects, call remote services and create human workflow tasks, all without having to write a single line of code. And when Greg went out to look for the fastest, most scalable process engine to power his baby, he settled for nothing else than Intalio|Server. If you're looking for a true hosted BPMS, check them out!

The second one is a company called OperMIX, which is based in Canada, and was founded by a cool chap named Hicham Jellab. Hicham and his folks work with large organizations that are using SAP on premise and Salesforce.com on demand. They're helping their customers integrate the two, and use a BPM platform in the middle. But because some customers want to focus on specific business scenarios and do not care to own the entire IT stack, they're relying on OperMIX to provide a hosted version of Intalio|BPMS. On top of it, they are using the Liferay open-source portal, our legendary SAP connector to connect to SAP R/3 or mySAP, and our WSDL connector to connect to Salesforce.com, then let customers design new processes directly from Intalio|Designer. Really cool stuff.

While both scenarios are quite different, they have a couple of things in common that make them work: First, the architecture was designed from the ground-up for web-based multi-tenancy. Second, the life-cycle of processes is preserved by religiously sticking to the Zero Code, single level approach. Third, both were in production before our customers issued their catchy press releases.

If you're looking for BPM as a service, one of our partners should have it for you.