3 BPM Blogs You Want To Subscribe To

Here are some top notch blogs that I have *have* to recommend:

1) Leadership BPM by Rashid N. Khan

Last year, Rashid retired as the CEO of Ultimus and now he started a blog in which he shares his vast amount of experience.

During this period I was involved in 100s of BPM deployments worldwide and collected a wealth of experience. Now that I have retired from Ultimus, I want to leverage this expeience and help senior executives to learn about and benefit from BPM and related technologies. I have a unique perspective and I have been very focused on the practical, nuts-and-bolts issues about BPM that senior executives have to understand if they are going to fully realize the potential of BPM.

The nice thing is that he now can give an independent, unconstrained look on things. Opinions of that skill and which can speek freely are hard to find.

In What it will take to deliver BPM as SaaS?, he already seems to pinpoint the crucial conditions of the latest BPM as a service hype.

In my judgment BPM SaaS has to have the following characteristics as a minimum. First, it must have the ability to model and modify executable processes in a hosted application. The ability to design executable processes, in contrast to simple flow diagram, is pretty challenging. ... Second, BPM SaaS must have the ability to allow customers to integrate with their inside-the-firewall data and other applications. This is crucial because BPM deals with company’s data and interacts with other applications. Without effective integration only the very simplistic BPM processes are candidates for SaaS, and CxOs are reluctant to invest money or mindshare on simplistic processes. Integration is the Achille’s heel of BPM SaaS and solutions for this will evolve only gradually. Perhaps the best approach for BPM vendors is the emerging class of "application appliances" that leverage virtualization technology to deliver inside-the-firewall solutions on a SaaS basis. This has the potential of solving the integration problem. I will discuss it in another blog as this is a topic on its own. Third, and easiest, is the ability for end-users to participate in business processes using a browser. ... Fourth, BPM SaaS must provide a means for customers to monitor and administer their processes over the Internet. Again, with the emergence of AJAX and RIAs, this is not a challenging obstacle. And fifth, BPM SaaS must provide some web-based reporting, BI and BAM capabilities.

In Is the BPM Industry stuck in no-man’s land?, Rashid starts by pointing out that BPM systems didn't get to the mainstream as they always envisioned:

Even if I take a conservative forecast and assume that the market was $1 billion in 1998 and growing at 15% per annum, it should be at least $4 billion today. But the most recent forecast continue to put it in the $2 billion range. So where does all the growth fizzle away? Second, every BPM vendor and analyst can provide a number of actual case studies of BPM deployments that demonstrate remarkable ROI and productivity benefits. And it is relatively easy for senior management to understand why BPM can deliver such results. Yet the penetration of BPM in organizations is still small and I would venture to say that less than 10% of processes are automated despite all the ROI and productivity proof points. Third, every year BPM vendors claim impressive growth and publish a roster of new customers. Yet most pure-play BPM vendors are relatively small companies and none have been able to go public despite the claims of growth and the fact that many of them have raised tens of millions of dollars in venture capital.

This is exactly what I thought as well and in my opinion this is largely due to the fact that executable processes should be part of the software applications themselves. The big problem still to date is that BPM Systems are considered as monolithic applications that are hard to integrate into a software development project. That is exactly the problem that we have focussed on in jBPM since the very beginning. And indeed it is not an easy one. Rashid seems to come to a similar conclusion:

First, BPM sounds glamorous, but it is not easy. This is because human beings work in extremely complex ways. Developing software that caters to all these ways is not easy. The “human interface” of BPM is complex and challenging. Second, the IT environments in which BPM has to thrive are very complex, varied and in constant flux. BPM cannot be successful without seamless integration with the rest of the IT infrastructure.

I hope that Rashid keeps up sharing his points of view.

What's cool for me is that when I started jBPM, Ultimus is actually the first product I looked at to see what the competition was like.

2) Small steps with big feet by Joram Barrez

Joram is a BPM and jBPM guru that I had the opportunity to collaborate with on a few occasions. For all your jBPM performance concerns, make sure you read his blog or get him involved. He tweaked jBPM performance better then we did !

