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.

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.

Every so often, someone makes the argument that essentially nothing has changed in the world of BPM.  Actually, this isn’t unique to BPM – it is a common refrain across all kinds of software categories.

And it is tempting to buy into this, when you realize how durable a writeup like the history of BPM can be (this isn’t a bad writeup, by the way). But one has to remember that history *should* be a bit durable with the passage of time. Jon Pyke recently opined that no one in BPM has anything new to offer.  But the substance of his post is that the marketing isn’t differentiated, and the product positioning isn’t differentiated, and further, that the people who work at these companies don’t know what differentiates them.

Having worked on both sides of the coin (on the software side and the consulting side), I have to disagree with some of Jon’s conclusions because the input data is more limited than he’s realized.

For example:  of course the marketing messages are commoditized among BPM vendors, as is product positioning.  Sadly, it is perfectly easy to copy someone else’s marketing and positioning – it takes minutes, hours, or days at most to do so.  I think the tragedy in BPM is that all the vendors seem willing to implement “checkbox” versions of every feature that analysts care about, rather than go deep with the product in areas that produce real value for customers.  Unfortunately, vendors have been largely rewarded for such behavior with good product comparison reviews and chart placement – but their customers have not been similarly rewarded by this kind of investment.

There are real differences in these products, but it requires a much more in-depth understanding of the products to appreciate it.  Can we be surprised that customers have a hard time achieving this level of product knowledge during the evaluation process?  I used to work with someone who was always telling me how “nothing had changed” in the last 5 years in BPM – at a time when, 5 years before, there was no BPMN – and at that time, BPMN was the de facto modeling standard for BPMS offerings.

There has been quite a bit of innovation in the last 10 years in BPM, but some of the best ideas didn’t get enough investment to go from interesting to indispensable, and some of the best ideas really were commoditized – picked up by all the pure play vendors (and later, but the stack vendors).  I could argue that nothing much has changed since 1994, when I wrote a sales process application that leveraged Lotus Notes VIP to replicate sales data and manage workflow between Sales, Sales Engineering, Manufacturing, and R&D.  But that would be a bit disingenuous. I could write that solution in 1994, but I didn’t have a way to communicate the process to the business (BPMN), that accurately reflected the implementation so we could make sure we had it right.  And I didn’t have a standard data representation for analyzing the process data (for business process improvement).  I certainly couldn’t handle in a trivial way a process that required parallelism the way I can with executable BPMN models.

Jon says:

That’s why, and I’ve said this many times before, BPM is far too important a topic to leave in the hands of product vendors – this is a Business thing – the clue is in the name BUSINESS PROCESS MANAGEMENT. [...] They will talk about the presentation layer, the SOA integration support, analytics, modeling and what have you.

This is, unfortunately, true of a great many people in the BPM ecosystem.  However, it doesn’t sound like a few of the pure plays that have been acquired (take a gander at Phil Gilbert’s blog for several essays on the subject of business taking control back from IT), and it doesn’t sound like some of the new vendors (ActionBase as one example).  Whether these vendors are well-represented at Gartner conferences is another question entirely, but it is ironic that it is typically the small vendor that is more focused on business value. One of Jon’s last points:

Every vendor believes they are unique but the fact of the matter is many of the software metaphors used in these products were defined by pioneering workflow vendors such as Filenet, Staffware, Plexus and Wang

Well, honestly, software metaphors are meant to be re-used, so I’m not sure that that, in and of itself, is a point of criticism.  For example, some of the metaphors in older integration technologies like CORBA and DCOM are embodied in SOAP and WSDL – but not many would argue that web services weren’t a step forward. And if BPM functionality is truly commoditized – is that bad for the customer and the industry if it becomes more standard and more cheaply available?

I know it is tempting to look at the glass as half-empty, but with so many BPM vendors performing so well in a challenging environment, its hard not to look at the glass as half-full. Call me an optimist.

Sandy Kemsley has a few good updates on these topics.

In the first, she releases a review on IBM’s BlueWorks online community for BPM.  Some of the interesting tidbits:

