Bruce Silver Associates Independent Expertise in BPM

Bruce Silver Associates Independent Expertise in BPM BPMN and the Business Process Expert Summary: BPMN has become the standard language of the Business Process Expert, usable for descriptive process modeling, simulation analysis, and even executable implementation design of end-to-end business processes. BPMN extends the familiar swimlane flowchart paradigm with events, the key to incorporating exceptions into process models and mapping to today s SOA middleware. First of six parts. Author: Bruce Silver Company: Bruce Silver Associates Created on: 30 October 2007 Author Bio Dr Bruce Silver is an independent industry analyst and consultant focused on business process management software. He provides training on process modeling with BPMN through http://www.bpmessentials.com, the BPM Institute, and Gartner conferences, and is the author of The BPMS Report series of product evaluations available from www.bpminstitute.org. Business process management (BPM) is an emerging discipline that looks at the enterprise in a radically new way. Instead of trying to automate and optimize individual functional units, like sales, supply chain, and customer service, in isolation, BPM views your company from the perspective of end-to-end cross-functional processes exactly the way your customers and trading partners see you. At the same time, new BPM tools have emerged that let you model, automate, measure, and optimize the business from such an end-to-end process perspective. These tools straddle the traditional business/it divide, and are elevating the importance of a new role in the organization, the Business Process Expert. The Business Process Expert is neither a traditional developer nor a traditional business analyst, but is able to apply the concepts, metrics, and performance objectives of business in the analysis, design, and optimization of IT implementations capable of executing and monitoring cross-functional processes. Such a role demands a new common language that bridges the worlds of business and IT as well, and now we have one: the Business Process Modeling Notation (BPMN), a standard from OMG. BPMN is simple enough to be readily understandable by business, yet rich enough to support executable implementation without changing the underlying metamodel! As a result, it has become the de facto standard or announced future direction of BPM Suite vendors ranging from Lombardi, Savvion, and Appian, to TIBCO, Oracle, IBM, and yes SAP. Thus, understanding how to model processes effectively using BPMN is becoming a must-have skill for the Business Process Expert. Bruce Silver Associates BPMS Watch www.brsilver.com/wordpress BPMN Training http://www.bpmessentials.com/ 500 Bear Valley Road, Aptos CA 95003 Tel: 831.685.8803 Fax: 831.603.3424 E-mail: bruce@brsilver.com

BPMN and the Business Process Expert Over the next several weeks, this six-part series will explain to the BPX community the unique features and benefits of BPMN; the notation and its underlying semantics; best practices for effective modeling with BPMN; understanding BPMN events; useful patterns for modeling exceptions; and more. In this first installment, we ll look at exactly why BPMN is vital to the Business Process Expert. What is BPMN? BPMN is a graphical notation for modeling business processes. A BPMN model is essentially a diagram of the process flow, but a process model is more than a drawing. Each diagram element, called a flow object, carries a specific meaning defined in the BPMN specification and subject to its rules. That meaning of the process diagram is intelligible to the business user, but the semantics are rich and precise enough to serve as a foundation for an executable implementation of the model. That combination sounds simple, even obvious, but it s something that we ve never had before. It also allows the process model to be more than a graphical business requirements document. In an increasing number of BPM suites, the model supported by IT-added implementation properties for each flow object actually becomes executable! In the BPMN model, each activity in the process flow is defined abstractly by its name, its performer swimlane, and where it fits sequentially (and hierarchically) in the flow. Technical details required for the implementation, such as business rules, user interfaces, or service call parameters, are typically specified outside of the BPMN standard but bound to diagram elements using tool-specific properties. (BPMN also provides a few standard attributes for this purpose, but most tools ignore them.) Thus, a BPMN model can serve as a business view of an end-to-end process solution that remains valid throughout the implementation lifecycle. BPMN is a vendor-independent standard, maintained by the Object Management Group (OMG). That sets it apart from a long history of business process analysis (BPA) tools based on vendor-proprietary process modeling notations. Tool vendor independence is tremendously significant. In practice it means a wide choice of tools supporting the same notation and process semantics, lower in cost than traditional BPA tools. A number of BPM suite vendors offer their BPMN modeling tools as free downloads. That means you can afford to distribute the task of process modeling broadly throughout the organization. How many Business Process Experts would you like to have in your company? If the answer is 100 or more, BPMN is the only way to go. Standardization of the diagram semantics also dramatically enhances shared understanding, which is the first and perhaps most important goal of process modeling. A properly constructed BPMN diagram has the same meaning to anyone looking at it, and reducing your current processes to BPMN has a quick payoff. The low-hanging fruit of process improvement often requires no IT implementation at all. Instead, process participants gathered around the diagram will readily identify potential improvements simply by inspection. In fact, this may be the first time any of them has seen or thought about the entire process end-to-end. BPMN provides the common visual language for that understanding in a way that a 300-page text document never can. BPMN can be used for descriptive modeling and analysis, without the benefit of implementation detail, or as part of a full IT process solution. OMG says that BPMN is methodology-neutral, meaning it is intended for a wide range of use, from simple description to executable design, and you can use just as much of it as you need. This flexibility has Bruce Silver Associates 2007 2

BPMN and the Business Process Expert helped jump-start the BPMN bandwagon, although it has created some obstacles to true model portability. A key component of BPMN s appeal to business users is its familiarity. In its simplest form, a BPMN diagram is just a flowchart, with swimlanes representing participant roles or organizational boundaries. It is not block-oriented like BPEL, which requires every conditional branch or parallel split in the flow to rejoin downstream with no dangling strands. Instead, BPMN is graph-oriented, meaning any activity can be routed anywhere else in the process, even back to a previous step. Business users like that freedom (although it occasionally makes mapping to BPEL execution engines difficult). Another component of that appeal is its inherent simplicity. There are only three basic shapes, or flow objects, in the diagram: Activity, denoted by a rounded rectangle, represents an action or work done in the process. It is the only flow object that is performed by a resource. Gateway, denoted by a diamond, represents flow control logic, such as conditional branching, splitting, or merging process paths. It is pure logic, not work done in the process. Event, denoted by a circle, represents a signal that something has happened. The event flow object in BPMN describes how a process can wait for such a signal, react to it if and when it occurs, or send such a signal either to an external entity or to another part of itself. BPMN goes on to define various subtypes of each of these, distinguished in the diagram by their icons or border styles, but the essential nature of each of the three base types is maintained throughout. More important is what is not included in BPMN: data flow, organizational roles, service components, physical systems, strategies and goals. Unlike the EPC diagrams of IDS Scheer ARIS, for example, which links each process activity to these various elements defined in other models, BPMN describes only the activity flow. Also, while in EPC the arrow that connects one diagram element to another can specify one of many user-defined relationships between the elements, in BPMN such an arrow, called a sequence flow, means only one thing, flow of control or enablement: after the previous activity is complete, go to the next one. Thus while the ARIS metamodel is undoubtedly richer, the simplicity of BPMN is precisely what allows it to be supported by such a wide variety of tool vendors. Elements such as data, roles, and service components are supported in those tools, but in a manner specific to each, and external to the process diagram. Activities and gateways are familiar flowcharting concepts, but events are not. In fact, BPMN s use of events is its singular distinguishing feature and the source of its remarkable expressive power. BPMN allows you to specify how a process can be started by an event, can wait for an event, or can be interrupted by an event and diverted onto an exception flow. In addition, in BPMN you can specify how a process can generate events that trigger other processes, respond to external requests, propagate errors, and even recover from failed business transactions. By making events first-class modeling objects, BPMN stands out by making exceptionhandling behavior a primary concern of the Business Process Expert. Traditionally, exception handling was the part of process implementation tossed over the wall to developers. But if you believe in the notion of business empowerment in IT, this makes no sense. The familiar 80-20 rule says that 80% of the costs, delays, and errors come from 20% of the instances the exceptions. So it should be up to the business to specify in a non- Bruce Silver Associates 2007 3

