Alberto Manuel’s excellent blog takes on the “year in review” post before anyone else this year!

He’s clearly a fan of the emergence of the ACM meme, and not a fan of the Social BPM meme.  He takes issue with BPMN2′s complexity:

BPMN 2.0: Well the new standard finally hit the cloud doesn’t it? I hate BPMN for the following reasons:
- It takes more time to draw a process with BPMN that other process notation language;

- Never provided 100% compliance with BPEL and XPDL, providing data loss when importing the never ending, complicated, difficult to understand flowcharts (read my previous post on Antiamba about this).

Anyway despite all the clutter provided it’s becoming a standard, because BPM community never cared about how processes should be mapped.

Well, I don’t fault BPMN2 for not complying with BPEL – that argument has been fought and won – BPEL doesn’t represent everything BPMN can represent without losing data/information – that’s a deficiency of BPEL’s representation more than BPMN’s.

I wouldn’t impugn the intent of the BPM community to having “never cared” about how processes should be mapped.  Bruce Silver, for example, is part of the BPM/BPMN community and he clearly cares (and has the classes and writings to prove it! ).

I’m also more optimistic about the PKBoK effort than he is (although, the name seems horribly circular and redundant…. ).   These types of efforts take a long time, however, so it isn’t like anyone should be waiting on the output of PKBoK to get started on their BPM initiatives!

I’m not quite ready to look back on 2010 and sum it up.  That’ll have to wait til  a bit closer to end of year.

Paul Vincent on BPMN 2 events (all 63 types of them) :

OK, “63 types of event” needs a bit of explanation (and justification). These consist of:

• 13 main event types: untyped, message, timer, escalation, conditional, link, error, cancel, compensation, signal, multiple, parallel multiple, and terminate
• … across 8 situations classified by location in a process:
• Start: top-level, event sub-process interrupting, and event sub-process non-interrupting
• Intermediate: catching, boundary interrupting, boundary non-interrupting, and throwing
• End

… but with some situations not requiring certain types of event (e.g. there is no “start cancel process” event) leaving58 63 event types defined [*1].Presumably BPMN tools will let the user specifiy the main event type and associate the correct symbol from the context in most cases, leaving us to consider just the 13 main event types.

Paul is right: 63 is too many. But I think he also hints at the right answer: the tooling should be able to pick the right symbol based on the context of the detail of the event (or conversely, show the author the right context if they pick a specific event).  But there’s no reason for anyone to know 63 event types off the top of their head.  In fact, they really don’t need to distinguish between all of the 13 “main” event types in most cases.

It is up to the BPMS providers to make the authoring experience powerful and yet simple enough to be manageable and useful.  If the notation has gotten away from us a bit, then software can help reduce it back down to something manageable.  One interesting aspect is that many of these event types are not currently supported by BPMS vendors-  so depending on which tool you’re using you can cross off a lot of the potential event types!  That isn’t exactly what I mean by “simplifying” but it is one way to get there, I suppose.

Bruce Silver is the gold standard for BPMN modeling training.  He also often gets the last word on subjects relating to BPMN:

All of the recent to-do from Jim Sinur and others about how business people don’t want to be constrained by no stinkin’ rules is just one side of the story.  The people who come to me for training have a different view.  They say, “We have lots of groups in the company doing process modeling.  But everyone does it their own way, and the models can’t be shared or integrated with each other.  So a lot of our investment in process modeling so far can’t really be leveraged.”

Bruce goes on to describe, quite eloquently, what I believe is one of the chief attractions of BPMN:

The value of the hierarchical style is that you can visually understand the end-to-end process (and its touchpoints with the global environment) on one page, and zoom in and out to see detail at any level… all within the confines of a single semantic model. It reflects what could be called an “architectural” approach to process modeling, the way business architects and enterprise architects like to think about it. In contrast, the traditional approach, creating separate high-level and detailed models, requires continual manual synchronization as the model(s) evolve over time.

