When using a BPMS, be sure to insert the correct fuel into the right tank
April 20th, 2009 by Alex Neihaus
Tony Baer has just posted a thoughtful blog post about ActiveVOS on his excellent On Strategies blog. A very nice freebie in the post is a link to a PowerPoint discussion of the differences between BPMN and BPEL, using the Mars/Venus-male/female dialectic to point out some interesting issues when mating the two standards.
One thing I always enjoy about talking with Tony and reading his blog is that he pulls no punches. (As a native Noo Yawker myself, it’s a style I really appreciate.)
Bottom line: Tony doesn’t like BPEL. In the distant mists of previous iterations, Active Endpoints was once a BPEL engine company, ergo, there’s a little whiff of A train at rush hour in Tony’s mind when he thinks of us. It’s almost like once tastemakers’ attention has turned elsewhere (think “virtualization” and “cloud”) “yesterday’s” technologies seem a little dusty. (And of course, that’s the exact moment that customers get something they can really implement.)
As my colleague Michael Rowley always points out, BPEL is the “native” execution language of SOA, the fuel of a SOA execution engine. So, if you want to create a BPM application that uses services and you don’t use BPEL — what else you gonna use? Someone’s proprietary Java engine? Would you put 2-cycle oil and gas mix into a 4-cycle engine? Of course not.
And if you want to do BPM in 2009, you gotta have both the right engine and the correct fuel to run it on. And that’s what we’re doing in ActiveVOS: allowing developers to do the right thing architecturally while insulating them from (very ugly) low-level coding. IOW, if BPEL is the “machine language” of SOA, who says you have to write it in binary, by hand?
Tony clearly gets this:
ActiveVOS, which is Active Endpoint’s [sic] product (a mouthful for a small company, yes?) takes a RAD approach to making BPEL just a little less BPEL. Instead of seeing endless lines of BPEL XML, it aggregates the BPEL into process steps that look a bit like the workflow diagrams that business process analysts consume.
This is, of course, true. We have an excellent visual designer that fuels the industry’s best execution engine. But I respectfully submit that Tony misses the point: what ActiveVOS is about isn’t BPEL; that’s just what the engine understands. Instead, the real value of ActiveVOS is that everything a developer does is standards-based. That means their employers have skill availability. That means there’s some level of portability. That means that core business processes are transparent. Yes, we have a BPEL engine. And no, nobody really needs to care about that.
It’s like what Consumer Reports is always telling drivers: assuming the right octane level the brand of gasoline makes no difference. BPEL is the right octane level for BPM in a SOA environment. And that’s that. Once you have a full tank of the right stuff, it’s how the car drives that matters. And we think ActiveVOS is the BMW of BPM systems; test drive ActiveVOS and see what we mean.
Are we sensitive on this point? Well, maybe just a little. We don’t understand why people keep focusing on the fuel. Like gasoline, BPEL is a commodity. An important one, but nobody buys a car based on the smell of the gas — they buy it for what it allows the engine to do.
So, while it’s important to know what you’re putting in your tank, it’s more important to focus on getting the right car. That’s where we’re focused in development of ActiveVOS, not on “making BPEL better.”
Tags: BPM
