Business Process Management

Comments on jBpm 3.0

2005-06-21T10:33:00.000-07:00

Since I commented on jBpm 2.0 model earlier in this blog, I have been asked to review jBpm 3.0 beta. This is not really a review per se, but my quick observations after spending a couple of hours on jBpm-3.0-beta4 and jBpm-bpel-1.0-alpha1.

jBpm 3.0 is essentially has the same underlying model as its predecessor, and that isn't surprising. From the architectural view point, it has more of a pluggable architecture (i.e., we can plug in our own modules that take up certain workflow responsibilities, for example, task handling), which can be a good thing. There is also a new graphical designer, which I didn't check out. There are a few implementation enhancements related to persistence and such, as well as many improvements related to deployment and documentation. However, I didn't see any notable changes or improvements from the modeling perspective.

The BPEL component, which is in alpha1 stage, is in very early stages of development. A full-blown implementation of the BPEL standard is not trivial, and I don't expect to see this component being ready atleast until the end of 2005. Some BPEL constructs have been added including messages and message correlations, but I don't know how complete they are. The current model still remains void of some non-trivial constructs such as scopes, compensations, and fault handlers. Some diligent analysis is required on my part before I can conclude whether or not jBpm can support all control flow constructs that BPEL specifies.

Overall, nothing in jBpm 3.0 made me change my earlier opinion that jBpm model is ad hoc and suboptimal, but Tom Baeyens has a different opinion (I hope that he is right and I am wrong). That said, I won't hesitate to use jBpm where ever I can, if I find it sufficient to fit the needs of the situation at hand.

BPM Theory for Laymen

2005-06-20T18:40:00.000-07:00

In this well-written article, Michael Havey explains the two most popular theories that are in vogue among the BPM crowd, which are Pi-Calculus and Petri Nets. The latter served my needs so far in implementing BPM systems I needed. My expertise and understanding of Pi-Calculus is less deep, and I haven't built any systems based on it. There is plenty of rigorous research concerning aplication of Petri Net theory to BPM/Workflow, but on the contrary, there isn't much concerning Pi-C and BPM. It however rules on the hype scale, probably because it is new and less known.

Business Rules & BPM

2005-05-21T22:01:00.000-07:00

There is a huge revival of interest in rule systems/engines - this time in the conext of managing 'business rules', not as an exercise in AI. The main premise of business rules management trend is that business rules should be extracted out of code and put under the control of business users. And that these users should be able to change the rules on-the-fly without needing to call upon a programmer. The software systems now are governed by these business rules, and their execution behavior may be altered with ease by the very people who best understand the business. That's neat. And very useful.

The scope of business rules is large, and the term 'business rule' could mean many things - facts/assertions (e.g., interest rate today is 5.75%), derivation rules (e.g., if total puchase > $300, discount rate is 10%), action rules (e.g., if payment is late by more than 45 days, call customer), constraints (e.g., a Gold customer never has credit score less than 650), and such. These rules can be organized in many forms including propositions, if-then-else clauses, decision tables, and decision trees. It is possible, in theory, to consolidate all these rules in a sophisticated rules reasoning system, and let everything in IT be driven by that.

BPM is obviously concerned with rules because business processes are governed by business rules. Many BPM systems today support business rules management of some sort, either by directly suporting it or by integrating with third party rules systems such as ILog Rules, Jess, and Corticon.

Compared to all the buzz, I think the real progress has been somewhat limited so far. It is possible that the trend is still in the early stages and will catch on rapidly in the coming years. It is also possible that this trend will fail to deliver the same way the expert systems have failed.

Some useful links:

BPM Maturity Model

2005-05-19T22:34:00.000-07:00

I haven't looked at this specific model myself, so I can't judge how good or complete it is. I do think a maturity model for BPM makes sense and could provide a valuable tool for understanding where the BPM gaps are within an organization.

An excerpt from the CIO Magazine Article: "Many companies asked us how much business process management they should do and how well they conduct business process management right now," Rosemann says. "Our model lets them measure business process management along five factors. Those five factors are information technology, methodology, performance management, culture and accountability."

Defragmentation of the BPM market

2005-05-14T04:51:00.000-07:00

Given the generic definition of 'business process', the overall workflow/BPM market ought to be huge, at least a few 10's of billions of dollars huge. But, it remains a very fragmented market with no one controlling a significant piece of the pie. One Aberdeen Group report in 2003 stated that IBM dominates the BPM market with about 16 percent market share, but I'd venture to guess it actually has less share than that, depending on how we define BPM. There are no pure-play workflow/BPM vendors that are big. IBMs, BEAs and Oralces don't count as pure-plays since they offer comprehensive solutions to coporate IT departments, not stand-alone workflow products. Most workflow vendors address their own specific vertical markets with tons of add-ons. Most pure-play workflow startups end up changing their business models to offer industry-specific solutions, or going out of business.

Given the current state, will the BPM market be consolidated? What will lead to such consolidation? Will there be a couple of BPM players controllong 95% of the market? I tend to think it is not going to happen in the foreseeable future. The reasons are many, but the primary reason lies in the fact that 'BPM' is not all about technology. No vendor today can sell a BPM product to a customer and walk away expecting the customer to implement a meaningful solution to his/her business problem. Given a BPM system, most customer do not know how to convert a business problem to a technical BPM solution. Vendors end up needing to know too much about the domain in order to help their customers implement meaningful solutions, often requiring them to add domain-specific extensions. No vendor can afford to know enough about all the domains or even half of them.

It is conceivable that, at some point in the future, there may be one or two major vendors offering the 'core' BPM technology, with many middle tier vendors offering domain specific extensions/solutions. The emerging standards such as BPEL may help such consolidation, when the market truly accepts them as standards. Some version of BPEL in the future, may be BPEL 4.0, may become such a standard, but there is a long way between BPEL 1.1 and BPEL 4.0. Or may be it is an impossible way.

It will be interesting to watch how the BPM market evolves with all the major players (Microsoft, IBM, Oracle, BEA and others) vying for a big share of the market.

Exception Handling in BPM

2005-05-11T22:14:00.000-07:00

Exceptions are a norm in business processes, and all BPM systems attempt to support exception handling to some degree. However, most systems have a limited view of what a business process exception means.

There are at least two kinds of exceptions. The first kind which occur because we have an automated BPM system - call them "technical exceptions." These are caused by system failures, network unavailability, web services binding problems, script/method execution errors, unexpected input formats, data transformation errors, and a whole bunch of things like these. Most sophisticated BPM systems that are EAI / integration centric, including the BPEL standard, address these exceptions thoroughly, and provide very elaborate exception handling mechanisms including catch-and-throw, notifications, compensations, automatic / manual retries, and more.

The exceptions of the second kind arise whether or not a BPM system is employed, and these are real business process exceptions - call them "business exceptions." Some of these exceptions may be foreseen and modeled in the BPM system explicitly. For example, a loan process may throw an explicit exception when the loan amount requested exceeds certain limit, or when a specific work item hasn't been acted upon for a certain duration. Some tend to classify any case that cannot go through straight-thru-processing (STP) as an exception case. Many modern BPM systems, including the BPEL standard, support explicit throwing of exceptions and custom exception handlers. Appropriate actions (such as rollbacks and compesation actions) are automatically taken when an explicit exception is thrown.

Some other exceptions are either not foreseen or not explicitly modeled in the BPM system, which may result in dead-paths or dead-locks during the process execution. Many BPM systems today fail to identify these exceptions, and offer little or no support for handling such exceptions.

There may be even more complex exceptions that may require certain process execution steps to be retracted and restarted. Imagine a scenario when you are booking a flight, and the agent starts the process with the assumption that you are a non-preferred customer. Just before completion, you inform the agent that you are a preferred customer. Now, process execution may need to be retracted, and a different branch of process may need to be selected. In such scenarios, a BPM system should be able to automatically determine how to backtrack to a past execution point and re-execute the process. Most BPM systems offer no support at all for these kinds of exceptions. And, much more complex variations of this scenario exist in the real world.

So, when a product brochure claims support for exception handling, do not assume it means all the above. It may mean very little to you, depending on what you are looking for.

Comments on jBpm

2005-01-05T15:57:00.000-08:00

There is a lot of buzz about jBpm since it joined Jboss. It is an exciting news for the workflow/bpm community, especially for those, like myself, who wished they didn't need to build their own workflow engines in the past. It appears that there is a lot of mometum with 30+ developers (as listed on www.sourceforge.net) and some 6500+ messages posted on forums.

I downloaded jBpm2.0 source and spent about 4 hrs browsing the code and understanding the model. My first feelings are mixed.

I was surprised to find that the underlying computational model behind jBpm isn't Petri Nets. Considering that the design of the core engine is influenced by the workflow patterns work (www.workflowpatterns.com) conducted by Wil van der Aalst and his group, I'd have expected, naturally, that Petri Nets would have been a natural choice. jBpm adapts more of state-machine approach with special constructs for forks and joins. All those workflow patterns that jBpm attempts to support are naturally supported by a Petri Net model.

The chosen model itself seems unfit to support all intended workflow patterns, unless one writes custom fork handlers, action handlers, and such, in effect leaving modeling constructs in the developer's hands. I would have liked the model to support all the intended patterns and much more. This model might be better than some others, but far from being complete.

I understand jBpm is still in the initial stages, but I don't see how BPEL can be translated into jpdl in the future, as promised, even after several iterations on jpdl. jpdl and its underlying model simply don't have some basic constructs (e.g., messages, message correlations, and compensation scopes/spheres, etc). Introducing them at a later stage isn't going to be a trivial exercise, at least in a meaningful way. In the absence of a sufficiently capable model, one can always allow custom Java programming to achieve anything one needs to achieve, but that isn't very valuable.

Workflow is just a Pi-process debate (contd)

2004-01-08T09:28:00.000-08:00

(Continued from the previous post)

Howard Smith posted a revision of the "Workflow is just a pi-process" paper today. It is a very worthwhile paper to read, but it needs a different title ("Pi-C as the Basis for BPMS"?), as the main assertion in the title is still useless (except for generating debate).

While pi-c and its variants may have the potential to form the basis for BPMSs, there is a lot of work left to be done. I am not aware of a single piece of 'rigorous' work on how pi-c can be applied to BPM addressing all aspects - completeness in terms of ability to model BPM concepts, modeling efficiency, reasoning and execution complexity, analytical capabilities, and others (I wonder why no professor has taken up this challenge). Any pointers to such works will be highly appreciated.

Meanwhile, vendors will build their 'process virtual machines' in their own ways to support the chosen standard language such as BPEL. There is no compelling reason to base one's process virtual machine on pi-c without understanding the benefits of doing so.

What constitutes "the BPM market"?

2004-01-02T12:37:00.000-08:00

Meta Group sees a boom in the BPM software market, and expects a growth rate of 15-20% in year 2004. That's impressive, but what exactly constitutes the BPM market? Meta Group estimates the market at $1.1B currently and that appears too small, considering majority of business applications are BPM applicatons (at least have some BPM aspects). Is it the market for the BPM pure plays that sell their BPM core to ISVs and enterprises? Then that is quite impressive! I need to dig more on this.

And, get ready for this, this report predicts that the Service Oriented Architecture (SOA) market will be worth $4.4 billion in 2005, and $43 billion in year 2010. Are VCs listening to this?

BPO and BPM

2003-12-25T22:05:00.000-08:00

Business Process Outsourcing (BPO) is a current major trend. Many functions including HR administration, customer support / call centers, sales and marketing, finance and accounting, legal services, medical transcriptioning, and such are finding their way to cheaper places.

IT is obviously the enabler of BPO, hence the name ITES (IT Enabled Services). I am wondering how the IT systems will evolve and what the issues will be in supporting BPO. If a company is going to outsource business processes to multiple service providers, it has a need to stitch together all those cross-boundary processes as seamlessly as possible.

There are a lot of similarities between manufacturing outsourcing (product supply chains) and business process outsourcing (service supply chains). However, there are some key differences - services are less tangible than products, hence require closer oversight. There are no inventory buffers in service supply chains, so it is harder to handle uncertainties. Back-office systems such as HR systems were never the points of integration with partners, now that becomes essential with back-office operations going BPO. All these factors should influence the nature of IT systems for BPO, and I am interested in reader's thoughts.

Gartner Fuses BP

2003-12-22T00:21:00.000-08:00