BPMN and the Business Process Expert technical way how any type of exception should be handled: a customer cancels or changes the order, an item is out of stock, or timeout occurs. If the event occurs, what should happen? The BPMN process model lets you specify that precisely in terms of the what; the implementation of model activities specified outside of BPMN defines the how. One of BPMN s most valuable features is also its least appreciated and most subtle: subprocesses. In BPMN, any activity that has component parts is by definition a subprocess. In the diagram you can represent a subprocess either collapsed, as an opaque simple activity shape, or expanded to reveal its internal structure. Moreover, the expanded view can be shown either in line in the diagram or in a separate diagram hyperlinked to the parent and logically part of it. While some process languages, such as BPEL, do not support subprocesses, subprocesses are central to the philosophy of BPM. For one thing, they are critical to modeling processes as end-to-end constructs. Subprocesses allow an end-to-end process to be described as a single hierarchical entity with a well-defined beginning and end, viewable at multiple levels of detail. The ability to render a BPMN subprocess as either collapsed or expanded lets you zoom in from the end-to-end view to any level of granularity, while maintaining the integrity of a single model at any level. In addition, subprocesses allow the modeler to abstract unknown fragments of the end-toend process. They also support distributed ownership of process fragments, since most organizations today are not organized and managed from a cross-functional process perspective. On the implementation side, subprocesses are perfect design-level containers for reusable business services, a central concept of SOA. Moreover, subprocesses allow those services to be stateful and be consumed in a rich self-describing way. Finally, subprocesses provide a way to specify the scope of an event, meaning the boundaries of a process fragment where a particular business event, if it occurs, has a particular handler flow. For example, if between point A and point B a customer can cancel an order without penalty or special handling, you can enclose the fragment bounded by A and B in a subprocess, attach a customer cancel event to it, and add the handler flow to the event. In fact, you can even declare that subprocess to be a business transaction, and describe in the BPMN the required transaction recovery behavior using compensation. The combination of subprocesses and events gives BPMN remarkable expressive power in the hands of a Business Process Expert. The preceding example hints at the last essential difference between BPMN and past modeling notations: BPMN was created with SOA in mind. That makes it a perfect fit with today s process implementations. Traditional flowcharting is based on a strict control flow paradigm with no real-time interaction with the outside world: after activity A do activity B, period. But in the age of SOA, the process is continuously interacting with the external environment, responding to service requests, requesting services from others, waiting for events, etc. BPMN models can describe that behavior explicitly with events and message flows, and can even describe the message exchanges (called choreography) between your process and an external process. This is no accident, since BPMN was originally conceived as the graphical notation for a web service orchestration language called BPML. Thus the ability to send messages, wait for messages, or be interrupted by messages was an essential feature from the outset. In the end, BPML was trumped in the marketplace by BPEL, a similar language, and BPMN morphed into a more general process modeling notation, supporting human tasks and Bruce Silver Associates 2007 4

BPMN and the Business Process Expert subprocesses, for example. In 2005, the organization behind BPMN merged with OMG, which formally adopted BPMN 1.0 in February 2006. This history may account for one of the biggest disappointments of BPMN, which is the lack of a standard for process model storage and interchange in XML. While the BPMN spec defines the shapes and their associated process semantics, the only sure-fire way today to import a model from BPMN tool A into BPMN tool B is to redraw the diagram. Even then, you can t be certain tool B supports all of the standard constructs you can model in tool A, since BPMN does not define a minimum set of supported elements to qualify as compliant. In the absence of a serialization standard from OMG, the Workflow Management Coalition extended its XPDL standard to capture all the elements of BPMN 1.0. XPDL 2.0 support was introduced in 2007 by a number of BPMN tool vendors, but interoperability between tools is still limited. OMG is in the process of releasing its own serialization of BPMN, called the Business Process Definition Metamodel (BPDM). BPDM is a formal metamodel based on OMG s Meta Object Facility (MOF), and in principle will allow mapping between BPMN and other notations such as UML. However, the draft BPDM specification diverges considerably from today s BPMN, so its applicability for interchange of existing models s questionable. Adoption of BPDM is expected by the end of 2007. BPMN 1.1, a minor change to the BPMN 1.0 specification, reached final draft in July 2007, and is supported by a small number of tools. BPMN 2.0, a significant change that will merge the notation with the formal metamodel, is not expected until late 2008 or 2009. Thus BPMN 1.0/1.1, despite limited portability between tools, represents an excellent standard for the Business Process Expert that should remain stable for at least another year, and supported by an ever-increasing array of BPM vendors in both standalone modeling tools and full BPM Suites. Bruce Silver Bruce Silver Associates 2007 5

Bruce Silver Associates Independent Expertise in BPM BPMN and the Business Process Expert, Part 2: Mastering the Notation Summary: A brief summary of the BPMN notation. BPMN describes process orchestration in terms of activities (tasks and subprocesses) connected by sequence flows. Branches, splits, and joins in the flow are modeled by various gateway types. Events specify how processes respond to signals received from external entities or other parts of the same process. Other parts of the notation are loosely specified and used to add business context only. Second of six parts. Author: Bruce Silver Company: Bruce Silver Associates Created on: 5 November 2007 Author Bio Dr Bruce Silver is an independent industry analyst and consultant focused on business process management software. He provides training on process modeling with BPMN through BPMessentials.com, the BPM Institute, and Gartner conferences, and is the author of The BPMS Report series of product evaluations available from the BPM Institute. In the first installment of this series, we saw why BPMN is important to the Business Process Expert. In this part, we ll look at the notation itself. In BPMN there are only three first-class diagram elements, or flow objects: Activity, a rounded rectangle, representing work performed in the process Gateway, a diamond, representing flow control logic, such as branching, splits, and joins Event, a circle, representing a signal that something has happened, either outside the process or inside. Each of these shapes has various subtypes indicated by an icon or symbol inside, or occasionally by border style. The color of a diagram element has no significance in BPMN. Sequence Flows These elements are connected in a process flow by a solid arrow called a sequence flow. A sequence flow from activity A to activity B does not signify some user-specified relationship between A and B. It signifies only one thing: After activity A completes, activity B starts, or is enabled to start. A sequence flow variant, called conditional sequence flow, and drawn with a mini-diamond on the tail, indicates that the transition from A to B is enabled only if a specified condition is met. But the more common variant, with no diamond on the tail, means the transition is immediate and unconditional. Bruce Silver Associates BPMS Watch www.brsilver.com/wordpress BPMN Training www.bpmessentials.com/ 500 Bear Valley Road, Aptos CA 95003 Tel: 831.685.8803 Fax: 831.603.3424 E-mail: bruce@brsilver.com

BPMN Mastering the Notation A B Figure 1. Sequence flow means when A ends, B starts. Activities Steps in the process are indicated by activities. BPMN defines two types of activities, task and subprocess. A task is an activity that has no component subpart structure of interest to the process model; it is atomic in that respect. A subprocess is an activity that has component structure of interest. BPMN allows the subprocess to be rendered either collapsed, as an opaque rounded rectangle with a + symbol inside, or expanded, as an enlarged rounded rectangle inside of which the component structure is drawn in the form of another BPMN diagram. The expansion of a collapsed subprocess may also be drawn on a separate page, which is considered part of the same business process diagram. Expanded subprocess Collapsed subprocess Figure 2. Subprocesses can be rendered either collapsed or expanded. Unlike BPEL and similar block languages, BPMN allows sequence flows to loop back to the same activity or a previous activity, as long as it does not cross the boundary of a process or subprocess. BPMN defines several task type attributes. Most modeling tools distinguish supported task types in the diagram by an icon inside the task, an extension allowed by the BPMN spec. The two task types of greatest importance are user, meaning a human task, and service, meaning an automated task. A send task means the process immediately sends a message, a signal to an external process or system. A receive task means the process pauses and waits to receive a message. Send and receive tasks are thus the same as message events. An activity, whether task or subprocess, can be specified as repeating. A loop task, indicated with a circular arrow icon inside, is like a While construct in programming. After the task is performed, a logic condition determines whether to perform it again or to continue. A multi-instance (MI) task, indicated with a parallel bar icon inside, is like a ForEach construct in programming. N instances of the activity are performed, either sequentially or in parallel, with N generally known in advance. Gateways Gateways control process flow. A decision gateway controls the flow from one incoming sequence flow to one or more outgoing sequence flows. A merge or join gateway controls the flow from multiple incoming sequence flows to one outgoing sequence flow. Conditional branching, parallel splits, and synchronizing joins all use the same diamond shape. An icon inside the diamond indicates the specific semantics of the gateway. Some Bruce Silver Associates 2007 2

