There's been an interesting back-and-forth between Edwin Khodabakchian of Oracle and Bruce Silver of Bruce Silver regarding BPEL, BPMN and the promise of business process management in general. To get to it, read Bruce's post, Is Oracle Discovering BPM?, and look at all the comments.

In the comments, Bruce and Edwin bring up various of the posts in my blog so I'll take them on as I have time over the next couple of days. I'm doing this in no particular order... but first, let's get right to the heart of it: Do I hate BPEL?

Words Matter (unless they don't)

Bruce sort of lumps me into a "BPEL-hater" camp, and Edwin then proceeds to discuss Oracle's take on BPEL, BPMN and a host of other things. Now, I've spent a bit of time around politics and know the best way to pigeonhole someone is to say, for example, "do you think BPEL is key to solving world peace or are you a BPEL-hater?"

Well it's neither, so, right here right now I'll take the oath and state categorically, without hesitation, equivocation or mental reservation: I neither love nor hate BPEL. I'm a BPEL agnostic. Why? Because I think BPEL has nothing to do with the management of business processes. And I believe that the management of business processes is what business process management should be about.

Non-intersecting non-parallel lines

BPEL is orthogonal to the problem-space of managing business processes, and of becoming more process-centric as a business. It is an execution language that, if your BPMS requires code, arguably makes writing that code easier (as Edwin points out, it includes more workflow semantics than other languages; it also assumes a world of web services. It also has limitations, which proponents promise to iron out in spec changes and proprietary extensions over the next few years). But being able to tell a computer chip about a process (i.e. writing code) is the least interesting aspect of aligning a company around process. In fact, as I have argued, if you have to code up a process, then you are probably impeding the business change that you were, in the first place, striving for.

Just because BPEL is called the "Business Process blah blah blah," don't confuse it with business process management. IT vendors are horrible about conscripting business-sounding terms to describe technical mish-mash, and then trying to define a business problem as something their technology solves. It happened with "business rules" and now it's happening with "business processes." (Sidebar: like business processes, which do and will continue to live everywhere, whether written in BPEL or not, business rules exist in a lot of places and you should optimize where they live based on ease-of-change and governance issues, not on dogma around a single "business rules repository" just because it uses the moniker "business rules").

In fact, my whole point is that business process management (lower case) is nothing to do with an implementation language. Companies that successfully implement bpm strategies will do so irrespective of what language they choose; there will be zero correlation between companies who are successful and what language they choose. Quick, how many great processes at Dell and GE and Wal-Mart are written using BPEL? Yet, they seem to be doing an OK job of things. Were BPEL available in 1992, can you imagine Lou Gerstner lining up everyone and saying "OK, we're going to save IBM by using BPEL." If you think so, reread "Elephants Can Dance" to see how it really happened. Governance. Alignment. Change. From the business. However, I CAN imagine a CEO today lining up everyone around a bpm transformation, and using that as a catalytic converter...

The technology portion of business process management demands an integration of technology into the fabric of the business... a technology embed... and this will result from tools that look and feel more like Word than Visual Studio; more PowerPoint than Visio, even. BPMS vendors who focus on the language of their engines, rather than the business problems of their customers, have failed to achieve significant market share, and they will continue to do so.

Enter Christopher Locke from The Cluetrain Manifesto, "Too much development is focused on whiz-bang technology, and not nearly enough on the cultural revolution all this implies and in fact demands. Imposed infrastructures hinder more than help. Most so-called empowerment initiatives are embarrassingly paternalistic, to the point of backfiring entirely."

The key to BPM is a less-code future, not a "this is the type of code you write" future. Any serious advance in bpm technology would be away from YAWL, and toward business facing tools that describe, via metadata, process behaviors. Advanced engines in all realms will be virtual machines, interpreting metadata in, essentially, real-time. BPM should be no exception. To strive for code seems wrong...

The keys to managing business processes successfully

Above, I posited that BPEL won't be a correlating factor in whether companies achieve success in transforming themselves around a process notion. There will be high correlation of success among companies which:

• Decide to manage themselves, or at least core capabilities, in a process-centric manner. This is a business imperative, not an implementation imperative. Many implementation methods will achieve success, including BPEL implementations. The technology component of this will be a new set of tools that the business can use to drive and integrate IT with more velocity than they've been capable of doing in the past. This is key... the limitations to date have been less about IT's unwillingness (or even the supposed Business-IT divide)... it's been about the capabilities of the business to confidently engage in conversations with the technical people. Great BPMSs will foster that conversation through new tools that engage the business more effectively in all aspects of the process lifecycle, from the beginning and then in continuous change cycles.
• Provide strong leadership from the top of the organization on both business and IT sides, embracing a process-centric approach to business design ("business SOA") and technology implementation (BPM on top of SOA, and as a driver of SOA). There will be more common traits among the leadership of successful companies than among the implementations.
• Standardize on a common graphical representation of the process across all users at run-time, at simulate-optimize-time and at design-time. (Fyi, I use the term "simulate-optimize" to distinguish the analyst's activities between running "what-if's" based on simulation data vs. historical data. Both are important and have different uses during the process lifecycle). At Lombardi we use BPMN for this, but the issue is that your organization uses a consistent standard that is rich and includes all aspects of a process's behavior. Global rules and events not depicted on the diagram will impede your ability to scale, and will impede agility, so be sure the modeling best practice fully describes the models, in the modeling tool. BPMSs that require experts to understand the system once it's deployed will fail, because the whole point is to continuously be able to change. If global rules or events are affecting the a given process, then my ability to pass ownership around is non-existent. We're back to Old School. The promise of BPM is achieved only if the model is depicted as surely as a map. Trade increased when trade routes were fully documented and could be read by all the sailors. In the same way, trade will increase as we scale our processes, and BPMSs are the systems upon which the corporate maps are drawn and executed.
• Embrace tools that foster business and IT participation during simulate-optimize-time and design-time.
• Ensure tools that provide 100% round-trip engineering, so that there is no manipulation of code independent of the graphical depiction of the process (the process cannot get "out-of-sync" and you are able to seamlessly move from the graphical model to execution of any version of the process). This is commonly referred to as a "shared model architecture." Now, to Edwin's point, you might be able to manipulate code directly, or manipulate the diagram directly - either may be done in a shared model environment. But, if you make a change in one place, it MUST be represented in both without hand-retooling. The best of the environments will allow you to use a modeling tool to its fullest extent AND run that process. If you need to constrain the model (as in a BPMN to BPEL constrained view of the world) you insert friction into the modeling exercise, and lose business users. Otherwise, process understanding is impaired, execution does not match the (documented) diagram, and we're back to being "monkeys with pants" as the Ask.com commercial says. With BPMN to BPEL implementations, you get a proprietary interface that attempts to translate something which per the standards doesn't translate exactly... beware of so-called "round trips" between BPMN and BPEL. The specs are defined, and they don't match up. And they won't match up for some time.
• Standardize on BPM tools that incorporate strong BAM, event handling and correlation on business events. These aspects of process applications are generally the key to higher value. These elements must be present in the graphical model (diagram). The business should be able to model the event flows as easily as the human interactions. Not implement, but model them.
• Standardize on BPM tools that provide superior levels of out-of-the-box visibility into processes built using those platforms. This is because very few organizations really build all the reports they intend to build... therefore out-of-the-box process-specific reporting is essential for real-world success.

Conclusion - I don't hate BPEL and I don't love it, either

BPEL iisn't about visibility, and it's not about change management, yet those are the central problems of business process management. BPEL as a technology is orthogonal to the problem of business process management.

It's simply a new way to write code. It has nothing to do with the management of business processes. I don't love it or hate it; other than that it is a distraction. BPEL isn't necessary to achieve the benefits promised by business process management - and therefore it's an impediment in the market conversations that are occurring with respect to business process management.

BPM is about the business, and more specifically about driving a change-oriented process culture into the business, using the enablers derived from the internet technologies and their forebears. Indeed, if BPMSs were to become synonymous with BPEL engines, then the business benefits of BPM would be reduced to the efficiencies of a few people writing a few programs. The bpm cause would be set back for years. That would be a shame.

Interestingly, Edwin stated it perfectly when he wrote that "BPM is a promise/a vision. A promise that users will take control of their business processes by having better visibility into them and by being able to continuously adapt and extend them." That's wonderful!

That's a big vision. It's an inclusive vision that embraces millions of people improving their work lives and expanding their markets. Let's work on that, not on which language a given programmer should use. Programmers are already involved in processes, and they're not the bottleneck. Business participation is the issue, and BPEL doesn't help that a bit.

Technorati Tags: BPEL, BPMN, Bruce Silver, Edwin K, Oracle