Archive for November 28th, 2007
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.
For text of the article, go to https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/70c51475-3b7b-2a10-248c-f4cc7b4dc52c
November 28th, 2007
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.
For the text of the article, go to https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/309737c3-3e75-2a10-7097-833d068f2858
November 28th, 2007
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.
For the text of this article, go to https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/10852310-ac6a-2a10-02be-d83f4d2dd647
November 28th, 2007
[Posted 27 Nov 2007 on BPMInstitute.org]
In the early days of BPM – four or five years ago – everyone thought BPEL was the BPM standard, at least for runtime execution. Not long after, the importance of business-friendly process modeling came to the fore, and BPMN emerged as the standard for that. The mismatch between graph-oriented BPMN models, where you can route the flow just about anywhere, and block-oriented BPEL, where you can’t, didn’t seem to worry BPM vendors. After all, a model was just a model, a business requirements document in diagrammatic form. The BPEL designer would use the BPMN as business input to the implementation and go from there.
Then a new concept emerged, the BPM Suite, which included process modeling, executable implementation, and BAM in an integrated toolset that promised the improved business-IT alignment and agility needed to cope with ever-changing business requirements. Suddenly the process model became more than a business requirements spec. It was actually the first phase of the process implementation. No problem, said the BPEL vendors. We’ll just generate skeleton BPEL from the process model, and use that as the starting point for the BPEL designer. Voila! Business empowerment! Business-IT alignment!
But this notion of the interface between process modeling and implementation design as a one-way handoff was flawed from the start. One problem was on the modeling tool side. Exporting the model to block-oriented BPEL imposed new constraints on the diagram. A model perfectly valid according to the BPMN spec suddenly gave validation errors when you tried to generate and export BPEL. Another problem was on the BPEL side. Once the BPEL design was fleshed out, it inevitably began to diverge from the initial BPMN diagram, so business analysts lost touch with the implementation shortly after the handoff. So much for business empowerment!
We had what became known as the roundtripping problem. A process model created in BPMN or comparable flowcharting notation could not be easily kept in sync with the executable BPEL design throughout the implementation lifecycle. Essentially, you couldn’t update the process model from the BPEL. Once the toothpaste was out of the tube, you weren’t going to get it back in. So the model was not a continuous business view of the implementation. In fact, it was still what it had always been – initial business requirements.
The roundtripping issue took some of the BPEL-based vendors by surprise. Coming to BPM from the integration side, they found the idea of business people coming anywhere near implementation design distasteful to begin with. But as it became clear that business empowerment is a key piece of the BPM value proposition after all, they began to acknowledge that BPMN-BPEL roundtripping was, well, a real problem.
Meanwhile, a host of smaller companies began to demonstrate success both with BPM buyers and industry analysts by ignoring BPEL altogether. Vendors like Lombardi, Appian, and Savvion, focused on human-centric processes more than integration, led the way with a new style of BPMS in which executable design is layered directly on top of the process model, in the form of implementation properties of BPMN activities. The new style does not create a handoff between different tools (with different flow models, data models, and programming models), but leverages a single tool shared by business and IT, with business focused on the activity flow and IT focused on making those activities executable.
In this new style of BPMS, there was no longer a roundtripping problem. If IT needed to change the activity flow, the modified process model was immediately visible to the business analyst. The tooling itself encouraged business-IT collaboration throughout the implementation cycle, and fit well in agile iterative methodologies that significantly shortened the cycle time from model to deployed solution. The advantages of business empowerment and increased agility easily overcame the disadvantage of a proprietary BPMS runtime, and in recent years this style has become favored by a majority of BPMS vendors. When large standards-oriented middleware vendors like BEA and TIBCO jumped into the BPM arena by buying BPMS pureplays, they didn’t go for BPEL. Instead they went for the shared modeling/design approach, in spite of the proprietary runtimes, and both are gradually migrating their tools toward full support of the BPMN standard.
So one answer to the roundtripping problem is to say that it no longer exists, but was an artifact of an earlier day, trying to apply BPEL where it doesn’t belong… in BPM! I think that argument has more than a grain of truth to it. But it’s not the whole story.
For the past year, I have been training users, both business and IT, on process modeling with BPMN. Naturally, I tend to see students whose companies have standardized on BPMN for process modeling. But they are not coming because they have just bought Lombardi, Savvion, or Appian. In fact, more often than not, if they have already made their BPM runtime decision, it is BPEL. It’s a standard, a commodity, available open source. It’s what IBM and Oracle use in their BPM runtime. So there are compelling factors in BPEL’s favor. But standardizing on both BPMN and BPEL? No, of course it’s not logical. Usually those decisions were made independently by separate groups in the company, completely unaware of the other’s issues. But the decisions were made, and if BPM is going to move forward in those companies, we need to deal with it.
Having been in the roundtripping-is-dead camp for about a year, I now find myself having to confront this issue once again. In my BPMN training, for example, students want to know what strategies or patterns should they use in their BPMN diagrams that will fit well with their expected BPEL implementations. It’s not something I expected to think about when I started.
In the BPMN specification, there is an attempt to describe simple BPEL mappings for many diagram patterns, but it has been long recognized that certain patterns cannot be mapped in the ways described in the BPMN spec. BPMN tools that validate for BPEL export based on these simple mappings tend to give users a lot of validation errors if the BPMN is not drawn in strict block-oriented fashion.
Attempts to create more sophisticated mappings have been few and far between. The best I have seen comes from Marlon Dumas and collaborators at Queensland University of Australia (see http://eprints.qut.edu.au/archive/00005266/) and from Yi Gao, CTO of the startup tool vendor eClarus (see http://www.eclarus.com/pdf/BPMN_BPEL_Mapping.pdf). They take different approaches, but agree on the general strategy, which is to identify the diagram fragments for which the BPEL mapping is straightforward, and transform or redraw the other fragments into semantically equivalent diagrams with straightforward mappings. Using this approach, the subset of BPMN diagrams that cannot be mapped to BPEL is actually quite small. In fact, a number of the problem patterns identified by Dumas are actually illegal in the BPMN spec. These techniques, however, have not been widely adopted to my knowledge by BPMN tool vendors. That’s issue number one.
Issue number two is more subtle, since the above-mentioned researchers start from the objective of creating “readable” BPEL from the BPMN, based on the assumption that process implementers still need to edit the generated BPEL. In my view, that’s totally wrong. The roundtripping problem may not be dead, but the model-design handoff paradigm sure is, at least for BPM. The collaborative implementation paradigm, in which executable design is layered on top of the BPMN model, is still the way to go. The way I look at it, BPEL is just like Java. You might generate it under the covers, but you don’t ever want to edit it directly. The part of BPEL worth leveraging is the fact that it is a standard and a commodity runtime, not a useful design language for BPM.
So if creating readable BPEL is not the right objective, what is? I think it should be defining the largest possible subset of BPMN that is automatically mappable (using the latest techniques) to BPEL, and then defining the mappings themselves. I need to know that, because I want to be able to teach my students the BPEL-friendly patterns to use in their BPMN diagrams. Already it’s a fact that BPMN training is mostly learning the diagram patterns that best express particular process semantics, so conceptually this is nothing new. Without direct BPEL editing, we don’t need to worry about mapping BPEL back to BPMN (but with direct BPEL editing, we certainly do).
With IBM, SAP, and Oracle expected to be influential in the BPMN 2.0 effort, we can expect to eventually see some help on this within the standard itself. But I don’t want to wait that long.
November 28th, 2007
[Posted 29 Oct 2007 on BPMInstitute.org]
The Business Process Modeling Notation (BPMN) standard from OMG has a lot to recommend it, but it’s not perfect. Since late February of this year, I’ve been doing BPMN training, and through that I have come to appreciate the subtle power of the notation and how it maps – or sometimes not – to the way real business analysts and architects want to model their processes. Some of BPMN’s problems, such as the lack of a standard XML storage and interchange format or a specification for minimal compliance, are so basic they make you wonder how it has succeeded in becoming the one important standard in BPM.
These issues are well known, and addressing them should be BPMN’s top priority, but they are undoubtedly hard and mired in vendor politics. While OMG dithers on such big picture issues, there are also a few of improvements in the notation that would fill important semantic gaps in the meantime. Here is my wish list.
Multiple Start
You often see diagrams that contain something like the following:
The idea is the process can be started in either of two ways, either manually from a user’s desktop, or automatically, such as through a web service. The initial activity may differ based on the manner of starting, but downstream the process is the same either way. Now, is this diagram legal in BPMN? The spec is vague on this point. Technically, a None start (the one without an icon, labeled “manual”) means the trigger is unspecified, while the Message start refers to a particular triggering signal. If you label the diagram as I have here, most modelers would understand the intent, but simulation engines or executable designs based on the model would not.
This is a very common pattern, and BPMN should have a way to model it less ambiguously. One possibility would be to adapt the event gateway to start events. In a BPMN event gateway, a process pauses to wait for one of N specified events, and the first one to occur triggers resumption of processing and determines the path taken out of the gateway. If another of the N events occurs subsequently, it is ignored. In BPEL, the Pick construct lets you do exactly that, either waiting in the middle of a process or triggering the start of a new process, but the BPMN event gateway can’t start a process. BPMN would benefit by adding similar triggered start behavior. You might argue that the diagram above already does this, but it’s ambiguous, and there is nothing that explicitly ignores the second event to occur.
Non-Aborting Intermediate Events
One of the most useful constructs in BPMN is the attached intermediate event. If a timer, message (signal from outside the process), error (signal from inside the process), or signal (from either inside or outside) event is drawn attached to the boundary of a process task or subprocess, the task or subprocess immediately aborts, and processing continues on the exception flow out of the event. Attached intermediate events can be used to handle timeouts, errors, or signals from an external party, such as a customer canceling an order. If the event occurs either before the activity it is attached to begins, or after it ends, it is ignored. Thus modelers can add subprocesses to define precisely the scope of any possible interrupting event. This is amazingly helpful in describing exception handling from a business perspective.
The only problem is sometimes you want to trigger some parallel processing without aborting the activity the event is attached to. For example, maybe after a timeout or external event you want to send a notification but not interrupt the waiting activity. Some tool vendors (e.g., TIBCO) allow this, but it is not allowed by the BPMN spec and the non-interrupting behavior is not visible in the diagram. BPMN should provide a variant of the intermediate event to indicate non-interruption of the activity if the event occurs.
A second variant is especially important in insurance, where you may want to be able to suspend (“pend”) the instance, allowing it to be resumed later from the point of suspension. As BPMN is now, you would technically restart the activity rather than resuming it.
Semi-Structured Behavior
In BPMN, any sequence flow (solid arrow connector) leading from activity A to activity B means, by definition, start (or enable) activity B when activity A ends. But it’s amazing how often users want to give the user performing activity A the power to start activity B, if he or she so chooses, from the middle of activity A, not after it ends. So B is concurrent with A, within the same process. Let’s say that both A and B are part of subprocess X, so that X is not done until both A and B are complete.
BPMN has a construct called an ad hoc subprocess. You could use it, for instance, with lots of annotations, to describe the above behavior, but it is not as useful as it might be. A BPMN ad hoc subprocess, shown with a tilde icon, is a container for activities that can be completed in any order, and do not all need to be completed. It cannot be simulated or used to generate an executable design, so it really violates the spirit of BPMN as a business view of process behavior that can be analyzed and implemented from the model.
One way this might be implemented is with the non-aborting intermediate event suggested earlier. Such an event attached to A could start B while A continues on. Modelers want to do this, but today BPMN does not allow it. In the diagram here, assume the event attached to A (shown here as the conditional, formerly called rule, event) is of the proposed non-aborting variety. In BPMN 1.1, the complex merge gateway (asterisk inside) means select the first path to arrive and ignore any others – the discriminator pattern. So B will be enabled either from the middle of A (via the conditional event) or when A is done, but not both times. Modeling semi-structured behavior in this way works with simulation engines (that support event probabilities) and can generate implementation, which is what we want.
Standard Merge
My last wish list item isn’t filling a gap in BPMN, but simply making it more usable. Multiple paths in a flow are combined into one using a merge gateway. The symbol inside the gateway – none or X for an exclusive merge, + for a parallel merge, and O for an inclusive merge – all actually denote the same behavior, but the spec requires that the correct symbol be used depending on whether the inputs are known to be exclusive alternatives, known to be enabled parallel paths, or parallel paths not all of which may be enabled.
In other words, the modeler has to be smart because the BPMN merge symbol is stupid – stupider, in fact, than real process engines, which can generally figure out which inputs to the merge are enabled and knows to wait for all of them before completing the merge. Only exotic patterns, such as the discriminator mentioned earlier, differ from what I would call standard merge behavior. So I propose that a merge gateway with no symbol inside be redefined from its current meaning of exclusive merge to standard merge, which would then replace exclusive merge, inclusive merge, and parallel join gateways. My students would thank OMG as well.
Notes added after original column:
1. BPMN 1.1 does provide a solution for Multiple Start. It uses the event gateway to represent the various starting triggers. An event gateway may be used at the beginning of a process either with no incoming sequence flow (i.e. as implied start node for the process), or directly following a None start event. In the latter case, the spec says the event gateway “bootstraps” the process start, i.e. the event gateway is really the thing that kicks it off. It’s not really consistent with the rest of the notation, but no matter. This does the trick. The spec is ambiguous about the kind of events allowed: Message for sure, Timer is explicitly disallowed, but what about Error, or Signal? Not clear.
2. There is a way to create non-aborting intermediate events in BPMN today. The problem is cumbersome notation and unfamiliarity to business users. Well, you can try to teach it, anyway. Here’s how it works. Any activity A with attached intermediate event E can be redrawn to exhibit equivalent triggered exception flow behavior without aborting A, as follows: Create subprocess A’ with a start event going in parallel to activity A followed by Terminate, and to event E followed by a normal End event.
Here E aborts A.
Here E triggers the exception task but does not abort A. Exception task (it could be a subprocess) immediately after E. However, if not complete it will be aborted when A completes, which is the problem with non-aborting events done this way. So Exception task should be something very short, like sending a notification. Any exception activities that should not be aborted when A completes go into Next exception task, which cannot start until A completes.
3. Looking back at my Semi Structured diagram above, I can’t figure out why I used a Complex (discriminator) gateway. Since the conditional event and the normal flow out of A are always exclusive alternatives, an exclusive merge - equivalent to no gateway at all! - seems to be all you need going into B. Am I missing something?
November 28th, 2007
[Posted 1 Oct 2007 on BPMInstitute.org]
Among the numerous virtues of BPMN, foremost is vendor independence, giving process modelers many tools to choose from, all describing processes using the same shapes and semantics. That’s huge, since without low-cost (or even free) tools you’ll never establish a culture of process broadly throughout the business. Occasionally, however, a student in my BPMN training will ask the embarrassing question, “So that means I can take the models I create in this class and import them into the BPMN tool we use in our company… Right?” Uh… well, not necessarily.
It seems that the number one reason for creating a standard in the first place – portability and interoperability across tools – was somehow forgotten by the BPMN standards committee in OMG. And a good solution is not yet clearly in sight.
First of all, lest anyone doubt that BPMN has become the de facto standard for process modeling – at least where BPMS-based implementation is contemplated – then consider that Appian, Lombardi, Savvion, Tibco, Intalio, SoftwareAG, and Oracle all use it today, and IBM, SAP, and BEA are planning to move to it soon. If BPMN is not on the analysts’ BPM RFP checklist today, it certainly will be next year. That’s what makes it so unbelievable that we still lack a standard XML interchange format for BPMN models.
There are three potential solutions on the table. All of them have problems, some fundamental, some fixable. But fixing the problems requires pressure from the BPM user community, pressure that so far has been absent. Tool vendors, it seems, like to import from standard formats, but export… not so much.
Solution #1 is to use BPEL as the model interchange format. BPEL is an OASIS standard for executable processes modeled as orchestrations of web services. Among the BPMN vendors, Oracle is perhaps the leading proponent of this approach. BPEL has in its favor the fact that it can handle BPMN’s event and transaction compensation behavior, and is a well-defined standard designed for portability … at least for the parts of the process described by BPEL. The problem, however, is that BPEL 2.0 does not describe human tasks, subprocesses, and other central features of BPMN process models. Also, BPMN’s freeform activity flows do not always map easily to BPEL’s “block-oriented” structure. But one can at least envision how BPEL, enhanced with People and Subprocess extensions, could be used for BPMN interchange, or at least a subset that excludes a few unmappable routing topologies.
Solution #2.is to use XPDL from the Workflow Management Coalition. XPDL was originally created to allow interchange between process modeling and workflow automation tools. Developed in a pre-SOA era, XPEL 1.0 lacked the necessary event-handling features, but version 2.0 was extended to include all of the elements described by BPMN. A lingering problem with XPDL is that it focuses on interchange of the diagrams but not necessarily the underlying process models. Not only does XPDL not demand that “compliant” tools support any particular subset of BPMN semantics, but it does not even insist that all tools serialize the same diagram in the same way. I have urged them to make model portability a priority in the upcoming XPDL 2.1, and I believe they will. I think users want to port the models, not just the pictures. But I believe WfMC is sensing a new opportunity here. Given that most BPMSs today are not BPEL-based, XPDL 2.1 has a much better chance of becoming the accepted interchange standard for BPMN.
Solution #3 is OMG’s own Business Process Definition Metamodel, or BPDM. BPDM has the singular advantage of being the officially sanctioned BPMN interchange standard from the organization that owns BPMN. However, it suffers from some serious problems of its own, not the least of which being that its developers believe they need to “fix” BPMN before they can serialize it, since (they say) the semantics are not precise enough. Precise enough for what? After hours of discussion with these guys, it turns out that they mean precise enough for identical runtime behavior or for exact mapping to UML. For me, that’s when the alarm bells go off, since if you believe that the implementer’s view of a BPMN process is really UML or Java, you’re out of touch with today’s BPM. In any case, the ability to create a BPMN model in tool A and then edit it in tool B is not the same goal as generating unique UML or Java code from a particular BPMN diagram. The former is a real need of process modelers today, as imperfect as BPMN 1.0 is. But OMG’s goal with BPDM appears to be the latter. Whatever merits it may have as a formal metamodel, I just can’t see BPDM succeeding as an interchange format for BPMN process models in the near term.
Each of these “solutions” to BPMN model portability, you may have noticed, is actually a by-product of some other goal of the standards committee, which explains why none hit the mark. But is model portability even an important goal? If so, practitioners need to make that need felt by the standards bodies, the analysts, or someone. And what does portability even mean? Do you need to preserve the exact look of the diagram? Do you need to preserve the same runtime behavior? Is BPMN even about specifying precise runtime behavior? Unfortunately, there is no consensus on these questions.
November 28th, 2007
[Posted 6 Sept 2007 on BPMInstitute.org]
One of the most powerful features of BPMN is the least appreciated… by modelers and tool vendors alike. I’m talking about subprocesses. Most of the process models I have seen would be much improved if they were used more liberally, and more effectively.
In BPMN, a process is viewed as a flow of activities, and an activity – a rectangle in the diagram – can signify only one of two things: a task, meaning it has no subparts of interest to the model, or a subprocess, meaning the activity has subparts of significance to the model. So right off the bat, any process activity can be represented as a subprocess, whether you show the internal detail or not. In BPMN, you can draw a subprocess either collapsed as a single rectangle with a + symbol inside, or expanded – either inline in the diagram or in a separate linked diagram. Both representations mean the same thing; they just show different levels of detail.
In my BPMN training we talk about five fundamental benefits of subprocesses. The simple idea that any process fragment can be displayed either collapsed or expanded accounts for Benefit #1. Subprocesses allow the end-to-end process to be described at multiple levels of detail.
When you are first capturing the workings of an as-is process, it’s ok to begin with a “flat” model taking thirty feet of wall space. But flat models are no good for shared process understanding. Better to start with a top-level view in which the whole end-to-end flow fits on one page, using very coarse-grained subprocesses. Then you can expand any of those top-level subprocesses in another BPMN diagram. Ideally, all these second-level diagrams should be hyperlinked to the top-level diagram, and in a few tools they are. The second-level diagrams probably contain subprocesses as well, so you can use this nesting technique to drill down to any level of detail without losing the end-to-end context.
This feature of subprocesses in BPMN accounts for their second benefit as well. Subprocesses encourage top-down thinking and analysis, also known as the end-to-end view. Use BPMN subprocesses to describe the entire process, end to end, on one page, so the handoffs between the major process components are visible to everyone from the start. BPM as a management discipline is all about breaking down the functional stovepipe views of business that stymie performance improvement and replacing them with end-to-end views and KPIs. If you use BPMN correctly, the end-to-end view is not an “artist’s conception” but actually the top-level of a real working model.
A third benefit is that subprocesses fit well with distributed process ownership. Each part of an end-to-end process may be only known in detail, and ultimately controlled, by a different group within the enterprise. If the top-level diagram accurately describes the interaction between those parts, including the exception paths, then each part can be modeled and maintained independently, while preserving the integrity of the end-to-end process.
A fourth benefit is that subprocesses are ideal representations of business services in SOA – units of business reuse that can be invoked by various processes and composite applications. In its collapsed representation, a subprocess describes the inputs and outputs of the service, and where it fits in the business context. Expanded, it can describe and analyze the inner workings of the service, whether or not it is implemented in a BPM suite.
The fifth benefit of subprocesses is in some ways the most powerful, but the least understood by process modelers. In BPMN, a subprocess defines the scope or context of an event, meaning the boundaries of the part of the process where some external signal – cancellation of an order, for instance – is valid and can be acted on in a particular way. If the event occurs before that fragment starts or after it ends, it can be ignored. In fact, a subprocess in BPMN may have no business significance other than describing when a deadline timer starts and ends, or where an error results in a particular action.
Developers using BPEL are familiar with this. In fact, BPEL calls it a “scope” and its primary purpose is to create start and end points for errors and events. As BPMN-based BPM suites increasingly add support for scoped events to their execution environments, process analysts using BPMN will need to understand that behavior in order to effectively model exception paths in their processes.
If your process modeling or design tool doesn’t support these five ways of using subprocesses, you should ask the vendor why not… or start looking for another tool. BPMN imposes some rules on subprocesses that take some getting used to. For example, a sequence flow cannot cross the subprocess boundary. But it’s all readily understandable by a business analyst with a little training.
If you want to step up your modeling game, subprocesses are usually the place to start.
November 28th, 2007
[Posted 15 Aug 2007 on BPMInstitute.org]
When I launched my course “Process Modeling with BPMN”, I discussed in this column why so many people beginning to “do” BPM were looking for training in modeling, and why that was especially needed for BPMN. Now, having delivered the training for five months, I have a better appreciation of BPMN’s strengths and limitations, a better understanding of what students really want, and what they really need to know about BPMN modeling. That learning is reflected in a major update of the 2-Day Training Course at BrainStorm DC (September 12-13) and New York (November 8-9) in conjunction with BPMInstitute.org. This column describes what I got right the first time, and where I’ve had to adjust.
One of the things I got right from the start is that BPMN’s extremely wide range of use and lack of built-in methodology is both a key strength and a weakness. Many students looking to “do” BPM are not thinking about automating their processes with a BPM suite. Modeling for them is essentially documenting the as-is process end to end, analyzing its shortcomings by visual inspection of the diagram, and making incremental improvements. BPMN can be used for that… and the training provides a methodology for doing so, leveraging the notation’s swimlanes to make cross-department handoffs – a key source of error and delay – stand out in the diagram, and collapsed subprocesses – linked to expanded detail on another sheet – for top-down models that can be shared and maintained.
But BPMN is most valuable when you go beyond simple documentation and analysis by inspection to quantitative analysis by simulation and executable process design. The reason is that the semantics of the notation’s core elements – activity, gateway, event – are precise enough that you can actually execute the model. That precision, and the rules that enforce it, can get in the way if all you’re trying to do is capture the as-is in a diagram. But if you view that capture as the first step along a path that ultimately goes to an improved executable implementation, then BPMN is the only way to go.
In fact, an increasing number of BPMS vendors have come to see that maintaining the BPMN diagram as a continuous “business view” of the evolving executable implementation is a central element of their BPM value proposition. This goes beyond the human-centric BPM pureplays like Savvion, Lombardi, and Appian, who embraced this idea from the start, but includes Tibco, Oracle, and webMethods (now SoftwareAG)… and I expect IBM and SAP to follow suit in the coming year. BPMN is the key to a new rapid iterative BPM implementation style in which business and IT collaborate continuously through the process lifecycle.
But this promise exacts a cost. BPMN has rules, and to make business-IT collaboration work, “business” has to learn them and follow them. The BPMN spec is often unhelpful, piling on needless complexity with multiple ways to draw the same process semantics and a bevy of exotic gateway and event types that are rarely used… and even more rarely needed. Addressing this reality – and the difficulty it poses for some business analysts – is a guiding principle of the updated training. We focus on the working subset of diagram patterns modelers really need, and which will suffice 90% of the time from simple as-is capture to full executable design.
Throughout the new training, we try to reinforce three central principles, or best practices, when process modeling with BPMN:
1. Make important process detail visible in the diagram. The central purpose of modeling is shared understanding. BPMN is mostly a diagramming notation, but each diagram element also has attributes, many of which are only visible in property sheets or generated documentation. You may need these attributes for model interchange, simulation analysis, or executable code generation, but for shared understanding, only information surfaced in the diagram has business value.
That means adding labels everywhere, not just to activities but gateways, sequence flows, and events. Differentiating successful end states from unsuccessful ones by labeling end events adds to shared understanding. For advanced modelers, clarifying throw-catch semantics by paired labels (between thrower and catcher) adds to shared understanding. True, these labels might be redundant to hidden attributes required for simulation or execution, but in BPMN, the diagram is king.
2. Make your diagrams valid. A model is not a doodle. In BPMN, each shape has defined process semantics, which depend on exactly how and where it is placed in the diagram. To make that work, BPMN defines rules, lots of them. To use BPMN effectively, especially if your ultimate goal is implementation, you need to learn the rules and apply them correctly. It’s not hard if you focus on the subset of BPMN that you really need, and reduce that to a few diagram patterns that everyone in the organization can learn.
The difference between a modeling tool and a simple drawing tool is that a modeling tool understands the rules, and can validate the diagram. The training includes graded hands-on exercises using itp commerce’s BPMN tool. In the original training, we did not explain or encourage use of its built-in validation function, since it would report errors when hidden attributes (required by the spec but useless for modelers – see #1 above) were missing. But after correcting so many student diagrams with basic validation errors, I now teach validation and encourage its use. I just say ignore the missing attribute errors, and in the next version of the itp commerce tool you’ll be able to selectively disable them.
3. Make your diagrams hierarchical. Models are not wallpaper. Placing stickies on 30 feet of wall space is a fine way to capture an as-is end to end process, but “flat” models that you need to view by walking around a room do not provide sharability and maintainability, central qualities of a good process model. In the training we teach a top-down methodology, in which the end to end diagram can be drawn on one page using BPMN’s collapsed subprocess notation, exploding each subprocess at greater detail in another page of the diagram, and so on using as many levels as needed. These drilldown levels are hyperlinked in the modeling tool, so you can zoom in or out as needed, while the tool manages it all as a single model for simulation or code generation.
This sounds easy, but BPMN adds a bit of complexity. For example, sequence flows – the lines connecting process activities – cannot cross a subprocess boundary. Since you want the diagram to be valid at every level, this creates some gotchas, and we show you how to avoid them. These three key principles drive the updated training. We teach advanced topics like error throwcatch, transaction compensation, and multi-pool processes – and even BPMN 1.1 changes like the new Signal event – but we’ve placed the major focus more squarely on learning the subset of diagram patterns you use all of the time, and applying the principles above. After five months of experience, this is what I’ve learned from the BPMN training.
November 28th, 2007
…to my blog. Yes, guilty as charged. One reason is I’ve been doing a lot of writing on other sites. Examples:
- monthly BPMS Watch column on BPMinstitute.org
- new BPMS reports, also on BPMInstitute.org. Completed so far are Appian, BEA, Lombardi, G360, TIBCO, webMethods (SoftwareAG), FlowCentric, Cordys. In review cycle: Oracle, Singularity. Next up: EMC Documentum, IBM (WebSphere/FileNet). Maybe Adobe. These are free downloads.
- 6-part series on BPMN and the Business Process Expert, on SAP’s BPX community site
- companion 6-part Flash video training on BPMN, also on BPX (forthcoming, end of December)
The least I can do is call your attention to these here, maybe generate some comments. I will repost the BPMInstitute columns here, and just the abstracts and links to the BPX content.
November 28th, 2007
