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.
Thinking Matters 
Pingback: BPM is not Software Engineering
I agree with Keith Swenson that BPM is not Software Engineering
However, I think that some of the arguments are a little broad. Ultimately we need to have software construction and business process design working toward the same set of goals in an organisation. {more at http://davethinkingaloud.blogspot.com/2008/11/bpm-is-not-software-engineering.html%5D
Pingback: links for 2008-11-26 « MyNotePad
Pingback: links for 2008-11-27 « steinarcarlsen
Pingback: ruote nov2008 status « processi
Pingback: Column 2 : Bookmarks for November 28th
We are software engineers who build systems using BPM and BPM tools. One thing I see all the time is a customer who has been sold BPMS software, and has tried to build a system with little or no Software Development experience. They do this because the vendor tells them they can – the software is that easy to use.
The result is almost always an expensive disaster.
I agree that BPM is not a Software Engineering tool as such, but I have to state that turning the collected specification, for that is the most you should be getting from business, IS the role of Software Engineers. You need the understanding and experience in order to build a robust system, and to interact with other systems.
As such, BPM is the tool that allows business people and technical people to communicate requirements. It is streets ahead of any other approach in that regard. This is the main reason we use it.
Essentially I agree with what you say, but our experience tells us that “BPM by business people, followed by Software Engineering” is more than possible, but “Pure BPM” (as you describe it) is just not feasible yet.
I am not saying that Software Engineering is unimportant in the support of business processes. I am simply saying that what the Software Engineers are doing should be called Software Engineering, and not BPM. Business people and Software Engineers collaborate to support the business process: BPM is what the business people do, Software Engineering is what the IT people do. Many existing “BPM Suites” require Software Engineering — there is no denying that.
You may think I am splitting hairs about terms. It is the imprecise use of these terms that cause disasters, like customers who have been told that the system does not require any Software Engineering involvement. We need to realize that it takes both, and to not confuse the one with the other.
And that’s where SOA comes in. No BPM (or BPMS) without SOA. No SOA without BPM.
Pingback: BPM - Is it a Software Engineering Tool? A Technology? or a Management Discipline? « BPM Focus
To expand on the SOA point, I would say that SOA is very clearly a Software Engineering activity.
Business people do not care whether the IT systems are structured as services or not. Remember, a business process can be performed manually, by email, by paper, etc, so there is certainly no requirement for SOA in order to do BPM.
A modern BPMS really should be “Service Oriented” — at least I would not recommend one that is not — simply because that makes for good Software Engineering.
I think I have a minor disagreement with you a little here Keith with your statement “BPMN exists for business people to express how people interact in a business setting”. BPMN is a form of UML as you stated and any kind of markup language or language in general other than spoken languages are beyong the vast majority of non-IT people (or Linguists).
(please note: this comment was caught in the spam filter for a few days)
You raise a lot of interesting issues & I agree with much of what you say.
I think though that the ‘business’ vs ‘IT’ dichotomy can obscure other possible perspectives which are sometimes important to the business problem space being addressed.
For example I agree it is often the case that ‘Business people are not comfortable with a lot of abstractions about software systems’. But not all abstractions are about software systems.
Abstraction is needed to analyse problems logically, and logical analysis is a shared domain – or at least it should be.
Again, there may be contexts where it might be valuable to remember that BPM systems are ‘there for the business person, not for the programmer’. But there are other players. The customer for example.
So I don’t think it’s always safe to assume that ‘[Once] 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.’
Yes it should not be transformed just for the convenience of the Software Engineer, but it may need to be transformed so as to deliver more effectively and/or more efficiently what the customer has requested.
A business process may involve ‘communications between people’; formulae ‘to determine who should be offered [activities]’; ‘capability to accept [an] activity, or pass it on to a different person’; and so on. But a business process – particularly one geared to meet the customer’s requirements rather than only reflect the supplier ‘business’ stakeholder’s needs and vision – will typically contain more than this, and may contain little or none of it.
I am thinking of a domain like financial services, where business processes can usefully be conceived (and logically analysed) primarily in terms of data and rules.
As far as BPMN and UML are concerned, your remarks certainly struck a chord. I may well be out of date, but each time I have dipped into UML I have found it inappropriate for representing end-to-end business processes at the logical level. What it seems ideal for is representing functionality which may be employed in a business process.
On the other hand I have not yet found anything in process analysis or design which I’ve been
unable to express in BPMN. Ergo I would lean to the view that BPMN is not a dialect of UML. But it is also part of BPMN’s strength that it does more than allow ‘business people to express how people interact in a business setting’.
Great post! I’m absolutelly in agree with your points, and probably i’m more radical in the way to interpreter the BPM. I believe BPM it’s not a Software Engineer Tool but it’s a methodology that help in a particular management practice. It help who have the the BPM Role within an organization to plan, organize, monitor, control and execute a set of actions to produce deliverables required by other units of the organization and/or it customers in response to requests received for these deliverables. The BPMS are tools that given a plan (the process models) of the desired execution undertakes to control and execute the assigned actions, to provide feedback on how it
is doing. To do that i’m in agree with Jerome that often a contribution of good Software Engineering is needed! After all the BPMS vendors are focused on the modeling of activities, organization, data and model execution and monitoring functionalities, but when when we talk about integration for example they always require IT engineering to be involved…
Pingback: Process for the Enterprise » Blog Archive » Discussion of the Thanksgiving Holiday: BPM vs. Software Engineering
Pingback: BPM HOJE » BPM não é Engenharia de Software
I’m agree with Keith Swenson, in all points. Every Software Enginneers must read this text.
Congratulations!!!
Pingback: Marco Mendes´s Blog » BPM Não é Engenharia de Software. BPM é sobre Pessoas e Processos de Negócio!
Thanks for all the great comments.
Chris, you are right, logical analysis is a shared domain. In re-reading the article, I realized I may have implied that “abstract thinking” was only for programmers, and I didn’t mean that, and I hope nobody took it that way. Of course business people make abstractions. What I meant is that the particular kinds of abstractions that are common in Software Engineering are not familiar to business people, and so in the area of supporting processes with technology, then need things that do not rely on these Software Engineering abstractions. Of course, they have many many “business” abstractions.
These comments have really help to illustrate the range of positions on the subject, and how different people are seeing the term “BPM” in different ways. If you are reading this, and feel that your view has not been presented, I encourage you to leave a comment to express that view.
Some blog posts do not automatically get linked, and I don’t quite know why:
http://blog.cryo.com.br/2008/12/03/bpm-nao-e-engenharia-de-software/
http://itredux.com/2008/11/28/bpm-is-process-engineering/
http://www.thebafiles.com/2008/11/bpm-is-not-software-engineering/
Craig Cameron made a comment that BPMN is just a form of UML. I disagree. BPMN exist precisely because it is NOT UML, because BPM is not Software Engineering. There are strong forces trying to push BPMN to be part of UML, but those forces are the same ones that think BPM is a kind of software engineering.
My main point is that we need to preserve BPMN from this trend. We need to make BPMN understandable and usable by business people, because that is who it is for in the first place. If it becomes a part of UML (with all the accoutrement that entails) it will be less and less useful for business people.
Pingback: BPM 2.0 « Euroside
‘Business people do not care whether the IT systems are structured as services or not. ‘
Well, whether they do or not , they certainly should.
SOA is more than software engineering in the sense that it use is nowadays absolutely critical for business agility.
Knowledge of what SOA is and why it is important should be part of an MBA course.
I think some engineers don’t really know what services are whereas it is second nature to business people. The latter also recognise that services are made up of those automated by software and those that are not, but when describing the organisations and how it works the way all services fit together needs to be modelled.
That is why the US defence industries use Idef0, and why BPMN is limited because it just represents processes.: ie the functionality that carries out services.
I agree with Jerome’s post. In fact, I stumbled across this article and know who Jerome is. This is because our company bought a solution from the same BPM vendor that Jerome’s business consults for (at least this is the majority of their business).
We as a company were sold the system on the premise that a business layperson could draw a business process and with a few clicks of the mouse and a few button taps could have an executable process.
Well that is true but what the user generally would get is not what they would want. I evaluated a lot of BPM systems and read a lot of analyst reviews before deciding to invest our company’s money in BPM technology. Several of the factors that lead me to make this decision were that most BPM systems have the Roles, Actions, and Stages type features built in that would take a regular software engineer many man-months or years to develop. I doubt many companies have the business process expertise or for that matter the resources, time, people, money, … to internally develop what BPM offers out of the box.
So, I bought a system to help me get that type of capability but pretty much threw aside all the “no programming required” statements knowing that there is only so much that can be done without using some type of “coding” be it visual or statement based.
But, I have been pleased overall with what the solution has brought to our company. The visual diagrams are easy for a business person or process engineer to follow through.
These are the people who know the business and that is what makes BPM so neat. It gets out on the table the process and who plays what part, and at what time, and under what conditions.
This makes the job of the traditional software engineer easier because they do not have to become a subject matter expert to effectively help bring a BPM diagram into an executable model.
Thanks for the post, I do agree with much of what you are saying just that in our case, we have not come across any processes that do not require some help from a traditional software engineer. In my case, I have a software engineering background and have added BPM to my toolbelt. I hope more people in our company like process engineers eventually are able to take the designer and help create the process maps for me.
Good points. No disagreement. Lets just call that software engineering “software engineering” and not BPM. I am not saying that current BPMS systems do not require software engineering, and I really know what you mean about those “claims” that no programming is required.
BPM is the stuff that is NOT done by the software engineers.
Reading the article and all those comments above it seems to me that much of us have agreed upon many points and statements on the main subject.
Unequivocally, BPM is not Sw Engineering, however BPM systems have proven their ample applications in different business industries, as a quite new alternative for business management; in the other hand BPM systems will need, always, the knowledgment of Sw Engineering to improve such systems, technically-speaking and fulfill BPM user´s new requirements
Pingback: BMP is not Software Engineering « Admar Moreira
Pingback: BPM é ou não Engenharia de Software? « Admarmoreira’s Blog
Pingback: BPMLab » BPM – это инжиниринг процессов
Pingback: Is the BPMN/BPEL Debate a Dead Horse? « Go Flow
BPM, M2, DSL
26Jan09
I stumbled across this very interesting article named “BPM is not Software Engineering” by Keith Swenson, …..
http://famelis.wordpress.com/2009/01/26/bpm-m2-dsl/
Pingback: Making the Complex Simple - How best to streamline and automate business processes « Business Process Management (BPM) - InSights
little difference of opinion here i think the term BPM is to bridge what Software engineers and business people do. BPM should help bridge or obliterate the gap.
In my opinion a BPMS today typically allows what software engineers earlier were not able to do (i.e., manage business process) which the software engineers today can to more effectively using BPMS and similarly the business is able to do what it was not able to do earlier (bits n bytes stuff) they are able to conveniently manage business rules by using the BPMS they are able to create rules, manage it as the process changes infact change the process on their own apart from just the empowerment of changing business decisions of BPMS.
It is a win-win situation for both Software engineers and business are they are able to eat each others pie and able to digest the same.
Pingback: Defining BPM and state thereof – The Perspectives at play « The Eclectic Zone
Pingback: Should We Redefine BPM? « Thoughts on Collaborative Planning
Pingback: Keith Swenson’s Blog – On Collaborative Planning « Adam Deane
Pingback: BPM: Bullshitagens por Minuto « Graffiti
Hello Sir,
Could you elaborate more on the meaning of a service activity in the context of your article? When would a business analyst use a service node in their diagram, considering what you wrote here?
Thank you.
Take a careful look at the definition of BPM at https://social-biz.org/2014/01/27/one-common-definition-for-bpm/
Note that BPM is the discipline of assessing and improving processes. As part of that, one might have an application developed to support the process. The development of that application is not BPM exactly, and it is important to keep the distinction in mind.
If you were manager of a branch of a bank, you might determine that you needed software to help users access their account. You might hire Joe, the developer, to write this application. Even though Joe’s application will help the bank, you would never say that Joe is “doing banking”. He is writing software, not running a bank. it is the same with these applications: they support processes, but they don’t “do BPM” which is a practice of measuring and improving processes.
That application developer might use a service node as part of the application. No problem. Does that answer the question?
Dear Sir,
Thank you so much for your super-fast reply. I would like to add some more to my question.
Is it the business person or the IT person identifying the fact that a service node needs to be placed in the diagram? I assume it is the business person. So, in a way a service node is the place (one of them) where business person becomes somewhat IT-aware, without doing SE. Am I right?
Yes and no. This question falls right on the grey line, and you are trying to find a clear demarcation in a fuzzy world. The post attempts to address the common mistake that BPM is just a type of software engineering. This mistake is pervasive. Many features of BPMN have been added by people misguided by this mistake. It is not clear that a true BPM practitioner actually needs a “service node”. Still, there are cases where certain information (such a credit score) is widely known to be automated, and therefor quite reasonable to put a service node to look up credit score. Does this mean that the business person is doing software engineering? You said it best: the business person is acting in an “IT aware” way, however there is still a wide gulf between occasionally placing a service node, and doing software engineering.
My goal with the post is to simply make sure people are aware of the different needs of the business user and the software engineer, and to avoid the trap of thinking that a BPMS should have all the normal software engineering aspects, and to also appreciate that just because a feature exists in BPMN does not mean that a true practitioner would actually need it.
Before you reply, the page found at https://social-biz.org/2014/01/27/one-common-definition-for-bpm/ is awesome!
thanks for the comment!
Hello again,
I assume you have some criteria or some guidelines for determining if the gray line should resolve to black or to white, because as a modeler one must make a decision when producing the diagram. I am still unclear about when a service task would be used by a business modeler. Am I trying to predict the unpredictable?
A service node will be used by the business analyst in the same way that it would be used by a software engineer: to automate the transfer of information to and from the process. If you look at the entire job of a business analyst, and the entire job of a software engineer, you will see that a business analyst will use this kind of node very rarely. The business analyst is working at a different level of abstraction. The business analyst deals with the concept of a customer, while the software engineer will be much more concerned about the details of a record that represents the customer.
The example I gave above of fetching a “credit score” is a reasonable example of a service that a business analyst might want to use: it is common knowledge that something called a credit score exists, and that it is relevant for making certain kinds of decisions. We know that credit scores change, and you wont have the current score for everyone local, so most people easily understand that you need some form of automated mechanism to go get it.
A software engineer would know that as well, and use the node that way, but the software engineer might also be aware that a different call needs to be made first to find the customer’s unique ID for looking them up, or a different call to get the credentials necessary to make charge the cost of the service to the right account, or possibly another call needs to be made after in order to translate the coded values into human readable values. The software engineer is working at a different level of abstraction … a much finer level with specifics about how the machines work, and actually what data values need to be sent and how they are represented.
So the service node is used in the same way by both professions, it is just that business analyst very rarely needs to use them, and the software engineer has a much greater need to use them. Does that help?
Thank you very much, Sir. Your detailed reply does help, of course. It is a pleasure to read your blogs, they really help me improve my bpm understanding. You are very generous!
Pingback: Still think you need BPEL? | Thinking Matters
Heello mate nice post