BT

BPM Is Not Software Engineering

by Boris Lublinsky on Jan 24, 2009 |

 

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.

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

What makes a programmer? by Stefan Tilkov

I thought I agreed after reading the first few paragraphs. I can perfectly accept the definition of BPM that turns it into a modeling discipline targeted at communicating what's need for business people to decide on how to improve processes, or help them describe the domain knowledge to software engineers. But the author lost me when he wrote:
A business person draws a diagram, that is the diagram that is executed.

If it's executable, it's by definition so formal that it is a program. If it's a program, the person creating it is a programmer. So in this definition, saying BPM is not software engineering seems just plain wrong to me. In fact I'd argue that this combination – business people are building models, so this can't require the knowledge and tools of a software engineer, but still is supposed to be exact enough to be executable - is the root of many of the problems in the BPM space.

Re: What makes a programmer? by Boris Lublinsky

Stefan,
Executable does not necessarily means automated. There are thousands of business processes that are executed, for example, using email.

Re: What makes a programmer? by Boris Lublinsky


If it's executable, it's by definition so formal that it is a program. If it's a program, the person creating it is a programmer.


I think, that this exact train of thought is the root cause Of today's BPM problems. A diagram, drawn by business person can be executed only in the most simplistic cases. In majority of cases, such diagram has to be precise enough to outline intent, but typically requires software engineer to do the actual implementation. Even with the modern BPM suites, implementation of the business process is complex enough to require professional developers.

Re: What makes a programmer? by Stefan Tilkov

You have me confused – I'm not sure whether we agree or disagree. If you define "executable" as "will be done somehow", the problem of course disappears and we agree.

Re: What makes a programmer? by John Reynolds


If it's executable, it's by definition so formal that it is a program. If it's a program, the person creating it is a programmer.


I think, that this exact train of thought is the root cause Of today's BPM problems. A diagram, drawn by business person can be executed only in the most simplistic cases. In majority of cases, such diagram has to be precise enough to outline intent, but typically requires software engineer to do the actual implementation. Even with the modern BPM suites, implementation of the business process is complex enough to require professional developers.


I have to agree that professional developers are almost always needed to fully implement the processes that business folks diagram.

That said, the development skills that a BPM programmer needs aren't the same as those needed by typical "middleware" and "framework" developers (Java and C# folks). There's generally no need to implement EJB's, create Object Hierarchies, etc. The required skills are pretty much HTML/Javascript, SQL, and a bit of XML and web services - Very procedural, mostly "scripting" - Programming... Yes - Software Engineering... Not so much.

Don't get me wrong - BPM programming can be very challenging, but the challenges are usually more related to resolving ambiguous or contradictory business requirements than they are towards typical software engineering problems.

BPM Needs Software Engineering Discipline by Kelvin Meeks

From my own observations, giving a business analyst a BPM tool - and not involving a Software Engineer in the design of the process flows - may result in business process definitions that don't include due consideration for edge-cases, normal error conditions, and exception paths.

Re: What makes a programmer? by Stefan Tilkov

John,
The required skills are pretty much HTML/Javascript, SQL, and a bit of XML and web services - Very procedural, mostly "scripting" - Programming... Yes - Software Engineering... Not so much.

We'll have to agree to disagree here; a view like this leaves me very, very frightened.

The problem is in the marketing of the BPM tools also by Hisham Ghazouli

The BPM tools are often marketed as the ultimate solution for the business to take control of their IT requirements. They don't need software engineers to make changes. It can all be done using these tools. Yeah, right.
What the business people fail to understand is that they can not implement a process unless they get the DBA or software engineer to change or implement features needed for the process to be tied together. For example, in order to approve an order the information needs to flow from the order system and back. I know I am thinking about this as a software engineer and in terms of data. But what is a process without data?

Bottom line? by Hermann Schmidt

I don't quite get the bottom line of Keith's article. If BPM is not SW-Engineering, then the inevitable conclusion must be that *NO* BPM model must be (machine-)executable, not even in parts. Once it is, there is Software and designing Software follows some principles, which business people are not familiar with, no matter what the used language looks like (textual or graphical).

Just because some language looks simple in the first place, does not mean that it cannot screw up things.

I am sure that Keith knows all this, that's why I am a bit lost.

I think, business people should never be exposed to general-purpose programming APIs or languages. Specifically designed DSLs with a narrow scope are fine. UML is not (if used as generator input). BPEL is not (making it graphical doesn't change a thing). Scripting languages? Inappropriate.
A BPM modelling tool is general-purpose, since it is not specific to any domain. A domain-specific process modelling tool would be a DSL with a graphical interface. Fair enough, but that's not what this discussion is all about, is it?

Re: BPM Needs Software Engineering Discipline by Gavin Terrill

Agreed. Even if they did, the diagram would quickly lose its value as a communication medium, as the edge-cases/exceptions etc create too much clutter.

Re: Bottom line? by Jean-Jacques Dubray

The bottom line is that if people that a) participate in Business Process Standard working groups, b0 build BPM products, or c) claim they "automate" processes could open their mind just a tiny bit behind thinking that every- and any-thing can be reduced to a few "programming" language statements we could probably be in a very different situation today.

