VOSibilities

As those of you who follow us know, we’re very proud of the fact that ActiveVOS is built from the ground up on standards. We strongly believe that standards support is the entry price for any BPMS that hopes to change the way process applications are built and deployed.

Now, I am pleased to report that OASIS has announced that the WS-BPEL Extension for People (also known by its alliterative shorthand name, BPEL4People) 1.1 specification is available for public review. In addition, the companion specification, WS-HumanTask 1.1, is also available for public review. ActiveVOS 7 implements both WS-HumanTask and BPEL4People.

In short, these two standards marry automated processing with a vastly updated and more intelligent approach to human workflow that (finally!) makes including people in complex processes as easy as including any system task.

Consider the graphic above. Prior to WS-HumanTask (and BPEL4People), creating human tasks usually required interaction with a proprietary workflow system that didn’t necessarily integrate easily with the rest of the application architecture:

One of the motivations of WS-HumanTask was an increasingly important need to support the ability to allow any application to create human tasks in a service-oriented manner. Human tasks had traditionally been created by tightly-coupled workflow management systems (WFMS). In such environments the workflow management system managed the entirety of a task’s lifecycle, an approach that did not allow the means to directly affect a task’s lifecycle outside of the workflow management environment (other than for a human to actually carry out the task). Particularly significant was an inability to allow applications to create a human task in such tightly coupled environments.

This graphic neatly shows how these new standards separate — and standardize — the work items from the processing of those items. All in all, a huge step forward for a new generation of process apps.

When you do take a look at the specs, I hope you’ll notice the level of commitment Active Endpoints has made to developing and finalizing these standards. Two of our technical leaders, Luc Clément and Michael Rowley, are listed as editors for the drafts. They are helping make a lasting contribution to BPM through their efforts to bring these standards to market, in partnership with the other members of the OASIS Technical Committee.

Keith Swenson has posted this interesting list of questions to ask a BPM vendor.  I liked his emphasis on standards, since it is so important that the hard work that goes into creating business processes not be trapped in proprietary technology.  However, I think he concentrated on the wrong standard — XPDL.  If you really care about safeguarding your investment in your processes, the standard that you should care the most about is BPEL4People.

Don’t get me wrong, XPDL has its place.  ActiveVOS can both import and export XPDL version 2.1 (the latest version).   But XPDL is not a technology that will allow you to take an business process that is executable on one vendor’s BPM engine and move it to another vendor’s engine.  It just won’t work.  If you are lucky, the resulting business process diagram will look recognizable because the “abstract model” (as XPDL calls it) will import successfully.  But don’t get your hopes up about saving all the work that you did on the executable details.

The problem is not that XPDL has no place to put those executable details — it does.  It just doesn’t put enough constraints on what should go there.  There are just too many different things you can do, so no two tools do the same things.   Also, the bar for being able to say that you support XPDL 2.1 is just too low.  If a tool exports something that conforms to the XML Schema (possibly with liberal use of extensions) and import doesn’t barf on any Schema-valid input, then the tool conforms.  But don’t look for guarantees that you will see, much less be able to execute, anything reasonable.

By contrast, users of ActiveVOS have had great success in using BPEL-based business processes that were created by either IBM, Oracle or TIBCO tooling.  They have also found that the BPEL generated by ActiveVOS can be used by the tools of those other vendors.  That is real investment protection.

I do like Keith’s idea of having a list of questions for BPM vendors to help in the evaluation process.  I think the best way to organize such an evaluation is around four key areas.

Are the key BPM standards supported?

• Does the product generate executable WS-BPEL 2.0 processes?
• Can you model processes using BPMN?
• Does the product use the BPEL4People for activities that are handled by people?
• Are worklists and tasks exposed through the WS-HumanTask standard?
• Does it support the important enterprise web-service standards, such as WS-Security and WS-ReliableMessaging?
• How about non-SOAP access to services, such as JMS, REST or plain Java?
• Does the product import and export XPDL?

Does the development environment make the process developer highly productive, especially for processes that are larger than mere toys?  For some important examples, how easy is it to:

