sandy

BPM Think Tank Day 1: BPEL

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.

BPM Think Tank Day 1: BPDM

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.

I posit that business processes can change in response to changing business because they’ve been implemented using BPM tools that enable this agility, and services tend to stay the same because they haven’t been architected to allow for change. Possibly Cummins’ views are a reflection more of EDS’ client base and their own practices than what’s really possible in terms of agility. Of course, there’s also the view that published services need to stay the same (or at least their external interface) since the publisher may be unaware of all the uses of the service and doesn’t want to risk breaking it, but that doesn’t mean that a service shouldn’t undergo internal optimization or an extension of its functionality as long as it can be easily changed to adapt to changing business requirements.

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.

BPM Think Tank Day 1: ebBP (aka BPSS)

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).

At BPM Think Tank

Yesterday was a holiday in Canada, and on this long weekend we headed for the cottage as many Canadians do. After a weekend of dealing with a tractor that wouldn’t start, a clogged septic tank and a phone line that wouldn’t work amid projects such as putting in the docks and launching the boat, it was almost a relief to get up at a ridiculous hour this morning and get on a plane for Washington.

Here in Washington (Arlington, actually), I’m about to head off to the BPM Think Tank — watch for posts under the BPMThinkTank category over the next three days while I’m here. I’m also trying to finish up the Short History of BPM series, since JC is fast translating the previous ones into French.

If you’re at the think tank, look me up or drop an email/comment to setup a meeting.

Column 2 translated: Colonne Deux anyone?

Jean-Christophe Dichant is with the FileNet Paris office, where I had some memorable moments during my brief tenure with FileNet in the early 00’s, and he blogs in French about BPM, which I’ve mentioned previously.

I invited JC to translate my “Short History of BPM” into French — with his own commentary — and publish it on his blog, and he has the first two parts up here and here. When you’re mostly unilingual, like me (my French is so bad that I can’t possibly refer to myself as fluent), there’s something weird about seeing your own writing translated into a language that you know slightly, but it’s pretty cool at the same time.

mesh conference, Day 1

Sort of a non-BPM few days lately, what with BarCampTdot on the weekend and the mesh conference today and tomorrow.

mesh kicked off this morning with an interview with Om Malik. During the Q&A, an audience member referenced a quote that he heard many years ago: “When information is free, the only thing of value is point of view”. Om countered that the thing of value is context, not necessarily point of view. I can certainly identify with this, since (I assume) the reason that a lot of you read this blog is for the context in which I place information, and my viewpoints on the content, rather than just the content itself.

The next session was a presentation by, then interview with, Michael Geist, a U of Ottawa law professor and a brilliant speaker on web 2.0 and society, and on digital rights issues. Definintely my favourite part of the day so far (although the bar hasn’t opened yet).

Today has an unduly heavy focus on media — for some reason, all the media and society sessions are today, and all the marketing and business sessions tomorrow — although there’s some interesting ones such as the one on “Are Bloggers Journalists?” that I’m in right now.

I am left with the uncomfortable question of where all the money from this conference is going, considering that the organizers are not professional organizers and presumably weren’t in this to make money from it; they all have “regular jobs” of sorts. It cost $350 to attend for the two days (not worth the price, in my estimate, and not very web 2.0 in spirit), and with the large number of big-name sponsors, it’s not clear that they needed to charge attendees that much to provide what they are providing. I know that Gartner conferences and the like are far more expensive, but they’re in the business to make money on conferences, and this is more of a low-key participatory conference (not an unconference, but borrowing a few of the networking concepts).

I have to give mesh the credit, however, for indirectly inspiring BlogHerNorth: back in April, Elisa Camahort (of BlogHer) pondered why mesh couldn’t find more than 6 women to speak when there were 50 speaking slots available (subtitled “Another example of why BlogHer won’t be passe in my lifetime”). Kate Trgovac picked up the ball and asked if it was time for BlogHerNorth, I added some comments and started a conversation with her and a few others, and the ball was rolling. So, thanks to some men who excluded (however unconsciously) women from their conference speaking roster, we’re inspired to create BlogHerNorth.

BlogHerNorth at BarCampTdot

