The typical BPM demo is actually hilarious. It gives an impression that is completely wrong: A business analyst draws a diagram of a simple hello world process, presses a button and a working system comes out. “Look, Ma! No coding.” Managers get absolutely wild when they see this… “So I can get rid of my unpredictable and slow developers?” Regrettably for the managers, nothing could be further from the truth.

Roles

Essentially, the development of business processes with a BPM system is not that different from regular software development. Though, there is one aspect that I would like to emphasize: Developing software with a BPM system can significantly improve the communication between the requirement’s stakeholders, the business analysts and the software developers.

In the development of software to support business processes, we can distinct 2 roles: The Business Analyst (BA) and the software developer. While these are 2 clearly distinct roles, note that in smaller organisations, the same person in an organisation can fulfill them.

In larger organisations, there is more specialization and the function business analyst and software developer is split up into separate full time positions. Even when one person does the business analysis and the technical implementation, the insights on how the roles work together leads to better quality of the software.

Executable business processes

To talk about how the roles of Business Analyst (BA) and developer interact, let’s first differentiate between abstract business processes and executable business processes. A business analyst is only concerned with the abstract business process. This includes mainly the graphical diagram. It does not include all the technical details needed to make the process run in a production environment. Let’s define an execution business process as a process that includes all these details so that it is a self-contained package that can be executed in a BPM engine.

The JBoss jBPM team thinks it is important that the business analyst is in control of the graphical representation of the business process. The graphical view of the business process should be a projection of the executable business process. Meaning that the graphical view should hide details and only show the aspects that are important to the business analyst.

We believe that an executable business process is a piece of software just like regular software written in an OO programming language and therefore, the same techniques of software development apply: namely iterative development and test driven development. Iterative development means that business analyst and technical developer each are responsible for different tasks in the development.

Business analysts do not create software

The business analyst is responsible for understanding the procedures in an organisation, how software will be used to support the procedures and documenting the way that people and software will work together. Mostly, business analysts use diagrams as the backbone for describing a business process, accompanied with a textual or sometimes oral:-( explanation. Creating a good visual representation of the business process that shows the important aspects and hides the details is a crucial factor.

As you might already know, all BPM systems support a graphical notation for their processes. But there’s this really stubborn myth that the goal of BPM systems is to eliminate the role of the software developer and eventually, the analyst will create executable software.

As we speak, this myth still is pursued by many of today’s BPM software vendors! As if the BPM systems would be able to automagically guess the best transaction-, locking-, asynchronous execution strategy and knows how to integrate with all of your enterprise’s systems... yeah right.

The “look ma, no single line of code for this process” works perfect for hello world examples and demos, but in real development scenarios it becomes painfully obvious that business analysts do *not* create software.

Hiding details

We at JBoss jBPM think that it is *vital* that The technical developer is responsible for adding technical details to the diagram to make the process executable. Developers do this in an iterative fashion, influencing the work of the business analyst. Their collaboration is now greatly improved because they have a common graphical model that they can use during their discussions. In JBoss jBPM we have created a model that allows for the business analyst’s important ideas to be expressed in the graphical diagram. But –similar as with UML class diagrams— developers must be able to hide the technical details for turning the graphical model into an executable piece of software.

Separating the responsibilities has an important implication. It means that the graphical view of a process should be decoupled from the technical details that have to be added by the technical developer. Most of today’s BPM systems fail at this.

If a developer needs to add e.g. a technical database update in which the business analyst is not interested, these systems still require the graphical model to be changed. That is unacceptable. A developer must be able to add details and implementation *without* touching the graphical diagram that is used as communication between the BA and the developer. In one of the later blogs we will refer to “Graph Oriented Programming” as a simple technique to achieve this decoupling.