A lot of the confusion and difficulty in the BPM community is because some people think that BPM is a kind of Software Engineering.
Update: Please reference the post: One Common Definition for BPM where BPM is clearly a practice of a manager who assesses and improves the process for an organizational unit. It is not the development of the application that support activity. This post originally written in 2008, we find that even in 2014 there is still confusion on this point.
From some viewpoints, BPM looks superficially like Software Engineering: you start with business requirements, you determine the information that is needed to do the work, you consider relationships, and you might make an application as a result. But there is a difference, and that difference is the entire reason that BPM exists.
I have nothing against Software Engineering. Quite the contrary, I consider myself an expert in Software Engineering (others may disagree:-) and have dedicated a large part of my life to learning the art and practice. Software Engineering has developed practices over a 50+ year history, from structured programming, object oriented programming, and service oriented architecture. A very sophisticated modeling language has been defined (separately and then unified into “UML”) and a large array of tools have been developed to help engineers at every step of development. There are many many different languages, libraries, and other helpful constructs to get the job done.
When we are holding a hammer, all the problems around us start to look like nails.
Software Engineers often see “Business Process Management” as simply an exercise of converting a drawing into an executable program. 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. These people 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?
“Business Process Management” is, as the name implies, about management of business processes. A business process is not managed by a software engineer. 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.
I know this is a platitude, but allow me to state the obvious: business people are not programmers. Everyone knows this, but that is precisely why BPM is not Software Engineering. BPM is designed for business people, not Software Engineers. Because of this, BPM must be qualitatively different:
- Business people are not comfortable with abstractions needed for software systems. Programmers deal with abstractions that are unique to the software field, even multiple abstract models at the same time, in order to communicate and define how the system will behave. This is a learned skill as part of Software Engineering. Business people do not have time to learn how to be a Software Engineer. A good BPM system will provide a representation of the process which is meaningful to a business person. It will have the aspects of the system that are important to business people, and consequently it may not have some things that a Software Engineer would like. The diagram must not be cluttered by aspects which are “implementation oriented” as opposed to business oriented.
- A BPM system is there for the business person, not for the programmer.
- One 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. Software Engineers have a long tradition of transforming from one representation to another (e.g. UML to 3GL, and 3GL to P Code, P Code to machine code, etc.) 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.
BPM and Software Engineering go hand-in-hand. Some business processes require some software engineering support to realize their full potential in making organizations efficient. In fact there is a spectrum:
- Pure Software Engineering: the entire process is relatively stable and not dependent upon specifics of the particular team, and can be designed and implemented using standard Software Engineering practices.
- BPM by business people, followed by Software Engineering: This is what gets talked about most in the press where a business person draws a “high level” diagram, which is then translated to a diagram used by software engineers to design the “integration” with other systems.
- Pure BPM: where a business person draws a diagram, and it is implemented without any need for Software Engineering.
Many times I have been confronted by Software Engineers saying: “It is not possible for a business person to draw an executable process. It just simply can not happen.” These Software Engineers are of course trying to imagine a business person doing Software Engineering, because they are thinking that BPM is a kind of Software Engineering. It also reflects a myopic view that the only business processes that exist are the ones rendered in software.
But I ask those Software Engineers to consider this: “Most business processes are implemented today directly by business people without any Software Engineering — by using email.” Yes, business people are perfectly capable of implementing and running business processes. It is not pretty, but most actual business processes are supported by sending documents by email … or worse, fax machines or paper. My wife can send an email message without understanding the first thing about how the bytes are communicated to the other system, or indeed without an inderstanding of how the letters that appear on the screen are related to bytes in the first place. Those business processes are not “integration centric” but they are still very important business processes. Clearly there exist business processes which need Software Engineering to be fully automated, but there are just as clearly many business processes which have no need for Software Engineering involvement during automation.
A programmer from 1980 might have just as easily declared: “There is no way that business person will ever write a program to produce a table of calculated numbers for a report”. But then the spreadsheet was invented which allows the business person to do just that. What you should notice that a spreadsheet represents things in a way that is useful and meaningful to the business person. It does not involve a compiler that outputs the “program” in a different form, for later execution on demand. Internally, the formulae (in most spreadsheet products) are being parsed and converted to an internal pseudocode which is then interpreted. But this is all completely hidden from the user. The business user enters a fomula, and sees the result. A programmer might product a cool new function, which gets integrated into the spreadsheet, and can be called as part of a formula, but the designing and implementation of that extension is not confused with the creation of the spreadsheet itself. Creating the spreadsheet can be done by a business person. Creating the extension module is done by a programmer using Software Engineering techniques.
A BPMS can and should be the same way: the business user draws a business process, in terms of communications between people at steps of the process. The business person defines a formula to determine who should be offered the activity. There should be built in capability to accept this activity, or pass it on to a different person. The business person should be able to define places to share documents and other data values. For some processes, integration to other systems is important, and so there must be the possibility to call to programs or systems which are developed by traditional Software Engineering techniques. These “extensions” of the BPM system are developed by Software Engineers, but the development of these extensions must not be confused with the development of the business process diagram.
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.
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.