Anatoly recently did a podcast with ebizQ’s Peter Schoof.  The transcript was posted on Anatoly’s blog, and well worth reading, but something he said in the pre-amble really caught my attention:

My activities in BPMN got me a reputation of an expert in process modeling. Let it be so; yet I believe it’s rather the basics of the craft than its top and personally I’m more interested in issues arising at BPM and performance consulting intersection and business process BPMS implementation methodology. It’s a common story: the public is more attracted to what an expert considers almost trivial while what he treats as an achievement may come unnoticed. As an example, the most popular posts at this blog are those tagged “FAQ”.

I added the emphasis in the second sentence, and included the whole paragraph for context.  One of the most difficult things to explain to novices and newcomers to BPM is that although the basics sound easy in black and white, a lot of judgment and experience comes to bear in making subjectively good decisions about how to leverage BPM techniques.  Rightly, this is not what people want to hear.  They want to hear that it is a science, an engineering discipline, if not a mathematical formula.  But it is not so.

I’ve often said what makes the difference between the average BPM practitioner and a really good one is that the best practitioners have a sense for how all the individual simple things will come together into a cohesive outcome – each individual action being pretty easy, but the combination of actions, and knowing which action to execute when, and under what circumstances-  that is the secret sauce of BPM.

What Anatoly’s blog largely provides is an insight into how he thinks through these basics – the subtleties that are like lego bricks – individually sort of simple (2×4, 2×2, etc. ) but in combination quite interesting business problems can be addressed. And it is the basics you need to master first.

Gartner’s Business Process Maturity Model is not for the faint of heart.  I’ve heard a couple of talks on the subject and read a couple of papers, and never found it terribly useful or informative to our action plans with customers.  Apparently Anatoly Belychook agrees based on this blog post:

Phase 0. Functional management. Organization has yet to realize that its performance as a whole depends not only on how certain functions are performed, but also on how well these functions coordinate with each other, i.e. the quality of business processes interconnecting them.

Phase 1. Business processes awareness. The organization explores itself through the prism of business processes. End-to-end business processes are discovered and process owners are appointed. Everyone draw process diagrams. Gaps and bottlenecks are identified and eliminated, without investments into processes automation (BPMS).

Phase 2. Automated execution and control of business processes. The organization learns to manage business processes in a continuous loop model – execute – analyze and seeks to improve their effectiveness, mostly on a separate processes basis.

Phase 3. Execution and control of end-to end business processes. Process boundaries are expanded under the control of BPMS, inter-process communications are worked out and end-to-end processes are established connecting the company to its customers/partners and/or their business processes.

Phase 4. Explicit and automatic link between business goals and business processes. With the help of simulation and dynamic business rules, business goals changes trigger automatic rebuilding the network of business processes.

Phase 5. Adaptive business structure. The ability to quickly react to changing business environment, anticipate these changes and create opportunities through deeper integration into various markets and partner ecosystems.

I would offer a simpler set of maturity levels, which is what I proposed at Lombardi when I was still employed there:

0. Process Ignorance: No organized process per se
1. Process Awareness: Documented processes
2. Process Discipline: Processes both documented and consistently adhered to
3. Process Proficiency:  Processes implemented in software
4. Process Excellence: Ongoing investment in process improvement is cultural in the organization.

As Anatoly says, in Gartner’s 5 phases, phase 0, 4, and 5 aren’t really interesting for discussion in today’s business climate.  But he points out a key trap in pursuing process maturity the way Gartner envisions it:

The key words are “for all processes.” Trying to evenly raise the maturity of all processes is a recipe for disaster. In accordance with Pareto’s law, 20% of processes are responsible for 80% of the company’s performance. Wouldn’t it be wiser to focus on these 20%?

Sure the BPM-3 grants much more control over the processes than BPM-1. But it’s much more expensive as well! Complete BPMS implementation of an end-to-end business process is a custom IT development, apart from other considerations. And cheap custom IT development just doesn’t happen.