BPMN Mastering the Notation defined gateways are actually redundant, in that a diagram drawn without the gateway has the same process semantics. The most common gateway is the exclusive data-based gateway, also called an XOR gateway and drawn either with an X inside or no symbol inside. An exclusive decision gateway means that a single outgoing sequence flow is selected by a conditional expression of process data. An exclusive merge gateway is actually redundant, since if the sequence flows into the gateway represent exclusive alternative paths, the uncontrolled flow (without the gateway) means the same thing, and if the sequence flows in are not exclusive alternatives, the exclusive gateway is illegal. The exclusive event-based gateway, more commonly called just event gateway, is drawn with a multiple event symbol inside and an intermediate event symbol beginning each outgoing sequence flow. It means a single outgoing sequence flow is selected by the first event to occur, like the Pick construct in BPEL. The most common use of event gateways is to listen for a message, with a timeout in case the message does not arrive. Response Error Timeout Figure 3. Event gateway means take path following the first event to occur. An inclusive decision gateway, some times called OR-gateway and drawn with an O symbol inside, means that one or more of the outgoing sequence flows may be enabled, as their enabling conditions are independent. For example, enable path 1 if the orderamount is over $1000, and enable path 2 if the shipto is a foreign address. Since one path out of a gateway always must be enabled for any instance, a default path, indicated by a tickmark on the sequence flow, is often provided. A conditional sequence flow, described earlier, is an alternative representation of this. Conditional sequence flows can only emerge from an activity. Drawing them out of gateways is a commonly seen error. Condition 1 Condition 1 Condition 2 Condition 2 Default Condition Default Condition Figure 4. Conditional sequence flow (left) and Inclusive gateway (right) are equivalent, used to represent independent enabling conditions. Merging paths that may or may not be exclusive alternatives, such as those coming out of an inclusive gateway, must use an inclusive merge gateway, or OR-join. All paths into the Bruce Silver Associates 2007 3

BPMN Mastering the Notation merge that are enabled must arrive at the gateway before the flow continues. An exclusive merge or parallel merge would be incorrect. A parallel split gateway, also called an AND gateway and drawn with a + symbol inside, means that all of the outgoing paths are enabled unconditionally. It is actually redundant, since drawing the outgoing sequence flows without the gateway means the same thing. A parallel join gateway, also called AND-join or synchronizing join, means all of the incoming sequence flows must arrive at the gateway before the flow continues. Unlike the parallel split, it is not redundant, but required to merge parallel flows. E E D F D F G G Figure 5. Parallel split gateway (left) is redundant, since uncontrolled flow (right) means the same thing. A complex gateway, with a * symbol inside, indicates flow control behavior beyond those achievable with the other gateway types. A use case for complex decision is where the set of multiple outgoing sequence flows is determined by a logical condition. It has somewhat more utility as a merge gateway. One use case is the voting pattern, where N out of M paths must arrive at the gateway (perhaps with a particular data value, such as a Yes vote) in order for the flow to continue. The second is the discriminator pattern, where the first path to arrive at the gateway is passed through and the others discarded. In all of these gateway types, the logic conditions describing the semantics may be specified in a BPMN attribute of the gateway. In fact, the BPMN spec says the attribute MUST be provided, but this requirement is often ignored in actual tools, with good reason. Simple labels applied to the sequence flows are more user-meaningful in the diagram, and BPMN tools that provide executable artifacts typically provide their own dialogs for defining the execution semantics, outside of BPMN. Events Events, circles indicating something has happened, are what makes BPMN different from conventional process modeling notations. BPMN distinguishes start, intermediate, and end events by their border style. Start events, drawn with a thin border, indicate the start of a process or subprocess. Multiple start events are allowed in BPMN, but the semantics are ambiguous and the spec discourages use of that pattern. End events, drawn with a thick border, indicate the end of a path in a process or subprocess. All enabled paths of a process or subprocess must reach an end event for the process or subprocess to complete normally. In other words, there is an implicit OR-join of all end events. Multiple end events in a process or subprocess are commonly seen. They simplify the drawing, differentiation of successful and failed end states, and allow some end states to throw events and others not to do so. Bruce Silver Associates 2007 4

BPMN Mastering the Notation Figure 6. Message event in sequence flow means either send the message or wait for the message. In BPMN 1.1, throwing and catching icons are different. Intermediate events, drawn with a double border, occur after a process starts but before it ends. Their semantics depend on their placement in the diagram. When drawn in sequence flow, i.e., with sequence flow both into and out of the event, an intermediate event can mean either throw the event signal or wait to catch an event signal, depending on the icon inside. When drawn attached to the boundary of an activity, it means if the event occurs, interrupt the activity and continue on the sequence flow out of the event, called the exception flow. Attached events are only active while the activity they are attached to are active. Events arriving earlier or later are ignored. Thus if an activity with an attached event completes before the event occurs, the sequence flow directly out of the activity, called the normal flow, is taken. If the attached event occurs, the exception flow is taken. Normal flow Exception flow Figure 7. Attached event means if the event occurs, interrupt the activity and proceed on exception flow. If activity completes before the event occurs, take the normal flow. The specific signal, or event type, is indicated by an icon inside the circle. BPMN defines many types, but only a small subset is commonly used. A timer event is indicated with a clock icon. Timer start means start the process on a prescribed schedule. Timer intermediate in sequence flow means wait for a specified duration, or wait until a specified date/time. Attached timer event means interrupt the activity if it has not completed by a specified duration (after the activity starts) or a specified date/time. Message event is indicated with an envelope symbol. In BPMN a message event means any signal to or from outside the process. Message start means the process is triggered by receipt of a message. Message end means the process sends a message signal when the end event is reached. Message intermediate event in sequence flow can mean either the process sends the message signal or pauses and waits for the message signal, exactly the same as send and receive tasks. The ambiguity of the symbol is removed in BPMN 1.1, which shows throwing event icons as black with white lines and catching events as white with black lines. A message signal can only be thrown to a target outside the process; it may not be caught by a message event within the same BPMN process. Bruce Silver Associates 2007 5

BPMN Mastering the Notation Scheduled or recurrent start Wait for [duration], Wait until [date/time] Exception flow on timeout Start triggered by external event or another process Wait for external event or signal from another process Exception flow on external event or signal from another process Figure 8. Most commonly used timer and message event patterns. Attached message event means if the message signal occurs while the activity it is attached to is active, interrupt the activity and proceed on the exception flow. In this way, the activity explicitly defines the context for the event. Process modelers may even wrap a fragment of the process in a subprocess activity solely for the purpose of defining that event context. For example, if in an order handling process having steps A to Z, the customer may cancel or change the order between steps B and G with a particular handling flow, the modeler may draw a subprocess enclosing the portion from B to G and attach a message event to it. Order cancellation or change downstream, having a different consequence and handling flow, could have other message events placed there. In this way, attached message events provide a business-friendly notation for explicitly indicating both the scope and handling of external events. An error event, drawn with a sine wave icon inside, indicates an error condition in the process. An error end event means the process throws the signal when it reaches the end event. An explicitly thrown error signal is meant to be caught by an error event attached to a subprocess enclosing the error end event. (For this reason, there is no error start event.) It is also common to see an attached error event where no throwing error end event is drawn. This implicit throw usually indicates a system fault in the activity. A none event, drawn with no symbol inside, is by far the most common. A none start event means the trigger is unspecified. A diagram with multiple none start events is ambiguous. Does this mean all of the none starts are simultaneously enabled, or not? It should be avoided. In a subprocess, you always use a none start, since the trigger is the sequence flow into the subprocess. None end events simply mean no signal is thrown when the end event is reached. They are very common. A none intermediate event in sequence flow indicates a named state or milestone in the process. It is rarely seen, but actually mirrors similar semantics in other modeling notations. An attached none event is not allowed. There are other event types, which will be described in part 4 of this series, but these are the important ones to know. Pools and Choreography So far we have been discussing what BPMN calls orchestration, i.e., one entity s side of what might be a multi-party process linking, say, a buyer to one or more sellers and middlemen. An orchestration has a well-defined beginning and end and describes the sequence of steps within it as if there were some engine that has visibility and control over Bruce Silver Associates 2007 6

