VOSibilities

One of the reasons I really enjoy working with application development software so much is the vitality of the online community. My recent post reacting to what I perceived as a dismissal of BPEL4People generated both responses and traffic for this, our brand spankin’ new blog. Unlike other technology areas, app dev — and the SOA world in particular — is full of well-thought-through blogs and fascinating personalities. I appreciate readers who have taken the time to find us and who are interested in what we have to say.

And, as the newbie in this universe, I seem to have stepped into the middle of a BPMN versus BPEL discussion. My post was perceived by some as exactly that: one should pick BPEL or BPMN. It felt like I got into a religious war, with competing accolytes for each side doing that shout-over-the-wall-at-the-other-side thing.

I want to make sure we are clear about how we view BPEL and BPMN. Over this last weekend, I had an email discussion with Mark Taber, our CEO, which I’d like to paraphrase to make sure everyone understands what we think is important for customers who are trying to orchestrate services that include human tasks. In short,

• We understand people are adopting BPMN. It’s a standard…and our company is all about standards.
• Today, BPMN is being used mostly for notation..that’s OK, but unless it’s executable it’s not any more relevant to writing an application than Visio is.
• If you want you BPMN notations to be executable, today that means buying proprietary execution stacks, which lock up your business process logic better than a life sentence at Guantanamo Bay.
• BPMN is only going to be useful when you can output it to a standardized, open and executable language. Guess what: we think that’s BPEL.

So, far from dissin’ BPMN, we think it’s got it’s legs…but the legs are built of BPEL.

As a kid, I was fascinated by Etch-a-Sketch toys. But I gave it up when I realized that after hours and hours and hours of drawing, my artwork (if you could call it that) was locked into the toy. I couldn’t change it easily and one simple shake would destroy the entire picture. That analogy holds perfectly for BPMN without BPEL: you can etch-a-sketch all your business processes with it, but if you want to run it, the BPMN ends up inside some vendor’s proprietary execution stack.

What standards-based SOA implementation wants that?

Well, this is my first real “content” post and I am about to challenge no less than eminent industry notable and EDS Fellow Fred Cummins, who recently took the opportunity to declare BPEL4People dSOAoa (pronounced d-SEW-ah-oh-ah and meaning “Dead SOA on arrival”).

I am not sure if Fred’s problem core problem is with BPEL4People as much as it is with BPEL itself, which he dismisses as “for programmers.” But it’s clear he doesn’t think much of either standard, favoring instead BPMN. And I’ll be the first to admit that I am not the one who can specifically refute many of his technical arguments.

But I do know one thing: being “for programmers” when it comes to standards-based workflow ain’t a bad thing. That’s because from my relatively non-technical perspective, two things have always been true about workflow systems. First, the support for them in programming languages has been abominable and, second, every single end-user workflow system that has ever been tried has been a failure.

If the charge is “BPEL (and therefore BPEL4People) is a programming language,” then my counter-charge is that BPMN is about non-executable pretty pictures. Wikipedia says, “The primary goal of BPMN is to provide a standard notation that is readily understandable by all business stakeholders…”

Pretty diagrams do not a business application make.

In short, workflow is something that has to be developed into an application, not “specified” by some end-user on a canvas. That’s because while you can expect a developer to be capable of understanding the workflow process and adapting it to the application, you can be certain an end-user won’t be able to integrate his or her expert-level knowledge of the business process into a database or transaction system.

One area I suspect Fred and I agree on, though, is the need for standards. Another reason workflow has been ineffective in business applications is that business are loathe to lock up their processes in proprietary formats. What BPEL4People and BPMN offer users is the opportunity to free themselves from proprietary workflow engines, which is surely a good thing.

Active Endpoints to Drive Mass Adoption of Services-based Applications

 Active Endpoints to Drive Mass Adoption of Services-based Applications: Download (227)