Lots of news on the Activiti front lately.

First, Tom Baeyens has a list of what industry experts are saying about Activiti.  I was even mentioned in this summary – a sure way to get a mention in our blog ;)

Next, Tom announces that Beta 1 is released (Nice to be out of alpha!).  It includes a release of Activity Cycle, contributed by Camunda.  Pretty good stuff.

All of this is followed by a re-org of the wiki, and the announcement of the first iPhone App for Activiti.  I’ll just say I think the iPhone app follows the obvious path – I’d like to see something a bit more… creative… but you have to start somewhere, right?  I’d like to see something a bit more dynamic… maybe I’ll have to write an iPhone App though before I criticize someone else’s efforts.

Seems as though progress on Activiti is going well.  Congrats to the various contributors -

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.

If I know Tom Baeyens, he’s pretty happy with this blog post announcing the collaboration of Activiti and Camunda on “Activiti Cycle”.  Previously, Camunda had announced Camunda Fox, a set of tools to help accelerate using open source software for BPM, while pursuing business-IT alignment.  Cycle has been proposed as the name for the collaborative authoring of Activiti processes, and Camunda has now become the lead developer on that feature set.  This sounds like a win-win for both organizations.

Recently Bern Ruecker’s article on “A Collaborative Approach for Real-World BPM” appeared in InfoQ. It is a good read, with much I agree with and just a few things I don’t.

We have been working in the business process management (BPM) space for years already, and it is very interesting to see the recently growing attention for it. Catalysts for this interest may be the growing maturity of the tools, the new 2.0 version of the BPMN standard, better understanding caused by more publications or improved preconditions for BPM approaches, to name only a few of the most important developments within BPM.

Couldn’t have said it better myself. Bern goes on to criticize tools that they’ve worked with:

Vendors offer more and more high-sophisticated graphical tools, which promise automation of business processes without any coding or even developers; however, we see a problem with these “traditional” vendor centric approaches: They don’t deliver on these promises!

Agreed.  But of course, most vendors don’t promise “no code” – but they do often claim that someone less than a true “developer” can deliver the solution.  In my experience, while these tools do enable personnel with less technical training to participate in the process development effort, there is no such thing as someone “too technical” for a BPM project.  Good technical help is important in any project involving information technology.  He goes on:

Without naming the concrete tool, which wouldn’t be fair since most of them share the same basic problems, a colleague had to implement an easy process with a small web GUI. The tool introduced an own magic Drag and Drop GUI designer, which seemed to be handy in the beginning, but when we almost finished the project, there were some small data validation requirements in the form, which the magic tool wasn’t designed for. In an attempt to get around these limitations, we spent more time futzing with the designer than we needed to implement the entire GUI in plain JSF, which we did in the end anyway.

I can understand his feeling here.  However, I have worked with at least one tool that has such a drag-and-drop GUI designer.  It is great for prototyping UI, as it requires no code to marshal data into and out of the the process context on the server.  There is also a validation framework that does just about everything imaginable for validation (but, admittedly, this validation framework is something only experts on the platform would know about).  There’s also an option to validate forms after submitting (in the event that validation can only be accomplished with server-side checks or more complicated business rule evaluation).   My concern with the statement above is, though it may be true for a single tool – a good understanding of the BPM software being employed, combined with good understanding of requirements, and with healthy value-based prioritization of work – should allow one to avoid rewriting the entire GUI in something like JSF.  Of course, in Bern’s specific situation it may have been necessary, but I believe that on the whole we’re better of leveraging the baked in capabilities of a BPM suite rather than writing custom interfaces in JSF (or other UI tech).  The exception being, if the customer is already an expert in the custom interface technology (already using JSF in their organization? great).

We, as BPM practitioners, have to keep in mind that it is not about the technology we’re most comfortable with, it is about technology our customers can consume, maintain, nourish, and build on.

Bern goes on with another anecdote:

For another customer, one developer told me, “It took more than two days to try to model some special requirements, which he could have written in Java directly in half an hour!”

I’ve heard this thousands of times.  9 out of 10 times, the developer is wrong, or missing the point.  Once in a while, they’re right.  But the point isn’t to bury the business model in Java code (wrong), or to put what should be Java code into the business model (missing the point), it is to use the model to represent what is significant to the business process, and to use code to represent (primarily) what isn’t.

Another customer tried to get transactions and stateful services running, which unfortunately required calling services as Web services. After experimenting with WS-Addressing, WS-AtomicTransaction and trying to patch several frameworks, he basically gave up and dumped the whole BPM tool.

I wish I knew which tool so that I can avoid it!  A decent BPM tool should include good coverage of web services scenarios.  And a Java API.  Bern’s article is a cautionary tale of products that don’t live up to the promise of BPM.

Bern goes on to argue that a BPM tool should be making the developer’s job easier, not harder.  While that may be true, I think the framing is wrong. The framing we would use is that a BPM tool should allow a model that accurately portrays the process to the business and also accurately represents the execution context required to run the process.  If it is harder for the developer to provide visibility to the business, that’s secondary to producing something that has high-fidelity between business model and IT reality.

Bern goes on to describe a solution that he calls “Camunda Fox” – which pulls together various other technology, including JBoss, jBPM, Signavio, and a glue layer created by Camunda.  It seems like a reasonable approach for a very technically competent team to tackle – especially a team that is intimately familiar with the technologies in question.  But it is a model-transforming approach with several inputs and outputs.  And this approach isn’t going to address the needs of a smaller business or smaller team that doesn’t have these technical skills, nor the budget to pay outside consultants to build and leverage this glue – I think Bern might argue that the “simpler” BPM tools won’t address these customers well either.  As Bern says, Camunda Fox isn’t a silver bullet, but it addresses projects that are pretty Java development focused.

I prefer to use BPM tools with a model-preserving approach (as described by Keith Swenson) because it is a higher fidelity mapping of business process to running software.

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-