Keith Swenson started his new BPM.com article by stating that:
A lot of the confusion and difficulty in the BPM community is because some people think that BPM is a kind of Software Engineering. Indeed, superficially it looks like Software Engineering: you start with requirements, you determine the pieces of information that need to be stored and retrieved from variables, you might have a drawing of the relationships, and in the end you have something that can be installed and executed on networked computers. But there is a difference, and that difference is the entire reason that BPM exists
According to Keith, software engineering has achieved a tremendous progress in its 50+ years of history, including structured and object-oriented programming, sophisticated modeling language (UML) and a large array of tools to help engineers at every step of development. As a result, a Software Engineer sees "Business Process Management" as simply another exercise in converting a drawing into an executable program:
When we are holding a hammer, all the problems around us start to look like nails... The steps in a business process are interpreted as just like steps in a program. Almost by reflex, the software engineer can translate high level functions into lower level sequences of functions, with control flow, etc, into something that can ultimately be converted to machine language, ready for execution. I imagine that many people in this category feel that BPM is just a lot of marketing hype around something that is quite routine in the Software Engineering world. What is the big deal anyway?
Keith tries to define the difference between software engineering and BPM through the differences between a business process and a typical program:
A "business process" is not a program. It may be supported by a program, but the business process is the thing that the organization wants done. You might say that the business process is the goal of the program, but not the program itself. A business process is managed by a business person: someone who understand the "business" and decides upon a strategy for doing that business, evaluates how well the business is going, and decides on how to change the process in order to meet changing conditions. The software engineer might manage the software, but a business person manages the business process.
He continues by outlining major differences between a BPM solution and a typical program:
- A business person draws a diagram, that is the diagram that is executed. It must not be transformed to a different form for the convenience of the Software Engineer. It must not be transformed to a different form for execution... This transformation is for the purpose of optimal execution, particularly on machines that were limited in processing power. Some business processes will still need this, but the vast majority of business processes will not be constrained by CPU performance.
- The history and analytic reports need to match the original diagram to support the business user in evaluating the performance of the organization, not for the programmer to tell how well the program is running.
- In a software system, the user rarely needs to know how the program is structured on the inside, but a business process is not a program in this sense. The process itself must be visible, even as the program supporting it executes. The people that are involved in the process must be able to understand what step you are in a process, what the next steps will be, and what the last steps were. This is the biggest difference between BPM and Software Engineering.
According to Keith, one of the biggest sources of confusion and misunderstanding is the fact that too often BPM design and development is done by software engineers:
Unfortunately, many people who study BPM systems, often come from a Software Engineering background, and automatically assume that BPM should have certain standard software features. Software Engineers view the system as a way to send, receive and transform information, and they are trained to reduce business problems to something that can execute in these terms. Business people do not focus on sending and reciving bytes, but instead about responsibility and commitment. It is a different way of viewing the business process. The effect of this difference is huge. By attempting to include all the Software Engineering features in with the BPM (business person) features, the result can be something that is not useful for either. You have people today still believing that BPEL is the ultimate way to implement business processes. BPEL only provides a way to send, receive, and transform... these are Software Engineering requirements, not business requirements. A Software Engineer will tell you that with these primitives you can implement anything, probably even a spreadsheet, but that misses the whole point about why we have spreadsheets and BPM in the first place: because they are not Software Engineering.
Keith concludes his article by evaluating current OMG BPMN 2.0 activities:
There is a huge discussion on the OMG email list currently about how BPMN is just another dialect of Unified Modeling Language (UML) the diagramming standard preferred by Software Engineers. Indeed a Software Engineer might look at BPMN and see something useful for Software Engineering. Remember that OMG is primarily an organization by and for Software Engineering, and it is not altogether surprising that many OMG members would come to this conclusion. Many of them even might imagine that UML is useful for all disciplines. Making BPMN a dialect of UML would be very convenient for the Software Engineering practice of reducing a diagram to an executable program.
BPMN exists for business people to express how people interact in a business setting. There are many within OMG who understand this as well, and I hope for all our sake that they do not get drowned out by those who view all problems as Software Engineering problems. BPMN does not exist for the convenience of Software Engineers, because BPM is not Software Engineering.
There is definitely a lot of confusion in the industry about the relationship between software engineering and BPM. Those are very different, but interrelated disciplines. On one hand, it is quite possible to design and implement business processes without any automation, and on the other hand, automation of business process definitely requires significant amount of software engineering involved.