standards – Page 7

Intro to BPEL

I just listened in on To BPEL or Not To BPEL, the title of which I believe resolves the pronunciation issue once and for all: although the presenter (Danny van der Rijn, principal architect at TIBCO) said “BEH-pull”, clearly it must be “BEE-pull” to make the title work. 🙂

Intended for those with a technical interest in BPEL, van der Rijn went through the history of BPEL from its origins as a melding of IBM’s WSFL and Microsoft’s XLANG, through the BPEL4WS 1.0 specification in 2002, 1.1 in 2003 and the soon-to-be-approved WS-BPEL 2.0. More importantly, he looked at why BPEL emerged: basically, the web services stack didn’t do enough to allow the orchestration of processes.

He then talked about what you’re not going to do with BPEL — it’s not a process modelling notation, it’s not for service creation — and stated that it’s not for portability: he mentions XPDL as a solution in that area (with no mention of BPDM). What I’m seeing, however, is that although BPEL may not have been intended as an interchange format, that’s exactly what it’s being used for in many cases. For many BPM engines, the “E” in BPEL is apocryphal: BPEL is a format that’s used to import process models from other applications, but it’s then converted to an internal (proprietary) format for the actual execution.

He covers off all the changes in 2.0: data, scoping model, message handling, activities and more, and walks through the basic BPEL components in some amount of detail. Overall, a good technical introduction to BPEL.

Unfortunately, about 40 minutes into the presentation, I received an “Invalid Flash Player Version” stating that I needed Flash Player version 8 to view the current content, and I lost all audio and video of the presentation. Flash? I was supposed to be using the Windows Media Player version of the presentation! On24.com really needs to get their act together: changing system requirements mid-presentation is not cool. Even when I installed the new Flash version and did a successful test, I wasn’t able to get back in. Guess that I’ll have to see the last bit in reruns.

XPDL and BPEL

An interesting bit on the WfMC site comparing XPDL and BPEL that was highlighted in a WfMC mailing this week:

BPEL and XPDL are entirely different yet complimentary standards. BPEL is an “execution language” designed to provide a definition of web services orchestration, specifically the underlying sequence of interactions, the flow of data from point-to-point. For this reason, it is best suited for straight-through processing or data-flows vis-a-vis application integration. The goal of XPDL is to store and exchange the process diagram, to allow one tool to model a process diagram, and another to read the diagram and edit, another to “run” the process model on an XPDL-compliant BPM engine, and so on. For this reason, XPDL is not an executable programming language like BPEL, but specifically a process design format that literally represents the “drawing” of the process definition. To wit, it has ‘XY’ or vector coordinates, including lines and points that define process flows. This allows an XPDL to store a one-to-one representation of a BPMN process diagram. For this reason, XPDL is effectively the file format or “serialization” of BPMN, as well as any non-BPMN design method or process model which use in their underlying definition the XPDL meta-model (there are presently about 50 tools which use XPDL for storing process models.)

A good distinction between the best uses of BPEL and XPDL, except for one point: very few vendors are using BPEL as an execution language; they’re using it as an interchange format, which is causing a lot of confusion about what format to use (XPDL or BPEL) to move process maps between a modelling and execution environment. As the above paragraph points out, XPDL maintains the graphical drawing information as well as the execution-specific information; it also supports everything that can be modelled in BPMN (which BPEL currently can’t).

There’s also an article by Jon Pyke of WfMC in Computer Business Review Online where he smacks them down for calling XPDL a failure in a previous article, and states that XPDL is “often incorrectly perceived to be competitive with the business process execution language, BPEL, standard”. XPDL and BPEL aren’t competing in the sense that someone would elect to use one over the other, but they are competitive in that they’re both used as interchange formats, just for different types of processes or in different tools. Unless your BPM engine actually uses BPEL as an execution language (which few do), you’re not going to go from BPMN to XPDL to BPEL and then on to your BPM engine’s proprietary execution language, because there’s no value added from an additional data transformation: you’d do BPMN=>BPEL=>[BPM engine execution language] (obviously skipping the last transformation if the native execution language is BPEL) for web services orchestration-type processes that can be described completely using BPEL, or you’d use BPMN=>XPDL=>[BPM engine execution language] (where the latter may or may not be BPEL) for the larger set of functions supported by XPDL, like human-facing steps. In many cases, the choice of XPDL or BPEL is dictated by what’s supported by the tools that you use for processes modelling; those tools intended to model processes of web services orchestrations are more likely to support BPEL, whereas those targetted at the “BPM suites” market are more likely to use XPDL.

Assorted thoughts on BPEL

There’s been a few interesting posts about BPEL lately.

First, SOA World Magazine (which appears on the WebSphere Journal site, not sure if it actually exists elsewhere since there was no back-link) has a post on BPEL’s Growing Up, covering a brief history, current status and the view forward, including BPEL4People:

Going forward, we’re already seeing the next generation of standards around BPEL being discussed. For example, the “BPEL4People” effort was first announced in late 2005 and is intended to standardize an approach similar to the one described above for incorporating human workflow tasks in BPEL processes. Besides being one of our favorite standards acronyms, BPEL4People is an important area of work since most business processes span both systems and humans.

They neglect to mention that BPEL4People is not really much more than a white paper, although a lot of people talk about it as if it’s a standard just about to hit the big time. I recently linked to a Oracle Contractors blog post where one of the comments on the post (#5) pointed out that “so far, there is no BPEL4PEOPLE”. Or as I put it in my commentary on the link, the emperor is looking around for his boxers.

SOA World Magazine goes on to say:

While BPEL vendors provide easy-to-use graphical tools for creating and editing BPEL processes, the very fact that BPEL processes are so detailed as to be executable makes these tools too complex for most business users. Instead, business users need to be able to specify higher-level process blueprints that can then be filled in by developers to make them executable.

Business Process Modeling Notation (BPMN) is a standard from OAG [sic] to address the above requirement.

Um, not necessarily. Now, the article was written by two guys who work for Oracle, so I can see why they have this view, but I’m not sure that everyone would share the view that developers are required to fill in the details in order to make models created by business analysts usable.

Secondly, the comments about Microsoft supporting BPEL. As David Chappell put it:

Like BizTalk Server today, WF [Windows Workflow Foundation] treats BPEL as a way to move process logic between different workflow engines, not as an executable format (and certainly not as a development language).

He goes on to nail the real reason for Microsoft’s adoption of BPEL:

Adding the ability to export and import BPEL workflows to WF — and thus to Windows itself — will help WF in situations where support for BPEL is a political necessity.

BPEL has become more of an RFP check item than a real requirement, since most end-customer organizations don’t really understand what it is or what it might do for them. And if you believe a recent Burton Group report, BPEL is just a placeholder for WS-CDL until that choreography standard is ready for prime time.

A Quick Peek at Cordys BPM

A month ago, I had a chance for a comprehensive demo of the Cordys BPMS via Webex, and I saw them briefly at the Gartner show last week. Their suite is of particular interest to me because the entire process life cycle of modelling, execution and monitoring is completely browser-based. I’ve been pushing browser-based process modelling/design for quite a while, since I think that this is the key to widespread collaboration in process modelling across all stakeholders of a process. I’ve reviewed a couple of browser-based process modellers — a full-featured version from Appian, and a front-end process mapping/sketch tool from Lombardi — and if it wasn’t already clear from what Appian has done, Cordys also proves that you can create a fully-functional process designer that runs in a browser and can have participants outside the corporate firewall. Like Appian, however, they currently only support Internet Explorer (and hence Windows), which will limit the collaboration capabilities at some point.

Cordys’ claim is that their modeller is BPMN compliant and supports the entire set of BPMN elements including all of the complex constructs such as transactions and compensation rollback, although I saw a few non-standard visual notations. They also support both XPDL 2.0 and BPEL for import and export, but no word on BPDM. Given this dedication to standards, I find it surprising that they can integrate only with their own ESB and business rules engine, although you could call third-party products via web services. They also have their own content repository (although you can integrate with any repository that allows object access via URL) and their own BAM. In general, I find that when a smaller vendor tries to build everything in a BPM suite themselves, some of the components are going to be lacking; furthermore, many organizations already have corporate standards for some or all of these, and you’d better integrate with the major players or you won’t get in the door.

Like most BPMS’, much of the Cordys process design environment is too complex for the average business user/analyst, and probably would be used by someone on the IT side with input from the business people; a business analyst might draw some of the process models, but as soon as you start clicking on objects and pulling up SOAP syntax, they’re going to be out of there. Like most BPMS vendors, Cordys claims that the process design environment is “targetted towards business people”, but vendors have been doing this for years now, and the business people have yet to be convinced. To be fair, I was given the demo by the very enthusiastic product architect who knew that I’m technical, so he pulled out every bell and whistle for a ride; likely business users see a very different version of the demo.

There’s a lot of functionality here, although nothing that I haven’t seen in some form in other products. There’s support for human-facing tasks either via browser-based inbox and search functions, or by forwarding the tasks to any email system via SMTP (like Outlook). There also appear to be shared worklists, but I didn’t get a sense of how automated work allocation could be performed, something that’s required to support high-volume transaction processing environments. There’s also support for web services orchestration to handle the system integration side of the BPM equation.

One thing that I like is the visual process debugger: although you have to hack a bit of XML to kick things off, you can step through a process, calling web services and popping up user interfaces as you hit the corresponding steps, and stepping over or into subprocesses (very reminiscent of a code debugger, but in a visual form).

They do a good job of an object repository as well, which helps increase reusability of objects, and allows you to search for processes and artifacts (such as forms or web services) to see where they’re used. Any process that’s built can also be exposed as a web service: just add inputs and outputs at the start and end points and the WSDL is auto-generated, allowing the process to be called as a service from any other application or service.

<geek>Another thing that I really liked is the AJAX-based framework and modelling layer for UI/forms design, which is an extension of Xforms. In addition to a nice graphical UI design environment, you can generate a working user interface directly from the WSDL of a web service — something that I’ve seen in other products such as webMethods, but I still think is cool — and run it immediately in the designer. In the demo that I saw, the architect found an external currency conversion web service, introspected it with the designer and generated a form representing the web service inputs and outputs that he popped directly onto the page, where he could then run it directly in debug mode, or rearrange and change the form objects. Any web service in the internal repository — including a process — can be dragged from the repository directly onto the page to auto-generate the UI. Linked data objects on a form communicate directly (when possible) without returning to the server in a true AJAX fashion, and you can easily create mashups such as the example that I saw with the external currency converter, a database table, and MSN Messenger. For the hardcore among us, you can also jump directly to the underlying scripting code.</geek>

Unfortunately, the AJAX framework is not available as a separate offering, only as part of the BPMS; I think that Cordys could easily spin this off as a pretty nice browser-based development environment, particularly for mashups.

The Incredible BPMN

Last year, I developed a course on process standards for FileNet (now IBM) that they use to train their sales teams and partners. It included a bit on BPMN, among other standards, because FileNet will soon be launching an ability to model in BPMN through an integration with Visio.

Frighteningly, their recent press release says “New features support BPM standards for business process modeling (BPMN) and execution (XPDL) and BPM integration as part of an overall Service Oriented Architecture (SOA) strategy” — do they think that the X in XPDL stands for eXecution?

This morning, I received an email from someone at a FileNet reseller who recently took the course that I developed online. He said “Thanks for your really great webcast” (I love feedback like that!), and also created a BPMN diagram using icons from The Incredible Machine:

The thought of combining the whimsical — yet design-like — diagrams of TIM with those of BPMN gave me a giggle and really made my day.

Free advice for BPM vendors

It’s not often that you get free advice from an analyst/consultant, but I gave this one away already today in a conversation with a vendor: don’t ignore BPDM. The fact that Lombardi has already announced support for it as the interchange format between Blueprint and TeamWorks (not a coincidence that Lombardi’s CTO sits on OMG standards committees) even though the standard is not yet released means that it’s likely to be presented to customers as a competitive differentiator by the BPM vendors who implement it very early on in the game. Assuming that it catches on, you’ll still need to support both BPDM and XPDL for a period of 2-5 years.

ProcessWorld Day 1: Briefing with Trevor Naidoo of IDS Scheer

I skipped the last breakout session of the day for a discussion with Trevor Naidoo, IDS Scheer’s Director of ARIS Solution Engineering. He’s responsible for the pre-sales technical activities, and used to be an ARIS customer, so is very familiar with how customers use the product and how they want to use it.

We spoke first about integration between ARIS and the BPMS products that automate processes, which included some discussion about standards. He pointed out that integration using pure standards tends to degrade to the least common denominator — a point that I’m not sure that I agree with for all standards, although it makes sense if you picked BPEL as your standard — which led them to take a different approach with their most tightly integrated partners, SAP and Oracle: that of “standards-based” integration, where they extend BPEL (I believe) in order to provide increased functionality. I’m not sure at what point a “standards-based” approach becomes “proprietary”, although I can see the value of going this way. In any case, they’re using different approaches for different vendors: “standards-based” for SAP and Oracle, BPEL for Lombardi, and XPDL for Fujitsu.

This really came around to the issue of how to get those process models into an execution engine, or if anyone is really doing it at all. Naidoo said that what was moving from ARIS to the execution engine was a “process outline”, which then required some amount of work to hook it up to the BPMS engine (as expected), and that the main value is not in the transfer itself — which could be readily recreated in the BPMS designer directly — but in engaging the business in the entire process design cycle. This, then, is what I suspected: that most people really are redrawing the process models in the BPMS designer, adding who knows how many translation errors along the way, because there is insufficient value to bother with the direct integration. This is not unique to ARIS; I saw the same thing at the Proforma user conference last year.

We moved on to talk about the technology. I hadn’t done my homework in this area, and was really unaware of ARIS’ support for browser-based design (yes, I’m on my usual rant about browser-based process modelling); they have a Java applet client for design in a browser environment, which is a pretty heavy footprint by today’s AJAX standards. I’d love to hear more about their plans to put that client on a diet, which will greatly facilitate design collaboration with occasional users, both inside and outside the corporate firewall.

We finished with a discussion of how to move the process modelling story from what is usually a departmental beginning within a company up to the executive level and therefore out across the entire organization: internal evangelism, if you will, to leverage that initial 10-person ARIS project into making ARIS an enterprise-wide process modelling tool. This is addressed to some degree by one of their new “solutions” (which appear to be specific packaging and bundling of products and services), the Enterprise BPM solution which (based on information from their website) includes the ARIS Business Architect, ARIS Business Optimizer, ARIS Business Simulator and ARIS Business Publisher as the basis for implementing a company-wide BPM infrastructure. I still think that there’s a fundamental disconnect in language between the players: the average business analyst or architect is likely too mired in detail to be able to present a high-level plan to the executives of their organization on why to super-size their ARIS installation, but I’m sure that the IDS Scheer sales team would be happy to help out. With Trevor’s able assistance, of course.

ProcessWorld Day 1: Keynote with Prof. Scheer

The opening keynote this morning was by Prof. August-Wilhelm Scheer, the founder and serious brain-trust behind IDS Scheer. You have to love this guy: not only is he brilliant and able to describe his ideas clearly, he opened and closed his session by playing sax in a jazz trio on stage.

He covered a lot of material in his talk, and I can’t begin to do it justice but will try to hit a few of the high points.

The goal of a modelling tool like ARIS is to support business processes from strategy to model to detailed description to implementation, including changes to any part of that chain and how the changes ripple through the other layers. The design-implementation-control life cycle of business processes, with a current strong focus on the optimization end of things, serves to bring together process modelling and execution like never before.

The business model at the top of any business process is the key competitive differentiator for an organization, requiring identification of the value proposition, supply chain, and target customer. This places the business model, and the surrounding business architecture, as part of an overall enterprise architecture. Looking at the business process architecture stack (think Zachman column 2), the business model leads to the business process, which requires/populates the business process repository. This, in turn, populates the IT-business process repository for the subset of the processes to be automated, through standardized modelling formats like BPMN and serialization formats like BPEL, which in turn connect to the enterprise service repository that documents the underlying services. Surrounding all this is the business process platform for service assembly/orchestration, portals, B2B, WFMS (wow, haven’t heard that term for a while: workflow management systems, for the youngsters in the crowd) and EAI.

IDS Scheer is involved with (or at least concerned with) a number of process-related standards, including ones such as BPMN and IDEF at the business process modelling level. I’m interested to see if they’re involved in the BPM Think Tank that OMG runs, such as the one coming up in July in San Francisco — an email exchange with someone from OMG a few minutes ago indicate that they’re not heavily involved in OMG standards. ARIS’ business model metamodel and their generally high level of innovation could almost certainly contribute to OMG standards development, if they’re not already.

One interesting point that Prof. Scheer finished with (well, before he started playing sax again) was that BPMS (i.e., process execution) vendor platforms will continue to be proprietary in spite of their “commitment” to standards (my quotation marks, since I agree with this thought), so products like ARIS are necessary in order to help facilitate the movement of models between execution systems. The business view needs to be open, while the implementation layer will remain proprietary.

BPMN-XPDL-BPEL value chain revisited

Right after I dissed the new for-pay incarnation of Business Integration Journal Business Transformation and Innovation, it turns out that I’m mentioned in an article in the November/December issue.

For the past 12 to 18 months, there has been growing interest and discussion surrounding BPMN, XPDL and BPEL. What has begun to take form is the recognition of the BPMN-XPDL-BPEL Value Chain, a concept first credited to analyst Sandy Kemsley by XPDL expert Keith Swenson.

I normally don’t read this publication cover to cover, but I was checking my email subscriptions folder and saw a message with the title “The BPMN-XPDL-BPEL Value Chain”. Having coined the phrase “BPMN-XPDL-BPEL value chain” in a blog post covering the BPM Think Tank last May, I tend to notice when it crops up elsewhere 🙂

The BIJ article, written by Nathaniel Palmer of WfMC, discusses the three process standards and their interrelationship, particularly around how XPDL and BPEL are complementary, not competitive. Nothing here that I haven’t written before, but it’s a good overview/summary article on the subject.

Of course, being from WfMC, which authors the XPDL standard, he doesn’t mention OMG’s BPDM, which could prove eventually to be XPDL’s nemesis.

BPMM tutorial

I’m in the online OMG tutorial on the Business Process Maturity Model (BPMM), which is a bit awkward because they’ve gone the really cheap route and done this with a conference call line with poor controls (everyone is in talk mode by default when they dial in, and a lot of people don’t realize that it’s good conference call etiquette to find the mute button on their phone so we heard a lot of background noise, beeps, coughing, breathing, etc.), and everyone needs to download the slides and follow along on their own. C’mon guys, GoToWebinar is pretty cheap, you could have sprung for that. 🙂

The BPMM acronym is problematic right from the beginning (aside from my gaffe last week when announcing the tutorial), when someone chimes in and says “but BPMN is in many shipping products now…”

Bill Curtis started with a history of maturity models; he and his partner have had a consulting practice around CMMI for a number of years, and obviously have a great deal of knowledge about maturity models in general. Apparently, one of their banking customers that had huge success with CMMI asked them for a business process maturity model a few years back, and so began BPMM.

Like CMMI, BPMM has five maturity models: initial, managed, standardized, predictable and optimizing (since the slides are marked as copyright of Capability Measurement, the consulting company that the two presenters run, I won’t reproduce the graphics here but you can download the full presentation here). At the initial level of process maturity, organizations tend to be undisciplined, individualistic and inconsistent, which makes them inefficient and stagnant. Funny, this put me in mind of Jon Pyke’s article yesterday where he spoke about how workflow systems “suck” because they don’t allow people to do their own thing in order to get things done; Pyke seems to be dissing workflow systems because they enforce repeatable processes.

Levels 2 and 3 of BPMM show the benefits of putting some business process maturity in place: managed, repeatable processes, integrated across the organization and adaptable to different circumstances. Roughly speaking, Level 2 involves putting some process automation and management in place for localized process improvement, and Level 3 involves organizational-level process improvement and reengineering by standardizing processes across the organization. My feeling, and that of the speakers, is that most organizations are at Level 1 in their process maturity, with some approaching Level 2 where organizations have implemented some process improvement initiatives, particularly those including a BPMS implementation.

Level 4 is taking a more statistical look at processes, reminiscent of Six Sigma: making processes less variable and more predictable, and gets into more performance management. BPMM is a roadmap, whereas Six Sigma is a set of tools that can be applied — probably starting around Level 3 or 4 — therefore can work together.

Level 5 is taking it to a proactive level, where an organization can recognize the difference between where they are and where they should be, and quickly take steps to achieve that. This is the level of continuous process improvement, where change management becomes just another standardized business process, focused on defect reduction and prevention.

There was a slide at the end about cultural transformation that I particularly liked: moving between Levels 1, 2 and 3 is about discipline, while moving to Levels 4 and 5 is about trust.

Although I can’t find the BPMM documents on the OMG site (which has the annoying habit of restricting access to standards in development), there is a BPMM information day in Washington DC next week where you can get more information.

On a related note, yesterday I attended the inaugural meeting of the Toronto BPMG chapter (more on that later), where Jim Baird talked about BPMG’s business process maturity model. Although I’m not familiar with it, I have to wonder if there’s room in the market for two business process maturity models.