This isn’t just true for BPM – it is true for QA, for CMM, for all kinds of organizational and technical efforts.  Failure to apply the Pareto principle is to fall into the sins of either waste or overproduction (depending on how you look at it).  When we tackle even one process for an improvement and/or implementation effort, we try to focus in on the most important 20% – the changes that will really move the needle in terms of process performance, rather than expending our work equally across each stage of the process.

Anatoly has posted another process pattern: the Incoming Processor Pattern.

It is a good pattern – and actually forms the basis for a lot of variants of that pattern (in a sense, it is the base case of a wide variety of patterns).

Essentially, Anatoly describes a process that begins with a message start event listener:

Beyond that, Anatoly points out there is a challenge with respect to having more than one instance of this process:

But here is the question: how would the message from client John Smith find its way into specific process instance associated with him? Let’s not forget that there are about thousand of instances behind the single pool “Credit card issuance” shown in the diagram. [...]

But when a message is sent into the middle of a process (i.e. to the intermediate event) one must specify the process instance ID. Moreover, the process instance ID is the internal BPMS data so we can’t expect that a message from an external entity (from collapsed pool on a BPMN diagram) would contain it explicitly. In our case it’s just client’s words “hello, I want my card.”

He even diagrams this “incoming processor”:

I found his description of this pattern interesting, because the BPMS that I use most often (Lombardi / IBM BPM) wouldn’t require the incoming processor pattern for this use case.  The typical case for BPMS’ is that the event listeners can hear events targeted at their process instance id.  But Lombardi took a different tact that IBM has preserved – events “correlate” on any piece of process instance information – process instance id is certainly one option, but so is a name, or a debit card number.  And the logic to find and message the right process instance is built into the engine.

Not only that- a message my correlate with more than one process instance -automatically- based on the various correlations.

So this is a case where the BPM engine allows the models to be both more expressive and more concise, and to leave the incoming processor logic as a black box that “just works.” But if your BPMS doesn’t do this for you, or if you need to do additional pre-processing logic before the process instance is triggered, this pattern will do the trick.

Once again, a great, thought-provoking post from Anatoly’s blog.

Anatoly often posts the best examples and cautionary tales in BPMN2. In the latest post, he derides the limited usability of Swim Lanes in BPMN 2 – And he has a point.

On the one hand, embedded subprocesses can’t have swim lanes (the best way to think about these is simply a set of collapsed activities, for notational convenience).

On the other hand, “Reusable subprocesses introduce additional complexity because unlike embedded they are executed in a separate data context”.

Anatoly’s conclusion is that overusing reusable subprocesses is bad practice, because of this overhead.  I conclude differently:  the BPMS should minimize or optimize this overhead – and the business process designer should be able to ignore it on a robust BPMS.  To make a coding analogy:  we should be talking about the difference between an embedded block of code and a function call.  Yes there is overhead, but it should be managed by the BPMS transparently.

In fact, some BPMS authoring environments don’t even allow for the embedded subprocess- treating it as just a special case of the reusable subprocess who’s primary difference is that it doesn’t happen to be re-used. I don’t think we should optimize around the shortcomings of a particular BPMS too much, in terms of our general BPMS modeling advice.  However, I’ll concede that once you’ve chosen your BPMS, you might as well optimize somewhat around its capabilities as they become known to you, and model accordingly.

Anatoly has posted an example regarding orchestration and collaboration, and he has two particularly good pieces of advice at the end, though the whole post is worth reading:

Rule 1. If your attempts to model a process are unsuccessful because some significant aspects are missed repeatedly then stop and think – maybe in fact it’s not a single process but two or more?

Rule 2. Do not overuse collaboration – stay within the orchestration as long as possible. Never introduce collaboration into a diagram just because you’ve recently learned how to do that.

Both of these are excellent.  Rule #1 is exactly how I approach splitting something into multiple processes.  Rule #2 is just a good rule in general for any piece of functionality you’re not overly familiar with, or any advanced functionality.  Start with the basics, and only go to the more advanced features when you clearly need to.

Anatoly is one of the clearest communicators on the subject of BPM today, from a practitioner’s viewpoint.  A few choice quotes:

