Process for the Enterprise » BPMN

Universal Translators, Open Source, and BPMN 2

Scott Francis — Tue, 07 Sep 2010 14:27:49 +0000

Bruce Silver has recently posted his latest efforts to perform BPMN model interchange. It has been a recurring theme on his blog, BPMN 2.0 and its potential for interchange, as well as XPDL’s capacity for interchange. Recently Bruce went on vacation and spent his time in a rather dubious way (just kidding, Bruce!):

On my summer vacation I’ve been thinking a lot about the XML side of BPMN. While we usually think of BPMN as a diagramming standard, it is also – in principle – a model interchange standard, an XML format than can be exported from tool A and imported into tool B. BPMN 2.0, XPDL 2.1 (for BPMN 1.2), and XPDL 2.2 (for BPMN 2.0) all purport to deliver this. In reality, however, BPMN model interchange faces serious – some would say insurmountable – hurdles. I have been working on a number of tools to overcome these obstacles.

So the holy grail of model portability isn’t fully realized yet. But BPMN 2.0 does represent progress. He goes on to outline what has to happen to enable model portability:

1. An explicitly enumerated set of interchangeable model elements and attributes. The full BPMN 2.0 schema is too open-ended for unrestricted interchange. Fortunately, we now have such an enumerated list in the Descriptive and Analytic process modeling conformance classes in the BPMN 2.0 spec.
2. Modeling tools that unambiguously support all the elements and attributes in those conformance classes, meaning the mapping of diagram shapes and labels to the standard is unambiguous. We have a number of such tools today. My work has focused on two of them: Process Modeler for Visio by itp commerce, which supports both BPMN 1.2 and 2.0, and native Visio 2010 Premium, which is just BPMN 1.2.

I agree that getting a complete set of BPMN 2.0 elements explicitly enumerated is going to be difficult. And getting the modeling tools to support all the elements and attributes, not to mention exporting them as XML, is too much to expect from our modeling tool software partners. I believe the only way we’re going to get this kind of interchange is with an open-source project – because open source projects excel at eventually covering wide specifications as people volunteer to fill in the gaps. Interchange of data, and support for a wide specification, are both well-suited to open source projects – if they have the right framework in place that makes it clear how a newcomer can add to it (by, for example, adding a new exchange adapter). I can envision a pretty interesting model interchange utility that would read a variant of BPMN2 produced by some tool, and perform a little magic on it to produce “clean” BPMN 2. Then a second adapter that would produce BPMN 2 that a target BPMS tool expects. The author (say, Bruce) doesn’t have to solve all the possible interchange combinations, just provide a framework and an example, and see what other interchange adapters people will add to it.

That’s the beauty of open source – if you build the framework, and make it “accessible” to developers… then if there is a need for something, it will be built. If not, it won’t. Not too much wasted effort.

I See Business Professionals… Using BPMN

Scott Francis — Fri, 03 Sep 2010 05:11:47 +0000

So Jim Sinur really opened a can of worms the other day with his missive on BPMN, literally calling for it to burn baby burn – nothing like a gentle start like that to initiate a moderate discussion of the finer points of BPMN. I couldn’t help but respond both within his blog as well as on our own blog. I feel like Jim is letting the business off the hook – as he puts it – they don’t care about process, and they’re too busy making money to worry about process. I think this is a cop out. There is a comment thread on Jim’s blog that I’d recommend reading for the follow up discussion, and the original “burn baby burn” statement got walked back somewhat.

But the debate didn’t stay contained there. Keith Swenson chimed in, taking advantage of the opportunity to pile on BPMN. I can’t accept the black-and-white approach he is taking to the discussion, and so of course we had a bit of back-and-forth about whether BPMN is appropriate for no one in the business (his contention) or at least some people (my contention). I was challenged to name people within the business who read or write BPMN, which was quite easy to do, because this is the kind of stuff we do every day for work. I think the comment thread on his blog, and on Jim’s, or incredibly telling.

But there was also a great post from Neil Ward-Dutton on the subject, that captures my perspective perfectly:

Or – in other words perhaps – surely it’s not too much to ask non-IT participants in BPM initiatives to take a little time to learn some fairly straightforward modelling technniques?

