VOSibilities

Please join us for an informative webinar on April 17 entitled BPEL Basics for Java Developers. Register here.

This informative webinar will help you expand your Java knowledge to acquire an understanding of the basics of BPEL. A high-level overview of BPEL and its importance in a web-services environment will be presented, along with a brief discussion of the basic BPEL activities and how they relate to Java concepts. The following topics will be covered:
• Parsing the Language of SOA with Java as a guide
• Breaking out of the VM: evolving from RPC to Web Services
• BPEL Activities - Receive, Reply, Invoke • BPEL Facilities - Fault Handling and Compensation (“Undo”)

We hope you can join us.

Try as I might, I can’t find a single line of source code in the download of Intalio’s Community Edition ”open source BPMS.” Imagine my surprise at this considering they have been claiming open source leadership for years. They even call themselves “the leading Open Source BPMS company.” Sure, you can find source code for individual piece parts if you go to another website and find it as part of Intalio’s donations to open source projects, but here I am talking about their claims of open source leadership in regards to their Community Edition product.

Because of the complexity of enterprise software, I believe software companies have to hold themselves to a higher level of “truth in labelling.” We don’t like it when toothpaste has antifreeze in it. And I don’t like it when an purportedly open source product has no source and licensing restrictions that sound like they were written in Redmond or Walldorf.

It may be simplistic but calling something “open source” means you get source code. While Sandy Kemsley finds it amusing when I quote Wikipedia, the simple fact is that Wikipedia’s definition of FOSS says open source allows users to “…study, change, and improve its design through the availability of its source code” (emphasis mine). To call yourself the “open source leader” and to launch an “open source service” (whatever that is) means you should conform to the conventional definition of what FOSS is. And that ain’t what Intalio is doing, near as I can tell.

I was recently fact-checking an upcoming analyst report on BPMS in which the author mentioned in passing that Intalio didn’t actually include source in its Community Edition downloads. I was dumbfounded (and more than a little miffed that these analysts could so blithely give these guys a pass on so fundamental a point).

Incredulous, I asked our product management people to take a look. As willing as I am to call Intalio out for misleading users about its Community Edition, I am still not willing to cut and paste the heated analysis I got back from the product managers. So, let me try to summarize:

• As far as we can tell, the license included with their product includes the restriction that users may not “…decompile, disassemble, or otherwise reverse engineer or attempt to reconstruct or discover any source code or underlying ideas or algorithms of the Intalio Software by any means whatsoever…” (again, emphasis mine)
• As far back as 2006, Intalio was happy allow confusion between “open source-like” and real open source in its licensing to morph into “open source leadership.” (Here, you have to knock Gartner for not being more consistent and giving Intalio the room to claim open source street cred undeservedly.)
• At the end of the day, Intalio’s claim of an open source mantle isn’t about standards or FOSS, it’s about its sales model.

It’s that last point that I really object to. It’s OK to be proprietary. It’s OK not to ship the source code. What’s not OK is to use the terminology of standards and open source to confuse users for the (very legitimate) purpose of driving sales. That’s just misleading.

Anne Thomas Mannes of the Burton Group has recently written a post that sums up what I believe is the missing in the discussion of SOA and BPM: the enormous challenge in getting line-of-business developer teams to use these techniques.

Anne writes:

I’ve talked to many companies that have implemented stunningly beautiful SOA infrastructures that support managed communications using virtualized proxies and dynamic bindings. They’ve deployed the best technology the industry has to offer — including registries, repositories, SOA management, XML gateways, and even the occasional ESB. Many have set up knowledge bases, best practices, guidance frameworks, and governance processes. And yet these SOA initiatives invariably stall out. The techies just can’t sell SOA to the business. They have yet to demonstrate how all this infrastructure yields any business value.

More to the point, the techies have not been able to explain to the business units why they should adopt a better attitude about sharing and collaboration–which is the fundamental cultural shift required for SOA to succeed. The pervasive attitude is “What’s in it for me?” As one of my interviewees said, “Altruism is not an enterprise strategy”.

Many Americans will remember former President Clinton’s famous prescription for political success in the 1992 presidential campaign: “It’s the economy, stupid.” In a single sound bite, Clinton moved beyond technical discussions of monetary and fiscal policy to the heart of the matter: people cared then, as now in a period of economic turmoil, about bread-and-butter issues.

The challenge of SOA and BPM in business today is that it’s all been high-falutin’ theory. And lots — lots — of money spent on piece parts that look good on architecture diagrams but which are unimplementable by mere mortals in line of business development project teams.

It’s no wonder these “stunningly beautiful SOA infrastructures” cannot be “sold” to the business. By themselves, they do do nothing. Squat, nichts, nada. It takes developers to make these investments pay back for the business and those guys are too smart to sign up for science projects when they get paid to do business applications.

Those who care about SOA and BPM and making it real should take Anne’s advice and stop navel-gazing at their lovely accomplishments. The discussion needs to turn to how to enable real developers to use SOA effectively.

To anyone reading this blog, it’ll come as no surprise that we are quite sure we have the answer. That’s why we created a new category, the visual orchestration system, and a new product, ActiveVOS, specifically for line of business application developers.

It’s a tall claim, but we have the stuff to prove it. (It’s also why we took the unusual step of putting a top-level menu on our new website called “Proof“.) ActiveVOS is all about the application, stupid. And it’s about ending the habit of peeling money off the roll simply to build beautiful architectures nobody can use.

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.

Our first podcast episode features our CEO, Mark Taber, detailing Active Endpoints’ vision for making possible the mass adoption of services-based applications. Mark touches on the problems facing developers and project teams who struggle with today’s overweight, expensive and hard-to-use tools. He also details how ActiveVOS is the most open and flexible solution to what has until now seemed like an intractable problem.

We hope you enjoy this podcast. If you have any comments or questions, please email us or leave a comment on the blog.

 

 VOSibilities podcast #1: Mark Taber on Visual Orchestration Systems [2:38m]: Play Now | Play in Popup | Download (456)

Today, Active Endpoints announced availability of ActiveBPEL Community Edition Server 5.0. The community edition contains the first implementation of BPEL4People.

Also today, OASIS announced the formation of a technical committee focused on finalizing the BPEL4People specification. We are participating in this technical committee and look forward to BPEL4People once and for all eliminating proprietary workflow from enterprise applications.

You can read more about Community Edition in our press release, attached to this post.

 Active Endpoints announces milestone 1 of Community Edition with BPEL4People: Download (330)

Active Endpoints to Drive Mass Adoption of Services-based Applications

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