AB: First of all, there is a kind of a general understanding of how to do BPM right. But the problem is that there are many small factors that can dramatically affect your BPM initiative and actually ruin it.  [...] if you do it in a waterfall-like approach, then there is no room for agility, so it’s not BPM, actually.

Couldn’t have said it better myself.

I would like to add that there may be one key factor for success, but there are always several key factors for failure. This is the problem. You must know a lot and be careful about many things at once. This is why BPM professional services are in demand.

Again, true words.  It is one of many reasons why BPM professionals are in demand, but maybe most of the other reasons boil down to this one.

AB: Well, I believe that this BPMS-ACM debate you referred to at the beginning was very productive and, in the end, we will see most BPMSs enabled by ACM capabilities. This is a great thing because there is really a full spectrum of structured, half-structured and unstructured processes and cases. We need to cover all of this spectrum.

I definitely recommend the whole podcast.

Anatoly Belychook’s recent post on Cross Functional patterns is covers the idea of buffering when choreographing processes between different functional groups.  As he points out, the “cardinality” of different functional organizations may be different – where one part of the organization might be dealing with a single order or invoice at a time, another part of the organization may prefer to work on batches of orders or invoices (e.g. paying invoices at End of Month), in other words, they need a buffer.  Of course, this pattern may seem obvious, but the good ones should seem obvious once properly explained.

Anatoly’s posts on patterns (rather than templates) have been good in the past, and this is no exception.  He’s using BizAgi modeler to generate the images and they look sharp.  Other vendors who produce models should take note and allow for crisp export of images of the models – to promote sharing on blogs, among other reasons!

Love Anatoly’s analogy in a recent post, Laws of BPM Robotics.  But my favorite line was in the first sentence:

One of our BPM project’s sponsor said at the very beginning, when we discussed the possible project: “my employees don’t need a control, they need help”. I argued at the moment, but later I realized that he was right.

This notion of helping versus controlling is at the root of doing BPM right.  There are those who will say “helping” isn’t BPM, its ACM, or Adaptive, or something to that effect.  But if you’re a BPM practitioner there is no reason to limit yourself this way.  Good business process depends upon people doing their jobs well – and helping them seems like a key element in getting the job done well.

I like Anatoly’s laws for the “BPM Robots” that should do work for us, supporting our own efforts:

1. A robot will never be able to do what you are able to do.
2. A robot will do only a part of what you are doing.
3. A robot will do only a part that you won’t like to do yourself.

Some will argue that BPM is only about routine work. But rather, one piece of BPM is removing or simplifying routine work in order to leave the core value-added work for the people who do it.  In other words, the goal of BPM isn’t routine work – it is to expose the real work by draining the swamp of the routine, mundane, unnecessary, and non-value-added.

Anatoly’s excellent blog turns its attention to ACM:

Adaptive Case Management was one of the most discussed BPM topics in 2010. It transformed from fuzzy marketing noise into a more or less consistent concept over the past year.

Why “more or less”? Because even the authors of “Mastering the Unpredictable” – probably the most authoritative book on ACM to date – say in the preface that there is no consensus among them, so the book in essence is a collection of articles. Nevertheless there are more similarities than differences in their positions, hence the consistent concept.

He goes on to give his take – an admittedly different perspective from many of the other authors on the subject and an interesting read.  He challenges the orthodoxy of both ACM thinking and BPM thinking in his blog, which is part of why I find it a refreshing read.

I missed this post from Keith Swenson the other day, as he responds to Anatoly’s post on ACM.

Keith cuts to the chase:

Anatoly Belychook asks the question: “is ACM a Paradigm or a Feature?” I could not resist responding because I like the post, and his logic is flawless, but it is based on false assumptions.  I think there is a lesson here on why so many BPM experts feel the way he does.

First, his summary of Adaptive Case Management (ACM) is one of the best I have seen.  There is no doubt that Anatoly understand the motivations behind ACM.

What he does next is quite surprising; he analyzes whether ACM meets certain requirements of BPM.  That is the flaw in his thinking: there is no reason to believe that ACM should meet the requirements of BPM.  Many BPM experts  start with an assumption that ACM should have BPM-like features, and then move on to conclude that ACM is really just a type of BPM.  Those wanting to understand the subject should be wary.

