BPM applications in the real world

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.

The BPMS check list

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.

BPM APIs and common practices

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.

BPM – adoption of standards

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.