Boris, replying to Stefan, gives us some clues about the answer:
>> Executable does not necessarily means automated. There are thousands of business processes that
>> are executed, for example, using email.

Indeed, a "business process" is far better represented by entities that collaborate to achieve a single goal. Unfortunately, our "programming" models have no idea what a "collaboration" is and how "state" is managed across the collaborating agents (human or software). Scripting a couple of steps here and there is not going to be able to represent what is really going on in a "business process".

Sadly, as we were getting ready to layout the foundation on which BPM could have happened (bidirectional interfaces, assemblies, orchestration languages (to implement the behavior of the collaborating agents)...), it seems that our industry has decided to go back to a synchronous, uni-directional, CRUD oriented, contractless middleware layer, deeply and totally incompatible with BPM.

So it is not exactly a "developer" vs "business" mindset problem, it is really a formalism problem where traditional programming models are simply unable to create an execution environment compatible with BPM (such as the one Boris is talking about). I am not sure Keith has expressed it that way, but maybe just for once, we could ask the question of whether BPM can be supported by traditional programming models. If not, which ones?

Re: Bottom line? by Stefan Tilkov

I follow you in that a a better, higher-level programming language (or programming model, whether graphical or textual) might be much better suited for BPM purposes than any of the available GPLs. But even the perfect DSL is still a formal language. Even if process flows/collaborations/orchestrations/whatever-you-like-as-appropriate are its main concepts, the formulation of a business process in a form that is executable is still a program. And I remain convinced that for building good programs, a sound knowledge of software engineering principles is a prerequisite. Do you disagree?

Re: Bottom line? by Jean-Jacques Dubray

Stefan:

could it be possible to agree that there are 3 major formalisms for describing "execution":
- Turing
- Petri
- Milner

Would you think that "a sound knowledge of software engineering principles is a prerequisite." would mean the same thing in each case? How can the principles of a "connected system" be the same as the ones of a signal processing application? I would argue that 99% of developers have a decent understanding of Turing-based approaches to programming, about 0.9 % kind of get Petri-based programming, and about 0.1% understand Milner (could even be lower).

When given a choice, a developer will always implement a unit of work as a series synchronous calls with a central thread of execution. Unfortunately, this implementation model does not work at all for BPM (we tried for 10 years, lots of smart people tried during that time, and we got nowhere).

IMHO what Keith means is that business people can express fairly fuzzy specifications for a business process. Humans that perform the business process will somehow fill in the blanks and adapt to lots of situations while achieving the goal(s) of the business process. Developers, with the current programming models, are not be able to achieve this kind of behavior. What they produce is rigid and cannot adapt easily to exceptions, nor is it easy to express all possible exception paths.

Maybe, just maybe, "developers" could decide once and for all that a (turing based) "centralized" execution engine is the fundamental reason for this roadblock, and maybe just maybe, they could decide to look a bit further. They could introduce, for instance, modern concepts such as "collaborations" between software agents. They could also reflect on the relationship between "states", activities/actions and business processes. Unfortunately a recent survey of would-be thought leaders in the field of BPM/SOA can't even correctly distinguish between a state and an action. I don't know how we will ever make any progress in these conditions.

Re: Bottom line? by Stefan Tilkov

The point I agree with is this one:
Humans that perform the business process will somehow fill in the blanks and adapt to lots of situations while achieving the goal(s) of the business process.