BPMN Mastering the Notation it. That control does not extend to the external entities, however. Interactions between the orchestration and the other parties to the global process must be expressed as signals, often requests and responses, which BPMN calls messages. BPMN has a way to represent the message exchange patterns linking orchestrations, which it calls choreography, using a dotted line arrow called a message flow. The business process diagram requires there for a container for each orchestration, called a pool. If there is no need to show choreography in the diagram and there is only one process, often the pool is implicit, not drawn. Customer Issue Travel Request Approve Travel Request Send Itinerary Select Booking Option Book Selection Receive Confirmation Itinerary Booking Options Booking Request Confirmation Travel Agency Receive Itinerary Propose Options Receive Booking Request Confirm Travel Bill Customer Figure 9. Orchestration is shown within a single pool. Message flows between pools indicate the choreography. Message flows can only be drawn between pools, not within a pool. Choreography mostly provides business context in BPMN models, not executable semantics. (The executable semantics in the orchestration is shown by the message events or send and receive tasks that generate and act on message events.) In many diagrams, choreography is not shown at all. Also, there is considerable evidence that OMG is significantly modifying the choreography notation of BPMN. However, some tools do make use of message flows to model executable semantics, such as partnerlinks in BPEL. Lanes and Artifacts The rest of the BPMN notation represents second-class elements, things that give diagrams business-meaningful context but have no precisely defined semantics, validation rules, or mapping to executable implementation. This is surprising to many people. What about swimlanes? Data flow? Both second class, in the sense that each tool vendor defines its own usage of these concepts. Lanes are subdivisions of a pool, typically representing organizational boundaries or human task roles. Technically they can mean whatever you want them to mean, and BPMN has no rules about what can or cannot cross a lane boundary. Data objects are a type of BPMN artifact, meaning having no standardized semantics. A data object can represent a business object, a document, or anything else for that matter. It can be linked to a sequence flow (or message flow) by a dotted line called an association, and data flow to or from activities can be shown by associations drawn with arrowheads. But the data flow has no defined control over the orchestration. Bruce Silver Associates 2007 7

BPMN Mastering the Notation Annotations are text comments in the diagram, linked to elements via association. A group is a dotted line box enclosing any part of the diagram; it has no defined semantics whatsoever. And that s all of BPMN! Next time we ll look at the art of modeling with BPMN, including some methodology and best practices. Bruce Silver Bruce Silver Associates 2007 8

Bruce Silver Associates Independent Expertise in BPM BPMN and the Business Process Expert, Part 3: The Art of Process Modeling Summary: BPMN s diagram semantics are expressive and precise, but the spec doesn t tell you everything you need to know to create effective models. Here we go beyond the spec with nine tips for making your process diagram say exactly what you mean. Third of six parts. Author: Bruce Silver Company: Bruce Silver Associates Created on: 19 November 2007 Author Bio Dr Bruce Silver is an independent industry analyst and consultant focused on business process management software. He provides training on process modeling with BPMN through BPMessentials.com, the BPM Institute, and Gartner conferences, and is the author of The BPMS Report series of product evaluations available from the BPM Institute. In the first two installments of this series, we saw why BPMN is important to the Business Process Expert and got an overview of the notation. In this part, we ll look beyond the spec to suggest some best practices for making your BPMN models most effective. The art of effective process modeling depends on what you are trying to do. Unlike traditional notations, which presuppose a particular methodology, BPMN is methodologyneutral, and can be used for multiple purposes. The first, which I call Level 1, is simply qualitative description, a diagram of the as-is (or proposed to-be) business process that stakeholders can gather around, discuss, and improve. Level 1 models may ignore exceptions and show only the happy path, and may not include every step, just those significant for discussion and qualitative analysis. The second, which I call Level 2, describes all the activities and flows in the process, including exceptions, and pays particular attention to their sequential and concurrent relationships. The goal of Level 2 modeling is a complete business-intelligible description of the process sufficient for quantitative analysis. Level 2 models contain all the detail required for accurate simulation, but are not by themselves executable. Level 2 modeling is still a business or BPX function. It does not require technical knowledge of the implementation of each activity, essentially just the activity s name, performer, and possible exceptions. The rules embodied in the BPMN spec mostly apply to modeling at Level 2. Level 3 modeling refers to using BPMN in executable process design, typically in a BPM Suite. It is similar to Level 2 modeling, but most tools that leverage BPMN as part of their executable design environment diverge here and there from the spec, since not everything that can be drawn in BPMN may be executable on the BPMS s process engine, and even Bruce Silver Associates BPMS Watch www.brsilver.com/wordpress BPMN Training www.bpmessentials.com/ 500 Bear Valley Road, Aptos CA 95003 Tel: 831.685.8803 Fax: 831.603.3424 E-mail: bruce@brsilver.com

BPMN The Art of Process Modeling when the engine can implement the BPMN semantics, the executable design may not describe it in accordance with BPMN. Thus BPMN at Level 3 is, today at least, vendorspecific in its details. So in this article, when I talk about the art of effective process modeling, I really mean at Level 2. Here are nine best practices to get you going. 1. Make the important information visible in the diagram. Label everything. BPMN is primarily a diagramming notation, but it also provides attributes for each diagram element. Many of these attributes are not displayed in the diagram itself, but are really placeholders for detail needed for technical implementation or simulation analysis. Even if modeling at Level 2 or 3, all of the important features of the process should be described, at least qualitatively, in the diagram itself. Shared understanding is always goal number one, and typically that comes from stakeholders gathered around a table looking at a printed version of the diagram. They are not accessing the diagram through a modeling tool, which shows the attributes in property sheets, and they are not reading through 200 pages of documentation generated by the modeling tool. They are looking at a printed diagram, so if a key bit of detail is not shown there, it may as well not be in the model. As a practical matter, this rule translates to label everything not just activities but subprocesses, gateways, events, and sequence flows. All of these have a Name attribute that corresponds to the object s label in the diagram. The BPMN spec never requires these objects to have labels, but does require, for instance, population of non-diagram attributes like gateway conditional expressions, message references, and error codes. Whether you choose to comply with those spec requirements or not, best practice is to create labels for gateway outputs that suggest, in business-intelligible terms, the meaning of each path. Unlike non-printing attributes, labels clarify in the diagram the meaning of a message event, the timeout of a timer event, or the source of an error. 2. Make your diagrams valid. BPMN has rules; learn to follow them. A process modeling tool is not the same as a drawing tool. You can download free BPMN stencils for Visio, but they don t bring with them the underlying semantics and rules of BPMN, so you can create invalid diagrams and never know it. A true modeling tool has a function called Validate, and if your diagram contains spec violations it will list them for you. Sure, a few of the rules in the spec may be arbitrary or even misguided such as requiring non-printing attributes but not labels, as discussed above but most of them merely enforce the semantic precision that is the key to linking business-intelligible diagrams to executable implementation. A model is not a doodle. It has rules, so follow them. 3. Make your diagrams hierarchical, using subprocesses. This is admittedly a personal bias, to which some others do not subscribe. When the as-is process is first captured by putting stickies on the wall, what you have is a flat process model, with all the detail at one process level. Of course, you can t take it in all at once, but instead have to walk around the room looking at one fragment at a time. Some people build their BPMN models this way, too, but it seems counter to the whole notion of BPM as a management discipline, which advocates looking at processes end-to-end. In traditionally Bruce Silver Associates 2007 2