From our case study work here I think what Scott is saying leads to a sensible, middle-ground answer – which is, that the applicability of BPMN depends on a number of factors; saying that BPMN (especially BPMN 2.0) either is, or is not, suitable for “the business” is too simplistic and black/white. It’s like saying Cloud Computing is the future of IT. Firstly it supposes that we have to talk about BPMN as an all-or-nothing proposition; secondly it supposes that “the business” is some kind of homogeneous organisation with one set of skills, experiences and inclinations.

I literally could not have said this better myself. He goes on to make another important point I agree with:

At the same time, though, there’s significant evidence to suggest that a core subset of BPMN symbols are absolutely usable by business analysts with experience in high-level analysis and design and provide great results in terms of delivering a common language across multi-disciplinary teams. I’ve come across many BAs who know and use (aspects of) BPMN as part of their armoury. They’re not “IT people” – they have business backgrounds and they work in line-of-business departments.

Great read from Neil.

In the comments on this one, Keith takes a nice shot at my assertion that understanding just a few BPMN shapes will allow you to read someone else’s thoughts on a process, or to communicate your own basic processes to others:

Also funny is the comment that learning six (or 7) shapes means that you understand the non-trivial interactions between those shapes at run time without needing the programmer’s insight into how systems function. That would be a little like saying that learning 26 letters makes you a Shakespeare, or able to read all western European languages. (But I must avoid use of similes since this apparently is sometimes confusing.) BPMN certainly is useful is some situations, it simply isn’t useful in all situations.

For the record, I don’t find Keith’s “similes” confusing at all. I find them inaccurate, misleading, and misrepresentative. And when we turn the analogy on its head, I think that proves how pointless they are. In practice, when people read Shakespeare they’re usually in school and get help from cliff’s notes, teachers, and fellow students. Not unlike those working with business processes and BPMN … and other tools (six sigma, lean, value stream, etc. ). Once again, I’ll point out that analogies are illustrative, they simply don’t constitute proof or refutation.

Jakob Freund of Camunda commented on Keith’s blog and summed up a reasonable reader’s interpretation of both Jim’s post and Keith’s post:

I think the main problem is that in both blog posts (Jim and yours) this very important distinction between “all” business professionals and “business (process) analysts” was not made. Analysts are not programmers but very often part of a business department, therefore a subset of “business professionals”. To throw all “business professionals” in one pot judging there skills in working with BPMN (or whatever) makes a good headline, but does not say anything useful.

Furthermore, there has not been made any distinction between “creating” and “reading” BPMN diagrams, and between the extremely different grades of complexity a process diagram can bear (please excuse my bad English).

But those are exactly the parameters you always have to look at when judging modeling approaches (no matter whether they are control flow – based, grids, prosa or what ever).

I guess it just comes down to this: BPMN is quite useful. It is even useful to people most of us would consider as “business professionals”. But there are other quite useful tools in our business process management space, and there’s no reason not to use each one when appropriate. I also recommend as practical reading, this post on practical application of BPMN by Jakob on his own Camunda blog. I liked how he closed his last comment:

cheers from my customer’s office in Germany (currently introducing BPMN in a 80k-people company, and huh, it works for Business people, but it’s bloody hard work to make that happen ).

Similarly, as I was writing on the same comment thread, I was about to head in to visit my customer, which also uses BPMN to communicate broad requirements between business stakeholders and IT. Regardless of what the theory says, the practical reality is our customers’ businesses are using this stuff.

Apparently BPMN is Too Hard

Scott Francis — Tue, 31 Aug 2010 11:47:23 +0000

Jim Sinur has thrown in the towel on BPMN in his latest post:

BPMN for business professionals is just not up to a business level of need. Some folks think that BPMN is good enough for IT and it should be good enough for business professionals. I think the former is true, but the latter is way off the mark.

BPMN really stands for “Business People May Not…understand”

IT professionals can’t really expect business folks to understand cryptic/standard formats when they really want to see a real representation of their processes with desirable icons; not engineering Icons. It’s kind of like someone saying “let them eat cake”. It is this IT arrogance that could sink BPM technologies.

