BPM For The Masses

Mariano Benitez12/13/2006

Abstract

A business process is a formal representation of the work done by people and systems of an organization and its partners, and is aimed at providing a product or service to internal or external customers. Business Process Management (BPM) is the art of formalizing and automating business processes. AquaLogic BPM Suite (ALBPM) is a Business Process Management system that allows the complete management of end-to-end business processes.
This article gives you an introduction to the functionality of the product, along with some very important things you need to consider when moving to BPM. It does not provide a complete description of the concepts of BPM, but it will give you the vision of BPM that the AquaLogic product proposes for it.
The article is aimed at anyone who wants to get an initial view of the product and the technology; it presents important information for solutions architects and for those responsible for designing software systems that are to be moved to BPM-based solutions. Developers and executives can benefit from the topics covered here as well.
Something to Do (Before You Start)
Before starting, I want you to ask yourself these questions:
What is BPM?
How do you think business processes get implemented in the real world?
Do you see the processes in your organization reflected clearly in your applications?
Can you easily follow the processes inside your organization?
Would using a BPM tool change the way people work in your organization?
When you’re done reading the article, ask yourself these questions again. Then look at the answers, and see if you may have a better way to tackle these issues. My intention is not to answer these questions directly, but to let you elaborate on them, drawing your own conclusions.
Policy of Truth (Let’s See Some Definitions)
A business process is a formal representation of the work done by people and systems of an organization and its partners, with the aim to provide a product or service to internal or external customers. In its simplest form, a process is a set of activities, representing different steps of the process, linked together through transitions. Activities can require human intervention or they can be totally automatic. For human interactive activities, you define a role in the process that identifies who is allowed to interact with the process at this point. The process acts as a definition, where instances of the process are the actual items moving through it, transitioning from activity to activity. Instances always start at the Begin activity of the process and finish in the End activity. The path the instances take depends entirely on the data of the instance and the external environment.
A transition is a directed link between activities, and many transitions may come in or out of an activity. Once an instance has completed an activity, the outgoing transitions are evaluated, and one is selected that will move the instance to the next activity. Conditional transitions contain a boolean expression that is evaluated and must be true to allow the instance to follow that transition. Some transitions are time-based, which means that they will trigger an automatic routing to the destination activity if the instance is still there at the due time. Processes can have state, too: You can define attributes to a process that will take a value for each instance, helping you keep the state of the instance, to transition to different activities (for example, if quote amount > X, then go to this activity).
This is what BPM is from a pure modeling perspective. This definition is not enough, however, to execute the process; you still need to talk to the other systems, reflecting the process into the infrastructure. Here is where integration comes into play. For each activity in the process, you can define tasks, which basically consist of code being executed when an instance reaches the activity. Tasks can be implemented in a variety of ways. When an instance reaches an automatic activity, the task defined for the activity will be executed, and, depending on the result of that execution, the instance can move to the next activity.
For human interactive activities, the execution of the task is triggered by the end user, from the client workspace. The AquaLogic product has built-in integration capabilities that can be used in the tasks code. (This feature is an important one in the product, which I will cover extensively in further articles.) Tasks update the process state, accessing and changing external systems, interacting with end users, and more. Tasks are what turn a simple process model into a process-driven application.
Business Process Management is the art of formalizing and automating business processes. To successfully evolve into a process-oriented organization, you need tools to design, execute, and monitor business processes. This is what Business Process Management Systems are built for. This is what AquaLogic BPM was designed for.
A Question of Time (Before You Move to BPM)
As organizations try to get more agile, they need to adapt the software they run their businesses with. From a conceptual point of view, the thing that changes most often is not the back-end applications, or the Web service definition to access a customer, or the location of the EJBs, or the version of ERP they are based on. The single most important thing that changes when businesses need to adapt is the process itself: Businesses must add a faster path to automatically approve orders based on some criteria, to modify a reference value that raises or lowers the approval rate. They need process approval and check activities in parallel, they need to change the role that performs an activity, they need to handle exceptions manually, and they need to enforce new business rules. Handling these kinds of changes is at the core of BPM, allowing modifications to be made in the business process without altering any of the underlying components.
In this next section I bring up some things that I consider very important to understanding the true value of BPM.
Behind the Wheel (the Process is in Control)
By embracing BPM, you are now externalizing one important piece of your business. The problem is that if your process model is not executable (it is a pure model), eventually you will have to map it to an application, transforming it, just like you did when moving from "analysis" to "design" to "implementation." This makes it really hard to map the business process to what really is being run in production. With AquaLogic BPM Suite, you build a complete process-driven application, attaching tasks to activities, which are the real operations that take place inside the process. A task is the code of the process and can be either user-driven or system-driven. The execution of tasks is the main driver of state changes in the process. So, the process really drives the application, directly enforcing the flow, tasks, and operations allowed on the process.
Writing process-driven applications does not change the way you write code or implement services; you will still write Java classes, Web services, and JSPs in the same way. The main difference is that the application is process driven. This means that all the code is triggered from activity tasks, so you just need to focus on the code for these tasks; the rest is handled for you. The basic process operations are provided out of the box, in the user workspace.
Walking in My Shoes (or in Your End User's Shoes)
The main shift for your end users (the users of the solutions you build) is that they have a single list of things to do. Users have an inbox where they see the pending instances and the tasks available to execute for each instance.
Before, they had to look on different pages, systems, and applications for actions to perform. Luckily, they received a notification that they had some new work to do, but it was very unlikely they would find it in a single view. BPM makes job assignment very intuitive for users.
The most important change for end users is that they are presented with a more task-oriented view of the work. They easily understand that they have a pending order waiting to be approved by executing the tasks enabled for that activity. By clearly defining the processes, you are creating a unit of work that is clear for all participating entities (other systems, other people).
With processes and instances, you need a user front-end for managing the instances (CRUD-like basic operations). For BPM, these operations would be create, search, execute, abort, delegate, and route. AquaLogic BPM Suite provides all these features out of the box, either from the HiPer Workspace (in any flavor) or directly, using APIs (Java- or Web service-based). You don’t need to build this functionality; it’s already there.
BPM is part of the big SOA movement and plays a very important role in this movement. Let me explain how.
World in My Eyes (the SOA World in the Eyes of BPM)
A number of well known people have defined how BPM and SOA relate to each other.
Bruce Silver’s BPMS Watch has a nice article on BEA’s take on BPM-SOA.
Alfred Chuang’s article on the Exec2Exec newsletter also provides a good description.
My view of SOA is that it is about building services that are encapsulated, reusable, and decoupled. SOA has two main "aspects"?: building decoupled services, and binding them together in a simple way. In a SOA enterprise, all services are ultimately linked together from top to bottom at different levels (otherwise they would not be used). Some bindings are pretty static, and others are very dynamic. BPM tries to provide a tool to model the level that changes the most—the business level. Processes use the SOA services as building blocks that will reflect your business process in the underlying systems. These core services are reused throughout all the processes, providing the real value of reuse. The processes bind the business, data, and presentation services into the value generator: the real business process.
Without a process layer, eventually you will wire the invocation of these services in the presentation layer or in the business layer, and some changes in the business logic will definitively imply finding what services to modify, and rewiring services to adjust to the new business definition. Let me elaborate with an example: You have a Web-application, with a two-tier architecture, with business components and presentation. Some presentation component contains the sequencing logic of the application. The business user decides to make a change in the business process, changing the order of some operations and the usage of a business component. How do you map the business requirement to the exact code you need to change? How do you know where to modify? Why do you need to know the implementation to change the process?
With the process layer, you have a clear space to make use of the available services, acting as the glue for those services, making them useful inside the scope of a business process. So, when your business changes, just one place changes: the process, not the services.
When talking about reuse in the context of BPM, multiple levels are open to consideration:
Low-level reuse of external systems, where many business processes will access the same Web service.
Medium-level reuse of BPM, where you can share process and component templates, reusing the best practices of the code and process models.
High-level reuse of processes, where you expose a process that can be used by other parts of the organization.
Now that I’ve painted a picture of what BPM is and how it fits in the new world, I'll go deeper into the product I want you to meet.
Something to Do (with AquaLogic BPM Suite)
AquaLogic BPM Suite is a product that embraces the whole lifecycle of business processes. It provides tools for all solution times: development time, runtime, and evolution time. For each stage, a number of tasks must be performed to complete the lifecycle, I will get into the tasks next, when I describe what can you do with ALBPM.
Enjoy the Silence (and What BPM Can Do for You)
AquaLogic BPM allows you to design, simulate, develop, execute, monitor, operate, and change business processes. I will explain what each of these things mean.
Development time
This is where you transform your ideas into an application, something executable that includes all things necessary to make it alive: presentation, processes, integration, everything all bundled in a BPM project source.
· Business Process Design—ALBPM Designer allows you to build in a graphical way the real business process, defining process roles, activities, and the flow between the activities. You can also document the operations that need to be performed on other systems. Here you are defining the way your business will work, establishing dependencies, SLAs, exception handling, and more. The result of the design is your business process model. This model will remain as the core of all other steps in the process lifecycle, even at runtime. This model can be visible to end users.
· Business Process Simulation—ALBPM Designer can simulate the execution of the business process. For each activity in the process, you can define resources, costs, times, and the distribution of the different transitions. The simulation will then use that information and generate information about times, bottlenecks, total costs, and so on. This allows you to understand where the process issues will be.
· Business Process Development—With ALBPM Studio you build a complete process-driven application. You define tasks for each activity in the process and what is executed on each task. Task implementations contain business process logic, integration code, and a presentation. The result of this is an executable application. This is where you declare and use the integration points to external system or resources that the process requires. You are defining here the application that will support your business process, the process UI, and the interaction with the external systems. Of course, you can use any component of your SOA infrastructure, including other BEA products. ALBPM has extensive integration capabilities that allow you to use any external software that has an interface to interact with. The result of the development is your business process-driven application. For simplicity sake, for the rest of the article I will refer to this as The Process.
Runtime
Once you have your application source, you can transform them into a living entity, exposing the BPM project to end users, creating instances, connecting with the other systems involved, and so on.
· Business Process Execution—ALBPM Enterprise is the runtime environment for business processes. It provides the process engine that runs the processes and a number of client applications that are the end user front end. This product is all you need to build a BPM environment, with running processes and users connecting to them. Infrastructure management applications are also provided. This is our core product—the "heart" of a BPM solution. The architecture of the product ensures that all enterprise-level features are provided, like scalability, performance, and availability. The product is built to support large-scale installations, with many users, processes, and more.
· Business Process Operation—The process engine keeps a record of the events that occur with each instance of the processes. It stores time, user, and results of any operation performed by users or systems. This information can be reviewed later to audit the steps that the instance has been through. This capability manifests cause/effect relations that, in many cases, were untraceable. You can also search for instances using flexible criteria to see the state of an instance at any moment, or you can override the default flow and grab an instance that is in a wrong state and send it to the proper place. Basic process-oriented operations are provided out of the box, like instance creation, cancellation, routing, delegation, and assignation. All these operations are enabled based on the permissions assigned to the users, and on the process definition.
· Business Process Monitoring—Based on the information available on the process engine, you can easily build dashboards that give you information that is relevant to the business process owner, in the owner's terms—like how much time the entire process takes, or how much money is pending to be collected because of delayed processing. For each process, you can define what measures are relevant to the business and what dimensions need to be defined to ensure proper drill down. All this information is used to build the dashboards that are later exposed at runtime, and provide information about the current state of the process.
Business process evolution
Inevitably, once your business process is alive, you will need to change it. The reason for change can be a result of changes in the market, or new business definitions, or you may have detected inefficiencies in the existing process. You go back to design and development, and implement the change in the process. ALBPM Enterprise handles multiple versions of processes, or replaces an existing process with another version. Different versions of the processes are kept isolated and don’t interfere with each other.
Business process management
Based on what I’ve described, you can manage the whole lifecycle of a business process, from inception to runtime. The ALBPM Product Suite was designed with this in mind. Its basic concepts have been there for more than 10 years and represents a pure BPM product.
Figure 1 provides an overview of the main components found in AquaLogic BPM Suite.

Figure 1. BEA AquaLogic BPM Suite components
Everything Counts (Even the Last Words)
If you are looking for tools to help you embrace a process-oriented way of building software for your organization, then ALBPM is the perfect way to let the tools drive you through the process lifecycle. ALBPM was designed from the ground up, with processes and integration being absolutely critical to a successful application. I want to emphasize two things that are fundamental to a complete understanding of BPM:
ALBPM transforms the way you think about solutions.
ALBPM transforms the way your end users work.
This article describes what BEA envisions as a fundamental piece in the software map of the future, about the way applications, development environments, and, most important, businesses will be driven in the future.
In further articles I will discuss the architecture of a BPM solution, including the product architecture, process modeling, and many other interesting topics. Stay tuned.