Archive for September, 2006
This morning I trekked over the hill to Redwood Shores to find out what Oracle is up to in BPM. I came away impressed.
Recall that they did an OEM deal two months ago with IDS Scheer for the ARIS Process Design Platform, the leader in business process analysis tools according to Gartner’s quadrant. At the time I speculated this had more to do with keeping up with SAP in the enterprise apps battle than engaging in the BPMS marketplace, but that’s apparently not entirely true. Yes, the Oracle Apps team is one very important customer for the “Oracle BPM Solution” — 1000 demanding beta users, with Larry’s ear to boot! – but not the only one. Armed with the new Oracle BPA Suite (i.e., ARIS), Oracle is also going after corporate customers in the mainstream BPMS market, Oracle ISVs looking to do something similar to the company’s own Fusion Apps, and system integrators looking to create their own repositories of models representing best practices and solution templates.
The Oracle BPM Solution consists of the BPA Suite plus the SOA Suite. The SOA Suite includes BPEL Designer and engine, Workflow services, Business Rules, BAM, Registry, Repository, ESB, adapters, security, service management… the whole deal. They also seem to be the second SOA vendor (besides BEA) who actually understands that BPM and SOA are not the same thing, with a clear idea of how to put them together.
OK, so far that sounds like a complete, but not especially cool, BPMS offering. Here’s the cool part, and it goes back to the recent BPEL discussion. Remember, a problem with BPEL in BPM has always been keeping the executable design in sync with the business analyst’s model once the developer has taken a whack at it — the notorious roundtripping problem. Oracle has solved that here with the Business Process Outline - a model that sits in between BPA (ARIS) and BPEL, with unambiguous mappings to both, and intelligible to business as well as IT. They described their conception of it last spring in Business Integration Journal, and I blogged about it then. But it’s place in the offering was not at all clear back then. Now it is.
The Process Outline is based on metadata shared by BPA and BPEL Designer. Both the process model and BPEL — at least the parts that need to be kept in sync — can be saved as Outline metadata. No matter what the BPEL developer does, Outliner stays in sync. Oracle envisions a new role as the target user of Outline: a “process architect” — more technical than a business analyst but not a programmer, and with a knowledge of the business side. Maybe a useful role for enterprise architects? (No jokes please). The interplay between the BPA user and the architect is viewed as an iterative collaboration, and this seems like an interesting approach to the supposed “business-IT collaboration” promised by SOA. A side benefit: the process architect adds business-friendly metadata to the service registry so that business users can actually use it to discover available implementations, another SOA promise. Why didn’t other vendors think of that?
The Oracle BPM Solution is GA today and in production at several customer sites. New versions supporting Outline will be rolling out in phases over the next several months.
September 29th, 2006
Yesterday Ismael posted something about a new team collaboration offering from Webex called Webex Connect, that appeared to have some connection to Cordys BPM, one of the offerings described in my 2006 BPMS Report series. I couldn’t tell exactly what it did, but Ismael seemed unusually excited about it, so I called my friends from Cordys to get more details.
In the meantime, Ismael was prevailed upon by one of his readers to say more about what the demo he saw actually did. In his response, he said:
The demo we saw goes something like this: you’re a sales manager, and a prospect sends you an email telling you that a technical problem needs to be fixed before you get your prized PO, look like a hero, and keep your fiancee happy (verbatim). The prospect is asking whether you knew about the trouble ticket that was recently entered into the BMC Remedy system.
Upon reception of this email, you check your real-time workspace to see which members of your team are online. You request an online meeting, which leads the system to call you on your cellphone in order to patch you in. You engage in a discussion with your colleagues, while checking the ticket from your dashboard. Once you figure out a solution for your prospect, you update the discount you gave to your customer, by using a Connect-generated user interface that serves as a front-end to your SAP ERP system. This very change is then automatically reflected into your sales forecasts that are managed by a SugarCRM instance deployed on premise.
Once all that has been done, you send an email back to your customer, explaining the resolution that was brought to solve the problem — and the additional discount you gave her, but decide that the overall process should be improved so that similar incidents are handled better and faster in the future. You start the Cordys browser-based process editor, change the workflow definition here and there, and call it a day.
Cordys’s relationship with Webex began in 2000. Cordys founder Jan Baan was an early investor in Webex, and consequently Webex became an early adopter of the Cordys composite application platform. Webex now appears to be repositioning for the SaaS market, and Cordys fits there as well, since it is one of the few BPM tools that provides a browser-based design environment.
In Connect, Webex is extending their AIM Pro client (IM framework) into a full online collaboration workspace, with document sharing, discussions, IM, etc. Cordys provides the embedded composite application framework underneath. From within the teamspace, users can define composite applications or mashups and make them available as a service, or they can use those mashup services. The mashups may or may not involve workflow. In any case, Cordys provides the underlying orchestration engine and design tool. If you are familiar with the Cordys product from the BPMS Report, you might think that certain aspects of the designer, such as message mapping, are too complicated for the target Webex Connect user, so they are planning a simpler Cordys-Lite interface there. Probably could use that in the regular Cordys product as well.
September 27th, 2006
Human-centric BPMers’ lack of love for BPEL is today taken for granted, but who knew there were BPEL-haters out there in the SOA world as well? After taking a look at the BPEL 2.0 spec, Dave Linthicum tries to reignite the bashing, based mostly on the facts that 1) processes still aren’t portable and 2) BPEL 2.0 is not backward-compatible with BPEL 1.1. Active Endpoints’ Fred Holahan counters with a spirited defense of BPEL. He says yes, BPEL is not 100% runtime-portable, but it is “knowledge-portable” — I guess sort of a process modeling language for programmers?
While I don’t think of myself as a BPEL-lover, I actually come down more on Fred’s side here than Daves’s. And I’ve moved to a more nuanced view that might provide a middle ground.
In his rebuttal to Fred, Dave says:
What’s most frustrating about the issues here is that orchestration is indeed a core feature of SOA…the configuration component that makes orchestration that part of the architecture providing agility…. Orchestration, at least the notion, is a necessity if you are building a SOA. It’s the layer that creates business solutions from the vast array of services and information flows found in new and existing systems. Orchestration is a godlike control mechanism that’s able to put our SOA to work, as well as provide a point of control. Orchestration layers allow you to change the way your business functions, as needed, to define or redefine any business process on-the-fly. This provides the business with the flexibility and agility needed, and the core value of SOA. The notion that portability or interoperability was never a promise of BPEL 1.1 does not jive with what has been said and written by the BPEL vendors, analysts, and bloggers….
I, too, was shocked when John Evdemon announced at Think Tank that portability was never a goal of BPEL, and I agree with Dave that hyping process portability was a big factor in getting BPEL’s “coalition of the willing” on board in the early days. So his dismay on this point is justified.
But in my view, the basic fallacy of Dave’s argument relates to the difference between SOA and BPM. Yes, orchestration is important to SOA — to create coarse-grained business services out of fine-grained services distributed over the ESB. And orchestration is also important to BPM — to create end-to-end business processes by orchestrating business services and human tasks. But BPM is not SOA, and business services are not what BPM means by business processes.
BPEL is really good for orchestrating business services out of fine-grained APIs — how SOA uses orchestration. It’s less good — although it can do it — for orchestrating end-to-end business processes. I think, in the end, this is how it’s going to play out in the marketplace as well: BPEL (or equivalent) within the SOA stack, and a separate process engine in the BPMS. The BPM pureplays, along with BEA and Tibco, are taking this approach, while IBM, Oracle, and SAP are still on the BPEL-or-bust path to BPM.
If you look at why BPEL 1.1 isn’t portable for BPM, it comes down to three basic limitations in the language: no support for human tasks, no support for subprocesses, and pitiful data manipulation. BPEL 2.0 mostly fixes the data manipulation part, but not human tasks and subprocesses. So how can you use an orchestration language without support for human tasks and subprocesses? For creating business services! You get more than Fred’s “knowledge-portability.” You get actual runtime portability, and a choice of engines at a commodity price. So it has real value there.
For BPM, I think the portability layer moves to BPMN, probably in some successor version that eliminates the constructs that can’t be mapped unambiguously to an execution language. If and when that happens, you may be able to execute a BPMN model on your choice of, say, Lombardi, BEA, or IBM engines, even though the execution languages are different.
September 26th, 2006
Today is the half-year anniversary of BPMS Watch, time to reflect on how it’s gone, and where to go next.
Ismael invited me to guest blog on IT|Redux at the beginning of the year, and after doing that for a couple months I had the urge to try it on my own. Unlike Ismael, Sandy, or other better-known BPM bloggers, I cover BPM only. That limits the audience, but I guess it’s the piece I know. Bloggers are always checking their stats, and I’m no exception. Here are my results after 6 months.
Feedburner reports subscribers to the feed are around 240, and still growing linearly at around 40 per month. That’s pretty good (I think). Blogger lore says that it’s better to cultivate a regular readership via the feed than to try to maximize one-off hits on Google. That’s good, since I have no idea how to do the latter.
AWStats tells me I have around 3000 unique visitors a month, 6000 visits a month, and 24,000 page views a month. Ismael tells me that’s pretty good as well, especially the daily page views. Technorati, where the A-list bloggers like to play… not so much. That site ranks blogs by the number of unique other blogs that link or track back to yours. I have 149 links from 42 blogs, rank around 66,000. Unless I expand my coverage into SOA or something, I don’t think I’ll go a lot higher on Technorati.
There are 117 registered users on the site. I expected more. You only need to register to comment or download one of my reports. I don’t get as many comments as I hoped. I still want to work on that.
The site is now syndicated on FindTechBlogs, part of KnowledgeStorm, an information aggregator. A number of other media companies have approached me about a similar thing, but so far only this one has pulled the trigger. I think I will have to broaden the message a bit to appeal to the wider market, and I’m thinking about how to do that.
So far I’ve aimed at thought leadership, mostly among readers who are pretty deep into BPM already — a lot of vendors, consultants, and IT people who “get” BPM. I think BPMS Watch has done a good job of surfacing issues around “BPM 2.0″, BPMN, what business analysts can or cannot do, the relationship of BPM and business rules, BPM and SOA, and other things that don’t get a lot of serious coverage elsewhere. I had expected to write a lot more about specific BPMS offerings, and I’m going to do that more in the next 6 months.
As I get into the BPMN training business, I am going to be dealing a lot more with BPM newbies and less technical types, and I need to create more reference material for them on the site as well. It might have to be another site, but the best thing about Wordpress (and I assume other blogging software) is how easy it is to maintain the site, so I’d like to find a way to reformat BPMS Watch to look a bit more like a website that includes a blog, rather than just a blog. Any Wordpress mavens out there who can point me in the right direction, please drop me a line.
The bottom line, though, is that blogging has been absolutely great as a marketing vehicle. It provides reach, visibility, direct engagement with the BPM community… and it’s free for both the blogger and the audience. I am totally swamped with paying work, much of that generated from blogging. (Yes, blogging is in a way self-limiting.) So I am in total agreement with Redmonk’s Stephen O’Grady and other so-called “open source” industry analysts… the traditional Gartner/Forrester subscription model is getting harder to sustain every year. If I am ever able to get a vendor to pay me $50K to put a dot in a box, I’ll know the tide has finally turned.
September 26th, 2006
Even though I made a point of not identifying the author in print, the creator of Figure 3 in my original What’s Wrong With This Picture post takes me to task for not contacting him discreetly with my correction. Welcome to the blogosphere, my man. Anyway, he posts his own correction, basically repeating my explanation.
But if the guy were really engaged, he would have noticed that images 4, 5, and 6 are also his bogus examples. So to accelerate this thing, let’s just post the answers here so we can move on to more interesting stuff.
Figure 4. Here he uses a compensation end event in one pool to “throw” a compensation caught by a compensation intermediate event in another pool. Can’t do that. In BPMN, different pools are different processes. They only communicate by message flows, not events. You can only throw and catch events within a single pool. In this diagram, for example, an unhappy buyer cannot terminate his own process and throw a compensation to the seller’s process that reverses the charge. Instead he would have to send a message to the seller (and return the goods), and the seller’s process could then throw the compensation and reverse the charge. That’s pretty basic.
Image 5. This essentially repeats all the errors of image 3 (e.g. see here), except within a BPMN “transaction” subprocess (double border). Transaction subprocesses and Cancel events (with the X inside) are kind of problematical in BPMN — BPEL doesn’t have a way to support them, and BPMN already supports business transactions even without them. The BPMN 1.0 spec essentially says “we’re still trying to figure this one out.” So in my BPMN training I’m going to recommend best practice is to avoid transaction subprocess and Cancel events entirely.
But just so you can’t say I’m double-counting the errors of image 3, image 5 throws in for good measure an error on the BPMN link event (arrow symbol inside). Here it’s shown as the start event for the Fulfill subprocess, which is incorrect. You would use a link start event for a subprocess in two cases: 1)as a chained off-page connector, e.g. if the main process after Confirm Availability went to an intermediate link event in a normal flow (i.e. with a sequence flow into it); that means go to the next step on another page of the diagram, which would be shown with a link start event. 2)state-based synchronization, typically used when a downstream activity starts based on completion of an activity in one thread of a parallel flow – if this sounds obscure it’s because, yes it is, but it maps to the “link” activity IBM somehow got into the BPEL spec. Anyway, neither of these applies in Figure 5, and the subprocess should not have the link start, just a regular start event.
Image 6. This one is just weird. I’m not sure if it technically violates the spec or not, but it’s not very helpful in explaining BPMN. Here printing a newspaper is modeled as a transactional subprocess. A message intermediate event from the publisher stops the presses in an exception flow, which then throws a cancel event, which does not compensate anything but just recycles the paper (!). In this example you could throw out the transaction subprocess entirely and replace the cancel event in the main flow with the publisher’s message event, leading to stop the presses (actually implicit already in the exception flow so you don’t even need that step) and then recycle paper. The transaction and cancel — the nominal purpose of this “example” — add zero to the semantics. Just bad teaching.
September 19th, 2006
Last week I got an in-depth briefing from Pegasystems. I wrote a report on their SmartBPM Suite v4.2 in the 2006 BPMS Report Series, but they’ve made some subtle tweaks to the product in v5.1. More than that, they’ve changed the way they talk about it, which for me helps tremendously in thinking about Pega in context of other BPMS offerings. And I came away quite impressed.
If you remember the old Pega, it was always about rules and object-oriented design. Everything was a rule — routing, integration, user interface… in addition to actual business rules. Plus they would go on forever about object inheritance, polymorphism, and all that yucky stuff. Now it’s about ease of development, managing complexity, and solution value out of the box. Can I dig that? Yes I can.
In the old Pega, the first step to building an app was defining the object class hierarchy. Yeah, that’s a great way to start a business-driven initiative! You can still do that if you want, but in the new Pega you can just start with process modeling, and they create the object class structure under the covers. When things start getting complex — different departments doing their own special tweaks – you can always get into the object class thing, but by then you’re already getting something done. Pega would argue, and I guess I can’t disagree, that when you’re rolling out a process broadly in the enterprise, different variations of the process are going to be required, and using object inheritance to manage both the base functionality and the variations is actually a strength. But they don’t make you get a CS degree to get started anymore. So that’s cool thing number one.
Cool thing number two is their emphasis on the end user experience, i.e. the task user interface for process participants. Other vendors, like Lombardi and Adobe, also hang their hat on this one, but Pega takes the prize for making dynamic Ajax interfaces and screenflows easy to develop with visual forms. It’s not even scripting, just point-click.
The third cool thing is solution value out of the box, particularly for insurance, health care, call center, etc. Other BPMS vendors have “solution template” demo software that they give away, but this is the real deal. Engineered, QA’ed, documented, warrantied software that does real work out of the box, with built-in support for complex business objects like HIPAA transaction sets, business rules, and performance management reports. I think this is a key reason they scored so well in the Gartner MQ, and they try to market these solution templates as something every BPMS is supposed to have. But when the industry norm is fake solution templates and you have real ones, I’m not sure that’s the best approach.
Anyway, kudos to Pega. I’m paying attention now.
September 19th, 2006
Last week I posted several examples of illegal and nonsensical BPMN that you can find online in popular free tutorials and BPMN tools. If you believe that the notation is too hard for business analysts to use, you might consider instead that widely propagated disinformation such as this is mostly to blame. Of course you can teach people to use BPMN effectively, including the part where it represents the biggest advance in process modeling, handling of business exceoptions.
Only one reader (thank you, Kevin Brennan!) tried to identify the errors, so I’m going to do it myself. In the first example (images 1 and 2 in the original post), I’ve circled each of the errors and given them numbers, referenced in the explanation below.
(click to enlarge)
Let’s start with the simple notation errors. Errors 1, 2, 3, 4, and 5 are all essentially the same. The small diamond on the tail of a sequence flow (solid arrow) means the sequence flow is conditional. The spec says it is used only when the sequence flow originates in an activity (task or subprocess), not when it originates in a gateway (diamond shape). Two unconditional sequence flows (i.e., without the little diamond) originating from the same activity means a parallel split (same as a gateway with a + inside). If some of the sequence flows from an activity have a condition (little diamond on the tail) it is the same as what BPMN calls an OR-gateway (diamond with an O inside).
An exclusive gateway (diamond with an X inside) means that only one of its outgoing sequence flows is enabled, based on the gateway condition (a property of the gateway, not a property of the sequence flow). So to correct errors 1-3, get rid of the sequence flow conditions (little diamonds).
Error 4 is a conditional sequence flow from a timer intermediate event, indicating an exception flow. A conditional sequence flow cannot originate from an intermediate event, per the BPMN spec. Get rid of the little diamond here too.
Error 5 is like errors 1-3 except here it is an event-triggered gateway, basically the same as an exclusive gateway except the process takes the path determined by the first event received. Get rid of the little diamonds.
Error 6 I’ve shown in 2 pieces, 6a and 6b. The spec says a sequence flow into an expanded subprocess should be drawn either to the boundary of the subprocess or to the start event drawn attached to the boundary. 6a shows the flow drawn to the start event inside the subprocess. OK, that’s kind of minor, until you pair it with 6b, which shows the sequence flow out of the subprocess drawn from one of the end events. There are 2 other end events in this subprocess, one labeled Rejection Response (which generates a message) and another labeled Bookings. If you trace through the diagram, you’ll see that only one of these 3 end events can be reached, so reaching any one of them ends the subprocess, and the flow continues to the next step, which in this case is an end event for the entire process (but it could be another activity). The diagram is confusing because all 3 end events in the subprocess terminate the subprocess, but the sequence flow is drawn to only one of them. To fix, best to attach the sequence flows to the subprocess boundary.
Errors 7-8 are the same — intermediate events intended to be compensation events (perhaps not obvious from the diagram, but in this case so indicated by the event properties in the tool itself). Compensation events should be indicated with the rewind symbol inside.
But the problem here is much more serious than that. A compensation event attached to an activity means that in response to a compensate signal (generated by a compensation end event or a transaction cancel end event), IF the activity has completed successfully, the specified compensation activity is executed to undo the completed activity, as part of the recovery logic of a business transaction. Modeling business transactions is a little complicated, but suffice it to say for now that the link from a compensation event to the compensating activity is an “association” (dotted line), NOT a sequence flow. A compensation event does not trigger an exception flow that interrupts the activity and then proceeds down its exception sequence flow. The activity must have already completed for the compensation event to have effect, and its effect is limited to executing the compensating activity linked by the association. So errors 9 and 10 are associations drawn as sequence flows. Errors 11 and 12 are the compensating activities shown without the compensation (rewind) symbol. Errors 13 and 14 are sequence flows out of the compensating activity, which is forbidden by BPMN. In a nutshell, this diagram confuses fault handling with compensation, and combines them in a flow triggered by a compensation event. They are separate things, but both are part of recovering from an exception (business exception or system fault) in a business transation.
Error 15 is not a notation error but a business semantics error. I think it’s just the tip of the iceberg in this particular example, but it’s illustrative of the exception handling problem in general.
Let’s look at what this travel booking process is trying to do. The first step is to verify the form of payment (but not charge the customer). If the verification fails, the process ends with a message to the customer. If the verification succeeds, the customer’s trip request is processed to create one or more candidate itineraries back to the customer, requesting confirmation. If the confirmation is not received in 2 days, the travel service terminates the process and sends a cancellation notice to the customer. If the confirmation is received in time, air and hotel are booked in parallel. After both are booked the customer is charged. If there is a problem with the debit, a notice is sent to the customer, and the process waits for an event in return, either an Update message or a Cancel message. “Update” presumably means “try again” since it loops back to the same Charge Buyer activity, and “Cancel” means abort the booking. If no response is received in 2 days, the task Contact Customer executes after which the process retries the debit (that doesn’t sound exactly right!) This retry cycle can repeat up to N times, after which the process terminates.
Attached to the entire process (except for the first verify form of payment step) is an intermediate message event listening for a Cancel message. (Presumably this is a different Cancel than the one specific to the Payment Problem notification described above.) No matter where in the process this occurs — before booking, during booking, after booking but before debiting customer, etc — the processing is the same (Handle Cancel Message). That is incorrect, since how you handle the cancel depends on the state of the process… how far you’ve gotten. Of course you could put all that state-dependent processing inside Handle Cancel Message, but then why did you draw this diagram in the first place?
I intended error 15 to mean modeling a single cancellation handling activity for the process regardless of state, where in reality the cancellation behavior has to be state-dependent. On reflection now, I believe that the author was trying to model a business transaction in which a Cancel message aborted the transaction and triggered compensation of the bookings and debits, but the exception flows, compensation events, and other BPMN rules got him so befuddled that the business semantics were completely lost.
It is tempting to draw from this example the conclusion that BPMN is too hard for business analysts to understand, or perhaps exception handling in BPMN is too hard. I don’t believe it. It’s just that there isn’t much educational material out there that shows people how to use BPMN correctly. Surely a business analyst should be able to model a customer transaction process that describes when and how to charge the customer, issue credits, allow cancellation, etc. Should all the exception-handling be left out of the model and turned over to the programmers? I don’t think so.
In a few days I’ll work out what I think would have been the right way to do this. It’s good practice for me as I put together my BPMN training.
September 14th, 2006
BPEL 2.0, the long-awaited love-child of the OASIS WS-BPEL TC, is at last in its final public comment phase. See John Evdemon’s blog for all the links. Sure, conventional wisdom says two years is a long time to change Switch to If-then, but if Assaf’s comments are correct, fixing BPEL 1.1’s primitive data manipulation syntax may prove to be a far more significant change. Once the thing is finally approved we can anticipate a ripple effect on BPMSes, and a round of new questions. Will Microsoft actually support it? (Unlikely.) Will there be an actual spec submitted for BPEL4People and BPEL-Subprocess? (Probably, but will anyone but IBM and SAP care?) Will BPMN have to change to support the new BPEL? (Bigger problems than that confront BPMN.) Once BPEL 2.0 is approved by a vote in OASIS, I think it has 6 months to prove it was worth waiting for. If it can’t do it, I think the energy on standardization moves to the modeling language (BPMN?) and the execution language becomes an implementation detail.
September 12th, 2006
In his comment on my post What’s Wrong With This Picture?, FairIsaac’s James Taylor asks many of the right questions about BPMN and Business Rules. I thought it deserved its own thread. He asks,
- how do I differentiate between decisions that are simple “Customer is New/Not New” and complex “Customer’s credit is good/bad”? One of these is about routing rules, one is about decision rules
- are there any subsets of the activity box to allow me to show decision services as activities more explicitly? Has this been discussed ever particularly in terms of allow looser synchronization of rules and process?
Actually, BPMN barely deals with rules at all, and where it does, it does it in kind of a strange way.
The BPMN spec defines an intermediate rule event, which can be attached to the boundary of an activity (task or subprocess) to indicate an exception flow triggered when a “rule becomes true.” Here a rule is defined as “an expression that evaluates some process data.” I have never seen this used in practice, but even imagining where it could be used, it’s not the way business rules are usually implemented in BPMS.
Let’s count the ways in which BPMN’s treatment of rules is strange:
- The most common use of business rules in BPMS is a decision service. That’s like James’s second example - customer credit is good or bad. In BPMN that would be modeled as a task (with a web service implementation). It has nothing to do with the rule event. In many examples used for descriptive modeling (i.e. no intention to drive an execution language like BPEL), the rule evaluation is implicit in a gateway. For example, a gateway might split paths for customer credit good vs bad, but the decision task (credit evaluation) is not even drawn… it’s just implied. That’s bad practice but very common.
- BPMN rule events refer, not surprisingly, to event-triggered rules. In BPMS these are less common than a decision service invoked by the process. Some BPMSs (e.g. Cordys, Pegasystems) use event-triggered rules to model constraints on runtime business objects. When instance data is inserted or updated, a business rule is triggered. The other place they’re used is BAM, where the rule is triggered by an update to a performance metric or KPI, i.e. an aggregated measure of process data. But I know of no BPMS that uses BPMN rule events to describe this behavior.
- What seems to me would be a good use of the BPMN rule event might be response to an external event such as update to an external database or content repository. In these cases the external event is generated by the database or CM system, not by a ”rule”, so the rule event is not reallydistinguished from an intermediate message event… the normal symbol for an external event triggering an exception flow.
- The other interesting thing about a BPMN rule event is that the event must occur within the context of a particular activity (task, subprocess, or entire process) to have effect. For example, if the business event that would cause a “customer credit is bad” rule to fire occurs prior to the activity where the BPMN rule event is attached, it’s as if the event never occurred. Also, the rule event’s effect is to interrupt (abort) the normal flow of that activity and launch the exception flow. But this is just a subset of things business rules can do. For example, what business rule management calls a declarative rule might say simply “if A and B, then C”, where C might just set the value of a variable. So BPMN rule events don’t map well to declarative rules.
In short, BPMN’s rule event does not seem a particularly useful construct.
September 11th, 2006
[Preview of next week's BPMS Watch column on BPMInstitute.org]
It’s conventional wisdom in business that 80% of the problems are caused by 20% of the work – the “exceptions.” In BPM, therefore, you’d think that exception handling would be a critical focus of process modeling and analysis. In most cases you’d be wrong.
Certainly the designers of the Business Process Modeling Notation (BPMN) standard at BPMI (now part of OMG) had exception handling in mind from the start. BPMN introduces to process modeling the notion of intermediate events. It’s a godawful name but an absolutely essential concept for making exception handling visible in the process diagram and understandable to business people. In fact, events are the key difference between BPMN and traditional flowcharting.
In BPMN, intermediate events are drawn as circles with a double border, with a symbol inside denoting the type of event: receipt of an external signal (message), a timeout, a system fault, etc. Drawn attached to the border of a process activity or subprocess, the semantics of BPMN say that when the event occurs, the activity or subprocess is interrupted immediately, and the process continues along the flow path leading out from the intermediate event. That path is called “exception flow.” If the event never occurs, the activity or subprocess completes normally and processing continues along the flow path leading out from it. That path is called “normal flow.” Is that hard to understand? No, I didn’t think so.
You’d be surprised, then, to know that a number of modeling tools offered by BPMS vendors that advertise themselves as BPMN-compliant don’t support intermediate events. What those vendors usually say is that the concept is too technical for business analysts to understand. What they really mean, in most cases, is that their process engine – the thing that “executes” the model to automate and monitor the process flow – can’t handle them. The modeling tool’s simulation engine has no idea what to do with them, either. So they’re just left out of the tool. Shame on OMG for allowing this pseudo-BPMN to proliferate as it has.
The traditional alternative to modeling exception handling explicitly in the process diagram is to do it in code, toss it over the wall to IT. Once in a while this might be necessary, but as a general principle it’s just plain wrong. By removing exception handling from the process model and burying it in implementation code, you’ve not only lost visibility into the most critical part of your process, you’ve lost the ability to use it in simulation analysis, you’ve lost agility, reuse, shared best practices, etc. All of those assume exception handling is surfaced in the process model.
In addition to intermediate events, BPMN adds another important notion to the process modeler’s vocabulary: business transactions. A transaction here means a collection of activities that must be performed “atomically” – all must complete successfully or else the system must be “rolled back” to its initial state, as if none of them had ever occurred. Unlike classic transaction protocols like two-phase commit, where the resource performing each part of the transaction is “locked” until the transaction either commits or rolls back, business transactions are by definition “long-running” – lasting seconds to days, too long to lock the resources – which also means you can’t truly restore the initial state as if nothing ever happened.
Instead, if an activity in the business transaction cannot complete successfully, already completed activities must be undone by their compensating activities, and any uncompleted activities in the transaction are abandoned. Undoing a debit, for example, might be issuing a credit for the same amount. It’s not a rollback as if the debit never happened – both the charge and the credit show up on your Visa bill – but it has equivalent business effect.
Here’s a scenario. You’re booking a trip to Europe online, air and hotel. Neither the airline nor the hotel can guarantee price or availability until you actually book specific dates with a credit card. Yes, it’s a nasty world we live in. But if you can’t match the dates of both hotel and air, you’re reservation isn’t much good. So consider them part of a single business transaction. Let’s even imagine that you first select your preferred complete itinerary (hotel and air) and then instruct the travel site to book it. Assume the travel site models this as a BPMN business transaction, first booking the hotel (no cancellation fee) and then the air (no avoiding the cancellation fee). The BPMN might look like this:
(click to enlarge)
The subprocess enclosing Book Hotel and Book Air acts as a business transaction. If the hotel is unavailable, the subprocess completes without booking the air. But if the hotel is available, it is booked with a deposit on the credit card. If the air is not available, the subprocess completes with a compensation end event – a call to completed activities to execute their defined compensation activity. For the Book Hotel activity, the compensation activity Cancel Hotel (with compensating credit for the deposit) is identified by its link to the compensation intermediate event (with the rewind symbol inside) on the boundary of Book Hotel.
The explanation may be long-winded, but the diagram is concise and explicit.
This is about business semantics, not programming. Business analysts can understand intermediate events, exception flows, and compensation. The problem to date has been a lack of quality training on BPMN supported by a clear methodology for translating process knowledge into diagram correctly. The current state of market education on BPMN is really quite appalling. (If you don’t believe me, look here .) That’s why I’m putting together my own training materials on Process Modeling with BPMN. Exception handling is too important to be tossed over the wall to the programmers. Real training and a methodology can give process analysts the tools they need to define how exceptions should be handled in their critical business processes.
September 8th, 2006
Previous Posts