Respectfully, I think Jim is letting the business off the hook. No need to learn any new skills over there on the business side, just draw something on a napkin and hope it turns into a process. Just make up any old iconography you want, no problem if no one other than you can understand it (you know, the value of standards is that more than one person or team can understand what is produced). Don’t bother to learn something that is about 10% harder than standard flowcharting (Bruce Silver has helpfully identified a subset of BPMN that is more appropriate for new-to-BPMN business users).

At a time when we’re asking IT to learn new skills and to be more business oriented, is it too much to ask Business to learn new skills to support process improvement? This isn’t unique to BPM – if the business is going to support ACM, they’re going to have to learn new tools for that as well. If the full BPMN icon set is too much for someone, use the subset that you understand and like to document your ideas, and make use of annotation. If someone shows you a diagram with more icons in it that you don’t follow, it should be straight forward to get an explanation or to look up the new notations you aren’t familiar with. While Jim may not be a fan of standardization of notation – business folks are plenty used to standards of notation (not just in BPMN). I use BPMN basic diagramming shapes to whiteboard processes for businesses all the time (literally on the whiteboard or in collaborative tools) – and they don’t have any trouble following what’s going on.

The problem isn’t that BPMN, as a notation, is too hard. It is that too many people think that BPM starts and stops with BPMN! There is so much more to managing business processes, and improving them, than BPMN. By way of comparison, think about search. Search is a highly technical subject with a very rigorous syntax. But nearly everyone can take advantage of its more simplistic forms – just typing in a few keywords into a Google search field. It doesn’t mean that they can’t understand a more complex query string when they see it, nor guess at the meaning of a phrase surrounded by quotes… nor understand the resulting page of search results (the outcome). In fact, if they find their need for search becoming more complex, they can actually endeavor to learn the more advanced forms (domain filtering, exclusion, wildcards, etc).

So let’s all agree that there is much that must be done in the world of BPM to address businesses better, but tossing out BPMN and letting business off the hook is hardly the solution. One need look no further than a tool like IBM’s BPM Blueprint to see that you can ease the business into BPMN style notation by first having them engage in process mapping or value stream mapping. You don’t have to throw out BPMN to do this. At the first company I worked for, we used to like to quote a line from a business book: “Genius of the ‘And’” – as in, why can’t I have both a simpler mapping notation, and a more detailed process execution notation that make sense together – instead of only one or the other?

It is time for everyone to step up to the plate in BPM, not just the software vendors. BPMN is part of the answer, but only part.

Something Besides BPMN for Requirements Solicitation

Scott Francis — Mon, 16 Aug 2010 18:31:04 +0000

Matt Harding of Aurora Energy just posted this on the SAP community blog:

Within business process modelling (from a detailed requirements and process design perspective), I believe the best option for business users is to use BPMN. But the question is: Are we just waiting for the iPhone of Business Process Modelling to come along.

I think Matt has a point – BPMN isn’t the best for requirements elicitation – it is the best for firming up an agreement between “Business” and “IT” as to what the process execution looks like. When we’re in the discovery/elicitation/collaboration efforts, we find it more useful to use simpler mapping approaches:

value stream mapping
outlines
process mapping a la Six Sigma (inputs, measurable outputs, of a linear view of the process)
mind mapping tools for doing associations or nested structures

Right now some of the best tools for doing this – besides white boards – are tools like IBM’s Blueprint, which doesn’t force you into a BPMN notion of things. It has separate views of process mapping and process modeling – and my main critique of the modeling section is that it needs to be more exact, whereas what I love about the process mapping side is precisely that it doesn’t require being exact. Another useful tool for brainstorming topics related to BPM: MindMeister. It let’s you brainstorm ancillary ideas to the process: how business objectives and values drive the objectives for the project. There are other tools that are useful for brainstorming project plans, etc.

Joins in Blueprint

Scott Francis — Sun, 25 Jul 2010 09:00:02 +0000

IBM’s BPM Blueprint folks recently posted a short video that shows how to create a “join” in a process. Its a painless video to watch because it is in double-time, but it definitely exposes an opportunity for improvement in how one goes about modeling joins.

