Business Processes and Agile

Believe it or not, it is hard to find a company where the word process is not used.

Most of the time, people either describe the process in words or they draw a picture of it following the internal signs and toolset.

As good as this approach is, there are a few drawbacks. First, it is hard to onboard a new employee on those processes as they also need to learn each company private signs. Secondly, when you seek external help, you will also have to onboard the external people to your company private signs.

What is BPMN ?

BPMN is a language that has been normalized by the ISO in 2013. It helps people from different companies draw processes using the same toolkit.

This toolkit is composed of :

• activity elements, where business logic can be executed (manually or by a robot) :

• event elements, to start and end the process, catch and throw messages :

• logical gateways, that allow making decisions :

• flow elements, to connect the previous elements :

• swimlanes, each of which represents a service or a team with actions or decisions to perform :

There are dozens of other variations of those base elements. For a complete description of those elements, I would encourage you to read the BPMN website documentation.

Few examples

The first example represents the choice between a manual task or a service task.

First, one has to make the choice between one of the two solutions (first Exclusive Gateway). Once the task is completed, one goes through the second Exclusive Gateway to close the choice process.

The second process shows an issue resolution where a user might need to ask the help desk a question.

The help desk is an external entity, so why we created a specific lane for it.

As you may notice, the user can decide if they need to send a question to the help desk entity (first Exclusive Gateway). If they don't need the help desk, they can directly solve the issue ("Solve issue" activity).
But if they cannot solve the issue by themselves, they send a message to the help desk (from "send question" event to "receive question" event). Then the help desk answers the question ("Respond question" activity). The response is sent back to the user (from "Send response" event to "Receive response" event) and the issue is solved.

Basic usage and goal

The first purpose of BPMN is to create a unified interface to help business and tech teams communicate. It is clear enough to be understandable by every member of a company.

Once a BPMN diagram is created, it helps people find the value chain in a process and outline the most important tasks.

However, the main purpose of the BPMN is not the process analysis (a lot of tools can help people do it), but it is to generate executable code.

To do it, the BPMN can be transformed in BPEL (Business Process Execution Language). The BPEL can then be transformed into executable code (mostly Java at the time) by a robot.

Our usage

When we need process modeling, we follow the upcoming path.

We start by leading the team into the creation of a BPMN for the company process.

Creating the diagram can be challenging because some information can be hidden, forgotten or lost. Once the diagram is fully completed, we can reach a point where every member of the team share the same level of knowledge.

Reaching this point is crucial, because it will avoid having essential stakeholder. Everyone's opinion will be as valuable because there is no hidden knowledge. It is a prerequisite waypoint before starting to modify or improve processes.

Even if the main purpose is not to analyze and optimize processes, it is possible at this point to reveal several quick wins, pain points to improve, and so on (see the Pain point discovery example below).

To add a new feature to an existing project, the team will start by creating the BPMN summarizing the new process to implement. Creating the BPMN diagram first will help them :

• be sure that everyone agrees with the proposed workflow
• verify that all the external data needed are available
• identify the upcoming pain points and blocking tasks.

Often the team can also decide to abandon a feature because either it is too complicated, either it doesn't meet the business requirements, or it is impossible to build (see the Feature discard example below).

Once a feature is built, we keep the diagram and add it to the documentation. With this set of diagrams, the team creates exhaustive documentation of the project. They can use it to :

• onboard new employees to the project
• solve bugs they encounter
• target everything they will have to modify for future tasks.

The drawback to this process is to include the BPMN diagram modification in the Definition of Done for each task.

Pain point discovery

In this example, we consider the checkout and order preparation of an e-commerce website. The following waypoints where encountered :

• The order is created by the client if the product is available
• The payment is manually validated by the financial team
• Once the payment is validated, the shipment is prepared in the warehouse

While building the BPMN process, we found out that the stock as displayed on the website was not consistent with the real stock in the warehouse. Indeed once the payment was validated, the requested product could be missing in the warehouse. This lead to a lot of cancellations and refunds.

To bypass this pain point, the team decided to create a booking system. Now the stocks are consistent.

Feature discard

In this example, we consider an e-commerce website.

When a customer wants to add a product to the cart, the browser sends a request which contains the chosen product to the company server. Then a process checks if there are special rules meant to modify the cart (such as linked product, special offers). Finally, the new cart content is sent back to the browser to be displayed.

To limit the number of interactions between the browser and the server, the product team want to deport the business rules for the cart from the server to the browser.

While we draw the BPMN diagram, we see that the server is not only applying simple rules to the cart, but it is also using the configuration.

The next step of the process is to check if the cart is coherent with the same rules.

As we have to duplicate the business logic from the server to the client, we decide to avoid doing this modification.

Consequences on the development team

As we said in the introduction, the main purpose of BPMN is not to process analysis but code generation. We have noticed that it is possible, even if we do not generate the code directly from the BPMN, to gather some learning from the diagram.

Decoupling the application

First of all, the diagram can allow us to decouple our infrastructure in different services. Each lane will correspond to a different service we have to build.

Let's consider an e-commerce website. To make a product available, the team has to make a list of manual actions in their back-office :

• Check the translations for every country
• Check if there is a sufficient number of available products
• Check if every country accepts the product

For this process, we can draw the following BPMN diagram :

By looking at this process, we can see that it is possible to automate a certain number of tasks :

• The translations generation
• The stock control
• The country acceptance check

We then draw the diagram with those tasks in different lanes.

Thanks to this diagram, we immediately discern the microservices that need to be built from a previous monolithic architecture.

Class naming

Secondly, by taking a closer look at the tasks in the process, a development team is able to deduce the class names. It turns out to be interesting for the construction of a common reference, which is a principle of DDD (Domain Driven Design).

We can consider the heap sort process.

If the array length is equal to one, we have a sorted array. If not we split the array in two and sort both sub-arrays. Finally, we put together the main array.

We can also see that we need a few classes :

• ArrayLength to perform the first check
• ArraySpliter to perform the first action
• ArrayCombinator to perform the last action

We can also create the tests for all those classes by getting the data from the input flow and the output flow

Conclusion

BPMN can help on a lot of issues but it must be combined with other tools that are better suited on more specific points, such as class diagrams (we'd rather use UML) or API documentation (Swagger does it very well). The BPMN diagrams are used a lot for the different use cases as described above. However, BPMN diagrams are not a silver bullet to make a dysfunctional team better.