Hm.  I would have phrased this differently- it isn’t that Anatoly’s assumptions are wrong – its just that the exercise Anatoly takes on is looking at how to satisfy BPM-style problems with ACM-style claimed feature-sets.  Anatoly would state it differently: How to satisfy enterprise level problems his customers are asking him to address, with ACM-style claimed feature-sets.  And, to consider whether you can solve enterprise style case management problems without paying attention to key issues of architecture, data entities, process architecture, etc.

The comments section reveal a very interesting discussion between Keith and Anatoly – well worth reading (thankfully BPM and ACM posts do not get cluttered with 100′s of comments like tech crunch articles!).

In one of his comments, Keith wraps with:

Hopefully this clarifies my point: while ACM capabilities may be a feature of a BPMS, ACM in general is not JUST a feature of a BPMS. To say the latter would be misleading.

Given that ACM describes an “approach” rather than a technology, of course this is true.  Likewise, BPM capabilities are not just a feature of a BPMS… I’d consider this a tautology.  I think what Anatoly was exploring is whether ACM software will survive as a standalone / separate market, or whether it will be collapsed with BPM software as a market. (Thus, feature vs. paradigm)

I might be projecting my own impressions onto his writing, however.

Interesting conclusions in Keith’s post, first this bit:

• BPM needs process architecture, ACM has no such need
• In BPM the person who designs the process needs to be a data architect, but in ACM these are different roles.  The person who designes the “process” does not need to be a data architect.
• BPM needs strong capabilities for integration, but in ACM there is little or no need for field-level integration.  ACM can work well with documents,  reports, and links to other application user interface.

And Keith asks: isn’t this enough to make it different?  Well, in technical terms, no.  But in terms of “approach”, yes. You can implement (and I have implemented) processes that required no “architecture”, “data architecture”, nor “integration”.  Typically those aren’t the kinds of processes people pay consultants to help them develop however, so I haven’t worked on that many of them. But it is definitely a different approach to start with the assumption that you won’t do these things.

Keith wraps with:

BPM systems will gain ACM-like features, but few doctors, policemen, and lawyers will use that.

Social Business Software like Jive, SharePoint, Quad, Chatter, and Connections will gain ACM-like features as well, and will be far more successful than the BPM systems, because those are systems that the doctors, policemen, and lawyers will use.

How funny.  I end up agreeing it is a feature of something, just not a feature of BPM.  :-)

I, too, find it ironic that Keith finally agrees ACM is a feature of something else (from a technical perspective)!  I think, by extension, ACM can be considered a (potential) feature of BPM.  And Keith may be right- that doctors, policemen, and lawyers will be using one of these other products (SharePoint? I doubt it) – but I wouldn’t jump to the conclusion that they won’t see BPM in their lives given all the government investment in process that’s happening.

Update: the discussion has moved to ebizQ now, thanks to Peter Schooff.

Anatoly uses an example of a cross-functional process to show how one can dramatically oversimplify how an actual business works – and as a result, write a really “broken” process.

The key insight he offers is this:  a BPM isn’t a workflow.  It is multiple processes and inter-process communications.  As a result, modeling a business process is an exercise in modeling multi-threaded systems (parallel programming).  The problem:

• Some people doesn’t see this barrier. They hit it but doesn’t realize what’s the problem really.
• Others instinctively bypass the barrier by implementing BPM pilot projects aiming at processes like “Vacation Request”. A pilot like this is going to be successful but does it have any value for business?

I believe this is the sources of most of the disappointment in BPM: those who narrow it down to the workflow end up with predictable failure.

Technically, multithreading is what distinguishes BPM from workflow. Remove the interaction between asynchronously executable processes via data, messages and signals and what you’ll get would be “workflow on steroids”, not BPM.