It relates to our previous post on process patterns. This video simply shows how to leverage a basic BPMN construct (the join) in a specific collaboration and modeling tool (blueprint). But this is also one of the van der Aalst “patterns”, that, as I mentioned previously, I’d rather call construct than pattern. And I think everyone would benefit if we start to discuss patterns with more useful abstractions embedded.

A Word on the Meaning of Patterns

Scott Francis — Fri, 23 Jul 2010 16:51:50 +0000

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).

BPMN 2 Examples Courtesy of Camunda

Scott Francis — Wed, 21 Jul 2010 12:17:48 +0000

BPM Guide has some examples of BPMN 2.0 diagrams, on the heels of Stephen White’s blog post that the BPMN 2.0 spec has been ratified by OMG. Thanks to Jakob Freund for publishing them.There are a couple of key points that Jakob makes throughout the article, that I’d like to call attention to:

Creating process models for both business AND it is actually one of the absolutely main topics of our consulting business. And it is a very big struggle, of course. For us it was important to show in the document that BPMN is not necessarily “too complicated for business”, because it totally depends on how you actually use the standard when process modeling. That’s why we always need a Framework around BPMN if we want to apply it in bigger modeling engagements.

This is a well-said point – BPMN doesn’t have to be too complicated for the business. But drawing diagrams that are not more complicated than they have to be takes some skill and practice. I often tell people who aren’t familiar with BPM that it takes a reasonable degree of abstract thinking to really do well. It is the abstractions and generalizations afforded by a process and its subprocesses that comprise the solution.

Apparently they built these examples with Trisotech’s tools:

The diagrams in the examples document however are all made with Trisotech’s Visio-based BPMN Modeler, provided for this purpose by Denis Gagné. The cool thing is that we could directly serialize the diagrams into BPMN 2.0 XML with that tool.

Denis, where is this tool! Sounds interesting!

Jakob also gives interesting examples of how to take advantage of collaboration diagrams. His final thoughts:

Make a “strategic” process diagram (Figure 6.1), just a simple sketch for a quick understanding

Make an “operational” process diagram (Figure 6.2) for analyzing the collaborational aspects

Enrich the diagram with the aspects of a process engine, therefore adding a pool for the process engine

Take that process engine pool into your technical environment and enrich it for execution (make a “technical” process diagram).

Good advice for how to approach modeling in BPMN.

BPMN 2 Recent Links

Scott Francis — Thu, 01 Jul 2010 05:23:08 +0000

Surprised to run across this post the other day on the BlueWorks blog. Not sure exactly what prompted the timing of it, but it is a good introduction to BPMN and why it exists.

Meanwhile, Tom Baeyens has his first Activiti presentation available via slideshare and on his blog. Activiti is the new BPMN 2 open source project he is working on at Alfresco.

Alfresco/Activity Contributing to BPMN 2 Effort

Scott Francis — Tue, 29 Jun 2010 19:08:59 +0000

Tom Baeyens writes:

We’re very committed to BPMN 2.0. In fact, we’re aiming to build the #1 BPMN 2.0 process engine and deliver the full BPM Suite components, all available as open source.

Glad to hear it – I’m sure the world of BPMN and Open Source BPM will be the better for it.

Bruce Silver: Just Enough BPMN

Scott Francis — Thu, 10 Jun 2010 19:07:01 +0000

Bruce Silver writes about the “right amount” of BPMN for the business:

In a way, we’re still back to the question Michael and I were wrestling with a couple years ago. Do you want to limit the BPMN palette to what business users already know (or think they know) from traditional flowcharting, and allow them to bend the semantics and rules? Or do you want to raise the bar and say here is a common process language that can be shared between business and IT? That takes a bit of education or training, since they probably don’t already know how to use it properly. But it’s not rocket science.

He goes on to say that he prefers the latter. In general, I do too. Once upon a time flowchart symbols weren’t familiar to businesses either. People can adapt to new notations and skills. BPMN isn’t *that* hard conceptually.

Of course, using a subset for white-boarding makes perfect sense because you are in a conversation, and if you draw something that isn’t precisely the right kind of gateway but write a note next to it or explain what you want, the people in the room will understand. I use a form of shorthand BPMN when I whiteboard that works well for me. You know someone does this a lot if they draw the message events in one continuous pen stroke (envelope and all).