Say you have a service that handles orders. You can’t just use it from the workflow, but you can write some code that gets data from the workflow engine, and passes it to the service. That’s a lot of coding just to get simple things done. I don’t know a single customer who’s asking for this feature (more on this here).

The market, as far as I can tell, is always looking for better ways to do more with less. That’s why SOA works so well with BPM. You either have or build new services so you can reuse them from different places. And you make reuse easy (i.e. no coding), so you can quickly implement processes, and easily change them.

It’s simpler, it’s cheaper, but most of all it’s agile, which means you can improve your business (not the code) faster and respond to customers better!

BPMN is not intended to be a computational langauge. Activities within BPMN may call for the execution of computational expressions that might be written in COBOL or Java. Activities might also call for somebody to weld a joint, or paint a door, or wire a lighting fixture, but we aren’t going to provide the detailed instructions for that either.

BPMN is incomplete, but so are the other BPM languages. It is a viewpoint for definition of business processes — a two-dimensional representation. BPDM will provide additional capabilities that will involve extensions to BPMN and additional viewpoints (possibly another form of extension to BPMN, i.e., graphics for different kinds of diagrams). But these extensions wil focus on a more robust repesentation of the business, not the computations that may be necessary to perform specific activities.

I fully agree, we need something that works at the level of the business process, which is why I’m such a big proponent of BPMN. I’d like to design business processes with BPMN, not with BPEL.

But I’m also a big proponent of the COBOL argument. COBOL is executable code. I can write a business logic that takes data, manipulates it, calls other services, takes decisions.

I can’t think of many business processes that can do without this basic requirements.

I probably need to read the BPMN specification again, because I’m missing how BPMN does that. How do you call a service? Store data? Calculate? Make decisions?

Where in the language can you put all that information necessary to make BPMN the equivalent of COBOL?

It’s incomplete. And the question is: do we reinvent the wheel to complete BPMN, or just reuse something that exists?

I happen to like reuse.

I think you need to think outside the box — the box being the design of business process languages for programmers. We are talking about business process languages for business with the semantics of business. The evolution of computer-based languages has been driven by efforts to better represent the concepts of the problem domain, letting the computer do the work to translate this to executable form. You have particular execution semantics in mind, and, yes, BPMN does not fit those semantics.

BPMN is intended to represent the concepts of business processes in a way that is easily understood by people who understand the domain. The graphical notation provides a way for them to communicate with each other. The semantics of BPMN are the concepts they communicate, and the concepts that ultimately should be reflected in the execution of those BPMN processes that are to be automated, as well as those processes that are not automated. The semantics specification can be improved, and there is a task force making improvements to be available in the next few months.

Just as a COBOL compiler translates COBOL expressions to very different assembler or machine language expressions, so BPMN models must be translated to the language of a business process execution engine — BPEL being one of those, although in fact BPEL is a family of languges when we consider the proprietary extensions.

BPMN has limitations, primarily because it provides only a two-dimensional view of processes. In addition, we understand the needs of business process modeling better today than we did when most of BPMN (and BPEL) was developed. BPDM (Business Process Definition Metamodel) will provide a more robust definition of modeling concepts, and will be the basis for further improvements of BPMN.

For example, BPDM addresses both private processes in a web services or SOA context, and the collaborative process or choreography that defines how autonomous processes or collaboration participants interact. It does this in a way that allows a tool to ensure that a participant’s processes are aligned to the shared choreography. BPMN provides a weak representation of choreography. BPEL provides none. Choreography is important to business people because it defines how businesses will interact to achieve mutual benefits from automated business transactions.

So the semantics are there and will get more robust. They are not the semantics of how the computer executes the processes, but rather the business semantics of what the business processes are intended to do and that the execution engines should support.

I’m not sure I understand your point. I’d be happy for a COBOL-like solution, moving away from assembly language is a good thing.

If your analogy is that BPMN is like COBOL, then I’m missing the how. COBOL is an execution language, it’s a What You Write Is What Executes kind of language.

When you say “If a tool implements the semantics correctly”, the question is which semantics? The BPMN semantics? Then I don’t know of a single BPMN implementation in the market place.

The BPEL or XPDL semantics? As long as those semantics differ — the whole point of this post — what you model is not what you execute.

And that’s a problem. How do we get one set of semantics, so what you model is in fact what you execute?

Computer people have always wished the world were different and have tried to force business solutions to fit nicely into computer programs. Efforts to provide languages to better describe real world problems started with COBOL and Fortran and have been going on ever since.

Viewing BPMN as just a bunch of boxes and lines completely overlooks the value. The standard defines semantics that allow people to communicate with other people. If a tool implements the semantics correctly, then, at a minimum the diagrams will be syntactically correct and provide a process definition at an appropraite level of abstraction for the purposes of many business people. Just because you can’t design an engine, doesn’t mean you can’t drive a car.

