Reframing the BPMN vs BPEL Debate poses some interesting questions. I took from it:

1. Is BPM a business Discipline or software engineering?
2. Whose responsibility is it to implement (automate) a business process?
3. Should we aim to move from design to deployment with no programming?
4. Whose responsibility is it to maintain a business process?

I have some opinions on these questions.

Is BPM a business Discipline or software engineering?

In my opinion it is foremost a business discipline. It  is about managing business processes, as the term says. It is identifying processes, understand them (model them), define a roadmap for process changes, design new processes, implement and monitor then. This all can – theoretically – be done without IT. Actually most of our day to day processes (drive to work, go to the supermarket on saturdays) are without an electronic workflow (well – some might have . Also the people of old had very much the same principles when they organized their kingdoms and businesses – without IT. They weren’t sending XML messages back and forth – but herolds and messengers on a horse and the like. This of course were also business processes which were also managed and clearly defined. They did not call it BPM back then, but it was in it’s essence.

But is it a question of scale and speed. In practical today’s business life it is inevitable to use IT to reach the needed performance of the business process execution and the needed information pool for the monitoring of it. Therefore the question of how to transfer modeled business processes from the business discipline of BPM to IT is crucial.

Whose responsibility is it to implement (automate) a business process?

In my opinion it is the responsibility of the process owner. The process owner in my opionion is foremost a business person. He is responsible to design and implement the business process. Design – I don’t mean necessarily the modeling with BPMN for example. This of course can be delegated. But the process owner is in the end responsible for the performance of the process and the profit it yields.

If the process owner decides, that a particular part of the process or the whole process should be supported by automation, then of course this part can be delegated.

Should we aim to move from design to deployment with no programming?

This is in my opinion unrealistic. Also it is a question of definition. What is programming and what is not programming? Typically people associate programming with imperative programming (like in C#) or with character based input. Modeling is on the other side which is more declarative and more graphical. But what about rules for example? They are character based and declarative. Also they can usually call subroutines, which are imperative. In some sense a BPMN model is also imperative. So what does this question mean? Probably it is, that it must be made easier for business experts to express which process they have and which they want. Of course it is a big benefit, if these models can be used in runtime or transformed in some canonical way into runtime. The success depend on if it is possible to express the process in the languange of the domain of the business process owner. This is why I think that Domain Specific Languages must be desiged with the greatest care and intelligence. And I think that this area is much less expoited than it could be. In my opinion much more is possible that we have achieved on the great scale already.

Whose responsibility is it to maintain a business process?

In my opinion it is the Business Process owners responsibility, who is a business person. And he might delegate it to someone of IT. However the model is the common communication channel between the two. So the model must be accurate, understandable, detailed, summary, and optimally simulateable. Especially the part of  interactive simulation has been much underestimated in my opinion, because it is able to show the behavior of a system implementation of a business process before it is implemented.