If you thought you had enough buzzwords and acronyms, listen to this new one from Gartner - Business Process Fusion or BPF. Great, now vendors can claim all new BPF product suites... Howard Smith's views on BPF here.

Will the Real BPM Please Stand Up?

2003-12-21T20:23:00.000-08:00

What really is "Business Process Management?" According to Darcy Fowkes of the Aberdeen Group, "Business Process Management defines, enables, and manages the exchange of enterprise information through the semantics of a business process view that involves employees, customers, partners, applications and databases. It has to be capable of modeling a process, brokering that process, delivering it with straight through processing (STP), and then managing it, all within a single environment. Because of its far reaching implications for the ability of enterprises to adapt, it is much more than a technology fad but a management issue that needs to be on senior management's agenda, driving the IT support of the business." link

I think this is a nice operational definition of BPM, from the business manager's perspective. I will just add analysis, simulation and optimization capabilities under the umbrella of BPM.

Given this broad definition of BPM, from the IT perspective, it encompasses many aspects including workflow, EAI, B2B, and extended value chain involving multiple partners. It is no wonder that every vendor is a BPM vendor and every system is a BPM system. Tibco, WebMethods, Savvion, Oracle, IBM, BEA, Microsoft, and many niche players are positioning themselves to be BPM vendors. Some offer EAI solutions, some are purely workflow, some are generic web service orchestration solutions, and some are B2B specialists. So, which is the real BPM system? The answer is both everyone and none. In reality, BPM system is not a single system, but rather the entire IT environment composed of multitude of systems doing multitude of things.

There is no problem with the broad and ambiguous definition of what BPMS is, except when it comes to defining BPM standards. Consider BPML and BPEL4WS which are touted as the next generation business process modeling languages that will form the basis for new generation of BPMSs. Are they really the next cure for cancer?

There is much more to a BPMS than BPML or BPEL. BPEL is primarily a control flow language (which is rich enough to model most workflow patterns), and supports message flow and limited (and sometimes ackward) data flow. It is not a complete language to support any of workflow, EAI and B2B processes (read the presentation of BPEL by Paul Brown of FiveSight Technologies for a concise characterization of BPEL).

With all that said, the "new generation BPM systems" are aligned well with the technology trends (web services, SOA, XML, and probably even the future Semantic Web - how long before we hear BPEL process ontologies buzz?), and hence will definitely subsume the current systems (which are primarily workflow and EAI systems). The question is when and in what form will they be.

Workflow is just a Pi-process debate

2003-12-21T17:08:00.000-08:00

Howard Smith and Peter Fingar caused a lot of commotion in the BPM/Workflow community when they asserted that "Workflow is just a pi-process" in this paper. You can follow the threads of that never ending debate on the W3C WS Choreography mailing list and on the Workflow Research Forum.

While the title is an attention grabber, I find that assertion to be useless, even if it is true. Howard and Peter make this assertion on the basis that BPML, which apparently takes inspiration from Pi-C, can successfully model the majority or all of these workflow patterns, and it can model the workflow engine itself (nothing to get excited about, a workflow engine can model itself).

So, what does that buy me? Pi-C, being Turing-complete, is capable of describing almost anything, but not always the best choice. Unless one wants to go to the extent of considering the number "1" a process, almost always one will add additional modeling layers on top of a theoretical framework such as Pi-C, rendering the theory less useful in offering formal semantics. In theory, the entire ERP system is a Pi-process, if anyone will implement it that way is questionable.

Anyway, there are a lot of insightful posts in the threads above, for those interested.

Getting started....

2003-12-21T12:53:00.000-08:00

A place to share and keep record of my thoughts on all things related to BPM - process modeling, web services, services orchestration and choreography, workflow modeling, wf-XML, BPMS, BPML, BPEL, ebXML, RosettaNet, Petrinets, Pi-Calculus, BPM vendors and products, and above all, if businesses really care....

I am a firm believer that process is the business more than anything else and also that IT systems can support design, execution and management of processes that best suit the business. While business processes always remain at the center of attention for both business and IT managers, a new buzz emerges every so often to align with technology trend changes. The new buzz of Business Process Management is a result of the new trend of loosely coupled service oriented IT architectures.

This blog will explore this new buzz as it evolves... Feel free to email your comments.