On the weekend, I attended BarCampTdot (aka BarCampToronto aka TorCamp), where we semi-officially launched BlorHerNorth. We held a session to talk about the vision for BlogHerNorth and to gather ideas on what participants might want to see; lots of ideas, no decisions. We won’t be running a full-scale conference this year, possibly in the spring, but some meetups or smaller sessions likely during the rest of this year to get the ball rolling.

Although the presenters will all be women since one of the main purposes is to highlight women in technology and blogging, the attendance is not restricted and we’re happy to hear input from anyone on what you’d like to see at a BlogHerNorth session.

Posts of links

I used to ignore blog posts that just contained lists of links, until recently when it finally hit me that if I value that person’s opinions when they write a regular blog post, why wouldn’t I value their opinion about what links that they find valuable? Of course, a list of links is really only valuable if the person adds their opinion for each link, which is exactly what del.icio.us allows you to do.

Thanks to Stephen O’Grady’s post about an experimental feature on del.icio.us, my new links (with my notes about them) will be posted once each day, as you see in the post immediately before this one. I like this much better than the Link Splicer functionality on FeedBurner, since everyone reading the blog can see it (not just those subscribing to my FeedBurner feed), and it’s a regular post so that you can add comments to it if you wish. You can also see what tags that I’ve used for each of the links, and click through to my collection of links with the same tags.

I’ll use this method instead of the “link only” type of posts that I have used to refer to another site with very little of my own commentary. There will likely be lots of links in the next couple of days while I sort out all of the things that I’ve tagged in Bloglines and turn them into del.icio.us links.

A Short History of BPM, Part 6

Continued from Part 5.

Part 6: The Tower of Babel I’m going to skip forward a few chapters in Genesis to describe the utter confusion that happened next when the combined space was relabelled, primarly by the big analysts, as business process management. Now, instead of being confused by what’s a workflow product and what’s an EAI product, customers were confused by which product serves which part of this still-fragmented market. To make the confusion even worse, the same analysts who lumped all of this together as BPM created divisions within the BPM space based on functionality. For example, here’s my previous diagram overlaid with Gartner’s BPM taxonomy from 2003:

They called it all “BPM suites”, but broke it down into five categories, with the key part of the market falling into the “pure-play” and “integration-focussed” categories:

Integration-focussed BPM manages system-to-system flows for process integration across multiple applications. At the time, products in this category were slowly emerging into the human-to-human flow applications but lagged in user sophistication and user-friendliness.
Pure-play BPM provides overarching design and connection between application-specific and integration-focussed workflows, for example, by triggering a subflow in another system and carrying the result back to the master process. These were the über-BPM products, modeling processes across the enterprise, not just subprocesses within the enterprise, and including modeling and analysis tools, business rules engines, and process simulation and optimization.

Basically, Gartner (and other analysts, quickly and slavishly followed by the vendors) put the words “workflow” and “EAI” out of fashion, and ushered in the era of referring to anything even remotely related to process as BPM. They then split the BPM space (mainly) into pure-play and integration-focussed, which corresponded roughly to the old divisions of workflow and EAI vendors. Along the way, I’m sure that they sold a boatload of analysis and consulting.

Keith Swenson has a post this week about how the term “workflow” fell out of favour during this period due to “marketing fluff”, a point with which I completely agree — after about 2001, you couldn’t use the word workflow in a conversation with an IT group without someone sneering at you for being old school. His point is that BPM has now come to be synonymous with EAI; I’m not sure that I agree with that, but I do think that BPM is one of the most misused and misunderstood terms around today.

Next: The new arrivals

A Short History of BPM, Part 5

Continued from Part 4.

Part 5: Creation finishes, but what’s left?

Now, the workflow and EAI markets started to converge. Both workflow and EAI products extended to include functionality that was useful in both spheres, such as business rules engines and more advanced process modelling tools. Business rules engines were typically integrated through OEM agreements, while process modelling was usually built as an integral part of the workflow or EAI product. Workflow products beefed up their EAI capabilities, and EAI improved their workflow tools.

Customers started to get confused: where did workflow end and EAI begin? When should you choose one product over another?

Next: the Tower of Babel