But to actually deliver on the promise of re-use, agility, and scale, if the BPMS doesn’t support your efforts organizationally you will run into roadblocks that have consequences… We’ll get to those in a moment… Here’s Neil’s take:

Most of what I’ve heard in discussion around this point focuses primarily on implications for the time to deliver projects: in other words, don’t think that once you’ve created a BPM and model your even close to finished application for real-world deployment. However there is a bigger issue at stake here, which is: exactly what kind of provision a given BPM technology platform makes for the specification of those items in the list above – and specifically, to what degree you’re encouraged to design and (when necessary) code these items so that each kind of concern is kept separate from all the others.

The quality of this “separation of concerns” in design might not make a huge amount of difference when you first start in implementation, but it can become incredibly important over time. And support for it turns out to be one of the most important (to my mind) differentiating points between BPM technology platforms.

Neil has hit it exactly.  The separation of concerns seems like quibbling between different philosophical approaches at first – but it is more important than that.  But when the separation of concerns is poor, or when the support for agility is poor, what are the consequences?

• The level of product and technical expertise you need to maintain your solutions goes up.  You can’t easily integrate people who are new to BPM to your project, and even when you do they have to be incredibly skilled computer scientists.
• The level of specific knowledge required of your business (and your technical hacks) is too high to easily bring new people into the project.  Anything they touch may have unintended consequences – sometimes far reaching and affecting more than just the process they intended to affect.
• Fear of change.  If a small change can have broad negative consequences or unintended side-effects outside of the process we’re editing, we will fear changing it.  We lose agility.  We might abandon a common implementation in exchange for process-specific implementations – and therefore losing the benefits to efficiency that re-use provide.
• Testing overhead.  If a small change in one process or process area can affect a broad array of other processes, the testing overhead is quite high.  Essentially I have to re-test everything.

But these are just the tactical problems. The real problem is that your BPM team won’t achieve the business outcomes you’re looking for – the I in ROI will be more expensive, the time to market slower, and the R lower.  It can wipe out much of the promise of BPM in the first place.

You can see some of this differentiation when you hear pundits and gurus talk about how “rigid” BPMS’ are – this says more about the BPMS they’ve been using than it does about the notion of a BPMS.  Meanwhile, some of us are pretty happy with how flexible our BPMS is… draw your own conclusions.

Neil’s next point:

Of course, because almost all BPM technology platforms centre implementation work around a graphical process model there is always likely to be a clean separation between definition of process and all of the other important design elements I’ve listed. But whereas some platforms provide a rich, well structured asset repository and clean design tools that implement the principle of “a place for everything, and everything in its place”, other platforms really provide quite weak facilities of this kind. With this latter group of platforms, it’s still theoretically possible to create process applications that are relatively easy to maintain; but designers and developers are going to be pushing against the tools available rather than working with them.

Reading this, it reminds me how much hue and cry there was over a certain company with a BPM product, buying an upstart company with an allegedly overlapping BPM product…. There was real differentiation in the process repository and in the basic architecture of the design environment.  But it was the kind of differentiation that customers and analysts would often miss – because the value isn’t as apparent in iteration 1 of project 1 (although it is apparent if you do them side by side).  It becomes much more apparent in iterations 3 and 4, projects 5 and 6.  If you’ve owned a BPM product for more than a year and you’re still looking at getting process #1 deployed, I’d recommend two things:

1. See about getting some professional help from a boutique consultancy focused on project success.  If you’re already working with one, consider a new one.
2. If that doesn’t get you on the path to more productivity and better use of your product, consider a different BPM platform.  You might have picked the wrong one.

Meanwhile, keep an eye on MWD’s research and their attempts to delve into the real differentiation between BPM vendors, and don’t just get caught up in the bright shiny features they’ll parade in front of us.

No related posts.

Starting with the shorter topics first:

The Word Export is much more pleasing to the eye than previous versions.  Having the graphics of severity and the diagram itself exported are a big help to the overall readability of the document.

The expand-all/collapse-all functionality in the Process Diagram is also convenient – especially when prepping to export a large diagram.

The BPMN export API works as advertised.  This is an important step to allow people to use BlueworksLive without feeling locked in.  After all, in a cloud “rental” model, one of the big fears is that your data is residing on someone else’s servers.  IBM needed to provide a clean way to get at that data and make it portable.  Not to mention, this lets customers apply some of their more standard SDLC to their requirements production in BlueworksLive.

First, there was quite a bit of attention given the Decision Discovery feature added to BlueworksLive.  I’d heard that this was coming, but I was picturing it as something that would be added to the automation features of BlueworksLive – I should have realized that the “Discovery” in the name implied that it would be part of the modeling (“Blueprinting”) part of the product.