Unfortunately, this is the case with many software products marketed aggressively as BPMS. For me, the main BPMS criterion is the support of BPMN-style messages. There are other criteria indeed but this is the most useful at the moment. Everything else – graphical modeling, workflow engine, web portal, monitoring – is implemented ususally, better or worse, but many products totally miss inter-process communication. Most likely not because it’s that difficult but rather because no one has explained how important it is.

Agreed-  in fact, in some cases it is useful to model the entity lifecycle (process, you might say) of a critical element – like an Order – as well as the various processes that interact with orders (e.g. production process).  We’ve taken this approach before with product returns and dispute resolutions, for example – and I often refer to the processes as “orthogonal” – they intersect, but they have different purposes and objectives.  Of course, as Anatoly points out – much of the complexity is the business, not BPMN.  BPMN isn’t making the business more complex, after all – it already was that complex.  Anatoly explains:

The name of complexity is business, not BPMN!
Whoever promises a simple solution to business issues, whether it’s BPM or something else – do not believe it. Business is a human competition by nature: smart people are competing for living better than others. Therefore business has been and will remain a complex matter.

The complexity of BPMN isn’t excessive, it’s adequate to the complexity of the business. Students of my BPMN training have no question about why there are so many events: no one is excessive. And by the way, note that BPMN 2.0 is practically no different from 1.x at workflow part – the standard evolves in supporting more sophisticated multithreaded programming: choreography, conversation.

But what really grabbed my attention is seeing a different perspective on the “routine work” argument that we hear so much about from the ACM camp (and I’d be interested to read more from Anatoly on this subject):

They say the percentage of knowledge work vs. routine work is constantly growing. But exactly where is it growing? Mostly at US companies that offshore routine activities to Asia. A predictable observation for analysts located in US. But as soon as the amount of knowledge work grows at one place, the amount of routine work grows in another. And managing routine procedures running on the other side of the globe is the best task for BPM that one can imagine.

He’s pointed out a US-bias I hadn’t noticed myself (one of the benefits of reading blogs from other countries – increased perspective!).  What he says makes sense – the routine work in the US hasn’t gone away – its just been (largely) reassigned to people in other timezones or countries.  With all the benefits and costs associated.

Anatoly’s blog is one of my favorites, and his post on Star Wars only reinforces it. And yes, you can model just about anything:

If you don’t know much about Signal events in BPMN2, read Anatoly’s blog post on the subject:

In order to make the diagram work we must limit the signal propagation somehow. How it can be done?

1. The first thing that comes into my mind is an attribute that would limit signal broadcasting by the current process instance boundaries. Yet there is no such attribute in the standard. Under BPMN 1.x one may say that it’s implementation issue not covered by the standard. But BPMN 2.0 fully specify the process metamodel. Let’s look at page 281 of OMG document dated June 2010: signal has a single attribute – its name. Therefore, a signal will be transmitted to all process instances.
2. If the signal has only name then let’s use what we have. The diagram above may work if we could change signal name dynamically i.e. during the process execution. If we could name the signal “Process 999 Concept Ready” instead of “Concept Ready” then everything will be fine. But it’s a dirty hack and it’s hard to count on it. BPMS engines allow to change certain things during the execution (e.g. timer settings) but unlikely the name.

As Anatoly points out, the signaling examples given in several highly regarded books are fine, but when you think about how to make them work for the n>1 case, the logic breaks down.

It turns out that Lombardi’s BPM product (Now IBM’s Websphere Lombardi Edition) does not distinguish between Message flow and Signal events (the distinction between the two has only artificial merit).  All events include an information payload (which can be arbitrarily simple or complex).  The receivers control what they listen to by identifying a correlation key.  The correlation key has to be something in the information payload, and as you can imagine, often one element of the payload is specifically designed to be the correlation key for listeners.

So sometimes implementations get the design right in a way that the spec-writers don’t – because of what I would call over-design.  Let’s face it, writing specifications like BPMN2 goes against the principle of lean development (producing the minimum viable set of features).

So I find it interesting to see some of the challenges Anatoly has faced by facing in some cases a more pure representation of the BPMN 2 specification.