BPMN The Art of Process Modeling stovepiped organizations, BPM is a reaction to the problem of not seeing the forest for the trees, and flat BPMN models that do not provide an end-to-end view are not a good answer. Instead, you should be able to model the end-to-end process on one page using coarsegrained-subprocesses, and drill down into each subprocess on a separate page of the diagram. Because it can render a subprocess either as a collapsed activity shape or expanded into its detailed flow and repeat that drilldown as many levels as necessary BPMN allows process description at multiple levels of detail, accessed by zooming in and out in the tool, without losing the integrity of a single end-to-end process model. 4. Use tasks to represent work. Label them VERB-NOUN. In BPMN, a task represents work done in the process, an action. It is not a function, not a state, and not a handoff to other participants in the same process. The state of a task (started or completed) and the sequential flow of work are implicit in the notation itself; you don t need to add tasks for them. In fact, it is incorrect to do so. Nevertheless, from beginners in BPMN you may see task sequences like this: Budget review Wait for budget document Budget document received Review budget document Budget review completed Send to manager review Instead, the correct sequence should be this: Review budget document, or if the budget document is received from outside the process instead of from a prior step, maybe this: Receive budget document Review budget document In BPMN, a message event (or, equivalent, a Receive task) inherently means wait for the event and then continue. A User task is inherently enabled to start when its incoming sequence flow reaches it, and the sequence flow out of it means that the task is completed. So diagrams should not insert tasks to signify those states, since they are implicit in the notion of sequence flow itself. 5. Reserve the verbs Send and Receive in task names (labels) for activities that either send a message or wait for (receive) a message. In BPMN, a message simply means a signal to or from an entity outside the process. The signal does not have to be a SOAP or JMS message. It could be a fax or a phone call. What is significant is that the fact that the signal means communication with an external entity. That entity could be the requester of the service that the process represents, such as a customer placing an order. Or it could represent an external service invoked by the process. Information passed by a task to another task downstream is not sending a message. In fact, the sequence flow by itself delivers process information to the task, so the upstream task doesn t have to send anything. Bruce Silver Associates 2007 3

BPMN The Art of Process Modeling BPMN defines special task types called Send and Receive used for inter-process communications. A Send task is the same as a throwing message event. Typically, it is not performed by a user but is assumed to be an automated activity that sends the message as soon as the sequence flow into it arrives. A Receive task is the same as a catching message event. It too is not performed by a user but is assumed to represent an event listener that pauses the flow until the event arrives, and then continues. 6. Use gateways to represent pure routing logic. Gateways do not perform work. They are not assigned to a resource such as a person or engine. They do not make decisions, but control the flow following a decision. However, it is not uncommon to see things like this: Invalid A Receive order Validate order OK B This is incorrect. Validating the order, whether performed by a person or a business rule engine, is work, and it requires a task in BPMN. A gateway following the decision task can then route the instance this way or that depending on the result. no A Receive order Validate order OK? yes B Also, sometimes you see complex decision logic, such as that used to validate an order, represented as a network of gateways in which each gateway represents a single rule in the decision. This is allowed in BPMN, but in general is not best practice, for several reasons. One, it is inherently procedural, whereas in the real decision the rules are often declarative. Two, it embeds the internal decision logic in the process, where it is best practice to externalize business rules so they can be maintained independently of process, particularly when the rules represent policies that cross process boundaries. And three, it makes the diagrams unnecessarily complex. Just use a single task to represent the decision, and follow it with a gateway to route the subsequent workflow. 7. Avoid multiple start events. The BPMN spec allows multiple start events in a process or subprocess, but recommends they be used sparingly and that the modeler be aware that other readers of the Diagram may have difficulty understanding the intent of the Diagram. I ll go further and say, just don t do it, since the semantics are, more often than not, inherently ambiguous. In the one case where the semantics are unambiguous, a single start event can be used to signify the same thing. You could see something like this in a process or subprocess: Bruce Silver Associates 2007 4

BPMN The Art of Process Modeling A B C Multiple None start events (no trigger symbol inside) means trigger all of the start events when the process is instantiated. But that s the same thing as a single None start with multiple sequence flows out of it, signifying parallel paths from the start. A B C Thus the multiple start events are not incorrect, just superfluous. Now what does this diagram mean? Call center A B Web C Usually the modeler s intent is that the process can be triggered one of two ways, such as through the call center or through the web. Some initial processing might be channeldependent, but all channels merge to a common downstream process. But is this the correct way to draw it? The BPMN spec says each start event is an independent event and generates a process instance. Thus you could argue that if the second event occurs after the first one, it generates a separate instance of the process, so the diagram above would be correct. But the spec also says that if a process requires two independent events to occur in order to start, you model this with two start events that flow to a common activity with a special merge attribute set. So in some cases, multiple start events mean the same instance and in other cases they mean different instances. That s bad spec-writing. Fortunately, BPMN 1.1 provides a less ambiguous solution to our modeler s use case: an event gateway used to bootstrap the process. (In BPMN 1.0, an event gateway could only be used in the middle of a process, not to instantiate it.) Call center A B Web C Bruce Silver Associates 2007 5

BPMN The Art of Process Modeling The event gateway means wait for one of the following events typically message events and take the sequence flow from the first one to occur. If another of the listed events occurs later, it triggers a new process instance unambiguously. Thus there is no good reason to ever use multiple start events. 8. Use multiple end events to classify end states. This might seem inconsistent with the previous recommendation, but it s really not. An end event does not by itself end a process or subprocess. If the process or subprocess contains parallel paths, all of them must reach an end event in order for it to complete. Thus there is an implicit AND-join of all end events in a process or subprocess. Even if there are no parallel paths, it is quite common to draw separate end events for each alternative path. On the other hand, you can draw sequence flows from each path in the diagram to a single end event, and there is nothing wrong with that, either. But it often clarifies the diagram to simply draw end events representing each possible end state of a process or subprocess, such as success or failure, and labeled accordingly. In a subprocess, particularly, where a gateway following the subprocess governs subsequent processing of the end-to-end process, this helps make the meaning of the diagram understood by all. yes Fulfill Notify error Success yes Approve no Notify not approved Validate Approved? OK? no Notify invalid Fail 9. Use subprocesses to scope events. This best practice will make more sense after the next article in this series, but it s so valuable it s worth repeating: An attached intermediate event timer, message, error whatever can only be detected by the process when the activity it is attached to is active. If the event occurs before the activity starts, or after it ends, BPMN says ignore it. If the event occurs while the activity is running, the BPMN says abort the activity and continue down the sequence flow out of the event, called the exception flow. The activity doesn t have to be a task. It can be a subprocess. In fact, it can be a subprocess created solely for the purpose of defining the fragment of the process where a particular event should result in a particular exception flow. Here s an example. Suppose you have an order handling process with steps A to Z and you want to indicate that between steps B and D the customer can change or cancel the order with no penalty, and between steps E and G a change or cancellation has a penalty, and after that any change or cancellation requires a completely new process. In BPMN this is easy to model. You simply enclose the sequence from B to D in a subprocess and attach a message event (external signal) to it with a no-penalty exception flow. You also enclose the sequence from E to G in another subprocess and attach a message event to it with a penalty exception Bruce Silver Associates 2007 6

BPMN The Art of Process Modeling flow. That s it! Don t tell me, as traditional BPA tool vendors often do, that BPMN events are too complicated for the Business Process Expert. A B C D Customer change or cancel No penalty handler For attached timer event, the activity that is attached to has additional significance. An attached timer event is typically used to specify deadline-triggered processing. Usually the deadline is specified not as a specific date/time but as a time interval after the activity starts. So it s the activity that determines when the clock starts and when it gets shut off. If in a process with steps A to Z you want to trigger some exception flow if step C is not completed within 2 hours after the process (i.e., step A) starts, you can simply enclose A through C in a subprocess and attach a timer event to it. Creating effective BPMN diagrams sometimes requires going beyond the spec. Learning how to harness the expressiveness of the notation is critical to shared understanding and business-it alignment. Bruce Silver Bruce Silver Associates 2007 7

