Introducing Business Process Management with JBoss BPM

(This article was excerpted from the book Effective Business Process Management with JBoss BPM by Eric D. Schabell.)

Organizations are constantly being tested in the markets in which they operate by shifting expectations of their customers, and by competitors looking to provide better value at a lower cost. This tension is the catalyst that continually pushes organizations to search for ways to improve their services, improve the speed which they deliver value to their customers, enable employees to get more done with less administrative overhead, and most importantly, to constantly grow by generating more revenue. This is the basis of BPM, to be able to identify and capture processes in an organization to create repeatable, measurable and consistent execution of goals to drive their business forward.

When an organization studies its operations, it discovers there are many processes used in its daily business. These processes are often not well thought out, or they were created to complete some aspect of the daily business, with little thought given to improving efficiency. At this point the organization looks for the first steps for improving through automation the processes that represent business value.

Business value could be anything that drives organizational goals forward to make customers happy, and thereby generate more revenue. This business value can be anything, such as keeping track of interaction with a customer. If that data could be captured, the marketing department could search a customer’s behavioral patterns to decide what products and services to market to a particular person. It would take mass marketing out of the equation and allow for direct, specific marketing towards individual customers’ needs.




It is possible to identify pieces of business value that are not worth automating because they are inconsistent or have too many potential paths to justify the effort to automate. Others will require traditional human brain power, which is not easy to capture in automated process form. An example of this would be the hiring of employees, a process that can be largely automated, but the actual decision to hire a specific candidate remains a factor of human intelligence. We can automate the process of handling applications, scheduling interviews, and the post process of on-boarding a new employee once hired. We leave the “hire or not to hire” task to humans.

Another important facet of capturing business value in processes is that we can monitor our processes and tasks as they are completed to provide business owners with valuable information. We can provide insights into aspects that interest the business owner, and make intelligent decisions about when and where to improve a process as the business evolves.

Imagine your business is running a retail process to sell products online. This process has a user task to approve large orders and is staffed by a set number of people during certain business hours. Bottlenecks may develop in your process as the business grows. What can you do when the Christmas holidays arrive and you expect a surge in orders? Will the current staffing of the user task allow you to process ten times the number of orders? What about one hundred times the orders?

By using historical data captured in previous process instances, it is possible to determine how many orders will be large enough to require human approval, and on average how long each approval took. If you simulate your process using tooling provided by BPM process engines, you can set the amount of humans working on the approval task in the process and set how long they take. By simulating hundreds or even thousands of process instances, you can watch the results of the orders flowing through your process and determine that you will need to staff your user task differently. During the normal months of the year you are able to process large orders with just two employees assigned for eight-hour days. During the holidays, due to expected increases, simulation testing reveals it will require twenty-four hour shifts to approve large orders, and you need to increase staffing to four employees. It is always better to know this before hiring new employees for the holidays and discovering it did not help process orders fast enough to justify the costs.

This process we look at is a step-by-step plan to accomplish a set of tasks that deliver business value. The basic series of events that leads to process discovery begins with identifying the piece of business value to be automated. This piece of business value is selected for its potential to improve the business as a whole when:

• The process can be automated.
• The process can be consistently executed in the same way.
• We can clearly define human involvement in the process.
• Automation of the process will remove current ad-hoc or inconsistent behavior.
• Measuring the process gains insights into current business behaviors.
• Insights provide a better means to decide when changes can and should be made to improve a process.
• We can reduce resource waste by efficiently handling wait-states.

Once a potential business process is identified, a workshop can be held by stakeholders from the business responsible for executing the process. For example, the human resource department might be in charge of registering new employees, getting them a workstation, starting their benefits, and assigning them an e-mail address. This process is discussed and dissected to identify the exact steps and order in which they would need to be accomplished to register a new employee. This results are put in a diagram with each step, from start to finish, drawn up as tasks to be completed.

These are the beginnings of a process, known as a process diagram. A process diagram contains all the elements needed to capture the steps in the processes without any of the execution details. You will find task nodes, start nodes, end nodes, transition arrows, gateways that split paths of the process, and gateways that join paths of the process together again.

The executions details needed to complete a process could be that a task in the process needs to send an email. The details we are missing to send an email from the task would be the sender, receiver, subject line, and body of the email. These need to be defined in the e-mail task. Another task might be to fetch data from an existing service in the organization, therefore requiring definitions for the location of the service, the service name, any data it might need, and whatever else is needed.

Figure 1 - A process that captures a piece of business
value, that of registering a booking for a hotel and 
a flight by taking payment from the provided credit 
card before notifying the buyer or determining 
that the payment was fraudulent and triggering 
a roll back of the bookings.