• IBM BlueWorks uses Flash.  Interestingly, Lombardi started with a flash interface (and it was a very slick prototype) and scrapped it for GWT/Ajax.  Why?  Because Flash was just not stable enough to support what they wanted to do (even in the early stages), and they could see that they were going to run out of “room to run” with Flash, whereas in GWT they felt the sky was the limit in terms of layout and functionality over time.  Quote from her blog: “The process designer is Flash-based, and it only took me about 5 minutes to crash it; luckily, it saved as I worked, so I didn’t lose any work.”
• She gives pretty good marks to the content they included, which might form the basis or significant contribution to a CoE.

Speaking of BPMN modelers in the cloud… Sandy followed up with a good post about why locating your hosting services in different locales matters (a lot) to customers.  Although I can point anecdotally to data points (companies) that don’t have an issue with the location of servers (unless it affects performance), I can also attest that quite a few customers in other geographies *do* have an issue with hosting location.

Hopefully as these services mature they can offer more options for their customers.  Certainly IBM has the global reach to put its cloud / community offerings in as many geographies as it needs to to be sufficient for its customers.

A research paper was recently published, which purports to research improving the traversal of large hierarchical process repositories.  After a good introduction and background to the topic, the authors quickly jump to IDS Scheer and IBM’s Websphere as examples of BPM tools.  And next, the authors jump to the conclusion that 3D modeling will solve the problem of complex modeling in BPM.

However, the evidence presented is incredibly unconvincing.  3D modeling may hold some promise for BPM, but the examples presented don’t look more understandable to me – they look less understandable. It seems like, conceptually, 3D might take advantage of our innate spatial relationship capabilities and render complex things more understandable… but that isn’t what comes across from the examples in this paper.

Much more powerful than “3D” is the concept of containment, and representing containment. Containment is a form of abstraction that allows me to talk about the behavior of a black box, but then shine a light inside the black box and you can see additional details at a finer granularity, only if and when you choose to.  Containment is the key abstraction needed for understanding large models, and 3D just looks like a fun science project by comparison.  Abstraction by containment is a big part of how we process geography, maps, and directions… and process flows are a geography (road / map) of sorts.

Meanwhile, we’ll have to keep waiting for the silver bullet for making large complex models more understandable or accessible!

Pretty interesting update from Joram Barrez on jBPM – looks like it now supports BPMN2.0. (or, more accurately, it will come January 1st).

Its a pretty interesting look under the hood of one of the top open-source solutions in the BPM space.  The BPMN2 implementation uses the jBoss PVM (process virtual machine) to execute the BPMN, rather than transforming BPMN into BPEL  or JPDL or some other XML format.

jBPM also gives the developer a good Java programmatic interface into the BPM engine implementation (and, the processes it runs).

This sort of development effort does make me wonder if, eventually, we’ll have a fairly standardized open-source BPMN engine with commercial products that incorporate it in different ways (picture Apache or jBoss as examples, or the WebKit in the browser world).  Hard to say if jBPM (or key pieces like PVM) will turn out to be that open-source engine of choice, but at least from the blog posts it seems like they’re taking an intelligent and focused approach.

Its hard to keep this argument buried, as Bruce Silver demonstrates in yet another post on this subject, reacting to yet another response from the BPEL crowd.  I was going to respond directly in his post here, but for some reason I couldn’t comment on his site today.

Bruce makes the killer arguments:  only a subset of BPMN is “isomorphic” to BPEL.  Quite simply: BPMN allows the author to represent process flows that BPEL cannot represent accurately in a model-preserving fashion.

There was an argument put forth that wouldn’t these limitations be true of proprietary execution implementations as well?  And the answer is – perhaps – if those execution implementations don’t account for tricky stuff like interleaving (my experience is, that they do).  The difference (mainly) is that these “proprietary” execution implementations speak BPMN natively and were designed from the ground up to support the use cases defined by BPMN. The same cannot be said for BPEL and the engines which implement primarily BPEL. An engine could do both – but I don’t think the right answer is translating BPMN to BPEL to get there.