Category: conferences

BPM Think Tank Day 1 wrapup

First, a major thumbs down to OMG for not providing free wifi in the conference rooms — this is an expected level of service at any computer-related conference these days. The Doubletree (where the conference is being held) has paid wifi throughout the hotel so I was able to get online, at a price. One of the conference speakers later made the comment in response to all the requests for wifi that we should just turn off our laptops since we were supposed to be paying attention to the conference rather than reading our email. Thanks, Mom, but I was actually taking notes and live blogging about the conference, not reading my email.

On a more serious note, every presenter who I heard speak today was an expert in their particular area, but knew almost nothing about competing standards. I heard the phrase “I’m not an expert in xxx” too many times today, and I think that anyone involved in standards like this who is speaking at such a workshop should be at least familiar with the other standards that they are inevitably going to be asked about. I’m still sorting through how all these standards and formats fit together, which are competitive versus complementary, and it doesn’t help when the speakers don’t have a vision of at least their part of the landscape.

My favourite presentation was John Evdemon’s: not only was he informative, he also has a lot of passion for his topic. We had a brief chat afterwards about how we can bring together process and Web 2.0 that I hope to continue later.

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.

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.

BPM Think Tank

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.

European BPM conferences

I went looking at last year’s BPMG conference webpage to find out about this year’s conference, and was surprised to see that not only have they moved their conference to September, but they’re headlining a European Gartner BPM summit in June on their conference page. I saw Steve Towers at the Gartner summit last week, so there’s obviously some cooperation going on between BPMG and Gartner, but is there really a market in London for two major BPM conferences within three months of each other? Or is this a case of Gartner just barging in, and BPMG scurrying around to try and salvage their mindshare?

The Sins of Patrick Morrissey

With that title, you can just imagine the black-cassocked priest striding across the Irish moors to confront his personal demons… or maybe I have an overactive imagination from watching a rerun of The Thorn Birds last night.

Anyway, this isn’t about Father Pat‘s own sins, but the sins that we all commit during the act of BPM. As a follow-up to Bruce Silver‘s comment on my previous posts about the Seven Deadly Sins of BPM, here they are, hot off the Savvion press:

  • Don’t model your current process
  • Don’t understand people and system requirements
  • Treat BPM as an IT problem
  • Focus on “architecture” in SOA rather than “service”, which ensures that the business doesn’t care about the project
  • Commit unnatural acts with existing applications
  • Hardwire your BPM application
  • Implement automation [of low-value processes] only

I was going to highlight a couple of these as sins that I’ve seen committed, but have to admit that I’ve seen them all, although have rarely committed any of them myself. I can’t even single one out as being the key one: they’re all killers.

The true path to BPM is clear: repent of your sins!

Gartner BPM summit day 3 and wrap-up

The last day at the Gartner conference was a short one for me: I skipped the vendor sessions in the morning, so only attended Daryl Plummer’s session “BPM in the Service Oriented Architecture” and the Andrew Spanyi talk at lunch before I had to leave for the airport.

Plummer’s session description started with the phrase “Is BPM in my SOA or is SOA in my BPM?” — where have I heard that before — then asked the questions “Where do BPM and SOA cross paths? How can SOA be leveraged for the business process? How can BPM be leveraged for an SOA?” There was quite a bit of recycled material in here, or maybe I was just getting conferenced-out by that point, but he did introduce a new (to me) acronym: ISE, or integrated service environment, which is apparently the process developer view of composite applications as opposed to BPMS, which is the business view of composite applications. He made a strong point that ISE is not just an IDE plus BPM, but is the following:

  • A development environment that enables creation, assembly, orchestration, deployment, automation and maintenance of composite applications based on services from the perspective of a process-centric developer.
  • Automates and manages the productivity of developers through frameworks, process flow, page flow and service invocations.
  • Provides the development work environment for an application platform suite to assemble services into processes and composite applications.
  • Supports SOA principles and XML Web services standards, as well as traditional component and modular code mechanisms.

First of all, it’s not clear to me why this isn’t just BPM plus some array of development tools. Second, it’s also not clear to me that a BPMS is the business view of composite applications: that’s one aspect of a BPMS, but most of them also provide a huge part of the process developer’s view as well. Is ISE a valid distinction in this ever-changing SOA environment, or just the buzzword du jour?

Spanyi’s talk at lunch was a bit lost in the hub-bub of a room full of people eating and — in the case of two people at my table — carrying on completely unrelated conversations, but I did pick up a copy of his latest book so can presumably get the gist of it from that.

One last note to Matt, who I sat with at lunch on Monday: send me your contact info, I want to hear more about your open source workflow project and I want to connect you to someone who is doing something similar.