Last in the morning's general session was Tom Laffey, TIBCO's EVP of products and technologies, and Matt Quinn, VP of product management and strategy. Like Ranadivé's talk earlier, they're talking about enterprise virtualization: positioning messaging, for example, as virtualizing the network layer, and BPM as enterprise process virtualization. I'm not completely clear if virtualization is just the current analyst-created buzzword in this context.

Laffey and Quinn tag-teamed quite a bit during the talk, so I won't attribute specific comments to either. TIBCO products cover a much broader spectrum that I do, so I'll focus just on the comments about BPM and SOA.

TIBCO's been doing messaging and ESB for a long time, and some amount of the SOA talk is about incremental feature improvements such as easier use of adapters. Apparently, Quinn made a prediction some months ago that SOA would grow so fast that it would swallow up BPM, so that BPM would just be a subset of SOA. Now, he believes (and most of us from the BPM side agree :) ) that BPM and SOA are separate but extremely synergistic practices/technologies, and both need to developed to a position of strength. To quote Ismael Ghalimi, BPM is SOA’s killer application, and SOA is BPM’s enabling infrastructure, a phrase that I've included in my presentation later today; like Ismael, I see BPM as a key consumer of what's produced via SOA, but they're not the same thing.

They touched on the new release of Business Studio, with its support for BPMN, XPDL and BPEL as well as UML for some types of data modelling. There's some new intelligent workforce management features, and some advanced user interface creation functionality using intelligent forms, which I think ties in with their General Interface AJAX toolkit.

Laffey just defined "mashup" as a browser-based event bus, which is an interesting viewpoint, and likely one that resonates better with this audience than the trendier descriptions.

They discussed other functionality, including business rules management, dynamic virtual information spaces (the ability to tap into a real-time event message stream and extract just what you want), and the analytics that will be added with the acquisition of Spotfire. By the way, we now appear to be calling analytics "business insight", which lets us keep the old BI acronym without the stigma of the business intelligence latency legacy. :)

They finished up with a 2-year roadmap of product releases, which I won't reproduce here because I'd hate to have to embarrass them later, and some discussion of changes to their engineering and product development processes.

Posted by Sandy Kemsley at 01:28 PM in BI • BPEL • BPM • BPMN • BRE • SOA • TUCON | Permalink | Comments (2) | TrackBacks (0) | Add to del.icio.us

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.

Posted by Sandy Kemsley at 12:58 PM in BPEL • BPM standards | Permalink | Comments (9) | TrackBacks (0) | Add to del.icio.us

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.

Posted by Sandy Kemsley at 11:21 AM in BPEL • BPM standards | Permalink | TrackBacks (0) | Add to del.icio.us

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.

Posted by Sandy Kemsley at 11:07 AM in BPEL | Permalink | TrackBacks (2) | Add to del.icio.us

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.

Posted by Sandy Kemsley at 12:21 PM in ARISProcessWorld2007 • BPA • BPEL • BPM • BPM standards • BPMN | Permalink | Comments (2) | TrackBacks (1) | Add to del.icio.us

Although labelled "The business value of BPM", this is really a webinar on BPM standards as a wrap-up of the recent OMG BPM Think Tank, which I blogged extensively about.

Since I was at the Think Tank and have a lot of opinions on the subject of BPM standards, I'll be presenting at this webinar (as opposed to my previous role as moderator) along with Connie Moore from Forrester and Jeanne Baker from OMG and Sterling Commerce. Connie will be covering the business value of standards, Jeanne will be doing a wrapup of the Think Tank, and I'll be doing an interactive discussion between the three of us on the future of BPM standards.

Being a presenter on this webinar prompted me to finally update my bio on the ebizQ site; a few people who I've met lately assume that I work for ebizQ, which I don't, so this should clear it up.

The webinar is on August 9th at noon Eastern, and you can sign up here.

Posted by Sandy Kemsley at 05:18 PM in BPEL • BPM standards • BPMN • BPMThinkTank | Permalink | TrackBacks (0) | Add to del.icio.us

I'm tuned into an ebizQ webinar on SOA standards, News Break: The First Standards-Based SOA Forum to Manage and Govern Your SOA. This link should be good for replay within a couple of hours after the webinar, or within a couple of days if you want the full version with the live Q&A. By the way, whatever happened to the link that would add the webinar directly to my Outlook calendar? I miss that! I'm simultaneously blogging (obviously), packing for my trip to Mashup Camp and listening to the fire alarms being tested in my building, so this may not be as detailed as usual.

The presenters are Keith Swenson of Fujitsu (who I've met a couple of times), Daryl Plummer of Gartner (who I heard speak at their BPM Summit earlier this year), Paul Butterworth of AmberPoint, Peter Kuerpick of Software AG and Jean Francois Abramatic of ILOG. The blurb for the webinar promised:

[A]n exciting multi-vendor announcement on how the leading SOA vendors are partnering to achieve a common SOA infrastructure. This initiative will leverage an open, standards based SOA registry and repository to manage and govern the complete SOA landscape. It will allow you to analyze interdependencies in your SOA including services, processes, applications and other SOA components.

In other words, now that most vendors have figured out that most customers are not going to be using a single-vendor SOA infrastructure, they're getting together to build some standards in the area of registry and repository.

Plummer started with a message about the importance of SOA governance, and the recent focus on this by many organizations. He stepped through Gartner's models of an SOA framework and service registry, and touched on policy management and a few other governance-related issues. He laid a lot of the groundwork for the rest of the webinar, since SOA governance is a key driver for standards.

Up next were Kuerpick and Swenson, the two webinar sponsors, to talk about the CentraSite Community, with is both a standards-based SOA forum and a product that provides an open registry and repository, impact analysis tools, and governance tools that store, tracks and analyze processes and their underlying services and interdependencies. They launched a canned demo of CentraSite that is also available on the site, which happens at just below light-speed, so I'll need another viewing to catch all the details, but it appears to be all browser-based and has some interesting functionality especially around interdependencies of services. CentraSite is already supported by several vendors, and any standards-based vendor should be able to publish directly to it but would need to get a bit more involved to be a full player. It will be interesting to see how this catches on over the coming months, and if it manages to sort out some of the SOA confusion.

One really interesting point is that both XPDL and BPEL are mentioned explicitly, and BPMN was also mentioned although it's not on the slides and isn't used in representing business processes within CentraSite as far as I could see in the demo. CentraSite is not a standards organizations, and much of the underlying standards work will be done by the existing standards bodies such as OASIS.

There is a community edition that is free of charge, and you can register to download a product evaluation.

More to come on this in the future, I'm sure.

Posted by Sandy Kemsley at 12:58 PM in BPEL • BPMN • SOA | Permalink | TrackBacks (0) | Add to del.icio.us

The Spring OMG newsletter is available online (direct link to PDF) with a 2-page article "OMG and Service-Oriented Architecture":

In essence, SOA is an architectural approach that seeks to align business processes with service protocols and the underlying software components and legacy applications that implement them.

So far, so good. Then they go on to say:

Both processes and services need to be carefully coordinated to assure an effective SOA implementation. You can’t really do SOA without a clear model of the business process to be supported.

Not sure that I fully agree with that: you have to have a clear model of your business process before you can implement SOA? Aren't the underlying services supposed to be reusable even if the business process changes? Isn't that really the whole point of SOA?

And you can’t link your business processes to your service models without the modeling standards the OMG is developing as part of its Model Driven Architecture® (MDA®).

Oh, I get it now.

They do include a nice diagram showing where the OMG standards fit in one representation of an SOA environment (see the newsletter for the full-size version). You can see where BPMN, BPDM and BPEL fit in, which I talked about in my posts from the BPM Think Tank last week, plus other standards such as SBVR (Semantics of Business Vocabulary and Rules) for business rules.

I also like that they're platform-independent about this, and that they don't equate SOA with WS-*.

You can check out the newly-formed OMG SIG on SOA if you want to get involved in discussing this MDA approach to SOA.

Posted by Sandy Kemsley at 10:44 PM in BPEL • BPMN • BPMThinkTank • SOA | Permalink | Comments (2) | TrackBacks (0) | Add to del.icio.us

Since I only finished posting about yesterday's sessions at the end of this morning, I decided to just do a final conference wrapup instead of separate wrapups for yesterday and today.

In general, the BPM Think Tank was great, and I'll definitely attend again in the future. I learned a lot about some of the standards that I didn't know much about before (like BPDM), and met some really smart people with lots of opinions on the topic of standards. It's been so long since I was involved in any sort of standards work (AIIM in the early 90's, and topographic data interchange formats for the Canadian Council of Surveying and Mapping back in the late 80's), and I had forgotten about both the frustrations of dealing with standards committees and the excitement of being able to contribute to a little bit of computing history that will make things work better for a lot of people.

I'm still mulling over the XPDL/BPDM conundrum (and, to a lesser extent, BPEL), but the fact that different standards bodies are all here participating is a good indicator that there is the collective will to head off problems like this. At last year’s Think Tank, discussions between BPMI and OMG around the competing graphical process models of BPMN and UML activity diagrams helped lead to the absorption of BPMI into OMG, and the championing of a single standard, BPMN, being put forward by the merged organization. We can only hope that something similar will happen with XPDL and BPDM in order to avoid future problems in the BPMN serialization domain.

I had the chance to meet several people who I had connected with online but never met face-to-face: Dana Morris of OMG, Bruce Silver, John Evdemon (who I'll be having ongoing discussions with about BPM and Web 2.0) and others. Jeanne Baker, who did such a great job at keeping things moving along during the sessions, even remembered one of my posts from last year about a webinar that she gave on standards -- she turned to me at lunch yesterday and asked "Did you write that blog post called 'Alphabet soup for lunch'?" -- proof that people will remember if you mention them in print. I missed other people completely in the crowd (Phil, where were you?).

There were a few logistical problems (conference rooms way too cold, no free wifi, not enough herbal tea, and no free t-shirts with vendor logos, about which I heard a lot of whining when I got home), but these were only minor annoyances in an otherwise well-executed conference with excellent content.

Posted by Sandy Kemsley at 10:33 PM in BPEL • BPM standards • BPMN • BPMThinkTank | Permalink | Comments (3) | TrackBacks (1) | Add to del.icio.us

This afternoon, I attended technology roundtable on XPDL led by Keith Swenson.

Keith went around the table and asked how we (or our customers) are modelling processes now. The biggest faction by far use Visio, but PowerPoint (!), UML activity diagrams (using the IBM/Rational tools) and proprietary/internal tools specific to an industry were also mentioned. For the most part, people are concerned with sharing processes between tools, not between organizations, since most organizations are very protective of their processes. A major issue with most of these tools is round-tripping and process lifecycle issues, since in many cases it's a one-way trip from the modelling tool to the execution engine. We talked about Byzio, the Zynium add-on to Visio that allows BPMN to be modelled in Visio, and a mapping from either a BPMN template or any other Visio set of shapes to XPDL. I reviewed Byzio several weeks back, and Keith is quite familiar with the product too.

We discussed how XPDL could be used to aggregate process models from disparate BPMS' that might be in use within the same organzization.

In discussing BPEL, Keith felt that XPDL provides all of the support for everything that BPEL can do with respect to the interface to web services; this further pushes the issue that BPEL is not really required if it's not being used as an execution language and if there is a transformation from XPDL to the specific engine's execution environment (which implies that the BPMS vendor's design tool can import the XPDL file).

XPDL provides support for extensions modelled in a BPMS vendor's design tool that are specific to that engine; these are preserved in XPDL and should not be affected if the XPDL is manipulated by another process design tool. This is critical for supporting round-tripping from a design tool to the BPMS vendor's engine (via their design tool) and back again, since the design tools should preserve the extensions even if they don't interpret it. An example of such an extension is assigning colour to swimlanes (which Fujitsu allows in its design tool): the file can be read into a tool that doesn't interpret the colour information, but when it is saved and read back into the design environment that does support colour, the colour's there. Vendor extensions such as this may be brought forward at XPDL TC meetings for inclusion in future versions of the standard.

The most recent set of major changes to XPDL were BPMN-related enhancements including X-Y coordinates of lines, topology, etc.; however, they forgot to include scale, since some measures are in real-world units (inches/cm) and some are in pixels. This caused further discussion on the separation of presentation and logic data, since both are included and intermingled in XPDL when it’s used to serialize BPMN, and if logic and presentation be versioned separately, since some purely cosmetic changes can be made to presentation without affecting logic. Other presentation-related information includes a "page" indicator, since a process may span multiple pages when visualized.

We had a lengthy discussion on additional versioning information that could be included in XPDL, and how this ties in with SOA governance initiatives for maintaining the integrity of interfaces and functionality.

I repeated what I said in an earlier post about blaming the large analysts for forcing (sometimes inappropriate) standards by creating RFP checklists that are used (somewhat blindly) by customers -- Keith agreed with this view.

We ended up with a bunch of ideas that deserve more thought: Should Java be extended to subsume BPEL functionality? XPDL is graph oriented, and BPEL is block structured; BPEL4people implies that you can extend a block-structured language to represent human-facing process flows which are inherently graph-oriented. Should BPDM be the metamodel behind XPDL? (This is not a viewpoint endorsed by OMG since XPDL uses some notation not recommended by OMG, and BPDM has a broader scope that inclues BPMN serialization.) If XPDL were made MOF-compliant, could it replace the need for BPDM?

Posted by Sandy Kemsley at 10:21 PM in BPEL • BPM standards • BPMN • BPMThinkTank | Permalink | TrackBacks (1) | Add to del.icio.us

I finished yesterday afternoon by attending a technology roundable on BPEL led by John Evdemon. There was a lot of ground covered there that I had heard in his workshop on Day 1 and the panel earlier yesterday that I won't repeat here, so just a few brief notes.

There are some things that can be described in BPEL that can't be modelled in BPMN, which I didn't realize. The example that Evdemon gave was an online order for a book, then a follow-on process kicked off the next day when the customer cancels the order. Although both of the processes can be modelled in BPMN, I think that his point is that the interaction between the processes can't be modelled there. There are apparently a few use cases like this that are being considered for inclusion in BPMN (if I understood correctly), but I didn't hear anything about this in the earlier BPMN roundtable. Stephen White's mappings of BPMN (available on the old BPMI.org site, so I imagine all still available on OMG's site) has many peole thinking that BPMN models a superset of BPEL, which is not strictly true.

Like the BPMN roundtable and some hallway discussions, there were a lot of comments about the linkage between process standards and enterprise architecture.

The issues that we discussed, and the notes that I made from the discussion:

• BPEL doesn't provide all the functionality that can be modelled in BPMN.
• If BPEL isn't used as an execution language, but just as an import/export language as is done by Microsoft, IBM and others, what value does it add over XPDL (or eventually, BPDM)?
• Are we eventually going to end up with just BPMN, BPDM (or XPDL, if you believe Bruce), and a vendor-specific execution language in the process chain?

I have some additional research to do, some of which will start in this afternoon's roundtables on XPDL and BPDM, about whether BPEL does add value over these standards by providing more specific web services information such as endpoints or ports. You can definitely use BPEL as an import/export and exchange format, or to store the representation of a process for future rehydration, but it appears that you could also use XPDL or eventually BPDM to do the same thing and provide a richer interpretation of models created using BPMN.

At the end of the day, when we all reconvened as a group, Evdemon gave a summary of what we discussed:

• What is the value of BPEL if XPDL is a direct serialization of BPMN? BPEL had a lot of press because of who's backing it, not necessarily because of its capabilities. (A direct quote from him during the roundtable itself on this subject: "Unless you're going cross-platform, you may not need BPEL.")
• Use BPEL to store current processes to be rehydrated later if needed for audit or other legal and compliance requirements. BPEL is also being used by other standards such as RosettaNet to provide process-related templates for those standards.
• Process formats may just become different serialization formats with different capabilities, accessible from many tools just like all the document formats that are available if you select File...Save As within Word.

Posted by Sandy Kemsley at 10:44 AM in BPEL • BPM standards • BPMN • BPMThinkTank | Permalink | TrackBacks (0) | Add to del.icio.us

We finished Wednesday morning with a panel on the business value of process standards, moderated by Connie Moore of Forrester, with panelists Richard Soley of OMG, Keith Swenson of Fujitsu and John Evdemon of Microsoft representing the BPMN-XPDL-BPEL value chain.

I'm now on the search for the Holy Grail of BPM standards: what's going to survive the coming shake-out, and how exactly do XPDL, BPDM and BPEL overlap, compete and complement each other? Swenson started his intro with a statement about BPDM and XPDL: basically, there's some great work happening on BPDM, but XPDL is here now and can be used in the interim. Was this an admission that XPDL is going to go away and be replaced by BPDM? I had a side conversation with Fred Cummins (who gave the BPDM workshop yesterday) before the panel, and he sees BPDM as providing a superset of functionality such that transforming to XPDL or BPEL doesn't add any value unless the particular BPM execution engine requires the transformation. BPMN has clearly won the graphical representation skirmish; can BPDM take the rest of the field? [Note to Phil Gilbert, who dissed me yesterday for asking why use BPDM if you have XPDL: this is live blogging so pretty much stream of consciousness, I'm just blogging what I hear and think during the session and haven't had time to formulate any real opinions or analysis of all this. So back off, buddy. :-) ]

Evdemon said that in his personal opinion, BPEL has a 3-out-of-5 importance rating for most organizations, mostly for checking off boxes on an RFP (in his position on the TC of the OASIS BPEL group, he said that it's a 5/5, which makes me wonder why OASIS would choose to use him as a public speaker on the standard when his corporate affiliation and personal opinions aren't really in line with the goals of the standards committee). He feels that BPEL got a lot of press unfairly, and that when he found out yesterday that XPDL can save a complete representation of all BPMN objects, he seemed to think that BPEL could become even less important and possibly even subsumed -- recall from my post yesterday on his workshop that he sees BPEL as more useful as an abstract (modelling or exchange) language rather than an execution language.

Swenson came back to the issue of XPDL versus BPEL, which he doesn't see as competing. XPDL is about process design, about serializing and saving what you drew in BPMN, and not so much about execution. He sees XPDL as a way of moving a process from one design/simulation/analysis tool to another (about 30 tools support it today), whereas BPEL is about the nuts and bolts of sending messages from one location/service/system to another. As Evdemon said, XPDL is like XMI for business processes. Swenson states that XPDL will continue to track and adjust to any changes to BPMN.

Interesting that the BPEL proponent thinks that BPEL is less important in the face of XPDL's current functionality, whereas the XPDL proponent thinks that BPEL and XPDL should coexist.

Even more interesting is that the panel did not directly address the issue of the business value of standards, only the standards themselves. It would have been good to hear a bit more about how to promote the idea of BPM standards within an organization, although given the current somewhat confusing state of overlapping standards, it's hard to know exactly what to recommend.

A last question was posed about BPDM that Soley addressed, namely, what is it and how does it compete/overlap with the others that we're talking about here. He claims that it's not intended to compete with any of these other standards, although that's still not clear to me.

A really valuable and lively session, I just wish that I had recorded it since the opinions and comments were flying by and I'm sure that I've missed some key points. Hopefully, I'll be able to explore these further in the roundtables this afternoon and tomorrow.

Posted by Sandy Kemsley at 12:33 PM in BPEL • BPM standards • BPMN • BPMThinkTank | Permalink | Comments (3) | TrackBacks (3) | Add to del.icio.us

I'm now in the final session of the day, with John Evdemon talking about BPEL. He's dealing with a number of interesting points, such as name (WS-BPEL versus BPEL versus BPEL4WS), pronunciation (he doesn't care, as long as you use it), the lack of graphical notation, and orchestration versus choreography. I particularly like his description of orchestration versus choreography, which is crystal clear: orchestration has the concept of a controlling party, even if other external organizations are involved in a process, and is concerned with the process from the viewpoint of that party includes its internal activities; choreography is at a higher level and looks at a process as message-passing between peers, without delving into the processes internal to any of the participants. BPEL is an orchestration language, and you can think of choreographing between the BPELs at each organization (sort of).

The motivation behind BPEL was application integration both within and between organizations -- EAI and B2B -- where everything is described as a service. It covers both non-programmers implementing flows by assembling components with flow logic, and programmers implementing the granular services using function logic that will make up those processes. There's also the idea of being able to model both executable processes and abstract processes using BPEL, although most of the excitement around BPEL has been due to the platform-independent nature of it as an execution language, that is, the logic for how messages actually get processed. Abstract BPEL, on the other hand, can be used to describe an organization's services at a deeper level than can be done via WSDL, without concern for execution.

Evdemon showed a diagram of how BPEL fits together with the rest of the WS-* stack, and shows how business process models and choreography models need to still be layered on top of BPEL to provide full capabilities.

Something that I didn't really think about before, but which came up in response to the questions "where does BPEL live?" is that Microsoft doesn't run BPEL directly, but translates it into BizTalk (unlike a product like Oracle BPEL Process Manager, which executes BPEL directly).

BPEL 2.0 is scheduled to go out for public review next month. New since v1.1:

• New activity types (if-then-else, repeatUntil, validate, forEach, extensionActivity)
• Completion condition in forEach activity
• Variable initialization
• XSLT for variable transformations (new XPath extension function)
• XPath access to variable data (XPath variable syntax)
• XML schema variables in web service activities (usability enhancements for WS-I compliant doc/lit-style WS interactions)
• Locally declared messageExchange
• Abstract processes (common base/syntax and profiles/semantics)

Evdemon's recommendation and predictions about BPEL shocked me: it's still under development, so don't use it yet in production and the portability of executable BPEL will be low to non-existent. He sees that many organizations implementing BPEL are using it like a programming language, which he implies is an inappropriate usage since it's missing some core capabilities, but that it's more of an orchestration modelling language. If that's the case, and the vendors are going to just translate it into their own proprietary execution language, then there seems to be little advantage to adopting BPEL over something like XPDL that can capture everything that BPMN can model, except possibly for better WS handling.

Posted by Sandy Kemsley at 05:41 PM in BPEL • BPM standards • BPMN • BPMThinkTank | Permalink | TrackBacks (2) | Add to del.icio.us

I'm in Fred Cummins' BPDM workshop, where his stated goal is to provide a general understanding of BPDM, engage us in a discussion of the requirements, and discuss the implications of BPDM to enterprise agility. Fred's an EDS fellow who writes occasionally on the EDS Next Big Thing blog.

BPMN and BPDM are both standards that are designed for use by business people, with the inclusion of non-automated as well as automated business processes, and they are both business models as opposed to execution models (like BPEL, WS-CDL or proprietary vendor execution models). BPMN is a standard for the graphical representation of a business process, whereas BPDM is the XML file format in which such a representation can be stored: hence, a tool might display a business process as BPMN and save it as BPDM (which makes BPDM competitive with XPDL from WfMC, which I previously discussed as a file format for BPMN, although Cummins later stated that the scope and goals of BPDM exceed those of XPDL).

We had a lengthy discussion about the relationship between choreography (a collaboration between multiple participants) and a business process/orchestration (how one of the participants manages their view of the interaction): the roles typically map directly between processes and choreography, whereas only the steps in a process that involve interaction with another one of the participants will appear in the choreography. BPDM is intended to capture both orchestration and choreography information, although there was some discussion about whether BPMN has all the graphical representation for everything needed for choreography. It does include the concept of pools (like swimlanes, but representing different organizations, not different functions within an organization) and can collapse a pool so that it is effectively a black box, so I think that it has most or all of what's required for representing inter-organization choreography. An organization only needs to map the other parties in a choreography as a black box (i.e., a collapsed pool), whereas it will map it's own internal activities fully within swimlanes in its own pool.

Cummins then moved on to the hot topic of BPM and SOA, with the following definitions/relations:

• BPM: Business processes are the orderly execution of activities that achieve defined objectives.
• SOA: Services offer capabilities that can be used in a variety of contexts.
• Business processes may use services to achieve their objectives.
• Services implemented with explicit business processes can be more quickly adapted to business changes.

Personally, I find that list a bit circular, and I think that his "definition" of SOA is actually a definition of services -- maybe a bit of a fine point. He made a vague point about how processes and services provide different levels of granularity of agility, then came back to make two statements about agility:

• Primary impact of business changes is on the business processes and organizational structure.
• The actual work (concrete services) and data of the business tend to stay the same.

There's a lengthy discussion going on now about the difference between defining a meta-process and defining a paradigm, which is getting just a bit too esoteric for my taste (the accusation "you're being too rigorous!" was just flung around the room), but does remind me that OMG is a standards organization and this is exactly why I prefer implementation to theory, in general... (several minutes elapse)

Cummins finished up with some things that are being considered for BPDM but are still unresolved, such as the integration of business rules (and presumably a BRE) into a business process model, and the integration with strategic planning that's necessary to make business process modelling a fully participating activity in enterprise architecture.

At the end of it all, this workshop had a lot less to do with BPDM than I wished that it had, and a lot more about some particular views on SOA and business agility that didn't really have anything to do with BPDM. I understand that BPDM is still a work in progress, but it would have been nice if the artists had unveiled the canvas for us to take a preliminary peek.

Jeanne Baker, who sat in on the session, pointed out that this think tank is for all standards groups, and that last year's think tank resulted in the merging of BPMI into OMG due to the overlapping scope of BPMN and UML activity diagrams. Maybe the next move is to bring together XPDL and BPDM instead of indulging in an unwanted standards war for business process metamodels.

Posted by Sandy Kemsley at 03:30 PM in BPEL • BPM • BPM standards • BPMN • BPMThinkTank • BRE • SOA | Permalink | Comments (2) | TrackBacks (1) | Add to del.icio.us

I'm in the BPM Think Tank pre-conference workshop on ebXML BPSS (Business Process Specification Schema), relabelled no less cryptically as ebBP (eBusiness Business Process, with the "specification schema" implied), presented by Sally St. Amand of the OASIS ebBP Technical Committee. St. Amand is obviously very knowledgable on the subject matter, but is a less-than-engaging speaker -- call it the bureaucratic style of presentation, full of long pauses and paper shuffling.

According to the TC's site:

The ebBP is a technical business process specification. It defines a standard language so that business systems can be configured to support the execution of business collaborations between partners or collaborating parties rather than the processing accomplished from the perspective of one business partner. The formal designation has been eBusiness eXtensible Markup Language (ebXML) Business Process Specification Schema (BPSS). It is more commonly known as ebBP (after the OASIS ebXML Business Process Technical Committee).

In other words, ebBP is an execution language for business collaboration between peers, like most eBusiness (and EDI) specifications before it, although it also allows for non-first-class participants (such as others in the supply chain) who may wish to observe the state of the process at certain points. In its basic format, it's very similar to other XML-based eBusiness specifications that I've seen, usually from vendors; these vendor-provided specifications will hopefully migrate towards the ebBP standard as V2.0.X is adopted. The benefit of including observer participants became really obvious in a diagram of an eBusiness exchange that includes an observer: the message flow can include messages to the observer at any time, rather than just between the two main participants, although only the first-class participants can initiate the signals.

ebBP specifies the XML format, but does not include any graphical representation or modelling. There is an open source ebBP editor, which I've downloaded but haven't tried out yet.

Working this into the general standards landscapte, ebBP is a choreography language for collaboration between different organizations, whereas BPEL is an orchestration language for processes that are controlled by one organization (although may execute across organizations).

Posted by Sandy Kemsley at 10:39 AM in BPEL • BPM standards • BPMThinkTank | Permalink | TrackBacks (1) | Add to del.icio.us

Phil Gilbert's post last week exposes the Emperor's clothes for what they are: BPEL is just another implementation language:

It's simply a new way to write code. It has nothing to do with the management of business processes. I don't love it or hate it; other than that it is a distraction. BPEL isn't necessary to achieve the benefits promised by business process management - and therefore it's an impediment in the market conversations that are occurring with respect to business process management.

Yes, BPEL can make writing code to implement BPM easier, but don't confuse that with anything to do with managing business, or with anything that allows the control of business processes to be moved into the hands of the business.

Posted by Sandy Kemsley at 10:51 AM in BPEL • BPM standards | Permalink | Comments (3) | TrackBacks (0) | Add to del.icio.us

I've just registered for the OMG's BPM Think Tank in Washington DC on May 23-25. The program is mostly about standards, which is a big focus for me right now. It will be a chance to see some people who I've met before, such as Phil Gilbert and Derek Miers, and meet a few others for the first time face-to-face, such as Bruce Silver, Keith Swenson (who I heard speak at the Gartner BPM Summit) and John Evdemon (who was referred to me by Harry Pierson when I met him at Mashup Camp).

If you're going, look me up. If you haven't signed up yet, discount registration fees for the BPM Think Tank are still available until May 1st.

OMG gets full marks for including bloggers when they're handing out press passes; my thanks to Dana Morris and Stephanie Covert for their forward-thinking press relations policies. I'll be blogging more about the event before, during and after.

Posted by Sandy Kemsley at 05:03 PM in BPEL • BPM standards • BPMN • BPMThinkTank • Blogging • GartnerBPM2006 | Permalink | TrackBacks (2) | Add to del.icio.us

A good article in DMReview (where normally I find much more about data warehousing and business intelligence than integration) on Fear, Uncertainty and Doubt about integration, especially for small-to-medium sized businesses that don't have IT budgets that look like the GDP of a small Pacific nation. I just love it when someone cuts through all the crap:

Integration is moving data elements from point A to point B with the necessary translation in between...Tier-one integration vendors have conditioned the market to believe that integration should cost millions of dollars and take years to implement. With today's offerings, this is simply no longer the case.

Couldn't have said it better myself.

Posted by Sandy Kemsley at 06:41 PM in BPEL • BPM • SOA | Permalink | TrackBacks (0) | Add to del.icio.us