A process is not complete until we define the data needed for the process, what tasks are to be automated, what tasks humans must complete, what systems are to be integrated, and  the execution details for each task.

To illustrate this, imagine you are developing a process definition for a travel agency booking system. A part of the larger project is to define a process for registering a selected flight, hotel, and charge the credit card provided, if not fraudulent, and notify the customer of their travel details. If the credit card is fraudulent, we want to cancel the booked flight and the hotel. Figure 1 shows a process diagram of the travel agency booking section of the project. It is a fully implemented business process once the execution details have been added to each task, such as the flight booking service details, the hotel booking service details, the flight cancellation service details, the hotel cancellation service details, the credit card payment details, the e-mail details needed to notify the customer of their travel arrangements, and sorting out the details for cancellation services before they are signaled to undo a booking.

The ideal process is a fully automated process that removes human involvement. This is a process without any user tasks and is referred to as Straight Through Processing (STP).

Figure 2: An example of a Straight Through
Process (STP), this Customer Evaluation process
has only tasks and decisions from start to finish.
This process will always reach an end node for 
each and every instance of the process 
that is started.

By capturing a process in a static diagram and removing all human interaction we have ensured that each instance will be completed in a consistent manner. Any ad-hoc activities that are part of human nature, like taking a coffee break or visiting with a colleague, are no longer occurring when we have captured an STP process.

Figure 2 is an example of an STP process, where the tasks and decisions are made without human involvement from start to finish. This process will always reach one of the end nodes in the process diagram for each and every instance of the process that is started.

Sometimes a piece of business value that is to be captured as a process cannot be fully automated. Human involvement is needed to complete these types of processes, yet automating parts of the tasks will improve the business enough to justify turning it into a process. By capturing a process that contains user tasks, we have stumbled upon a very important feature of BPM, which allows us to manage wait states. A wait state is any task that requires that we pause processing and wait for some external event to notify the process to move onwards.

In classical application delivery, it is very hard to keep track of state. Waiting means putting information into storage so we can put our application to sleep until it is needed and we are ready to continue. With BPM technology we are provided with a state engine that manages wait states by keeping track of where we are in the process, by releasing resources that other process instances can use while our process instance is put to sleep. It also manages the rehydration of our process instance when it is ready to wake and continue from the current wait state. When a process instance reaches the wait state, it will save all state information needed to run the process instance and dehydrate, or go to sleep and wait for something to trigger a restart. When a trigger arrives to restart a process instance, it will rehydrate by gathering the necessary state data, and populating the process instance exactly as it was before the wait. It will then use the trigger provided information, such as a user task form with input data, to continue moving the process instance forward from where it stopped previously.

Figure 3 shows a process that leverages a user task called Approve Reward. When a process instance is started, the first task reached is the user task Approve Reward, at which time the task is assigned to a manager and waits until a manager has time to work on the task. When this user task is reached, the process engine will set up the task, and then be put to sleep so that it releases all resources for other process instances to use. This is how a single BPM process engine can execute many, many process instances at one time; there is a small set of active process instances. Most will be either in a completed state or they will be in a wait state and not be utilizing any computing resources.

Figure 3: The Rewards process has a wait state
in the form of a user task that is used by a manager
 to approve or deny a submitted employee reward. 
The manager decision determines the completion 
path to be taken, approved or rejected.

Once the task is claimed, worked on and completed, the process instance will be signaled that it is ready to move onwards. The process engine will rehydrate or wake up the process instance, putting it back into a state to move onwards with the data provided by the user task and evaluate if it should take the reject path or accept path for this particular employee reward.

Now that you have a feel for the basics of what BPM is, let’s take a look at the three main elements that make up a BPM solution and need to be supported by any BPM product you might use.

An introduction to rules, events and processes

The basic building blocks for any BPM project requires a product to have the ability to integrate business rules, business events and business processes. In this section I will introduce the concept of a Business Rules Management Systems (BRMS), discuss what rules are, look at how events differ from rules, and look at business processes.

What are business rules?

In traditional application development, the information used to decide what is to be done at any point in the application exists in the application itself. This logic is referred to as business rules and is implemented in static application code, becoming part of the artifacts that are compiled, tested and delivered into production. Each change to business rules within such an application requires a complete release cycle, in which code is changed, compiled, tested and delivered to production. This costs time and is susceptible to errors. Changes to business rules are passed from the business owners during requirement discovery phases, to a project team and developers, whose interpretation might differ from what was intended.

The next time you are looking at applications in your organization, look for constructs like if-then-statements and case-statements, which are basic indicators of business rules within applications. These constructs are indicators of business rules that should be externalized from applications. Once such business rules are externalized you can deliver applications, and later modify the externalized business rules without needing new application code. It is now possible to put the business rules into the hands of the business owners, who understand how to maintain the life-cycle of the applications using the business rules.