Sandy Kemsley covered Janette Wong’s talk at CASCON recently. The point of the talk was to discuss applying workflow patterns to modeling business requirements, and turning those into executable business processes. A good bit of the commentary revolved around all the hard work still required to make a design pattern actually executable – in particular with respect to role-based task assignment:

She used an example of an “authorization” business requirement, where manager can create confidential requests, and transfer those confidential requests to others. This can be matched to the standard role-based distribution pattern, which is fine for modeling, but then needs to be mapped to an implementation platform: in this case, some combination of WebSphere Process Server (WPS), LDAP or other directory service for user authentication and authorization, a workflow client application for human task management, and any other data sources that include user/role information. This multi-system implementation requires not only a conceptual mapping of the process and roles, but also actual integration between the systems that house the information. WPS provides instance-based authorization roles, then needs to bind that to the other sources at runtime in order to populate those roles; it doesn’t automate the solution, and in fact only provides a small amount of assistance in getting to that mapping. This is complicated further by role and authorization information that is spread out over multiple systems, particularly existing legacy systems; the business may think of the roles as being encapsulated in one of these other systems, which then needs to be mapped into the executing process.

I feel like the patterns (like “multiple instances without a priori runtime knowledge pattern”) are more accurately described as key phrases or constructs, rather than patterns (though there are exceptions to that generalization).   Wait, what is the problem the “multiple instances without a priori runtime knowledge” solves??

I think more of something along these lines in wikipedia.  And the kind of patterns you are likely to read on Anatoly’s blog.  In wikipedia, an “observer” pattern tells me a lot about what it might be doing.  Anatoly’s “Do Redo” pattern rings true, for example.  They describe what they attempt to solve (for the most part).

Of course, many people misunderstand the point of patterns. They wonder why there is still so much work to do!   But patterns are not libraries of code – they’re patterns of design and code.  Its like knowing how to tie a square knot.  Although you know the pattern, you still have to tie the knot each time you want to use it.  Design patterns are much the same way.

The point of the design pattern isn’t that it is less work – it is that you already know you have a good solution if the design pattern fits your problem definition.  The problem with the workflow pattern site is that it lists solutions with no problem.

Anatoly’s blog actually covers design patterns quite well:

Pattern in BPM is a typical process fragment of typical way of communication between processes (some examples).

One may ask: which one is more usefull? My opinion it’s a pattern:

• Templates are specific (one process – one template), patterns are universal. A good pattern can be used in a variety of business processes regardless of the industry.
• A practical benefit of using a template may be less than expected. It usually covers the happy path only and the devil is in details – various workarounds, escalations and exceptions.
• The effect of using the right pattern can be large. For example, there was a case in our practice when the process plotted at 6 A4 sheets glued side-by-side was reduced to the elegant design with just 15 activities by using the right pattern.
• The value of the antipattern is its ability to preserve you from mistakes. The price of a mistake is unlimited in theory and sometimes it’s really big in practice.

And yet industry analysts continue to overly focus on templates… I’d rather have design patterns and useful, re-usable components.  To my mind, templates try to “automate” the process design effort – to commoditize what cannot easily be commoditized.  Design patterns “enable” the process design effort – empowering and improving the design effort (as do re-usable components).

Design patterns in BPM aren’t a lost cause- they’re a key enabler of the successful process designer.  But names matter- and in that department, Anatoly’s approach is vastly superior.

With all this talk about BPMN, it seems like a good time to refer people to a Analoly’s excellent blog, where he has constructed a signal event example / walk-through:

Like messages, signals are used to synchronize and exchange information between different parts of the process. They differ from each other by the following:

1. Message flow is drawn in the diagram explicitly by the dashed arrow while in the signal case the sender (”thrower”) and receiver (”catcher”) are linked implicitly by the signal name. That is, if there is a thrower signal (marked by a filled triangle) on a diagram labelled “we won”, then look for a catcher signal (non-filled triangle) with the same label on this and/or other diagrams .
2. Messages can only pass between different pools (i.e. between different processes), there is no such limitation for signals.
3. The most important difference: messages are point-to-point communcations: an instance of a sender process cummunicates to one specific instance of the receiver process (let’s forget about start events for simplicity). Accordingly for a process engine to be able to deliver a message, one must specify the process ID of the recipient – e.g. by a process attribute. A signal passes from one process instance to many: to all instances awaiting a signal of given name at the moment. Thus signals are broadcast messages.