• Incorporate existing web services into a process?
• Detect changes to web service definitions and update the process accordingly?
• Define services provided by the process (including defining XML Schemas and WSDL)?
• Define new human tasks using existing data definitions (XSDs)?
• Prepare the input data for human tasks or services?
• Support services that “call back” into a running process, and specify the appropriate data to use for correlation?
• Find all uses of a variable within a large process?

An executable process is deployed software.  What support is available for ensuring and maintaining its quality?

• Is there test case generation?
• Is there test suite support?
• Is there remote debugging?
• Is there Metadata for controlling the difference between staging and deployment?
• Can you new versions without effecting existing process instances?
• Can you deploy new versions that do change existing process instances?

What can be done to a running instance?  Can you:

• See where it has been (with anotations on the process diagram)?
• View current and historical data?
• Change data?
• Skip activities?
• Single step through activities?
• Rewind execution, optionally reverting all process data to what it was?

What kind of runtime console support is there?

• Can you get reports with either operational or business information?
• Can the end user create any kind of new report and incorporate it into the runtime console?
• How powerful is the query capability to find a process instance you care about?

All of these characteristics of a BPMS will eventually be important to anyone that is creating the kind of critical business processes that will really transform a business.  Knowing the answers to these questions can help you to avoid making the wrong choice.

In a very interesting post on his Gartner blog, Jim Sinur asks, “What is the greatest hurdle facing BPM?” He then describes three “top choices” on which (unsurprisingly) we have an opinion.

The first challenge Jim raises is “enabling people,” writing “While BPM has been helping with ‘heads down’ process workers for a while now, BPM needs to move to supporting more people activities.”

We violently agree. ActiveVOS was the first BPMS to ship a complete and standards-based capability to integrate human tasks with automated business processes (check out Dana Gardner’s BriefingsDirect Analyst Insight Edition podcast on BPEL4People). ActiveVOS is specifically designed to integrate people flexibly into end-to-end, completely integrated processes. And, boy, has this been a winner for us in our product. I can’t think of a customer who has deployed ActiveVOS in the last two quarters that hasn’t integrated human workflow into their processes. The reason this has been so popular among customers? It’s now easy to do…and it’s open.

The second challenge Jim talks about is “leveraging information.”  Jim writes:

While BPM works well with structured data and content management capabilities, BPM needs to embrace events beyond the progress of business activities in the known paths of a pre-defined process. Process will need to support more information around the context in which the process is running in at the moment. What is the effect of markets, geographies or the state of the partner chain that the process is operating within right now? This means close ties to complex event processing and intelligent decision management. This would not only include the current state of the process, but would include past trends to optimize process outcomes.

This is the proverbial softball for ActiveVOS. Only ActiveVOS includes an integrated CEP engine. Why integrate CEP into a BPMS? Because if you do it well (and we think we did), you make it possible for BPM applications to add CEP capabilities as needed, delivering just the kind of flexibility Jim is seeking. In ActiveVOS, CEP is a deployment time option. You don’t have to change the the process to take advantage of CEP, and the normal BPMS execution engine generates all the events and stream data needed for the CEP processor. It’s a snap to leverage information this way…and thereby overcome one more hurdle to widespread BPM adoption.

Finally, Jim writes about “scope of impact.” Jim says, “Expanding BPM’s influence to innovative end to end processes that are linked to important value chains will test what BPM really brings to the party.”

We couldn’t agree more. We believe that the sustaining competitive difference between ActiveVOS and “pretty picture” BPMSs (the ones that claim you can punch a button and magically deploy a complex end-to-end process) is our emphasis on integration. We believe in model-based execution. We are true believers that business analysts have to be driving the development of business processes. But we are also fervent believers that to achieve the impact Jim describes requires BPMS technology that integrates all the existing applications and data that are central and not-so-central to the process. Those resources are likely to be inside the IT infrastructure today — and the BPMS needs to maniacally focus on making it easy for IT to leverage them into new processes. I read Jim’s comments to mean that far from going around IT, he’s calling for exactly the kind of collaboration between end users, business analysts and IT that we are designing our product to promote.

We think the road ahead for BPM has some curves…but is otherwise clear ahead.

Active Endpoints’ own Michael Rowley joins Dana Gardner’s analyst round table for an update on the BPEL4People standard and the results of the recent activities that are guiding the development of this standard.

 

 BriefingsDirect Analyst Insights Podcast #37: BPEL4People: Human Tasks in Business Process Applications [47:20m]: Play Now | Play in Popup | Download (888)
 BriefingsDirect Analyst Insights Podcast #37: BPEL4People: Human Tasks in Business Process Applications - transcript: Download (399)

Unlike other companies that want to keep everything a big secret until they ship a release, we can’t wait for you to discover the cool new things we’re shipping in the latest release of our BPM product, ActiveVOS.

We plan to have ActiveVOS 6.1 available on March 10, 2009. But for BPM developers and business analysts longing for a simpler, more intelligent, easier-to-use BPM system, there’s no need to keep our new release secret. ActiveVOS 6.1 is precisely what you have been waiting for. And, if the vicissitudes of QA testing cooperate, you can have it next week.

The PDF attached to this post, authored by our Director of Products, Luc Clément and our Director of Strategy and Technology, Michael Rowley, is a great overview of what’s in ActiveVOS 6.1.

Check out the very sophisticated control of in-flight processes via our new “process rewind” capability in ActiveVOS 6.1. And, for those of you who a) know that BPEL is the core language for SOA and b) have thought BPEL is too complex, be sure to read up on how ActiveVOS 6.1 automatically generate BPEL assigns and the WSDL’s necessary to create compelling BPM applications.

 What's New in ActiveVOS 6.1: Download (1109)

Last week, Active Endpoints’ Michael Rowley participated in the quarterly face-to-face meeting of the OASIS Technical Committee working on the BPEL4People and WS-Human Task specifications. In this very engaging podcast, Rowley describes the inner workings of TC’s (something you usually don’t hear much about), describes the work the TC has recently accomplished and articulates the grand vision for business process management (BPM) and workflow that the committee has been working  on.

If you’ve been wondering about the state of standards-based BPM and workflow systems or, frankly, if you think BPEL and BPEL4People have dropped out of sight, I strongly encourage you to listen to this podcast. You’ll hear how some the of most important thought-leaders in the IT world, including IBM, SAP, Oracle, Microsoft, TIBCO and, of course, Active Endpoints, are working towards a BPM world in which standardized systems make it possible to implement business processes in ways we haven’t been able to reach as yet.

We hope you enjoy this look at BPM today and in the future.

 

 VOSibilities podcast #27 An Update on the BPEL4People Standard [24:53m]: Play Now | Play in Popup | Download (373)

Loraine Lawson recently did a great job of summarizing some of the predictions for 2009 for IT. Loraine noticed that there was one item that was common among the predictions by David Linthicum, Joe McKendrick and Eric Roch. Joe put it this way: “There will be fewer big-bang SOA projects rolled across the whole enterprise, and many more incremental, bottom-up efforts — many of which may be under the radar.” Although not mentioned in Loraine’s post, Dana Gardner also has this podcast interview with several pontificators who predict, among other things, that businesses in 2009 will emphasize projects that can reduce costs in the near term.

So, what technology do you want to use if you already have several services and you want to quickly and easily create a few new services, partly by building off of existing services and partly from scratch? Installing an ESB would be a mistake. If you already have one, that’s great, but a small project isn’t the right place to kick off the move to an enterprise-wide bus.

What about development technologies? Should you create your new services using JAX-WS and JAXB deployed using JavaEE deployment machinery? No. Why pay all of the complexity costs related to mapping XML and web services into Java in this case? The new business logic would be so dwarfed by all of the generated code and configuration files that it would be lost in the muck. Just the JAXB generated classes alone will usually be counted in dozens for any real XML document.

Why not use an orchestration language that is already designed to use XML and WSDL as the native type system for the variables and method signatures? In other words why not use BPEL? If the new service can’t be fully automated you can use BPEL4People to handle the involvement of people in the service.