Not everyone sees the value in the single semantic model.

I’ve also seen value in building process models for several related processes (a process cluster, if you will), and then rationalizing these individual processes with a larger conceptual process that contains and incorporates them all.  The rationalizing often uncovers interesting corner cases and use cases that weren’t previously well thought-out- and also uncovers serious opportunities for re-use at the implementation level.  This approach more frequently happens in BPM projects that evolve into programs, but can also happen within the context of a program that explicitly decides not to try to tackle the (admittedly) harder problem of having all the processes within a cluster participate in the larger process and so they get their feet wet with processes in isolation at first.

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.

Antiamba’s Ligurio says that “BPMN can bring death to your process“:

The problem lies that BPMN is so complex to implement, that people made some workarounds, simplifying process maps. If a business process needs to be mapped (some don’t like ad-hoc) it should be done in a way everybody understands it, and it can be exchanged using multiple platforms that support process notation. Once it does not happen, there is a high risk of losing process data, because you can’t use things like intermediate message, or timer, that was represented in the process repository you need to move. Thus, you are sending your process data to oblivion (and BPEL, if used, also).

If process map is an asset, imagine re-training people that work in call centrer executing business processes by the book, telling that the decision gateway changed to something different, because process maps were updated to other tool. This has an impact in the way people perform tasks and in customer perception how the company execute. If process managers don’t have this concern they are very far from process execution where everything happens.

I can definitely relate to his criticisms of the tools around BPMN.  We have a problem in our business right now.  Almost every BPM software package supports BPMN.  But what does “support” mean?  It usually means, the BPMS uses a subset of BPMN notation standard.  Anything produced would be BPMN compliant.  However, it does not mean that ALL BPMN notation is available.  Therefore, despite two tools speaking a “common language” there may not be a 1-to-1 translation of a BPMN model in one tool to a BPMN model in another tool.

The definition of BPMN 2 will help.  By defining a storage format, it gives vendors a more concrete target to hit in terms of export/import.  And it will make missing BPMN icons feel more like a bug than an annoyance.

But Ligurio takes the criticism to BPMN, rather than, primarily, the vendors.  Vendors have got to get their act together and embrace BPMN 2 more fully. He blames BPMN for allowing you to model things so many different ways – but in a modeling world absent BPMN, this problem is worse, not better.

Earlier in his post, Ligurio criticizes Blueprint for its Visio importer being less-than-perfect.  However, keep in mind that Blueprint is importing native Visio XML.  This is not some standard BPMN XML that Blueprint is importing – because Visio doesn’t produce it, despite using a BPMN stencil.  He seems disappointed with the idea of manually choosing that one kind of gateway icon maps to a split, or a decision gateway, rather than Blueprint just guessing.  Keeping in mind that Visio can label anything a split or gateway, regardless of what it truly is, this seems to be asking a bit much.  It isn’t as if you have to choose the mapping for every occurrence of an icon – just once per type.

The more accurate criticism is that Blueprint doesn’t (yet) support things like complex gateways and attached events (and pools vs. lanes).  I know the Blueprint folks are trying to avoid these “advanced” use cases, but if they want Blueprint to stay relevant as users get more advanced or import valid BPMN diagrams from other tools, they simply have to add this functionality or risk becoming irrelevant. Having said that, Ligurio’s example diagram has a sequence flow crossing pool boundaries, which looks like a no-no according to the BPMN spec (they often get over-used in tools where they are supported).

He runs into similar issues with ARIS and ITP Commerce.  Bottom line: he has a 25-page process. It will clearly get mangled in import routines today, and require lots of manual work to clean up.

My advice:  for now, stick with one modeling environment.  Choose one that starts with modeling and lets you seamlessly add execution details.  If you use a “modeling only” environment it should stay at a very high level to work out concepts and disagreements – not to model execution-level details.