Its a good summary of signal events, which are quite commonly used in some BPM tools, and less commonly in others.

Dr. Stein of Aris has a blog about workflow patterns in BPMN2:

“In many areas, patterns are used to codify best practices. A pattern describes a solution for a problem. Originally, patterns were used in architecture to describe architectural design ideas. In software engineering, patterns are used to describe typical software design solutions, for example like client-server architecture.

In business process management, the so called workflow patterns by Prof. van der Aalst and friends exist. In their original description, they described the most important 20 workflow constructs like loops, decisions, and sequence flows. Later, Prof. van der Aalst and other research fellows extended the list of patterns and revised the initial description (see workflow pattern homepage). Still, the original 20 workflow patterns are valid and a useful tool to learn a modelling language such as BPMN.”

I’m just not excited about the van der Aalst “patterns” that are oft-quoted in BPM circles. The more accurate statement is that they are snippets of BPMN that demonstrate how various “constructs” work.  They’re useful demonstrations of how BPMN can work, and how to use a particular tool to diagram specific constructs.  And the work of van der Aalst and colleagues was very useful as well in identifying edge case diagrams that expose tricky aspects of the notation’s execution semantics.  They are not, truly, patterns as I would think of them.  Showing three activities executing in a sequence is hardly a “pattern” any more than three lines of code that execute in a row are a pattern.  Splits and joins are just constructs of the notation. The patterns don’t identify the usefulness of the pattern or the “why you would want to do this” aspect.  In that sense, they largely fall short of the bar for a pattern in my book.  A typical name for a “pattern” in this study : “Multiple Instances without Synchronization”… huh?  A name only a parent could love.  What’s the business case for this that helps me understand how it relates to business process? There isn’t one.  The point of these patterns, documented here, is to identify technical edge cases and compliance, not to create patterns that you will base your actual design work off of … and maybe that’s my main complaint.

The “four eyes” pattern is a pattern (where n-1 potential reviewers have to approve something before it moves on).  There are lots of real patterns out there – and generally they’ll get names that make sense- an “observer” pattern, the “shadow process” pattern, etc.  Having voiced my complaint, maybe I need to take some time to document a few BPMN2 style patterns to clarify.  Anatoly Belychook has described a few on his blog, in the past (as well as anti-patterns).

Anatoly has an excellent post attempting to explain the difference between Design Patterns and Templates:

• Debuts are templates: learn them and use them, chessbooks plot the game 20 moves ahead from the initial position.
• Typical combinations of the middle game are patterns. E.g. fork is a pattern: if you can see an opportuntiy then use it or threaten to do so. Two rooks on the same vertical is a pattern too while two pawns is an antipattern: try to avoid such a position if possible. But no chessbook contains instructions how to make a fork starting from the initial position.

It’s an interesting point in the BPM arena because patterns are more generally useful, but a good-fit template may save you more time on a specific situation. The Template, however, just gives you a head start- it doesn’t advise you for future improvement efforts, whereas good knowledge of patterns can save you time and effort over and over again as you develop processes.

Jim Sinur coined the phrase, and because it has a ring to it, people have picked up on it (perhaps behind Jim’s intent):

• Doing by Design is the pre-planned definition of a predictable, routine process as traditional BPM suggests.  It involves a life-cycle that starts with process discovery, process definition, application development, simulation, testing, and ultimately deploying it.  This works if the process is predictable.
• Design by Doing is an approach that works when the process is not predictable, and can not be written down ahead of time.  Since you can not predict it, you have to elaborate it as you go along.  You design it, as you are doing it.  There is no development life-cycle.  This works on unpredictable emergent process.

Keith Swenson thinks Design by Doing is advocating ACM:

Instead, a clear term is needed for “design by doing” and that is Case Management — particularly a newly enable technical approach known as Adaptive Case Management.  By having a clear label for “design by doing”, we will help people understand what we are talking about, what is required, what is not required, and will help this emerging market form.