Yes there is more to defining robust business processes. There is also more than is addressed by BPEL (like human participation and choreography). BPDM will add the modeling elements and constructs to BPMN that will enable the abstract descriptions of some business people to be more fully developed by others. This does not mean that BPDM will include all of the design considerations of an automated business process.

When COBOL and Fortran emerged, there were assembly language programmers who complained about how they could no longer do everything they could do in assembler. It turned out that for the development of most (all?) applications, the power of assembly language was not necessary, but the productivity of higher-level languages was essential. The same is happening with business process modeling — it’s most important to make it easy to express the business ideas — the computer can do the work of making it efficient to execute.

BPEL is an assembly language for a virtual machine; BPMN is a language for business people. If you want BPEL from BPMN (and BPDM), we can make the computer generate it and optimize it — we don’t need to try to make business people think like computers.

A lot of interesting points…

I just have a couple of comments at this point.

I would not agree that BPMN is too constrained for higher-level process modeling. I don’t think there is a lack of capability in BPMN in as much as there is a lack of appropriate “how to” books or articles. Not all the elements and properties that are necessary for BPEL are required for generic modeling. By looking at the BPMN 1.0 spec, a reader would naturally see all the complexity, but not necessarily the simplicity (we tried to incorporate).

Higher-level (e.g., executive level) process concepts are often shown in diagrams that include processes, but are not strictly process flows, which is the focus of BPMN. These other views could be standardized and should trace down to BPMN, but they have a different purpose and shouldn’t be confused with current BPMN diagrams. However, libraries of BPMN artifacts could be defined and standardized to represent higher-level concepts within a process. These artifacts could be included in a process diagram, but they would not affect the semantics of a process flow.

The mapping to BPEL is another topic under much discussion at this point…

I believe that BPMN and BPEL are undergoing the same process as UML. It should be noted that we need a minimum of two models to represent the real world phenomena; one to represent “structure” and one to represent “transformation” or “interaction” of entities (or objects). The purpose of E/R has always been to represent the structure of a database, not for manipulating or enforcing the integrity of a database. The “Class” diagrams in UML are now used to replace E/R and the “method” compartment is used for specifying ”store procedures” and ‘triggers”.

In my article on “Business User Perspective on UML, BPMN, and BPMS”, I urged for the unification of BPMN and UML. I believe that Ismael has come to similar conclusions in one of his recent articles. Let us not re-invent the wheel, and let us concentrate on simplifying rather than enriching modeling symbols unnecessarily!

You are right, we need to add more layers on top of BPEL. For example, to better handle human workflow. Start with implementations, derive a common specification, and you get something that’s proven to work and is portable. Why? Because you have working code to prove both points.

So imagine a BPMN notation for BPEL + BPEL4People extensions. And a server that executes both. Wouldn’t that cover the range of use cases?

As for non-WS, we use BPEL to invoke Java code, talk to SAP R/3 over its proprietary RFC, queue messages using JMS, and much more. WSDL has a nice way of abstracting all the different protocols, and we’ve yet to run into a message exchange that can’t be described using a one-way or request-response operation.

For BPDM to address an executable that is standard and portable, it needs to at the least re-invent BPEL. Our customers don’t have time for that. They want something that works today.

BPEL does not address manual steps, non-WS integration, and a variety of use cases that are fundamental to many real world processes. So BPMN and BPEL cannot be bridged in the near term, because BPEL only addresses a subset of process problems.

I think what companies want is a common language for describing and collaborating on all processes (BPMN) and a platform for managing and orchestrating those processes (BPM suites). Ideally that executable would be standards-based and portable, but just having an effective BPM environment that allows you to build processes quickly and enable a whole new level of visibility across the enterprise is much better than what they have now. BPDM will address the portability issues when it is locked down.

One possibility is to create a high-level notation out of BPMN that relaxes the restrictions, adds new high level constructs, but remains similar in spirit to BPMN. Then you have a standard way to represent ideas and exchange them with people, at different levels of detail.

John,

I really like the BPMN visual notation, of all the alternatives I’ve seen, it’s the one I will pick. That’s the starting point, but it needs to be modified to fix the bugs. And that’s exactly what we’re doing. We’re using the notation as much as we can, with changes where they are necessary, and underneath relying on the more proven process model.

My wish would be to see a new graphical language that could be used at that higher level, that would represent business processes whether they be automated or manual, and would incorporate business objects and indicate what systems are needed. This would allow a complete description of a process, and the interfaces and handoffs between people and systems.

I guess there are tools that do this, some better than others. But it would be nice to see a standard emerge. Then the icons that represent the automated processes can just be transformed to BPMN so that the more constraining features can be added.