We software developers are used to embracing new technologies. Every day, we have to learn new versions of frameworks to make best use of the features available in them. We deal with the frustration of learning new APIs, integrating them in our project's architecture, and taking advantage of the all-new functionality that these new components provide us. We thrive on that. The software industry continuously pushes us into innovating how we design and architect our software solutions, sometimes to the point of not just creating a new framework, but a new paradigm to enhance communication and descriptiveness of the company's internal sequence of activities and software, which we need to understand as developers.
Business Process Management (BPM) is one of those paradigms whose scope goes further from the development arena and into all sorts of company realms. BPM provides visibility about a company's business processes, allowing us to improve and speed them up to increase profits and reduce costs, consequently improving the way the company works. It is a discipline with its own objectives, life cycle, and best practices, and one of its biggest added values is the common language it defines between all its participants—the business process.
You will find in this chapter the starting point to define these business processes, and how they help in building solutions that drive a company in a way that helps it to adapt faster to the business reality.
We will review this paradigm and how it enriches what we already know about building solutions, along with the technical topics to put them in practice into the latest jBPM version. To do so, we will cover both theoretical topics that would apply to understanding any Business Process Management System (BPMS) and the technical topics to build highly adaptable applications using jBPM6. Important concepts and definitions are highlighted throughout this book to help you solve new problems as they are found.
When you start embracing these new concepts, you'll find new ways of modeling situations, finding solutions, and building applications that will be of interest for many different people: the development team for integration purposes, the business analysts and managers for formalizing processes, the end users who will interact with the user interface, and pretty much anyone with an interest in the company processes. It is of great importance that you share this new knowledge with as many people in the organization as possible, because BPM is not just a development tool but a full company driver that will surely help your project and your company to be a success by establishing a common language between different areas of expertise.
BPM improves the quality and flexibility of the software solutions we build by helping the company to drive its business. BPM establishes a management strategy to establish an integral way of managing the company's activities, which allows different domains to concentrate on the efficiency of tasks in terms of time as well as costs. BPM allows a company to use an iterative cycle to continuously detect and improve both activities and processes as needed or desired by a company. Driving a successful BPM implementation requires a lot of learning, but we'll cover as much of that learning as possible in this book. I strongly recommend that you involve as many areas and roles as possible in your BPM implementations by taking advantage of the common language generated by the BPM methodology. Furthermore, sharing your experiences develops your professional skills and helps you to gather different perspectives and visions from the topics that you find relevant. So, let's get started!
The content of the book is divided into three different stages:
Theoretical background
Introduction, analysis, and explanations of standard specifications
BPM APIs and common practices
Each stage focuses on different concepts.
This stage will drive the language used when you discuss BPM-related topics. Important definitions that you will adopt will be explained, exemplified, and dissected. That makes this stage vital, as those definitions will relate to your everyday work and to the way you communicate with others in the project (and in the company). This is also the reason why it is important that the important aspects of BPM are discussed with your peers. You might constitute a new vocabulary out of them, and just like any vocabulary, it's important that it is shared by everyone.
Each definition will be scoped to a particular context. I will first explain each concept in a very generic way, as it helps you to understand the reason and purpose of the concept without including any reference to implementation or technical details. In more technical sections, I will map these concepts to more technical terms with concrete references to jBPM6.
This stage will (hopefully) drive your architecture and integration strategies. Standard specifications are created to define a common baseline to be shared and applied in new developments, which is based on the collaboration and experience of many groups and companies to aid in integration with other systems. If you decide to change implementations, standards could help you a lot in not having to rework migrations from one implementation to another.
This book introduces two main standards specifications, Business Process Model and Notation Version 2.0 (BPMN 2.0) and the Web Service Human Task specification. Both are used by jBPM6 and reflect good practices to create industry accepted and interoperable applications.
We won't go into the full details of the specifications in this book. We'll cover the details regarding where jBPM6 is not 100 percent compliant with the standard specification and how to deal with those cases. The standard specifications are not included for being size restrictive. Reading them, however, is very good to gain perspective on common practices adopted in a wide range of industries. We will provide links to them as we dive into them.
This stage will ultimately drive your implementations by covering a complete list of the most important technical topics inside jBPM6, which will be discussed and demonstrated in practice.
We will begin with simple examples, and then the examples will gain complexity to reach real-life situations. All the source code used in the examples will be available to download and examine, but not all the lines of code will be explained. The technical sections of this book should be read with the source code available. The main idea is that you see the projects in your favorite IDE to practice just as if you were developing your own projects; this will help you to practice and get used to real development tools, projects, and errors.
This first chapter is focused on the whole conceptual background needed to get you started with jBPM6. Most of the concepts that will be introduced in the next section are related to the BPM discipline. These concepts are essential, and the clearer you understand them, the easier it will be to start with your first projects.
In order to understand the concept that guides BPM, we must first begin by understanding all the concepts behind that name, and the first one we need to understand is the concept of process.
In the broadest sense, a process is a series of steps or transformations to achieve a specific objective in a particular context. Like any transformation, it needs to have something to transform and a well-defined desired output of the transformation.
For example, if we want to build a house, we need to follow a set of steps depending on the area of the house, the materials, any services available, and so on. The steps also depend on the outcome (house style) we want. Some of the steps can be done at the same time, while some need to wait for other steps to be finished.
The important thing is the coordination between those steps to perform the transformation in the way we intend to, and each step needs to be clear and concise. In short, for each transformation (process), we need to know all the steps required to achieve the required outcome (goal), which will be the desired result of a process. Usually, goals and objectives have the ultimate outcome of improving the revenue or production of a company, and can have multiple yet different end results, thereby improving the conditions of the business.
The knowledge of how to achieve the goal and the transformation steps are usually held by an expert in the context. I may probably have a basic idea about how to lift a few walls for a room, but for a real-life scenario, I may not be able to describe all the steps needed to make quality housing. If we really want to know about real-life processes, we need to talk to experts in that field. This expert knows how to deal with normal processes and also how to deal with specific or exceptional situations for a wide range of different houses and buildings.
The word business associated to the process definition can seem ambiguous, but it is mostly due to how abstract the concept of business really is. From a developer-friendly perspective, we can think of business as a particular domain or context, or group of contexts. It could be easily exchanged in this case for domain, field, company, company unit, and any lingo that specifies a defined area of work. Business processes need to be evaluated, analyzed, designed, modeled, and validated by people who understand the domain where those processes belong. Since there are different business roles within a company, each should know a different perspective of the same process. Then, the business process becomes a common point of interaction and a common language between those roles. Activities, decisions, events, and many different components will define the structure of the way a process that is relative to a business needs to be conducted.
It is important to notice that the goal of business processes is tightly associated to the business goals, objectives, and strategies. With all these considerations in mind, we can arrive to the following definition:
Business processes are a sequence of business activities done by business users and business applications (company or third-party systems) to achieve a business goal for the purpose of a specific increase in value from the business' perspective.
We'll analyze this definition in detail by splitting it into its three main concepts and covering them thoroughly.
An activity is a black box piece of work that contributes directly to achieving a business goal. We surely need to understand how the activity is performed. However, as we say, it is a black box, because from the process' perspective, the only things important are the inputs it needs and the outputs produced. The activity performed can be very simple or very complex, depending on the perspective of the process definition.
What is considered an activity in one process perspective can be composed of a group of low-level processes, which are in turn composed of a series of simpler activities. For example, a high-level process in a car factory can have an activity called "Build the Car's Engine", but from a lower-level perspective, activities could be detailed to the point of just telling a robotic arm to activate the weld for a second (one minuscule step in the car's engine preparation). In other words, a business process can be composed of multiple subprocesses.
Once you select a perspective or level for a particular process definition, you should stick to it for describing all activities regarding that specific process. You can call other lower-level processes from activities, so you can always go into more detail later. Besides, high-level strategic processes and low-level more technical processes will surely have different roles and experts behind them. A manager in a car factory might not be interested in having so much detail in their perspective, but an engineer would. Also, managers prefer to see the bigger picture, and tend to simplify their views to be able to cope with everything at once.
Usually, the low-level perspectives end up driving the operative end of the company, performing work such as the following:
Handling customer information
Documenting specific metadata
Invoking service notifications
In the end, all processes are tied together by high-level perspective processes, which end up providing information for decision making, managing, and coordination. High-level processes usually aggregate information about the general performance, possible improvements, or any sort of relevant information for management. We will see examples of subprocesses, role assignment, and different activity type handling when we cover process writing in Chapter 3, Using BPMN 2.0 to Model Business Scenarios.
The activity name is usually composed of the following:
A verb
A noun
Some examples of activity names are "Review Architectural Document", "Clean the Cutting Machine", "Analyze Client Risk", and so on.
It might seem a simple thing to put a name to an activity, but there are a few considerations to take beforehand. Remember that when you write a process, you are doing it from a particular perspective—whether it is a high level view of the whole company activity inside a process, or the flow of a very specific step performed by a company. Therefore, the activity name must make sense from that perspective. It wouldn't make much sense to name an activity "Rotate robotic arm elbow 45 degrees" in a high-level process, because its point of view should be much more abstract and wide.
Also, you should avoid any technical developer jargon in your activities' names. Remember that the process is thought to be a place for common language within a business or business unit, so the jargon used (if any) to write the process should be the jargon of that particular domain. It should be clearly understood by business users. In other words, try to avoid names such as the following:
Call
InternalWebService->getMyData()Execute batch command W-3302
REST call to
http://my.domain:8080/rest/esoteric-service
Also, try to avoid any terms that will make the process hard to read, like obfuscated IDs or out-of-scope terminology. Remember that depending on the process perspective, the people who will be interested in reading or updating such processes will be accustomed to different terminologies.
Business processes, at least when designed correctly, are not thought to be monolithic systems that cover everything, but coordination software between other systems (the business applications) and people (the business users). There are some differences in the way people and systems behave and also in the way they need to be coordinated.
Human activities represent the human interactions in our processes. In the BPMN 2.0 specification, they are called User tasks. Every time we have a person involved in our business processes, we will have a human activity in our processes to represent such interaction.
When we think of human interactions in our business process execution, we think of having a person or group of people involved in a set of activities that will produce a specific result; the human response time to complete such activities takes minutes, or hours, or days. So, the process engine must be prepared to handle such activities in a way it can wait for long periods of time for the result of the task by providing asynchronous management of those tasks in runtime configurations.
Systems, on the other hand, usually represent automatic responses. Compared to human activities, external system activities take very small amounts of time—usually ranging from milliseconds for the fastest cases to minutes for the slowest automated activities. Companies generally have a set of external systems exposed through well-defined interfaces that solve very specific problems. When we need one of these services' information, we can just call external systems (through service calls, event handling, or simple scripting) and get the results into the process.
However, it is worth mentioning that systems may not provide automatic responses, or may take a long time to respond. Because of this, and for many other reasons we will mention later on, we should try to consider as many tasks in our process as asynchronous tasks.
Systems can be classified based on their technical behavior as synchronous (the process engine will wait for the completion of a task, that is, a service invocation) or asynchronous (the system will continue its execution and wait for the external system to notify the process engine when the task is completed, that is, a thread-managed operation), while human interactions are intrinsically asynchronous. Also, systems can be classified, depending on their provider, as either internal or external third-party interactions.
Human interactions can be classified depending on the people involved in executing them. They can be performed by a specific role or group of roles within a company or domain, just one specific person, or maybe specified through a specific variable in the process. Examples of this classification would be the call center group of a company, customers, third-party users, and so on.
It's important to understand that these classifications are not important from the process engine perspective. All the engine will deal with is a name mapping of a particular group of activities to their implementation. The classification is useful mostly from the point of view of maintenance and documentation, which helps to know the ownership of each application/system in order to understand how the interaction will be made.
The most important part of the business process definition is achieving a goal. It's the sole reason for the process' existence; without it, the process has no purpose at all. This should never be forgotten.
The business goal of a process shouldn't be disruptive or impossible to accomplish in any way in the selected business process perspective. Each business process definition must define a clear goal and all the activities must be defined in order to contribute to achieving said goal.
Mixing goals and perspectives is a common mistake that you need to avoid when you model your first business processes. For example, when defining the process of building a car in an automated factory, we might use the same process to define the steps a robotic arm should follow to make a simple weld, overcomplicating the process. When this happens, it's recommended to split the business process definition into multiple well-scoped processes for the sake of understandability and maintainability.
One way of achieving this difficult task is to create a brief textual description of the process' main responsibility, its ownership, and the concrete goal that it was designed to achieve. This brief description can be used to train new people to understand why the process is useful to the company. You will also end up with a self-documented process that can be used by the company to improve quality levels.
Now that we have defined what a business process is, we can start understanding how to manage the way processes interact with our organization. To do so, we will define six different stages that involve business process discovery, modeling, formalizing, execution, monitoring, and improvement. They constitute an iterative lifecycle for our business processes and the way they relate to their context. The following figure shows all the relevant participants and the cyclic nature of BPM:
BPM cycle and its participants
The BPM discipline's scope and main goal is to improve the current business situation by planning iterations to solve well-defined problems, and it is not about coding Java or software development at all. You may be wondering how BPM achieves such a difficult task and also how it is related to jBPM6.
After the first three chapters of this book, the content will be really technical. However, it will be clearly shown how all these concepts solve real-life situations. We will see that the jBPM6 project structure, APIs, and designs are backed up by these concepts, and you will understand the importance of knowing them for future designs.
The following sections describe the stages proposed by the BPM disciplines. These stages highlight the most important points that need to be understood to start using BPM systems.
Discovery of new processes is started most of the time by business analysts. It involves a certain level of knowledge engineering; a branch of requirement gathering involved in correctly merging different knowledge representation strategies, such as business rules, process definitions, and so on, with the knowledge from domain experts.
This stage has added weight when you're implementing the first iteration of the BPM cycle, which is choosing a starting point to demonstrate the importance of BPM for the business. I recommend choosing a small process to start, with a noncritical objective from the business perspective, since the results of the first iteration will surely teach you a lot of ways to do it better in the next iteration. It is important to take time to evaluate the learned lessons at the end of each of the iterations.
You'll notice that business analysts alone are not enough to perform this stage. Most companies that reach a certain level of maturity on BPM end up having a Process Improvement department, which involves technical people and a project leader solely dedicated to discovering and improving company business processes. They also include or collaborate with business experts, sponsors, and BPM champions (highly ranked people in the company, by title or merit, who are dedicated to encouraging the use of BPM throughout the company). Making BPM an enterprise-wide discipline is extremely important to make it work successfully; therefore, communication and acceptance of all areas of the company involved in BPM becomes a priority.
After identifying a goal to build a process around, this stage consists of performing interviews with business experts, representatives of operation, and anyone who is involved (or that should be involved) in the process. To achieve effective interviews, you have to prepare a questionnaire for each person/role involved in the process. Always target your questions to each role in the company. It is also advisable to have a wide set of questions to ask each interviewee as well as more specific questions, in case complex activities arise.
Some questions that I've found useful for these interviews are as follows:
What is your role in process X?
Which screens do you use to complete the activity X?
Are you doing paper work? What kind of forms are you filling out?
Is the activity related to the review of information sent by another person or system?
Are you an expert of a specific topic? Are you the only one responsible for that activity? Are there more people trained for that specific activity?
How many activities are you doing inside a specific business process?
How many activities related to different business processes are you currently doing? (per day/week/month)
Do you need to move information from one place to another by moving paper forms to different departments or using the postal service?
Do you use e-mail/chat as a communication channel to send information to customers or to other business units?
Do you interact directly with customers/clients face to face?
Are you aware of the BPM practice and why the company wants to adopt it?
Are you handling duplicate or unnecessary information?
What are the well-known flaws of your activities?
How do you deal with exceptional situations, missing pieces of information, or new cases?
If they answer that they do paper work, you should get a scanned version of all the forms that have to be filled out. If they are using different systems/screens/applications, get those screenshots.
Always let interviewees know the goal of the process being analyzed and the purpose of improving the processes and how that would help them in their everyday work. This will increase collaboration on their side and reduce the stress associated with the fear of being scrutinized on work performance. You're not there to evaluate them, but to learn from them. Let them know that.
The information the interviews provide will help you understand what is being done to achieve the business goal, and it will result in a list of all the activities that the company executes related to that particular process.
Once you have all the different answers, you will be able to cross-reference them to determine the main path of the business process at hand. An example that could be the outcome of this first stage can be seen in the following figure:
The preceding figure shows a brief graphical description of the relevant steps in approving a loan, but still doesn't adhere to any specific format. This is something to be dealt with in a later stage.
During this stage, you might also find new terms related to the activities in the process. Try to disambiguate those terms as much as possible by creating and updating a business dictionary with all the related terminology of the particular process.
Finally, find hidden activities related to company-wide processes (the most usual case is related to batch processes whose result end up impacting process activities). You'll need some expertise in the domain, which is why you need to check with domain experts to point out vocabulary inconsistencies, missing activities, and ambiguous terms, as well as to identify irrelevant business activities, duplicated activities, and so on.
When the business process, its owner, and the business goal have been identified, we can start working in a formal, unambiguous representation of the business process.
Formalizing processes is done using a predefined language. The purpose of the language is to be able to share the model with other people in a way that can only be understood in one way, as long as other people understand said language. There are many languages that have been designed over the last 20 years for this purpose; most of them are based on different graphical representations to help people quickly understand the activities needed to achieve the business goal.
When picking a language, you should always consider the ones that define the most widely accepted standard to make sure that most people can understand it. In 2014, the most widely accepted standard happens to be BPMN 2.0. We will learn the graphical representation and execution semantics of BPMN 2.0 in depth in Chapter 3, Using BPMN 2.0 to Model Business Scenarios. For the time being, let's just say that it provides a widely accepted formal language to represent processes that is not just implemented by jBPM6, but by many other process engines. So, even if you decide to use another engine, writing your processes in BPMN 2.0 would still be a good idea.
In this stage, business analysts trained in BPMN 2.0 will model the business processes. They should choose the level of accuracy of the process representation, depending on the time and information available for this stage. Since BPM is an iterative discipline, they can improve on that accuracy in later iterations.
This stage is also a very good point to start testing our processes through simulations. By determining the resources assigned to our process activities (people, time, and money), we can predict in a statistical way which activities would consume the most of each resource and plan ahead on assigning appropriate resources based on those simulations.
The resulting artifacts from this stage will be the formalized process with a graphical representation that can be shared and understood by different roles in the company.
In the third stage, the Development team works with the Business Analyst team to add all the technical details that will allow the process to run.
By now, we have a very important asset already implemented, that is, the business process' formal representation. This will act as common ground for exchange of ideas, improvement, formalized contract between areas, and also as documentation of what is being done. For that reason, it is important to keep it safe, versioned, and centralized. For this purpose, we usually set up a knowledge repository to store them.
Also, at this stage, the process definition needs to be enriched with all the information that its activities will handle and manipulate to achieve the business goal. There are different options to achieve this, and we'll discuss them in detail in the following sections.
We will select a model to work with, and our executable entity model will be created based on discovery stage results.
We usually have an inherited business model from legacy systems. When that's the case, you have three options:
The first option is using the inherited model for your process activities. Its pros and cons are as follows:
Pros: It is fast to implement, especially if the developers of your organization already know the model.
Cons: Inherited models could carry an unnecessary complexity for the process' required level of data. Also, any change needed to be done to the process' internal model might impact a third-party project.
The second option is storing external keys for the real entities inside your business process. The data will remain consistent and updated as long as it can be managed by a master data source from the process' engine point of view. Its pros and cons are follows:
Pros: You can reuse your old model and even its persistence, and only store a key to get the related information when needed.
Cons: If you store a key, you will need to query another data source every time the information is needed, and depending on the case, you might need to modify external information (with all the problems regarding permissions, communication, transactions, and so on). Depending on the amount of concurrent process executions, this could cause a performance issue.
The third option is creating an understandable wrapper model that abstracts the legacy model, data sources, and communication strategies required by your business processes' model objects. Its pros and cons are follows:
Pros: You can map any outdated terms or concepts to a business process' relevant names and structures, and define underlying strategies to fetch information from external systems or to produce the needed data.
Cons: Writing and maintaining the integrity of the wrapper model will take time, and an expert on both models will have to worry about keeping everything in sync.
Once you define and know how to get and update information from your business model, you will need to bind each bit of information with the correspondent activity in your process. We usually do this with an expression language that allows us to express, in a declarative way, the information that we need without saying where it can be obtained. One example of this could be #{ambulance.doctor.speciality}.
This expression will be evaluated at runtime, and an internal mechanism will be used to retrieve the information.
The business process provides us with a set of activities that need inputs and produce outputs. As technical developers, we will have to provide technological assets to provide such functionality, from creating form renderers for human interactions to creating connectors to external web services and transformations for external models to our entity model. In Chapter 7, Defining Your Environment with the Runtime Manager, we will analyze all the technical requirements to implement user interfaces, and in Chapter 10, Integrating KIE Workbench with External Systems, we will review all the relevant details about system-to-system interactions and the mechanisms that we need to know in order to keep everything simple.
Having a clear vision of the components that we need to implement and having a standardized and conceptually coherent way of interaction will make our life easier, and we will end up with simple applications that are easy to maintain.
By the time we finish this stage, our business processes will be executable. This will allow us to test, verify, validate, and simulate the process behavior. For the next iterations, this stage becomes unnecessary, and the only thing that changes between one implementation and another are the external systems' connectors as well as the technologies used to build frontends. All these topics will be covered in the jBPM6 technical sections where the technical details that need to be considered and best practices will be introduced. Also, in this stage, we can start showing the progress of our process definition in playbacks, so all parties involved in the process discovery and formalizing can see that the goals of the business processes are achieved.
At runtime, we will put our business process and assets in a production environment. For the first iterations, it will probably be a production-like environment (that is, a full development environment).
This is the point where we start training users to understand how to interact with the activities of the business processes. For doing so, it's a best practice to use a unified approach to build User Interfaces (UIs), because it simplifies training (the user will not need to adapt to different components). We will see about unified user interfaces in Chapter 6, Human Interactions.
During the first iteration of this stage, the runtime should be restricted to a few simple processes and to a small well known group of users. When we have already tested the processes doing the real work in this situation, we will be ready to handle bigger processes, bigger groups of people, and more critical tasks and business goals.
This stage is when we actually start detecting how our processes behave in the real world. We can measure how the model allows users to have information; if they need extra information, we can see which tasks can have an improved performance and many other things that start providing us with invaluable information for the next iteration. Always take notes of that information, as it will be very important for future process-related improvement.
The first step is the most difficult. After we learn to take them, pretty soon walking becomes a simple thing. The same thing happens when sending our processes to a production environment. The experience you gain from doing so is very useful, and following this book, I hope you can do it with the least amount of problems possible.
Once we have finished the major steps of stage 4 and we have a stable enough runtime, we need to start concerning ourselves with the information that runtime gives us. Process execution can send many events to components that are external to the actual runtime. Those components can be fed to a dashboard-like tool to allow us to monitor process execution and actual performance metrics. This is a stage where the process simulation from stage 2 can be validated, and notes of the actual estimations should be taken for improvement of process simulations in the next iteration.
These dashboards are really important for key people who want to see snapshots of how the company is working in order to make the right decisions. As you can imagine, knowing the number of processes and activities that are completed per hour can be really helpful for planning, accepting new commitments of work from providers and customers, as well as measuring the company's growth rate. This is just one example of the things that you can do if you have the information available.
Monitoring is about real-time information analysis and display, but it should also be about flexibility. You might need to add new sources and types of metrics as fast as possible to measure them within the runtime. A related branch of studies called Business Activity Monitoring (BAM) defines best practices for doing so. Tools for BAM must be flexible enough to show information in such a dynamic manner. For example, a manager might want to see aggregated data from different sources when he asks for something like this:
"The average time of completion of one or a group of processes related to client X accounts in the last month."
We usually display this information in different widgets that are specially designed to show very simple values. These widgets provide an overview about what is happening in the company in just one screen where we can see multiple bar graphs, line graphs, and tables that let us quickly see what percentage of processes are in different stages throughout our process runtime environment.
The important thing about the monitoring stage is the externalization of information. These metrics can provide you with different perspectives to know which are the best places for improvement in your business processes and in your company altogether.
Now, we will bring together all the things that we learn from the other stages and plan accordingly to better our business processes in our next iteration. By the time we reach this stage, we have our process runtime (and business relevant metrics) running to provide us with relevant information about the processes' execution. We might also have learned about exceptional situations in our processes that weren't considered at first and their ad hoc solutions. We now know how to simulate our processes better. We might also have new questions for our business experts from what we learned.
In this stage, we take care of business changes that need to be reflected in our business processes. All their improvements, along with the planning generated from the learned lessons, is used as an input for the next iterations—starting again from stage 1 and completing the BPM cycle.
Once we understand the basic elements of the BPM discipline, we need to apply it to a real-world scenario in order to learn from involvement and acquire experience. To do so, the best way to go is to use Business Process Management System (BPMS) as an aid in most of the BPM discipline stages.
A BPMS helps in the BPM discipline in the same way an Enterprise Service Bus (ESB) helps in defining a service-oriented architecture (SOA). It provides a centralized environment to define, implement, and run business processes.
BPMS is a middleware component (a piece of software that allows us to create more software). It provides us with the tools to directly work on the specifics of our case, taking advantage of the already available functionality that is oriented to solve very specific tasks for each stage of the discipline. In the next section, we will see a list of things to take into account when we are evaluating a BPM system.
A BPM system must have a lot of different features to be a good asset for its users. For each individual stage of the cycle, you should find different tools or projects that you will need to evaluate before deciding to adopt them.
For the Discovery stage, a BPMS should provide you with a way to gather business knowledge. The tools that are most useful for this stage are questionnaire builders, interview recording software, and other means to store and analyze information from interviewees and other sources to understand how things work in the company. Most of the open source projects provide a modeling tool without giving us the appropriate information gathering and analysis tools. This usually confuses new adopters, because they start working without figuring out first what they need to model and solve. You should be aware of this and be prepared to spend some time asking questions and analyzing the results.
The Formalization stage needs tools to model your business processes. The best ones nowadays should all support the BPMN 2.0 language to write these processes. Most of these tools are targeted to business analysts whose only technical requirement is understanding of the BPMN 2.0 language, so be prepared to provide training for the people involved in writing the processes. During the first iterations, the first processes are usually defined by people who already know how to write the processes and the implications of modeling an executable business process, and they can even use that writing time to transmit their knowledge.
Another thing to notice about the quality of a process editor is how it integrates with external configurations and modeling information, such as entity models and specific business-centric activity descriptions. Make sure that you're able to do those things when you evaluate a process editor.
The Implementation and Runtime stages are the ones where the most tools are usually found. They constitute the main component of a BPMS, that is, they provide an execution environment for your processes. From the software point of view, these two stages are well covered by the existing open source projects in the market. It's important to understand that a BPMS should allow the technical people of the company to directly interact with the process engine so that they can customize and extend the provided generic behavior. During these stages, we will see a strong relation of BPM with SOA-based applications. BPM can become a very important component in relation to web services, as a coordinator, and as a consumer; it can even be exposed itself as a web service. In Chapter 10, Integrating KIE Workbench with External Systems, we will see how to expose existing tooling through web services.
In the Monitoring and Improvement stages, you should concentrate on three things; the API provided to extract information about process executions from the runtime, how simple it is to create a new indicator, and the dashboard's visual flexibility.
Most problems arise in the most decision-intensive stages, that is, stages 1, 5, and 6. There is no current standard methodology to discover business processes. Since they are nontechnical tasks, the maturity of the software related to these stages is usually not great. Even if you have automated questionnaire forms, dashboards, and improvement planning software, you still need to analyze the data by people and make decisions. Also, to make those decisions, you need to learn about the company to do those tasks correctly.
From a developer's perspective, most BPMS provides a set of API's to easily plug and integrate your applications with the process engine (irrespective of the technology or language that you use in your company's applications). BPMS also provide a clear description about the information they store by default, and how to extend and customize that information for specific domain analysis. This mechanism is usually designed to be generic and extensible.
The main differences that you can usually find between process engines are as follows:
How flexible the core is in adopting new custom services
How well documented the engine is
How often releases are updated
What standards the project implements
How well it integrates with other technologies and frameworks
How much support it receives, either paid or from the open source community
These items are a good starting point to evaluate and compare different Process Engines' features. After that is done, the next step is to analyze the available tools for each stage.
Tooling usually is heavily evaluated during the first phase of comparison between different projects, especially in case of integration projects. For real-life full implementations, it is always preferable to adapt the tools for a particular usage—after modest to extensive modifications are made to them. Usually, the desired output is to integrate it with existing applications and within company proprietary frameworks.
From the process engine internal functionality perspective, it's easy to build tools and integrate them into your existing applications using the APIs provided. From the BPMS perspective, you should always check that the internal functionality from the process engine is easily exposed through a set of APIs, because the majority of closed source products don't expose the internal APIs to provide extension points, and this can make integration quite difficult to manage. BPM plays an important role in integration with other enterprise applications and providing service coordination. The more importance BPM gains for a company, the more it will be related to controlling different activities performed by many different applications in a company. The easier the said integration can be done, the better and less painful BPM adoption becomes.
To integrate tools, if it is in the interest of your company during evaluation time, you should check the following features:
The amount of tooling available
The number of features
The flexibility of the results generated by the tooling
The technology that the project uses to build the tooling
The skills that you have over those frontend technologies
The difficulty of extending or porting the tooling
Remember, you must be ready to change all project generic UIs/tools provided by the BPMS. You must know how they were built. A good measure of the tooling development quality is how easy it is to start extending the tooling projects.
Last, but no less important, is the evaluation of how well the features of the selected BPMS relate to established standards. There are two standards you should check for current applications, the Web Service Human Task (WS-HT) standard and the BPMN 2.0 standard. The WS-HT standard defines two main features:
A standard set of APIs (interfaces) to interact and manage human activities.
A complete and flexible human activities life cycle. This life cycle defines the states through which a human interaction will transit during its life.
Also, the BPMN 2.0 standard defines a set of XML tags to describe business processes, their interactions with external systems, and their structures.
The biggest advantage of having a set of standard API's is that the better the different implementations adhere to those standards, the easier it is to decouple the definitions of processes from the engine's internal functionality—this allows for the possibility of migrating to another technology if you ever wish to. We will learn more about BPMN 2.0 and human interactions in Chapter 3, Using BPMN 2.0 to Model Business Scenarios, and Chapter 6, Human Interactions, respectively.
Now that we've covered all these conceptual topics, we are finally at a point where we can start applying them to real-life projects. All the presented concepts in this chapter will be quite necessary over the next chapters to help you understand how and why the tools are designed the way they are.
In the following chapters, we will analyze how to implement and use tools that are related to the BPM realm. We will learn about leveraging rule engines, complex event processing, and other tools with the process engine to be able to solve real world problems.
We'll start by explaining how BPM systems are structured to provide an automated way of handling the BPM discipline stages, and how those tools are used to develop applications to help your company do its job.