Bruce Silver Associates Independent Expertise in BPM BPMN and the Business Process Expert, Part 4: Mastering BPMN Events Summary: The ability to describe event-triggered behavior directly in the diagram separates BPMN from traditional modeling notations. An event can start a process, resume a waiting process, or abort a process activity and redirect the flow. The BPMN spec describes many different event types, but learning just a few patterns is all you really need. Fourth of six parts. Author: Bruce Silver Company: Bruce Silver Associates Created on: 3 December 2007 Author Bio Dr Bruce Silver is an independent industry analyst and consultant focused on business process management software. He provides training on process modeling with BPMN through BPMessentials.com, the BPM Institute, and Gartner conferences, and is the author of The BPMS Report series of product evaluations available from the BPM Institute. If you had to name the one thing that sets BPMN apart from traditional process modeling notations, it would be events. That is to say BPMN provides a logically consistent notation for representing event-triggered behavior directly in the diagram. BPMN lets you show, for example, that a process is started by a particular event, or is waiting someplace for an event, or is redirected from its normal flow to a special event-triggered exception flow. BPMN also lets you show how one process interacts with other processes, both internal and external, via events, and even how one part of a process can signal to another part of the same process using events. This article will show you how to use events correctly and effectively. 1 In BPMN, an event is a signal that something happened. It is not assigned to a resource, and it does not perform work unless you consider sending and listening for signals work. In the notation, the event symbol always a circle does not represent the implementation of that signal, how it was generated or received, but rather the interaction of that signal with the process. Not all modeling tools that claim to be BPMN-based support events. While there is nothing in the BPMN spec that says a tool must support events, let s just say that tools that don t are leaving out the good stuff. 1 The notation for a few event types will change a bit in BPMN 1.1. Except for discussion of the Signal event, new in BPMN 1.1, the graphics in this article use the BPMN 1.0 notation. However, where the semantics of an event are clarified in BPMN 1.1, we use the newer interpretation. Bruce Silver Associates BPMS Watch www.brsilver.com/wordpress BPMN Training www.bpmessentials.com/ 500 Bear Valley Road, Aptos CA 95003 Tel: 831.685.8803 Fax: 831.603.3424 E-mail: bruce@brsilver.com

BPMN Mastering BPMN Events BPMN 1.0 defines a wide variety of event trigger types, distinguished by their icons, and if your BPMN tool is able to make the model executable, it is extremely unlikely to support every single one of them. That s not so bad, since there are actually only a few event types that you need 99% of the time, and these are the ones provided by most BPMN tools. Start Events A start event, a circle with a thin border, indicates the start of a process or subprocess. A none start event, with no symbol inside, means the trigger is unspecified. In a subprocess, none start is the only type of start event allowed, since the sequence flow in to the subprocess is, by default, always the trigger. In the main, or top-level, process, you will also frequently see message and timer start events. In BPMN, a signal received from outside the process is called a message, whether it s a SOAP message or a fax, phone call, or paper mail. A message start event indicates that the process is triggered by a particular message, identified by the label and/or the event s message attribute. A timer start event indicates that the process starts at a particular date and time or on a periodic date/time cycle. None, message, and timer are the only start event types supported by most tools. However, the spec defines a few more. A rule (renamed conditional in BPMN 1.1) start event means the process is triggered when a data expression (within the process) becomes true. Say you want to trigger a process whenever a new customer is added to the ERP system. Is that a rule event or a message? In most tools this would be a message, as the ERP system would be considered external to the process. In fact, rule start is inherently ambiguous because what does data within the process mean when the process hasn t started yet? But there it is. A multiple start event signifies that any of N events (of the types described above) will trigger the process. You rarely see this, but you do see the need for a related use case, where the process can be triggered in different ways and the initial processing depends on which trigger it was. (Downstream activities may be common.) In BPMN 1.0, most users would diagram it this way: Manual start Fill out claim form Validate claim Web service But this is ambiguous, since the none start is undefined. The BPMN spec says that if a process or subprocess has multiple start events, they are all enabled when the process or subprocess starts, and that is not the intent here. BPMN 1.1 provides a less ambiguous notation, using the event gateway. The event gateway uses the multiple event (actually an intermediate event, not start event) tucked inside a gateway diamond. Normally it means wait (within a started process) for one of N events, and take the path from the first event to occur, ignoring any others that occur Bruce Silver Associates 2007 2

BPMN Mastering BPMN Events subsequently. But how did the process get started in the first place? When it immediately follows a start event, the event gateway is said to bootstrap the process. So you can think of the combination of the start event and the event gateway as the multistart notation we are looking for. Notice that manual start has been recategorized as a message event. BPMN should really add a new trigger type for user-initiated processes, and allow it in event gateways, for this pattern to be consistent with the rest of BPMN. Manual start Fill out claim form Validate claim Web service In BPMN 1.1 there is also signal start. We ll talk about signal later on. End Event An end event, a circle with a thick border, denotes the end of a branch of a process or subprocess. A process or subprocess with parallel paths must allow all parallel paths to reach an end event in order to complete. While it is recommended to use a single start event in a process or subprocess, use of multiple end events is often best practice. Each separate end event can carry a label to indicate the end state (e.g., success or failure) of the process or subprocess. Also, some end events may throw an event signal, called a result, either to an external system or process or to another part of the same process, depending on the event type. A none end event simply ends the process path without throwing the result signal. A message end event throws a result signal to an external process, service, or system. It can be used for any purpose, to return data or simply to indicate completion. An error end event sends an error signal to another part of the same process, specifically an Error intermediate event attached to the subprocess containing the Error end event. The Error event that catches the thrown error signal will abort the subprocess immediately, even if parallel paths in the process or subprocess have not yet reached their end event. Terminate is a very useful end event. It does not throw a result signal but immediately ends the subprocess that contains it, without waiting for parallel paths to complete. As we shall see, you can use it to implement the equivalent of a non-aborting attached event. These are the common ones. There is also multiple end, meaning multiple result signals will be thrown; cancel and compensate, used for business transaction recovery, to be discussed in Part 5 of this series; and signal, discussed later on. Bruce Silver Associates 2007 3

BPMN Mastering BPMN Events Intermediate Event in Sequence Flow Intermediate events are the cool part of BPMN. Drawn with a double border, they signify events that occur after the process has started but before it has ended. Depending on the trigger type and where it is drawn in the diagram, an intermediate event can mean either pause and wait for the signal, then continue; immediately send the signal and continue; or immediately abort a running activity and redirect processing to an exception flow. An intermediate event drawn with sequence flow in and out (called in sequence flow or in normal flow) can mean, depending on the trigger type, either wait for the event or throw the event. Some trigger types, like message, multiple, and signal, can do both, so in BPMN 1.1 the throwing variant is drawn with the icon filled and the catching variant is drawn unfilled. In BPMN 1.0 they both are drawn unfilled, so best practice is to standardize its use only for one of those meanings and use a Send or Receive task for the other. A Send task is exactly the same as a message intermediate event (throwing) in sequence flow. A Receive task is exactly the same as a message intermediate event (catching) in sequence flow. A timer event in sequence flow means a delay, either wait for a specified duration or wait until a specified date/time. A catching message event in sequence flow means wait for a signal from outside the process, then resume. Remember, in BPMN a message really means any kind of signal from outside, even a phone call or web interaction. The key is that it comes from outside the process. These are the common ones in sequence flow. The spec also defines a rule (conditional) event, meaning wait for some process data expression to become true; multiple event, meaning wait for any of N events to occur; and signal, both throwing and catching, discussed later. A none intermediate event in sequence flow, while rarely used, has a valuable use case. It simply represents a state of the process; there is no signal sent or received. Such states are common in other modeling notations, and the none intermediate event could be used to translate them to BPMN. The link event is like a goto on the diagram, typically used to connect parts of a single process spread across multiple pages. A link event drawn on one page with a sequence flow in but none out is logically connected to a paired link event on another page drawn with no sequence flow in but a sequence flow out. It s just an off-page connector. Attached Intermediate Event An intermediate event drawn attached to the boundary of a process activity (attached event) means something completely different from the same intermediate event drawn in sequence flow. An attached event always means if the trigger occurs, abort the activity the event is attached to, and proceed down the sequence flow coming out of the event, called the exception flow. If the activity completes without the trigger occurring, take the sequence flow directly out of the activity, called the normal flow. Bruce Silver Associates 2007 4