Business rule management systems are designed to provide exactly this kind of support and tooling to business rules owners and application developers. Business rule management systems provide tooling to express rules in terms that the business owners understand, and allows the developer to focus on application delivery while the business owner retains visibility of the business rules serving customers. Finally, with business rules centralized in an external location it becomes easier to maintain consistency across applications leveraging the business rules. If business rules are spread out across multiple applications, there is a risk of duplication, and rule maintenance becomes difficult as the application landscape expands.

What are business events?

Business rules are triggered based on a condition that has to be met, and when that condition is met the rule triggers an action. Rules are evaluated one-by-one, and they are either triggered or not. Rules can be grouped together, but they are still evaluated one-by-one to determine if a rule has a condition that is met that causes its action to be executed.

Business rules are also part of a concept called business events. Events can be triggered when a rule, or set of rules, match their conditions over a defined time period. Events that take place within the context of a business rule management system are still business rules, but now you add a temporal element.

For example, traditionally there are rules that can be applied to credit card transactions. Imagine a rule that requires that a purchase must have a total value that fits the credit limit for that card. Should the purchase being attempted exceed that credit limit, the action taken will be to reject the purchase. This rule can be applied time and time again, without regard for any sort of time-sensitive information. It is only when we add a time element that it becomes a business event, such as looking at a period of transactions to determine if any took place in locations that are not physically possible. Such a series of purchases, say in Tokyo, San Francisco and Amsterdam in a span of 24 hours, would result in a business event triggering the blockage of the credit card, and a notification process to alert the card holder of fraudulent usage of the credit card.

A more modern example is how enterprises use business events to monitor their corporate image across all manner of social media channels. In the travel industry for example, you see event monitoring coupled with large customer contact centers, which are manned by hundreds of employees who receive notifications whenever online comments reference their company. If they can use event monitoring to detect and respond to messages, negative or positive, directly with the customer who wrote them they can have a positive effect on their image in the market. This is a powerful use of business events and is only possible with a business rule management system that has event processing.

What are business processes?

We have discussed how business processes can be discovered in an organization to reduce inefficient manual processes by automating as much as possible. What are business processes used for besides automation? Business processes are used to improve consistency in completing a series of tasks, increases visibility, and reduces errors.

Before an organization starts using processes to streamline its business activities, it is just a large pool of employees that are trying to bring value to their customers. This can be done by filling orders or providing services. These employees are assigned tasks that might require interaction with back-office systems like shipping, financial, or inventory, or it might require they contact a transport company to handle order delivery.

A modern organization evolves over time, automating some interactions with back-office systems, and adding technology to provide a service layer that communicates with various applications. The problem is these services are used by applications for specific tasks, and not linked together to handle a complete series of tasks that makes up a business process.

Once the back-office and external organizations have been put behind an automated layer of services, business process discovery can identify the processes that can be automated. Business processes become the layer of organization or integration that brings a series of identified tasks to complete a part of the business, sometimes involving human interaction. By managing the user tasks deemed necessary to remain in business processes, they can be repeated in a consistent manner, measured for efficiency, and reduce errors during their completion. Finally, an overview of business activities can be monitored and reports generated to keep track of how various parts of the organization are functioning. This can lead to quicker decisions around adapting existing processes, or implementing new ones, to further accelerate the earning potential of the organization as a whole.

To review, it starts with experts from the business helping to identify needed tasks and the sequence in which they are to be completed. A small group of human resource employees could be used to discuss the hiring process. They would tell their stories about how they put together a job description, place advertisements for the job opening, handle incoming reactions from applicants, schedule interviews using existing calendaring systems for employees selected to interview candidates, gather interview impressions from the employees, obtain a decision from the hiring owner of the job, inform rejected candidates, notify the hired candidate, begin the onboarding, etc. Portions of this process are worth automating, like the onboarding process that uses manual tasks, when automation would save valuable time and resources.

A BPM suite is used to automate the process by integrating services in the organization, directly with systems, or managing human interaction with tasks users need to complete. The BPM suite captures the process instance data and generates reports to provide business owners up to date information and visibility into every aspect of business operations.

When looking at BRMS products you will note they support rules and events. A BPM suite product needs to be a super-set by encompassing BRMS functionality and adding in support for process development and execution. Therefore, when talking about a BPM suite we will be referring to rules, events, and processes in a single suite.



For source code, sample chapters, the Online Author Forum, and other resources, go to

https://www.manning.com/books/effective-business-process-management-with-jboss-bpm