I don’t know, why not just call it “design by doing” and use that as the tag-line for your product offering… ACM doesn’t quite have the same ring to it, and it isn’t nearly as easy to relate to.  Trying to convert a useful phrase into a three-letter acronym is, of course, the purview of techies and software firms.

Max J Pucher comments in Keith’s blog:

[..] So why is everyone trying to expand BPM now? Simple. Because they do not want to be part of an outgoing era! They do not want to admit that possibly BPM is not the final wisdom as it was proposed for so long. The BPM pundits know as they have added methodologies to manage the methodology of managing processes that they have crossed the line. Now that there is a movement that they know in their guts will kill old-style BPM, they at least want to retain the name because then they won’t have to admit defeat. Also ACM builds to some extent on the management concepts of BPM methodology, because it does require a capability map to assign process owners. [..]

Actually, I think the simplest explanation for the sudden desire to coin a new phrase, by firms previously happy to be labeled BPM, is this:  a bunch of companies have already acquired one or two BPM software vendors.  How many more BPM software companies do we expect Oracle, IBM, SAP, Software AG, and SAP to buy?  Would you rather be the “XYZ” software company that is more clearly defined as a complement to the BPM companies these firms already purchased, rather than a BPM company that has significant product overlap?  Of course!  (well, as Max says, he doesn’t care about the labels for his product, Papyrus, so I don’t mean to personalize this to Max, by any means!).  And if you’re a big established company, now is the time to find your opportunity to differentiate from IBM and Oracle – RPM from Progress, ACM from Fujitsu (and a few smaller vendors).

I even think this effort to differentiate the three letter acronyms is logical from the perspective of these firms, and in the self-interest of these firms.  But like some others (Anatoly for example), I’d like to keep BPM separate from BPMS (method from technology).  There are other folks who are just tired of chasing the latest 3 letter acronym and think the exercise doesn’t benefit customers or practitioners.   I see managing unpredictable work as still being “process-driven” even if others don’t.  Design-by-Doing sure sounds like a process to me, folks.  Maybe a meta-process, but a process nonetheless.

I’d like to see the ACM crowd turn their attention to explaining how they make the design-by-doing approach easier through their software offerings – explain why your software is just the right socket wrench for the job, rather than a screwdriver.  Educate the market on why the software fits the problem definition.  As a practitioner, I want to understand whether your software improves the odds of my customers achieving good results.

Regardless, it sure has made for a lot of good reading lately on BPM blogs.

Anatoly has a good post on a process anti-pattern, which is a process that shows a “sure” message receive (in other words, doesn’t allow for other outcomes – an approval process without a “reject” path for example, or a “time-out” path).

Of course, the simpler version of the process is fine for getting the basics of the process down, but you have to make sure you don’t base estimates on the simple representation, when there is more effort to make a more robust implementation work correctly.

I described an alternate (work-around) pattern that works on BPMS tools that support multiple attached events on an activity in the comments of Anatoly’s post, but I thought it only fair to supply an actual diagram here (click to enlarge):

I left out the second pool and cross-pool messaging to simplify the diagram a bit for purposes of posting here.  Essentially, rather than use an “event gateway” which looks ahead in the diagram to figure out which event fired and therefore which path is followed, we use attached events to do the same thing – if any of these events fire, it will close the activity and move down the path to the next activity.  Of course, the events could be configured so that they don’t close the activity they’re attached to (for example, a timing event could warn you of a delay, rather than canceling due to a delay).

It isn’t “pure” BPMN diagramming to do this the way I’ve drawn it – but with pretty much every BPM vendor these days you have to make some compromises to get the job done, and BPMN certainly gives you more than one way to solve any problem you’re presented with.  As Anatoly mentioned in his post: most of the BPM vendors consider the event gateway a “luxury” and therefore don’t implement it, or don’t implement it fully.  Hopefully one of the vendors will take the entire BPMN spec seriously, or one of the open source projects will, and put pressure on the others to step it up.