His latest blog Blogs about jBPM you don’t want to miss! provides links to a lot of interesting jBPM related posts that are very informative.

3) PlanetjBPM by Ronald van Kuijk (aka kukeltje)

Ronald provides great practical tips and tricks on jBPM. He's another BPM and jBPM guru calling himself rightfully the jBPM Forum Addict. In practice this means that he helped thousands of people getting started with jBPM over the last 5 years by answering basically every question on the jBPM user forum.

BPEL versus BPM

Pierre Vigneras wrote a nice article on InfoQ about how BPEL is not the right solution for BPM. As you might know that is what I have been saying for a long time. Also the discussion that follows the article is quite interesting.

Seven Forms Of BPM

My article Seven Forms Of BPM with JBoss jBPM just got published on dzone. In this article, I explain 7 distinct concrete forms of BPM. Some are more business oriented and some are more technical oriented. BPM is a hugely overloaded term, resulting in a lot of confusion. Hopefully this article helps to clear out at least some of the confusion.

If you don't like clicking your way through the pages, consider the printer friendly format of the article.

How Are Services, Data And Processes Tied Up in an SOA?

After reading InfoQ's report on Fred Cummins' essay about the data in an SOA, I thought the discussion could get a lot more concrete if we added an overview picture in the mix. Here's my take on how applications, services, data and processes are related.

Please ignore my absent taste for colour and drawing skills :-)

Applications and functionality is typically developed in application silos. Sometimes they come as Commercial Off The Shelf (COTS) products, sometimes they are custom build applications. Fred touches on an interesting topic with

"
Those who focus on data management have, for decades, driven the industry toward consolidation of databases under a philosophy that tighter coupling means greater efficiency and consistency.
"

Since the increased focus on integration technologies and SOA, there is a common misconception that tight coupling is bad. For integrating disparate systems, that is typically true. But inside of application silo's tight coupling is typically a good thing.

An application silo usually manages data and it includes support for the related business processes. These processes can be implemented by an embeddable BPMS or they can be just as well coded in a programming language. These processes can have all the characteristics of processes implemented on top of the ESB in e.g. BPEL. They are long running and transactional, they can include human tasks as well as service invocations to services on the bus and so on. Application silo processes are only distinct from the processes on top of the ESB in the sense that they are an integral part of the application silo and therefore they are hosted in a different environment like e.g. Java instead of XML/WSDL. That is where the value of the jPDL process language comes in. It's really embeddable and it integrates very nice with any Java environment. That's why jPDL is embedded a lot in Java based portals, Enterprise Content Management (ECM) systems and custom Java applications. It's really fit for this tight coupled Java environment.

Each of these application silo's typically has a functional interface that exposes the operations supported by the application. A User Interface (UI) can then expose the functional interface to users and the same functional interface can also be exposed to the Enterprise Service Bus (ESB) via a Service Adapter.

The main purpose of an Enterprise Service Bus is integrating disparate systems. So it's typically XML/WSDL based. If many events and service invocations are published on the ESB related to one business process, then it might make sense to track the overall process with an ESB-level process. BPEL is the ideal process language for this environment.

What not a lot of people realize is that the location of business process implementations can be freely picked. If most of the accessed functionality and data for a given process is related to one application silo, it might make much more sense to implement it inside of that application silo. Still in that scenario, services can be consumed from other systems over the ESB.

On the other hand, if the process must integrate with many disparate systems, most of the events are already published on the ESB and there is no application to which this process clearly belongs, then it's most likely easier to implement it as a BPEL process on top of the ESB.

The main point I have tried to make is that the implementation of Business Processes should not be tied to integration technologies (read: the ESB). They can be just as well located within the application silos.

This also exposes one of the difficulties in mapping the analyst's business processes to implementation level processes. Analysts draw boxes and arrows in a diagram and they are not really concerned with this architectural background that provides the environment for implementing those processes. So an analysis process still has to be mapped to executable process languages in application silo's or on top of the ESB. This is not always a one-to-one mapping.

Task Assignment And Pools Harder Then You Think