The premise is that you set up a few Considerations (one or more).  The combination of these considerations is like a truth table.  However, BlueworksLive also lets you provide more than one conclusion – which is nice.  When modeling, we can label the column headers smartly, allowing the contents of each cell to be concise and simple (Yes/No, >$500/<$500, etc.).  Finally, we can label the conclusions well- “Adjustment Required”.  If we have more than one conclusion, it gets its own column to keep ideas separate.

A couple of surprising perks:  you can reorder columns and rows with a simple drag-and-drop.  Look, this makes sense given the point of the tool – flexible discovery of decisions.  But this is the kind of fit-and-finish often missing in enterprise software.

I also appreciated that they thought through why the cells should be free-form rather than constrained to integers or strings or a particular data type. The goal is to leave discovery unconstrained.  Plenty of time for constraints when you move into modeling for execution (had this been targeted at execution, you can bet there would have been tight treatment of data types).

Like David Brakoniecki, I think BlueworksLive is showing that it will live up to its promise as a BPM discovery tool.  Not because it does everything it needs to do today, but because IBM have shown that they’ll keep turning the screws until they get there.  His take on the impact of tiny changes at this point in the maturity of the product:

Now, at the push of a button, the process documentation and process diagram can be exported into a single word document. Basically, this document becomes the high-level scope of any potential BPM deployment or process improvement initiative. All of the great power of Blueworks around social collaboration and process discovery now can painless produce a document to playback to the client or business teams for review and iterative improvement.

SaaS products really emphasize the benefit of incremental improvement.

Related posts:

1. BlueworksLive May 2011 Update
2. New BlueworksLive Features
3. Blueprint December 09 Update

We use BPMN all the time in our projects, but we do a lot of process implementation projects, and it is a good fit for the tooling we use.  Craig makes a good point about someone not understanding BPMN precisely – but at least BPMN has a precise definition – unlike the usual whiteboard drawings.

I like to get on the whiteboard and build out the diagram and explain and talk as we do it.  By seeing and hearing the build-out, there’s much less chance of confusion about the interpretation.  And when you’re done, the diagram is actually accurate for someone who reads it “after-the-fact” if they know BPMN.

Having said all that, BPMN is a means to an end.  It isn’t the goal, it is a tool.  There are other tools and in the right time-place each one is useful.

Whenever there is a standard there’s inevitably a bit of back-lash against the standard from experts – almost as if it is a badge of honor to buck the industry standard.  I say this knowing full well that I’ve done it before myself!  But with experience comes a little wisdom and perspective and I don’t hand out badges of honor for either obeying doctrine or bucking it.  The badges of honor come for delivering great results.

BPMN isn’t perfect.  In fact, to misquote Churchill, it is the worst form of process modeling that has been tried… except for all the others that have been tried from time to time.

Related posts:

1. EPC vs BPMN?
2. Don’t Take My Word for it: Jakob Freund says BPMN Works!
3. Sandy Kemsley Reviews Bruce Silver’s BPMN Training

Not that IBM is covering EVERY corner of BPMN 2.0, but it is a significant advance – in that they are surprisingly supporting import and export of BPMN 2.0 XML from the Process Designer:

In a recent post, I talked about what “BPMN 2.0 support” really means, in both non-executable and executable model contexts.  It’s not primarily about the notation, although a few shapes and symbols – notably non-interrupting events and event subprocesses – are new in BPMN 2.0. BPMN 2.0 support is really about the XML serialization, the ability to export the process model according to the XSD and rules of the spec, and ideally import from the XML as well.  IBM BPM 7.5.1 can do both.

[...]

The important thing, though, is not just the palette of shapes but the fact that Process Designer supports export and import of the BPMN 2.0 standard XML format.  (Oracle BPM 11g has had the BPMN 2.0 shapes for a year and a half and still cannot do that.)  I haven’t seen the XML yet but I believe that the export includes data objects, data inputs and outputs, data association mappings (assignment), and other details of executable BPMN 2.0. At least I hope it does.

A few new palette items have been added as well, though as Bruce notes, we’re still missing explicit representation of message flows.  I happen to agree with Bruce that this could improve the readability of IBM BPM models. And knowing how things are implemented underneath, I believe I’m qualified to say there aren’t really any technical barriers to having this “transparently” implement message flows, except to update some of the assumptions that go into the process canvas.

Great news, and great recap from Bruce.

Related posts:

1. Carrying the BPMN Interchange Torch
2. A BPMN 2.0 Update from Bruce Silver
3. BPMN vs BPEL round 15

Sam can’t really (in good conscience) make a Decision about any Vacation Request in isolation.  Only one Employee can be absent at any one time, so every Decision that Sam makes potentially effects all of the Pending Requests.  To be fair to everyone, Sam needs to take into account all of the Pending Vacation Requests before rendering a Decision on any of them.

And further:

Examples like these are what makes implementing “real world” processes hard.  Processes seldom execute in a vacuum, and work done within one instance often influences other instances.  Participants often have to consider multiple Tasks together, rather than performing each task in isolation.

He’s right, of course.  This is why a demonstration of a BPM solution can look easy, but the actual implementation actually takes real work and thought.

John purposely held back from suggesting a clever BPMN modeling solution or other trick of the trade to give us something to think about. I’ll give you my thoughts on how to approach the problem.   But in a general sense, this falls back into a general process pattern:

• a process model that does a decent job of representing one process “instance”.
• another process that manages the set of all processes
• yet another process that is the maintenance and improvement of the process definition and the management of process instances collectively.

What John is describing is a variation on the second level of process.  It already goes without saying that we need to manage a set of vacation requests collectively.  The extra wrinkle is that at a step in the approval process, the process should present context to the user, that likely includes:

• All pending and approved vacation requests for other team members
• Possibly other pending and approved vacation requests for people on other teams
• Remaining vacation days for this person
• Remaining days in the year in which to use those days
• Time since last vacation

All of this information gives the Approver context in which to make the decision.  The individual process’ execution flow hasn’t gotten more complicated. But the implementation details of that Approve step got more interesting.  Luckily, the information above will be pretty easy to provide if your BPMS had reasonable tracking and introspection capabilities.  So if we simply invest some trust in our user, and supply them with the information they need to make a decision, we’ll get really good outcomes with minimum implementation headaches.

Sometimes the really interesting bits in a process implementation aren’t in the BPMN.  As John points out, we shouldn’t assume that every detail should be captured in a BPMN model.

Related posts:

1. Simplify, Please
2. John Reynold’s Implementation Dream Team
3. Too Important not to Cross-Link: Activity Data

The process above is not an extremely complex or hard to understand BPMN Process, but it is a perfectly valid one. BPMN was fully intended to support such modeling. So what is the problem? Why are there complaints about BPMN?

Look, BPMN has more complexity than it needs to have for many uses, and less complexity than it needs for other uses, but I’m with him on this one.

Is it too complex to use for simpler models? No.

Do these simpler processes require too complex a BPMN model to be understandable? No, they do not.

To me, the focus on complexity is a bit off.  The issue is expressiveness.  I don’t think that BPMN is too complex for the expressiveness it provides.  What makes one tool better than another has a lot to do with its expressiveness.

Stephen has it right when he says “The burden, then, is not on BPMN as a specification, it is on companies that develop process modeling tools or methodologies to help their users effectively create business processes – using the BPMN language.”  (Of course, it would help if the spec writers don’t get too carried away, and actually take a break for a while to see how BPMN2 shakes out before starting on a new version).

He has it right because often these simpler conceptual models evolve into more complex executable models (or just more detailed models), and it is reasonable that the same people who understood the simpler model want to be able to see and grasp how the more complex versions relate to the original simple model.  As we’ve commented before, most business users can get by on just a fraction of the BPMN language.

Related posts:

1. Takedown: Bruce Silver has had enough of the BPMN vs. BPEL Debate
2. IBM Fulfilling BPMN 2.0 Promises?
3. Large Models in BPMN

Sure, maybe there were only 3-4 BPM standards going to 5 when BPMN was introduced… but now there’s BPMN 2… and one gets the feeling that there will be more!

But Gosling has a fantastic repartee that even more closely nails it:

Tell me the BPMN 2 specification doesn’t feel like that…!

Related posts:

1. Universal Translators, Open Source, and BPMN 2
2. BPMN too Complex?
3. Another take on Process Modeling… it’s a Process.

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.

Related posts:

1. When Does a Pattern Become a Process?
2. BPM Design Pattern: Buffering
3. Decorator Pattern for BPM

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.

Related posts:

1. IBM Fulfilling BPMN 2.0 Promises?
2. BPMN 2 Examples Courtesy of Camunda
3. Universal Translators, Open Source, and BPMN 2

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.

Related posts:

1. Good Presentation on Mixing Rules and Processes
2. ebizQ Podcast with Anatoly
3. Anatoly’s Anti-patterns: Sure Message Receive