BPMN2 model portability, along with the diagram interchange format, will help these problems greatly.  But the commercial vendors have to step up their game to support a much larger subset of the BPMN specification if they want customers to consider them compliant.

Meanwhile, it isn’t BPMN killing your process.  It is BPMN exposing the problems in process definition and communication that were always there – but going unnoticed.  They’re now coming to light, and vendors have an opportunity to really address these issues.

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.

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.

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.

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:

1. value stream mapping
2. outlines
3. process mapping a la Six Sigma (inputs, measurable outputs, of a linear view of the process)
4. 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.

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.

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

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.

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.

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

Jakob Freund of Camunda debunks the notion that BPMN doesn’t work, after detailing a good story about deploying a BPM project with a German manufacturer:

So why do I tell you all this, apart from soliciting our stuff  . It’s just that I have recently read some blog posts, articles etc. about BPMN, following discussions or even (wannabe) “flame wars”, that deny BPMN’s capabilities to serve as an improvement for business-it-communication. But most of those authors do not seem to have any real project experience with BPMN. Well, maybe I am wrong. I just thought I should tell the world that there are enough people out there who do not have any programming skills at all, but use BPMN the way it is meant to be used, and it works.

So BPMN is no silver bullet, and must be improved, I totally agree with that. But it is a step in the right direction that we should benefit from instead of asking for the business-it-silver-bullet that cannot become reality anyway. Sometimes I think we ask for magic solutions and then moan about getting fooled by vendors…

I wholeheartedly agree. Thank you, Jakob, for sharing with us-

When I worked for a BPM software vendor, I often told people that I wasn’t too worried about open source software because BPM is a different animal than many other software categories-  user experience is critical;  the problem-space is wide, rather than narrow; and it requires seamless coordination of many different activities, rather than just a few activities.  Add to that, the standards and specifications hadn’t firmed up yet, as they had for databases.

However, the environment is evolving:

• BPMN 2.0 provides what might be the first standard that is complete enough for open source software to use as a basis for competing with the commercial vendors
• User Interface software development tools have improved.  It is easier to produce visually appealing applications that run inside a browser than it ever was before (thanks to HTML 5, AJAX, and several libraries built to leverage both).
• The cloud makes potential deployment of complicated software components easier to manage.

This sets the stage for a new round of open source software projects.  Tom Baeyens and Joram Barrez (formerly of the jBPM team) have joined Alfresco and are building a new BPM solution with a tight integration to ECM (Alfresco) in mind. They’re calling the new effort “Activiti”, just announced yesterday.  The alpha is already up on their website and downloadable.

Sandy Kemsley was briefed last week and has a very good summary written up.

I also had the pleasure of a briefing – quite flattered that Tom and company thought of us as well.  There are a couple of developments with Activiti that I already find refreshing:

1. They’re using a version of Signavio’s modeler.  Gero Decker’s team produces one of the better web-based BPMN 2 compliant modeling tools out there.
2. The installation process was pretty painless – even on my Mac – for a developer.  You need Java and Ant to run the install and build the demo, but clearly it would be a small effort to create a consumer-usable installer if that was warranted.  Since the install is really for the server components, I don’t know if an end-user consumable install is really necessary. Authors would just point their browser at the server.  Did I mention that the whole stack ran just fine, natively, on my Mac as well as a Windows VM?
3. The documentation is already pretty comprehensive, and gets down to no-nonsense details (not true for many commercial products).
4. There’s already a REST API.  I like the early emphasis on interfaces, APIs, and framework – because that effort will be rewarded by making it easier for contributors to be productive.

There’s still a focus on embedding the engine inside other software – and on more liberal licensing terms (Apache license) that should make it easier for software companies to adopt it.  And I think the market is ripe for an open source BPM platform that leverages standard underlying technologies and is built from the beginning to allow for cloud-based deployment.  I think they’re off to a good start to create something that is really developer-friendly.

So what are the concerns?