Workflows and business processes are often perceived as simple in the sense that non technical people can draw diagrams that can be executed. John Reynolds explain a typical example of task assignment in Getting tasks to the right participants - Part 1:

“When a Loan Application comes in, make the application available to all of our Credit Officers who have sufficient Lending Authority to process the loan, and who haven’t already met their quota of applications for the week. Of course if everybody has already met their quotas for the week, then let everyone have an opportunity to work on the new application.

One more thing, only a few of our Credit Officers can approve loans over $100,000, so don’t route low value loans to them unless they are the only available credit officers.

And don’t let anyone claim more than 3 applications at a time. Our Credit Officers are compensated for the number of loans that they process, and some of them will claim all the applications that they can in hopes of earning more money.”

This really sounds like a realistic task assignment to me. My point here is that it's impossible to capture this kind of logic in the business process diagram. It reinforces the message about process development that I've been giving for a long time. Analysts provide a description of a business process. Typically that is a diagram plus free text documentation like e.g. this kind of task assignment rules. Then it is up to the process developer to come up with an executable process that looks exactly like the business analyst's diagram, but this time it is an executable process. Iterative development can then be realised on the executable process. I don't believe that round tripping between analyst and implementation models is feasible for the majority of BPM use cases, especially if those turn out to be very different.

The second post that I refer to is Bruce Silver's BPMN to Requester: Get Outta My Pool. In that post, Bruce points out that BPMN swimlanes are in fact inspired by BPEL's partner links and that experienced business analyst have a hard time understanding those basics. In fact, I think the business analysts are right. Analyst models should not be constrained with executable details. If we want to create a notation that can serve analysts and process developers, then it should be nothing more but boxes and arrows. All the extra semantics that are added to diagrams only are targetted to either the analysts or to the developer. But those extra semantical decorations and concepts never make (the same) sense to both target audiences.

This really shows the scheziphrenic nature of BPMN. On the one hand BPMN aims to be a free modelling notation for business analysts. And on the other hand, it tries to map one on one to an executable service orchestration language like BPEL.

Brewing The jBPM Community

Our managers were a bit concerned at first. "Are you sure it's a good idea to have an IT event in a beer factory?". Of course it is...

Last Friday, we had the jBPM Community Day. A rememberable day it turned out to be. We assembled the full core of the jBPM contributors from JBoss and other companies at the Guinness storehouse in Dublin. More then 40 people showed up, of which half of them flew in specially for this event.

The three muscateers arrived. The first thing they noticed was this thing that looked like a spaceship mounted on top of the beer factory.

Finding the way to the room took some concentration.
But most of us made it before the Master of Ceremony kicked it off.
We gave most of the platform for talks to core members of the community. That turned out to be a bulls eye.

Joram Barrez started addressed any performance question that people in the audience might wonder about. Also he showed the value of how easy the Business Intelligence information could be extracted from jBPM process executions.

Next, Mark Proctor managed to sneek in a Drools-spy into our jBPM event.
Paul Browne talked about the situations where drools rules and jPDL processes make a perfect match. Both Joram and Paul are great speakers and they know what they talk about. Thanks a lot, guys!

Then it was time to do some sightseeing in the building.
And to taste the Guinness at the gravity bar (the space ship thing).
An awsome, full 360 degrees view!
After that pint of Guinness, my short talk was scheduled. Next time we need to have someone that pulls the plug when I go over my time limit again :-)

Then we splitted the audience in two separate tracks. The core contributors went to discuss the future of the project.
Ronald (aka Kukeltje) showed how to hold a Guinness so that your neighbour doesn't see it and with the other hand answering forum questions at the same time.

On a more serious note: this is where the most constructive feedback was generated. We had a great brainstorm session on how we can improve the migration path from jPDL 3 to the upcoming jPDL 4.

At the same time, the other people users got an introduction to jPDL from Koen Aers, the creator of the jPDL eclipse plugin designer.

The reception dinner closed a fruitful day.
Then we went down to the temple bar area and the Master of Ceremony found this great pub with live music.

But with strickt rules !
The 2BInternational team met with the locals and showed us that they had more moves then only in Business Process Management.

But then things started to get messy.
So I concluded it was time to stop taking pictures :-)

Oh... and there was a memorable close of this memorable evening. When walking to the hotel, I came across this die hard artist still out on the street doing a perfect inpersonation of Mark Proctor. Awsome!
Amen.

High-Quality Free BPM Book

Thanks to Sandy Kemsley, I found Michael Zur Muehlen has published his very nice e-book online. No registration required so definitely have a look at it. Even though the book seems to be a couple of years old, it includes a thoughtful and still very relevant description of BPM as a discipline and the relation to BPM software technology.

Dublin, Here We Come !

The jBPM Community Day on June 6th is starting to become a real international event with people coming from Belgium, The Netherlands, France, Germany, Italy and Ireland of course.

The program is updated and gives a good idea of what's going to happen. Also a list of hotels and activities is added (thanks, Paul!)

Don't miss it ! Be sure to registration quickly. It is as easy as sending an email to dublin@jbpm.org

BPM != BPEL

It seems to be a very stubbern misunderstanding that I have tried to straighten out many times before. But for those that didn't get it yet, even John Evdemon, co-chair of the BPEL technical committee said already in 2007 that BPM != BPEL and now in the recent BPMN discussion he adds: If you can do something it doesn't mean that you should...

HTH

Buzzwords In Pictures

Sometimes you can find good explanations of tech buzzwords in real life. So far, I found out what Ajax, SOA and backup really means.

If your HTML-over-HTTP-house is on fire, the Ajax hose comes to the rescue.


If your integration stinks like a sewage system, just put a SOA cover on it.


And a backup is even more vital then I ever imagined.

I'll translate for the non-dutch speaking: "Even mother nature provides a back-up" And in the round circle it says : "Test one month for free". Sign me up ! Sign me up !

Big Problems Ahead For BPMN 2.0 ?

Boris Lublinsky posted a good overview on InfoQ about the online discussions around BPMN 2.0 and it reveals IMO a very profound problem in traditional BPM thinking.

One group wants to give the graphical process modelling notation executable semantics. In that case, a BPMN 2.0 diagram would specify exact (and hopefully portable) semantics and it can be executed on a computer system. On the other hand, some people raise concerns about the simplicity in that approach.

This again shows that today the dual nature of BPM is not enough recognized by BPM vendors. BPM tries to make the bridge between non technical business analysts and the implementation of a business process.

A business process analyis can contain a diagram and it expresses how people and systems work together. Such an analysis is targetted at other people so it can include free text and a diagram. It's description of how things work in the real world. Analysis can be done without even automation. An analysis is always an important input to express the requirements for the automation of a business process. Some analysts use very expressive diagram notations, while others just use boxes and arrows. But even in case a lot of details are expressed in the diagram, they are not necessarily expressing runtime execution semantics in the software sense of the word.

In case a business process is automated with a Business Process Management System (BPMS) , an executable process needs to be created. An executable process serves as input to a BPMS, after which it will be able to execute the process. Executing a process by a BPMS means a combination of monitoring progress and performing automated tasks. Executable processes can also be based around a diagram. But in this case, the diagram is a projection of a software artifact. The executable process will in most cases contain technical details outside the scope of the diagram. Whatever way you look at it, an executable process is software.

There are some aspects that cause some fog around this clear picture. In practice, it turns out that the roles are not that clearly separated. In fact, a lot of business analysts have technical knowledge so they already are able to think in terms of what it means to execute the software. Also, there are different levels of process languages. The more a executable process language targets to be general purpose, the more complex it will be and the more technical it will become.

If a diagram notation (like BPMN) wants to be used for both the analysis as well as the executable process diagram, it should limit the number of details that can be expressed. As analysis details don't match with technical details necessary for making the process executable. The more details that are exposed in the graphical notation, the conflicts will arise because of this dual nature of the process diagram.

More and more vendors start to see that the gap between the analysis process and the executable process can not just be eliminated. But still quite a few target round tripping, which means that the analysis model is kept in sync with the executable model. I have seen multiple vendors come out with features that support this. Still I think that is a waiste of time. Building tools that synchronize automagically between the analysis and the executable diagram is too hard. Using those tools effectively will only succeed in environments with a lot of discipline cause changes in the executable process will often require an analyst to incorporate those changes into the analysis diagram. Furthermore, those tools impose too much assumptions on the analysis language and the executable process language. FWIW, such an approach never did fly with UML Class Diagrams, and I don't see how the situation is different for processes. In fact, in case of UML class diagrams, no-one even thought of automagically synchronizing the analysis class model with the executable classes.

Instead, I think it is much more practical to create an executable process language that can build the executable details around a given diagram structure. That way, the executable process diagram will be very similar to the analysis diagram. The better the executable process, the less the diagram will have to change. But a conversion step cannot just be eliminated. Even if the executable process languages was 'perfect' in keeping the same diagram, some parts in the analysis diagram might not even be automated.

Once a business process gets automated, the diagram in the analysis document can be replaced with the executable process diagram. This has as a consequence that the analysis diagram becomes read-only for the analysts once it has been converted to an executable process.

Instead of embracing the dual nature of BPM, the InfoQ post outlines very well how two opposite camps have formed around analysis and implementation. Previously the focus of BPMN was on analysis only. It's much easier to reach consensus in that more limited scope. Now, the big vendors got involved and expressed a clear vision to make BPMN executable. That opens up the whole discussion of the environment. BPEL clearly chose for an ESB environment based on WSDL. But (just to give another example) jPDL is defined in a Java environment. I don't yet see how you can define an executable process language without selecting a concrete environment in which it operates. This is exactly why we support multiple process languages on our Process Virtual Machine.

The way things are moving now, the move towards executability of BPMN is starting to become clear. But looking further in that direction, I can only see quicksand. As indicated above, the vision of making BPMN executable could quickly be dragged down by many technical "details". It will be interesting to see how that is going to play out, but my fear is that it's not gonna be a smooth ride.

One thing puzzles me, though. Why is everyone talking about a new file format for BPMN 2.0, while there is XPDL ? The WfMC guys did a lot of effort to get XPDL synced up with BPMN and they made a lot of noise about it, so it cannot be an oversight. Still everyone seems to be silent about the possibility of using XPDL as the file format. Does anyone know more about the motivations for this silence ?

jBPM Community Day in Dublin On June 6th

The jBPM Community Day in Dublin is a great opportunity to learn more about jBPM, the Process Virtual Machine or JBoss in general. The core jBPM developers and key members of the community will be there in a relaxed atmosphere. It's just friday afternoon on June 6th. There will be some informative sessions, guinness entertainment and plenty of breaks to network and talk to others in the jBPM community. Lunch and evening meal included and it's free ! What more could you want :-)

Click here for more information about this great event.

You can register by simply sending an email to dublin@jbpm.org with your name in it.

I hope to see you all there.

Process Virtual Machine Alpha2 Released

The Process Virtual Machine is a simple Java library for building and executing state machines. It can optionally store process definitions and executions in a relational database. The Process Virtual Machine serves high level BPM as well as low level Java state machines. It serves as a foundation for several process language implementations like jPDL, BPEL, XPDL and Pageflow.

This second release adds a deployer architecture, enterprise bindings and documentation about the persistence of processes. It further improves the stream handling and the job executor.

Check it out !

The Process Virtual Machine Homepage
Documentation
Download

Enjoy and let us know what you think of it.

JavaPolis Refactored To Javoxx

JavaPolis becomes Javoxx

"
New name
New logo
Same Concept : Giving a voice to the Java community
"

Check it out on the JavaPolis website, On the Javoxx website and at Parleys.com

Mark December 8-12 in your calendars, book your flight and hotel and start packing your bags. This is a mandatory excursion for each self respecting Java developer. This is one of the few situations where I'm happy to fulfil my obligations!

In Depth Analysis Of OSS BPM By Jason Woodruff

Jason was able to extract our grand vision perfectly from the bits and pieces that we've published here and there on the forums, articles and website.

Congrats, Jason.