BPMN Mastering BPMN Events The activity defines the scope of the event. If the trigger signal occurs before the activity starts or after it ends, it is ignored. Thus, it is common to wrap a sequence of tasks within a subprocess activity solely for the purpose of defining that scope. For example, if in an order handling process having steps A to F, you allow the customer to cancel or change the order between steps B and D with a particular handling flow, you can draw a subprocess enclosing the portion from B to D and attach a message event to it. Order cancellation or change downstream, having a different consequence and handling flow, could have other message events placed there. A B C D Customer cancel Cancel Handler In this way, attached events provide a business-friendly notation for explicitly indicating both the scope and handling of events, be they external (message events), timeouts (timer events), system faults (error events), etc. In BPMN, the exception flow is allowed to go anywhere (within its enclosing subprocess, if any). It can go to a handler task, or loop back to the activity and restart it, or jump to an end event. New Signal Event Certain event types, like message, error, compensate, and cancel, support both throwing and catching, so both the source of a signal and the triggered behavior can be shown within the same business process diagram. But each of these types is limited in its use. A message event can only be used to signal across a process (pool) boundary; it cannot be used to signal from one subprocess to another within the same pool. Also, a message signal technically is addressed to a specific target, such as a message queue, rather than broadcast in publish/subscribe manner. An error event can only be used to signal within a single process (pool). It can be broadcast, but you cannot have an error intermediate event in sequence flow, so you cannot use error event to wait for a signal. Also, fundamentally, it suggests an error condition has occurred. Compensate and cancel are specific to transaction recovery; we ll cover them in part 5. BPMN 1.1 addresses the need for a more general purpose signaling mechanism with the new signal event. It can be broadcast to multiple catchers, in pub-sub style. It can work either within a pool or across pool boundaries. It can be used as a start event, throwing or catching intermediate event in sequence flow, attached intermediate event, or end event. It does not necessarily imply an error condition. Signal can do it all. Bruce Silver Associates 2007 5

BPMN Mastering BPMN Events An important use case for the signal event is, from the middle of one activity triggering the start of a second parallel activity within the same process. BPMN has a hard time doing anything from the middle of an activity, since sequence flow presupposes that the activity is done. Consider the diagram above, from the BPMN 1.1 spec. It illustrates what the BPM academics call the milestone pattern. Two parallel activities follow A. One has parts B and C, and the other is just D. You want to say D can start once B is done. If the subprocess boundary didn t exist, you could just draw a sequence flows from A and B to an AND-join preceding D. But the subprocess boundary does exist, for many possible reasons event scoping, service reuse, ownership and governance. It s a given, and you can t cross subprocess boundaries with a sequence flow. But you can with a signal event. A throwing signal event following B links to a catching signal event in sequence flow (wait-for) before D. Another use case might be an exception process triggered by a variety of errors in the diagram. This should be drawn in a separate pool. Exceptions thrown by signal end events (or throwing intermediate events) can be caught by a signal start event triggering the exception process. Because of the pub-sub linking, the thrower is loosely coupled to the catching process. Signal events will add a powerful new dimension to event-triggered behavior once BPMN 1.1-compliant tools emerge. Non-Aborting Attached Events One limitation of attached events in BPMN is they always abort the activity. It would be nice to have a variant that preserves the scoping and triggered exception flow behavior without aborting the original activity. Some BPM Suites, like TIBCO and Lombardi, offer this, but the BPMN spec does not sanction it. Perhaps a future version of BPMN will support it directly in the attached event notation, but as it stands currently, non-aborting attached events takes a workaround using Terminate and Signal events. Consider activity A with an attached event E, as drawn above. In standard BPMN, if A completes without the E signal occurring, the task Next normal starts. If E occurs before A completes, Exception task starts. Exception task and Next normal are exclusive alternatives. Bruce Silver Associates 2007 6

BPMN Mastering BPMN Events But suppose you wanted a non-aborting version of this, i.e., if E occurs while A is incomplete, trigger Exception task but don t abort A. Let it continue, and when it completes go to Next normal. For example, maybe Exception task is just a notification. Thus the normal flow and exception flow are parallel threads of this process or subprocess. One way to do it uses the Terminate end event in combination with Signal. Instead of attaching E to the boundary of A, wrap A in a subprocess A, and make E an intermediate event in a sequence flow in parallel with A, as in the diagram below. Now E is a wait-for event, not an attached event, and the sequence flow out of E leads to a Signal end event. The Signal informs any paired listening events that the event E has occurred. Note that if A finishes before E occurs, the Terminate ends A and the Signal event is never thrown. But if E occurs before A is done, the Signal event is thrown. A does not complete until A is done, but the Signal is thrown before that. In parallel with A, there is a paired wait-for Signal event, listening for the signal that the event E has occurred. If this occurs, Exception task runs in parallel with A, and both the normal flow out of A and the exception flow are enabled in parallel. This is just what we want. Merging of the normal and exception flows downstream in a join is tricky, since if E does not occur, the join cannot complete, since one input is still waiting at the Signal event. The solution is to let the normal flow downstream from Next Normal end in another Terminate event, which avoids the deadlock. A E E occurred Next Normal A E occurred Exception Task Getting Started: Focus on Basic Patterns The variety of BPMN events can seem overwhelming when you get started, but in practice you can do most of what you need with just message and timer events. The important thing is to understand the differences between each of the basic patterns. Use the cheat sheet below, and you re on your way to becoming an BPMN event expert. Bruce Silver Associates 2007 7

BPMN Mastering BPMN Events Bruce Silver Bruce Silver Associates 2007 8

Bruce Silver Associates Independent Expertise in BPM BPMN and the Business Process Expert, Part 5: Handling Errors and Business Exceptions Summary: If 80% of the cost and problems with business processes comes from 20% of the instances the exceptions shouldn t business have a role in specifying exception handling? BPMN supports that view. Here we ll learn the diagram patterns to use in the most common exception-handling scenarios. Fifth of six parts. Author: Bruce Silver Company: Bruce Silver Associates Created on: 17 December 2007 Author Bio Dr Bruce Silver is an independent industry analyst and consultant focused on business process management software. He provides training on process modeling with BPMN through BPMessentials.com, the BPM Institute, and Gartner conferences, and is the author of The BPMS Report series of product evaluations available from the BPM Institute. When you begin modeling your process, it is customary to begin with the happy path, the activity flows appropriate when nothing goes wrong. But things often do go wrong, in a wide variety of ways. Some problems are technical a step returns an error code rather than a business result. Others reflect business exceptions, such as the inability to complete the process without additional information. BPMN stands out from traditional modeling notations in its explicit support for exception handling in the diagram. As always, the key to effective modeling is making the diagram as clear and expressive as possible. In this part, we ll focus on specific diagram patterns to use for modeling the most common types of exceptions. One way to categorize exceptions is by their source. Is the exception detected internally by process logic, or is it a signal received from outside the process? Another way is to distinguish business exceptions from system faults. A system fault means that a model activity cannot provide a business result because of some technical problem an error code is returned by the implementation, or a communications link is down. A business exception means that the model activity can complete successfully but returns a bad business result an item is out of stock, or requested information does not arrive in time, or the customer cancels the order. These categories business exception or system fault, internally detected or externally signaled provide a useful framework for selecting diagram patterns and building a base of common understanding shared by all in your organization. These patterns are not mandated by the BPMN spec, but should be considered best practice usage of the notation. Bruce Silver Associates BPMS Watch www.brsilver.com/wordpress BPMN Training www.bpmessentials.com/ 500 Bear Valley Road, Aptos CA 95003 Tel: 831.685.8803 Fax: 831.603.3424 E-mail: bruce@brsilver.com