Of course using the right language is not sufficient. For the project to be small and simple, it should also be easy to test and deploy. It should make it easy to manage running services. And just because you want high developer productivity doesn’t mean you can give up the need to develop truly high performance services. And if the project is really going to generate a quick ROI and operate “under the radar,” it has to be budget-friendly.

ActiveVOS anyone?

I am pleased to post the second episode in our continuing series of product vignettes — short video recordings of important features in ActiveVOS.

This time, Mike Moniz demonstrates how to use ActiveVOS to customize the work list manager (he calls it an “inbox”) that users access in order to process tasks assigned to them by the ActiveVOS BPM system.

Make no mistake: what you are looking at is a fully compliant BPEL4People and the WS-Human Task client which can be easily modified to meet your UI requirements. By leveraging the inter-related BPEL4People and WS-HT standards, ActiveVOS is able to deftly include human activities in complex automated workflows.

Frequent readers of our blog know that there’s a healthy debate (here and here) going on about whether or not BPEL is appropriate for SOA-based BPM. (BPMN is often proposed as the “alternative.”) We think that debate misses the point: computers require precise definition of all the runtime details to run applications. Ergo, an execution-oriented language like BPEL is required.

We think the real question boils down to: does BPEL have what it takes to both run “on the metal” and permit the inclusion of human tasks into running processes? When you see what you can do with BPEL4People and WS-Human Task in ActiveVOS 6, the answer is clearly, “Yes.”

 

 VOSibilities podcast #25: Customizing a BPEL4People and WS-Human Task client worklist manager: Play Now | Play in Popup | Download (1608)
 VOSibilities podcast #25: Customizing a BPEL4People and WS-Human Task client worklist manager: Download (293)

In this fascinating podcast, Michael Rowley, director of strategy and technology at Active Endpoints discusses the history of how the Business Process Modeling Language (BPMN) and the Business Process Execution Language (BPEL) were unfortunately “separated” at birth. He also describes why BPMN and BPEL belong together and what the current efforts in the standards organizations working on BPMN and BPEL are doing to re-unite these two critical standards for SOA-based development.

The good news is that SOA developers are the ultimate winners of the inevitable reconciliation of BPMN and BPEL, but as Rowley describes, the reconciliation isn’t intended — and indeed shouldn’t be — a perfect union.

Rowley concludes by describing what ActiveVOS 6.0 delivers today for SOA developers who want to work with BPMN and BPEL in a single, integrated, deployable product.

We hope you enjoy this podcast, and, as always, welcome your comments on this podcast.

 

 VOSibilities podcast #19: Why BPMN and BPEL were (unfortunately) separated at birth and what it means for SOA developers [19:41m]: Play Now | Play in Popup | Download (1099)

