Our thoughts are in the form of process, so I proclaim now that we should communicate and articulate them as processes.  procper makes this possible, easy, and fun.  While we are still in stealth mode, contact us to find out how.

BPEL for Process Modeling

Of course, as varied as they may be, there are reasons organizations are succumbing to “BPEL for modeling”. Below I have provided a couple of contributing factors and misconceptions that I have witnessed:

• The budgets for the SOA/BPEL project were requisitioned by IT and they did not plan appropriate time from the business community for process modeling.
• The processes are believed to be “IT processes”, and business process modeling is not needed.
• Processes change, and the cost to maintain both business and BPEL models individually will be high.
• BPEL modeling is “good enough”. Besides, nobody looks at business process models after they are initially designed.
• And the most common: Initially, structured business process modeling was followed, but it was not kept in sync with the BPEL model [for a variety of reasons] and the two diverged.

The list goes on. However, the fact remains that BPEL is a business process execution language, not a modeling language.  Not surprisingly, using it for modeling has serious implications.

• For organizations that did initially set out to perform business process modeling separate from BPEL, only to later diverge, the reality of what is being executed (BPEL) compared to what was agreed/communicated is now also out of sync.  It could be argued that this is worse than never modeling in the first place.  
• For the places that decided to just go ahead and model using BPEL, their models are generally not easily understood by the business, or even people in IT that don’t understand BPEL. They certainly don’t put the organization in the position of easily documenting, updating, and communicating/disseminating process information.
• And for those of you who still think your IT processes do not need to be documented clearly for the business to understand, you will someday.

So, put the BPEL hammer down for a minute, back away from it, and take a look at BPMN and other business process modeling options.  [Sincere Plug] But, if you are stuck with BPEL for modeling processes, procper is the only tool that will allow the business to wrap their arms around the processes you have modeled.  procper is the tool of choice for communicating and disseminating your process  models, regardless of the languages/tools chosen, including BPEL.

He has even stood up a web site called Recovery.gov where he reiterates the importance of efficiency, accountability, and transparency.

Click here to view the embedded video.

Welcome to a new age.  Obama’s unprecidented approach using technology simply cannot be reversed.  As the American public tastes this new, transparent process for government and information, it will simply not accept any sort of rescission.  Not from this administration nor any in the future.

This statistic is not a bad thing.  The fact that BPMN can be useful to so many people without requiring a complete understading of every element of the standard is indeed a great indication of the relevance, simplicity, and flexibility BPMN provides.  Some feel a lack of training contributes to the average model consisting “of just 9 different symbols”, which suggests that people “need” more than they actually use.  That may be the case, and if it is, as BPMN becomes more commonplace, more of the vocabulary will certainly be utilized broadly.

So, perhaps the article would have been more concretely titled “How much BPMN do you acually use?”, which is precisely the time-sensitive, practical information that vendors, organizations, and people can use in determing the maturity of their own BPMN efforts.

Though we are not a typical BPMN “software vendor” in the way that Michael zur Muehlen refers, we are indeed faced with understadning the most important and critical features users take advantage of while modeling business processes.  Supporting multiple specifications as we do requires a huge effort, helped only by educated prioritizing on where to spend our energy.

Following is part of the chart you can find at “How much BPMN do you need?” showing the most used elements from BPMN. Thank you, Michael zur Muehlen, for sharing your findings.

BPMN Construct Usage

The objective of BPMN is to support business process management for both technical users and business users by providing a notation that is intuitive to business users yet able to represent complex process semantics.

Specifically, BPMN sets out to integrate business process with technology by providing an approach that allows for mapping to process execution language like BPEL (Business Process Execution Language).  As technology becomes engrained in every facet of business and as business processes become engrained into technology solutions, BPMN finds itself in a uniquely well-positioned environment.

Future plans for BPMN are to further define this “notation” and turn it into detailed specifications.  This will, of course, help minimize the gaps between the varying  interpretations of BPMN that exist today. Software vendors will have more clarity when conforming to the BPMN standard, allowing for faster development turn-arounds as well as easier and intuitive integration.

Given its unique positioning, existing uptake and momentum, and active continuous improvement, BPMN has a fair number of variables in its favor as it works to become the de facto BPM standard.