BPMN Handling Errors and Business Exceptions Other important considerations in modeling exception handling are when the exception can be detected, and what should happen when it is. For exceptions detected internally to the process, the when is usually understood to be an end state of a particular activity. However, exceptions signaled from outside could occur when the process is in any number of states, so it is important to think about what the proper response to that signal should be whenever it could occur. Internal Business Exception Pattern Many BPMN beginners instinctively associate exception handling with events. But by far the most common exception-handling pattern doesn t use events at all, just a basic gateway. That is the internal business exception pattern, meaning the exception is detected internally by logic in a process activity that completes normally but with a bad business result. In that case, simply follow that activity with a gateway that tests the business result. One branch out of the gateway leads to the happy path, and the other branch leads to the exception path. Do Something yes Normal path OK? no Exception path BPMN places almost no restrictions on where the exception path can go. It can lead directly to an end event, or loop back to the activity preceding the gateway, or somewhere else. One significant restriction is if the exception is enclosed in a subprocess, the exception path cannot cross the subprocess boundary. For example, the following diagram, intended to terminate the top-level process based on a business exception in a subprocess, is illegal in BPMN: First subprocess Next subprocess Do Something yes Normal path OK? Handle exception Instead you need to end the exception path inside the subprocess, and if necessary insert another gateway after the subprocess to end the parent process. While the second gateway may seem redundant, it allows the diagram to remain valid whether the subprocess is collapsed or expanded. Bruce Silver Associates 2007 2

BPMN Handling Errors and Business Exceptions First subprocess Do Something OK? yes Normal path yes Next subprocess Handle exception OK? no Timeout Exception Pattern A second common exception is when a process activity is not completed by a particular date and time or by some specified duration after it starts. For that, use the timeout exception pattern based on an attached timer event. In an attached timer event, the clock starts when the activity it is attached to is first enabled. If the activity completes before that duration expires, the normal flow out of the activity is enabled. If not, the activity is aborted and the exception flow out of the timer event is enabled. A B C 30 min Handle timeout You can use subprocesses to specify when the timer starts and stops. For example, the diagram above says that if activity C is not completed within 30 minutes of the start of activity B, the exception flow is triggered. System Fault Pattern A system fault means the process activity cannot complete successfully because of a technical problem. It is not the same as completing with a bad business result. For example, a database query that returns no matching records is a business exception. A database query that cannot be executed because of bad SQL syntax or because the server is down would be a system fault. Typically system faults are exceptions on automated activities, or in BPMN parlance, service tasks. An error intermediate event attached to a service task indicates the system fault pattern. It signifies that the task could not complete successfully. If the task completed successfully but returned a bad business result, best practice would be to call that a business exception, but many modelers would use an attached error event for that as well. Request a service Next step Service unavailableservice fault Handle service fault Handle service unavailable Bruce Silver Associates 2007 3

BPMN Handling Errors and Business Exceptions In BPMN each fault is specified by an ErrorCode attribute, so there may be more than one, each with its own exception flow. Business Exception Throw-Catch Pattern An error event can also be used to handle business exceptions when the simple internal business exception pattern described earlier is insufficient. Typically that occurs when the detected business exception in a subprocess needs to end a parallel thread of the subprocess before beginning the exception flow. In that case, an error end event in the subprocess can throw the error result signal that is caught by an error intermediate event attached to the subprocess boundary. In this business exception throw-catch pattern, paired events are linked by a common ErrorCode attribute. Subprocess Something else in parallel Do Something yes Normal path OK? Some error handling Throw error Catch error More error handling For example, here an internal business exception in the task Do Something is handled with the simple internal business exception pattern described earlier. Following the gateway there is some error handling and that path ends. The exception path out of the gateway doesn t end in a None end event but in an error end event. That is because there is a concurrent path as well, here labeled Something Else in Parallel. For this error, we want to abort that activity and then do more error handling. The thrown error signal is caught by the event labeled Catch Error on the subprocess boundary. Like all attached events, it aborts the activity the entire subprocess and then triggers the exception flow. Thus an error event attached to a subprocess may have one or more error end events in the expanded view of the subprocess that specify where the error signal is thrown. Unsolicited External Business Exception Pattern So far all the exceptions have been internal to the process. What about external business exceptions, such as an order change or cancellation? The unsolicited external business exception pattern uses an attached message event, which catches the signal from the external entity. If the exception signal occurs while the activity it is attached to is running, the activity is aborted and processing continues on the exception flow. As with timeouts, subprocesses are essential for scoping these events. Think about the earliest point in the process, and also the latest, where the external exception is handled in a particular way. Now you can enclose that fragment in a subprocess, attach the message event to it, and use the exception flow to lead to that handler. For example, in the diagram below a customer can cancel the order after B has started but before C has ended. Bruce Silver Associates 2007 4

BPMN Handling Errors and Business Exceptions A B C Customer cancel Handle cancel Solicited Response Exception Pattern The preceding pattern is used to respond to unsolicited external events. But what about exception responses solicited from external entities? Typically for these you would use an event gateway, since you are waiting for the event, not aborting on the event. A common scenario is a request for additional information, or perhaps a service request. An event gateway pauses the process to wait for a response. The normal response on one gate represents the happy path. An exception response, such as item out of stock, could be placed on another gate to define the exception path. No response at all within a specified timeout interval would be modeled as a timer event on a third gate. It could lead to a separate exception path or one shared with the exception response, as shown below. Normal response Normal path Service request Exception response Exception path No response Transaction Compensation BPMN goes beyond these basic exception handling patterns to model business transaction recovery through compensation. A business transaction is a set of activities that must complete atomically, meaning either all activities in the set are performed successfully or the state of the system must be restored as if none of them were. Unlike classic ACID transaction protocols like two-phase commit, business transactions are inherently long running, so their resources cannot be locked for the duration of the transaction. Instead, each activity in the business transaction is executed normally, but if any part of the transaction fails to complete, those activities already completed are undone by executing a compensating activity. For example, the compensating activity for a debit charge would be a credit for the same amount. BPMN provides a way to specify all of this in the diagram. Actually, it specifies two alternative ways. We ll talk about one of them. A subprocess in BPMN can be specified as transactional, in which case the rounded rectangle is drawn with a double border. That signifies that if the entire subprocess does not complete successfully, it must be compensated to restore a consistent state of all participating resources. Any activity participating in the transaction that needs to be undone if the transaction fails can be linked to its compensating activity via a compensation intermediate event, drawn with a rewind icon inside. Bruce Silver Associates 2007 5

BPMN Handling Errors and Business Exceptions A UndoA The compensation event is unlike all other attached events. For one thing, it has no sequence flow out, but only an association to the compensating activity, also marked with a rewind icon. For another, the event is only effective if the activity it is attached to has already completed successfully. (Regular attached events are only effective if the activities they are attached to are still running.) The sole purpose of the attached compensation event is to link an activity with its compensating activity. A cancel event, drawn with an X icon, attached to the border of a transactional subprocess, is a special type of error event. Like a regular error event, it aborts the subprocess when triggered, but before starting on the exception flow it implicitly commands compensation of the transaction. That means that all activities in the transactional subprocess that have completed and have defined compensating activities should execute those compensating activities to restore a consistent state of all the resources. Once compensation is done, the exception flow proceeds. As with the regular error event, throw of the cancel signal can optionally be shown explicitly by a cancel end event inside the transactional subprocess. In the above example from the BPMN spec, the transactional subprocess labeled Bookings contains concurrent activities Book Flight and Book Hotel. If either one of them fails, the error (here thrown implicitly as in our system fault pattern) is caught by the cancel event. If Book Hotel fails after Book Flight has completed, invoking compensation executes Cancel Flight to restore a consistent state. Any other event type attached to the subprocess, like the regular error event here labeled Hazards, aborts the transaction without invoking compensation. Bruce Silver Associates 2007 6

BPMN Handling Errors and Business Exceptions Transaction compensation is a neat solution to modeling transaction recovery explicitly in the diagram. Unfortunately, few if any BPMN-based execution environments today provide direct implementation. Bruce Silver Bruce Silver Associates 2007 7