1. It isn’t clear (to me, yet) what the long-term involvement / direction of Signavio is – after all, Signavio has a for-profit business of hosting modeling in the cloud.  But at some point I think a true open source project will want to be able to improve on the modeler as well as other components at the engine level.
2. There’s a lot of work yet to do. Right now much of the engine isn’t yet implemented.  This is actually apparent from the documentation – and I love that the team had the courage to expose what they have, and what they don’t have ready at this point.
3. Earlier I mentioned developer-friendly… what about user-friendly??

Well, as to the last concern, I’ll give my 2 cents.  I think for a commercial product, user-friendly is one of the out-of-the-gate concerns. For an open source project, developer-friendly has to come first – because if it is developer-friendly, then additional developers can join the team and build the user-friendly layers.  If you start out with something relatively user-friendly but not developer friendly, it is as though you were “charging” your developers more to work on your software – because they have to give up more of their time before they can produce something useful.

Already two of us at bp3 have downloaded the alpha, installed it and run it.  We may end up investing some time in the project ourselves.  Clearly Alfresco and the other companies involved in the project are putting a lot of energy into this effort, and more PR behind it than I felt jBPM ever got as part of RedHat.  They’re off to a good start, with ambitious goals – and as they say, dream no little dreams…

Dr. Stein of Aris BPM Blog:

Computer users love to challenge each other by starting totally useless “flamewars”. Just think about how emotion comes up if people discuss Windows vs. Linux, Extreme Programming vs. classical software development, iPhone vs. Android, PHP vs. Ruby or EPC vs. BPMN. Wait, EPC vs. BPMN? Yes, I noticed several times that people have very strong feelings about both process modeling notations and tend to favor one over the other. For example, both groups (EPC lovers and BPMN lovers) claim that their notation is more expressive than the other one. But how could that be? Is one group lying? Or is there just a big misunderstanding?

I’ve personally never noticed this EPC vs. BPMN debate.

Bruce Silver writes:

I failed, but Robert Shapiro has carried that effort forward in the Finalization Task Force phase, and today he succeeded in getting it on the ballot.  You can see the proposal here. What that means is that in a few days, FTF members will vote to either approve the inclusion of these process modeling conformance classes in the final specification, or not.  There is still some opposition to the idea, mostly from vendors who may not be able to claim conformance with all of the classes in their first BPMN 2.0 release.  So there is a chance, maybe a good chance, that this will not pass.

So… If you want to see interchange of BPMN 2.0 models between tools, you need to make your voice heard, and quickly.  There are twenty-some voting members of the FTF, including IBM, Oracle, Lombardi, Tibco, Global 360, Fujitsu, SAP, Cordys, Red Hat, CA, HP, BizAGI, iGrafx, Camunda, Trisotech, NIST, and MITRE.  If you are a customer or partner of any of these organizations, please urge them to support the BPMN2.0 Process Modeling Conformance Class proposal.  Time is of the essence, as the vote is in the next few days!

I agree, this is important, and it will be harder to get it done later – no time like the present to push your voting members to vote for this.  Thought this battle was already lost, but it has one more shot before the final spec is approved.

Dave Duggal attempts a take-down of BPMN in a comment on Keith Swenson’s blog, concluding with:

“There is a reason why business leaders are suddenly have wandering eyes, they don’t think BPMN is the vehicle for the component-based distributed future.”

I humbly refer you to Bruce Silver’s blog for a quick rebuttal.  The market is adopting BPMN more than ever, and at an increasing pace.  Better to spend your energies figuring out how to make BPMN more effective (in combination with whatever other techniques you recommend) rather than making your recommended approaches an either-or proposition.  I think I’ve been hearing about this component-based distributed future since CORBA. I’m all for distributed and component-based, but I don’t hear an either-or proposition, and this doesn’t sound like business-leader language.

The question business leaders ask is will BPM and BPMN yield ROI? and the answer is yes.