Last week, David Linthicum’s SOA podcast continued a theme he’s been on lately, a discussion of BPEL’s “fallings” [sic]. I think he meant failings…but in any event, he mentions several times in the podcast that a post he’d previously written on this topic had generated quite a discussion (it did) and feedback from unnamed “BPEL vendors” (that’d be us; I can’t imagine why he didn’t name us. (-: )

Anyway, today after I heard the podcast, I asked Chris Keller, our founder and vp of development and one of the most knowledgeable people on BPEL in the world for his feedback. Chris has not only written the BPEL engine that’s at the core of our visual orchestration system (a VOS is a whole lot more than a BPEL engine), he’s active on the OASIS committees that are furthering the standards.

Chris gave me a lot of food for thought, and being in a playful mood, I thought it might be fun to that feedback into a Q&A. Sorta like a game show, with Mr. Linthicum as the contestant. The prize, for correct answers, is a free ActiveVOS license. Let’s see how Mr. Linthicum does…

Question 1: In the podcast, David says that a major problem with BPEL is that it’s synchronous.
Did David get it right? Click the arrow to find out… Then click here to read the correct answer
Sorry, no. Chris points out that the exact opposite is true. BPEL is asynchronous by definition.

Question 2: David says BPEL has a few programmer-level issues including limitations around request/reply exchanges in a heterogeneous architecture.
Did David get it right? Click the arrow to find out…Then click here to read the correct answer
Whooppss…wrong again. Chris points out that this isn’t a problem with BPEL as much as it is a problem with vendor support for standards that make request-response asynchronous, like reliable messaging. It’s one prime reasons for the WS-TF standards effort.

Question 3: David says BPEL has issues with failure recovery, exception handling and multi-programming model support.
Did David get it right? Click the arrow to find out…Then click here to read the correct answer
So very sorry. Chris points that exception handling is covered by the specifications and that recovery isn’t something that belongs in the specification at all (This is a major differentiator among vendors, and something ActiveVOS does brilliantly — ed.). As for multi-programming model support, we aren’t quite sure what David means, but if he’s talking about multi-tasking, the spec has that covered, too.

Question 4: David says BPEL is not very good at adding a human as part of the process and as SOA moves forward, he’s finding that composites and workflows are more applicable than simple service binding and extending.
Did David get it right? Click the arrow to find out…Then click here to read the correct answer
Close…but no cigar. Chris points WS-HT and BPEL4People have been added to the specification for precisely this purpose. While David’s criticism was once correct, it’s not applicable today.

We hope that you’ve enjoyed our little episode of The BPEL Game Show. And sorry, David, but you didn’t win our prize. However, anytime you’d like to be brought up-to-date on why BPEL is at the heart of SOA development, we’re happy to update you so you can win the next time.

I’ve been waiting to post this video podcast episode for a couple of weeks because I wanted to understand better all the vitriol and confusion in the marketplace between BPMN promoters on one side and BPEL proponents on the other

No less an authority than Bruce Silver noted over two years ago “…that the world of BPMS is divided into BPEL-lovers and BPEL-haters…” And as soon as I arrived at Active Endpoints last January, I could really feel the tension…an internecine battle among people who believe in the same outcome and passionately hold that standards-based technology is ultimately the correct path for customers.

But at the end of the day, there are two inescapable facts. First, BPMN is not executable. BPEL is. Together, they are a more potent, winning combination for customers than peanut butter and jelly. I just can’t understand why BPMN promoters skip over this fact.

This BPMN-bigot blind-spot this allows Lombardi, SAP and others to claim ”support” for standards and yet execute the processes on a proprietary execution engine. Isn’t that the maximum possible deprecation of BPMN? Isn’t it a violation of the original intent of BPMN to run it on proprietary engines, ensuring customers lose agility and increasing their costs? Why don’t BPMN people just loathe that idea?

We do, and that’s the second inescapable fact: no modelling-direct-to-execution technology has ever succeeded. That’s why BPEL4People is so important (and why we are on the BPEL4People Technical Committee and have implemented the current capabilities of BPEL4People in ActiveVOS 5).

It’s really pretty simple (and here comes a mixed metaphor I can’t believe I’m posting): dolphins don’t talk but old dogs can be taught new tricks. Dolphins may actually be smarter than humans, but they don’t speak in words. BPMN may be great, but it won’t run “on the metal.” OTOH, BPEL can be extended with human activities that are first-class participants in a BPEL orchestration. That ole dog sure can hunt.

Bottom line: BPEL and BPMN together is what kumbaya sounds like for BPMS. And today’s podcast episode is a proof point: watch how Mark Ford shows an orchestration that includes human workflow as a first-class participant and which is 100% standards-based. (And watch for us to shortly say a whole lot more about ActiveVOS and BPMS.)

 

 VOSibilities podcast #6: Mark Ford on BPEL4People [2:35m]: Play Now | Play in Popup | Download (1233)

 

 VOSibilities podcast #6: Mark Ford on BPEL4People [2:35m]: Play Now | Play in Popup | Download (234)

David Worthington of SD Times covers the release of ActiveVOS 5.0 and writes that we have “…cracked the code to bring Web services into mass deployment for line of business applications.” The entire article is here.

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.

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 (849)