I ran a “Round Table” at the BPM ThinkTank on the subject of BPMN and XPDL. There always is the question: “Why not use BPEL?” Then I explain how XPDL holds the graphical layout, the X & Y coordinates, the size the nodes, the paths of the lines. BPEL has not support for the graphical layout.

“But you don’t need to save the graphical layout!”

This emphatic comment came from one attendee. I truly appreciate the sincerity of the statement, while at the same time it unsettled me. After all, I had just explained that the advantage of XPDL is that you can exchange progress diagrams, and here he was saying there is no need for that. This is not the first nor the last time I will hear this.

“Need” is directly related to your expectation of “use”. Many people approach business processes with the mind set that the process diagram is just the starting point, and this will be converted to a set of instructions that will coordinate information flows. This is very much like the role that UML takes in traditional 3GL programming: you start with a diagram, you flesh it out, you eventually switch to filling in the code, then you end up with executable code. With the UML style MDA, you don’t need the original diagram in order to execute the final program.

It is my impression that many many people believe that BPM is just an extension of this kind of programming style. The diagram is just the initial phase. Then that diagram is converted to executable code (in many cases BPEL) and then shipped to the execution engine. During the transform, the process is reduced to a set of low level instructions. Look at what the basic instructions in BPEL can do: send XML to some server, read XML from some server, transform XML. Once you have reduced the process to this level, why would anyone need to “see” the process execute? An opaque server is fine, as long as it responds correctly to all the incoming events, and sends out the proper responses. This is the approach promoted by Microsoft, IBM, Oracle, and SAP. This is a traditional “Enterprise Application Integration” approach. And for the EAI worldview, it is true: you don’t need to save the process diagram layout details.

Many readers will basically agree with the above, but many will vehemently disagree. There is a large community of people who believe that BPM can be something that is fundamentally different from traditional programming. I have mentioned in other posts the difficulty of naming this. Let’s call it “human oriented BPM” or “workflow oriented BPM” for now.

What is different about Human Oriented BPM?

In human oriented BPM, the diagram matters. People are doing the tasks, and people are not like services which simply take a set of input parameters and transform them to output values. People need to understand the purpose of the work, and a little bit about what others are going to do both before and after their task. The diagram is designed as somethign that can represent the responsibilities of different people at different points. This diagram helps people to coordinate what they are doing with what the others do. The diagram is not simple a convenient first step in producing a program. Instead, it is an essential part of the final application.

With Human Oriented BPM, the human action retains its identity throughout enactment of the process. Say you have a business process instance which has not completed yet. With human oriented BPM you can ask at any time the question: Why is this process not completed, and who is “holding the ball”?

Human BPMS supports change. Since processes often take a long time (e.g. 3 to 9 months or more) a Human Oriented BPMS needs to answer “who is holding the ball” not just because people are curious, but because the responsibilities that people hold may change over the time span of the process. You might find that the person holding the ball is no longer in that organization.

A Human BPMS must have the ability to reassign that task to a new person, which means that the system must not lose the identity of the task. For example, an EAI oriented BPMS might take a human level task, and break it into a sequence of data level operations, such as update an account, send an email, mark a tracking record. Reassignment can mean undoing all the small steps that are associated with the “task”, and redoing them for the new person. This is not impossible in an EAI Oriented BPMS, I am just pointing out that the identity of a task must be maintained.

A Human BPMS must be able to identify performance of the human level tasks within the process. Even if the human task is broken into a set of lower level operations, the detail of the performance of the operations is “noise” that detracts from the performance of the human activities. If a particular department is responsible for reviewing contracts, a business user wants to know statistics about how quickly those reviews are completed, and not necessarily how well their document management system transfers the documents. Somehow, even in the analytics, the human activities must not lose their identity.

This does not completely distinguish a Human BPMS from an EAI BPMS, so I will have to come back to this in a future post.

I hope at least that this makes it clear that that a key aspect of a Human BPM is that the process diagram is a diagram of the responsibilities of different people, and that the human level task maintains its identity throughout the enactment of the process. In a human BPMS, we don’t simply throw out the diagram and replace it with the equivalent set of low level operations, but the diagram itself is a fundamental part of the application.