... with the caveat that many times the business process diagram simply does not reflect reality (but let's not get into that). What I'm trying to say is that the business process description is necessarily incomplete and informal if it is supposed to be created by a business person and not a programmer. The programming model doesn't change this, even though I agree it affects the set of skills the developer needs.

Re: What makes a programmer? by John Reynolds

Don't be frightened Stefan :-)

In an attempt to clarify my thoughts I posted a more reasoned response on my java.net blog.

Re: Bottom line? by Hermann Schmidt

Jean-Jacques,

you are taking the scientific route and look much further ahead than I did. I regarded the platforms of today. The attempts to process automation which I have seen so far all have the deficiencies you mentioned. However, those products are purchased by companies in expectation to automate their processes further. As a consultant, I need to adapt to that and give the right usage recommendations for those (maybe crappy) products.

This scenario makes BPM a lot like SW-engineering. I don't get the budget to research and establish a new programming model. I'd love to go another route, really, but the industry follows the heavyweights and if they don't get it right, all I can do is fire-fighting or quit this hopeless subject and look for something else (my current tendency, BTW).

Re: Bottom line? by Jean-Jacques Dubray

Stefan:

>> The programming model doesn't change this

the programming model that our industry has converged towards is synchronous and assume that the fundamental unit of work is best described by an isolated request-response pattern (~single threaded). It it is true that every computing problem can be reified behind this simple concept, who would believe that a long running, graph-oriented problem could be simply decomposed in such fashion and serendipitously achieve round-tripping and perfect alignment with the way business users would think about the problem?

Could we just get real for one second? This is not about teaching everyone to script a couple of things, this is really about developers and architects understanding that we have reached the limits of the synchronous single-request programming model. The day people will understand that problems are a lot easier to solve in other programming formalism we will have made a big step forward. It is like trying to solve some problems that are best addressed by spherical geometry while trying to use euclidean geometry.

The better programming model by Hermann Schmidt

I believe I see now where you are heading. Does your envisioned architecture consist of autonomous entities, which communicate asynchronously with a kind of rendezvous mechanism (sync points) or mailbox-like message exchange?

It still appears abstract to me. Is your research work or that framework you've mentioned once related to this subject?

Re: Bottom line? by Jean-Jacques Dubray

Hermann:

the problem is with the vendors and industry thought leaders. I have been working in the BPM field for over 10 years now, building products, defining standards, using other vendors' product. It is of course not the role of an end-user to go at this level.

Most people in the vendors camp are looking to recycle whatever technology or formalism they can without looking any further. In the BPM space for instance there was the "pi-calculus" phase. The concepts of Milner theory are very important to understand for BPM. However, Milner's theory itself is totally unusable for BPM. Yet, the BPM camp had to fight at least 5 years to make these people understand that this was a dead end. In the WS-CDL standard I had to create a UML diagram of Pi-Calculus to help people understand that the semantics were incomplete. (Milner never had BPM in mind when he worked on Pi-calculus). So what happened? Some vendors claim that Orchestration languages were sufficient to "execute" business processes. They are only necessary, but not enough...

Nowadays, the REST camp is making us return to a synchronous, CRUD oriented programming model. They are wiping out other critical elements of BPM technologies that SOA had put in place: bi-directional interfaces, assemblies, orchestration languages, forward versioning strategies... On the other hand, the BPMN camp is completely ignoring the concepts of "Resource Orientation" (not REST). Worse, some people are now thinking to use BPMN as a scripting engine for REST.

Those are just a few examples of the insanity that has surrounded the field of BPM. BPM will only take off the day we will have aligned Service Orientation, Resource Orientation and Event Orientation as part of a process-centric programming model. Until then, all efforts are pretty much wasted on all sides (BPMN, BPEL, REST...).

>> quit this hopeless subject and look for something else (my current tendency, BTW).
I am with you, this is for now hopeless. Everybody is trying to push his little technology and control its little territory while the end user looses.

Re: BPM Needs Software Engineering Discipline by Johan den Haan

I think with have to make a clear distinction between the problem domain and the solution domain. In the problem domain you model the organization. This organization can be supported by software. A model of this software is a model of the solution domain.

In for example Model-Driven SOA we try to define a methodology/process to transform the problem domain model into a solution domain model. I think it is not possible to automate this process because the models take a very different perspective. Problem domain vs. solution domain, user perspective vs. system perspective, etc.

BPN Analysis vs. Modelling by Bernd Eckenfels

I have some experience with Business Process Modellers who are not programmers. And I can tell you they make a good job in understanding the requirements and even in documenting a possible process in diagrams, but the resulting diagrams are not executable for logical errors or complexity reasons.

It takes a programmer to understand reuse/interfaces/modules as well as error handling or simple loop/branching conditions and invariants.

You can state that BPM is not programming, but you cannot expect the BPM artifacts to be executable in that case. (Let alone field level programming for transformations).

Greetings
Bernd

Workshop about this topic takes place during German SE2009 by Sebastian Stein

It is indeed an interesting topic. Therefore, a workshop about the relationship between "Requirements Engineering" and BPM will take place during this year's German software engineering conference. Paper submission is already closed, but you can also participate in the workshop without presenting a paper. I also blogged more details about this workshop some time ago.

Re: BPN Analysis vs. Modelling by Boris Lublinsky

It takes a programmer to understand reuse/interfaces/modules as well as error handling or simple loop/branching conditions and invariants.

You can state that BPM is not programming, but you cannot expect the BPM artifacts to be executable in that case.


Thanks Bern,
That is a perfect way to sum it up. I would probably change the last sentence to say:
You can state that BPM is not programming, but you cannot expect the BPM artifacts to be automated in that case.

Re: BPN Analysis vs. Modelling by Stefan Tilkov

That is a perfect way to sum it up


I agree, although JJ will now surely accuse the author of being a RESTafarian.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

24 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT