Business processes integrate systems, partners, and people to achieve key strategic and operations objectives. Examples of business processes include getting and filling orders, processing invoices, reconciling shipping notices and received goods and processing insurance claims and loan applications. The Holy Grail of enterprise computing is adaptive business processes that can be defined, refined, and optimized to respond to changing business environments, government regulations and competitive pressures. This vision has followed us through the evolution of mainframes, Management Information Systems (MIS), packaged applications, J2EE-based application platforms, business process management systems (BPMS) and now, Service Oriented Architectures (SOA). We are getting there!
Many solutions exist for designing and deploying business processes. Some are derived from proprietary BPMSs or workflow engines; others have been built as process execution engines for Web Services and SOA, and are usually based on the Business Process Execution Language (BPEL) for Web Services. All of these solutions have a common goal: to support the business process lifecycle from modeling and design to implementation and monitoring, and then back to design. Full lifecycle support enables continuous process improvement. Being able to iterate continually through the process lifecycle is called closed loop. Systems that support this are called closed-loop business process management or closed-loop BPM solutions.
Large enterprise software vendors offer closed-loop BPM solutions, while niche vendors offer point solutions that tackle part of the cycle, such as modeling. But can you put together best-of-breed tools from multiple software vendors without spending a lot of time integrating them? In other words, are there any interoperable standards-based tools that support the business process lifecycle? The good news is that with standards such as BPEL and Business Process Modeling Notation (BPMN) you can implement standards-based, closed-loop BPM.
BPEL - a standard, portable language for orchestrating services into end-to-end business processes - builds on a decade of progress in business process management, workflow, and integration technologies. It's built from the ground up around XML and Web Services and is supported on both the Microsoft .NET and Java platforms. BPMN, as an amalgamation of best practices in the business process modeling community, provides a simple, standard means of communicating process information to key stakeholders.
The business process lifecycle consists of the following steps:
This cycle is shown in Figure 1
.
There are many ways to implement business processes (including using packaged applications that, for the sake of brevity, we won't discuss here). Figure 2 shows the spectrum of possible approaches for process design and deployment as well as the level of automation and flexibility offered by each approach. The obvious Procedural Code-based Solution (far left) uses SOA and Web Services but uses a development tool to write procedural code. The ideal 100% Standards-based Solution (far right) is a flexible, adaptable solution. Other approaches fall in between.
How do you model, implement, and deploy business processes using a procedural approach? The choices are reasonably clear. The business analyst models the system using a modeling tool (for example, in UML), and the programmer incorporates existing services and develops new ones with J2EE. Although the analyst creates a high-level process model, it doesn't map directly to an executable process model, so the programmer has to implement the processes based on his understanding of the process model. Processes built in this way are hard to develop and error-prone because of the disconnect between the high level model and the completed process.
Further, systems built this way are difficult to change because you have to rewrite code. It's also hard to get performance metrics at the business level, such as the length of time it takes to ship an order - but these metrics are important to business managers. Without them, they are left "blind" to the real state of the business. Besides, changing business policies isn't easy since policies are hard-coded in application logic, making automated change impossible.
So what does the ideal solution for modeling, implementing, and executing a business process look like? The ideal solution models business processes using BPMN and implements and executes them using BPEL. A business analyst can use a business-process modeling tool (such as Popkin's System Architect) and then export the process model as BPEL. This can then be imported into a BPEL-compliant SOA/process development tool (such as BPEL Designer in Oracle JDeveloper 10g) to define and implement the process further.
BPMN, developed by the Business Process Modeling Initiative (BPMI.org), provides a notation that all business users can easily use and understand. These users include business analysts who model business processes, technical developers who build systems that implement those processes, and managers who must understand and review process diagrams.
Some key BPMN features include:
BPMN objects have a rich set of attributes that enables easy mapping to BPEL. The skeletal BPEL process output from the modeling tool generally consists of process scopes, invoke/receive activities, and partner links to the appropriate services. Further work is required by the programmer, including binding to heterogeneous systems, supporting synchronous and asynchronous message exchange patterns, transforming data and schema, coordinating activity flow, managing exceptions, handling non-deterministic events, defining compensating transactions, and managing version control.
BPEL provides a rich yet simple abstraction for addressing these requirements by adding implementation details on top of the BPMN model.
Here are the steps for turning a high-level BPMN process model into an automated process that can then be deployed:
Proprietary BPM, workflow, and process integration products can import BPEL. But, a native BPEL execution engine has many advantages over non-native implementations. For example, it won't lose information during the import/export process, and you can switch between model and BPEL code in real-time during development. BPMN and BPEL tools simplify communication between business analysts and developers, enabling them to collaborate more effectively. These tools do this by providing a seamless visual modeling experience from process design through implementation.
Once business processes have been deployed, it's critical to monitor their performance by measuring key process metrics and having real-time visibility into process execution. Monitoring can be done at the operational or business level. Standards are still evolving in the monitoring and optimization domain; however, interoperable platform-based solutions are available. Figure 3 shows the various alternatives for process monitoring and optimization and the level of automation offered by each one.
Operational monitoring generally involves getting details such as process status, messages exchanged, performance, and audit trails. This is typically done via process monitoring metrics presented through a console. Many BPEL engines, process orchestration engines, BPMSs, and workflow engines that support BPEL provide a console for drilling down into the execution of business processes.
Available metrics could include how long it takes to ship an order, how long it takes to get goods from suppliers and pay for them, or how long it takes to provision a DSL line.For example, Oracle BPEL Process Manager includes a sensor framework that can publish process transitions and events to a queue (e.g., JMS) and database tables, which can then be received by a BAM tool. BAM gives you visibility into key business indicators along with user alerts and dashboards to respond in real-time to events or exceptions.
BAM tools can:
Consider the following example of a loan flow process deployed at a typical loan broker. The broker accepts a request from a client, does a credit check with an external service, and routes the application to two loan agencies. After getting two offers, the better offer is selected and the customer is notified. In this section, we'll show how you can automate this business process with available solutions based on SOA and Web Service principles using BPMN and BPEL.
In the modeling phase, the business analyst specifies the participants (LoanBroker, CreditRatingService, StarLoanService, UnitedLoanService, and the customer). The loan flow process orchestrates interactions between these services into end-to-end flows. To enable this, the analyst specifies the sequence of events and message flows between these entities using BPMN within the modeling tool, such as Popkin's System Architect. Figure 4 illustrates the high-level BPMN process model and a drill-down into a subset of this process, where a request for a loan offer is routed to the two loan agencies.
To further analyze this process, you could model the loan application inflow rate and processing time for each loan agency and then run simulations to come up with the throughput or response time for the end-to-end flow. If we also assume that a certain number of loan agents at the two agencies are needed to complete the task, and we assume an average time to process a loan, we can use simulations to help determine resource usage and the number of resources required based on the expected load. Some modeling tools let you run simulations based on the process model. For example, if you're using Popkin's System Architect to model business processes, you can use Popkin's SA Simulator II to run the simulations (i.e., run through the hypothetical scenarios).
After modeling the process in BPMN, you export to BPEL. You can then complete the BPEL skeleton generated from the BPMN modeling tool to include URLs for the services, and XSDs for the loan application and loan offer, and data transformations for the documents exchanged between the services.
Oracle BPEL Designer provides a graphical way to build the loan-flow BPEL process. Because it uses BPEL as its native format, processes built with Oracle BPEL Designer are 100% portable. It's also available as a plug-in for Oracle's JDeveloper IDE, or the Open Source Eclipse IDE, so developers can easily program the code for implementing new services and user interfaces in the same tool as they implement the BPEL processes. Figure 5 shows the Loan Flow process modeled in Oracle BPEL Designer.
Once the process is deployed, the BPEL engine can provide metrics on the performance of each instance of a process. For example, Oracle BPEL Process Manager includes a BPEL Console that you can use for an aggregate view, or drill down into a particular instance of a business process's execution. However, you can also roll process metrics into a BAM solution. The BAM dashboard can be used to provide critical business data such as the number of loan requests approved during a certain timeframe, loan offers by provider, or the average processing time per loan. For example, Oracle BAM lets you instrument BPEL processes with sensors to monitor critical activities and variables. The BAM dashboard can also provide alerts - such as the approval of multiple customers with low credit scores or a loan rejection rate greater than 10% - that may indicate potential problems, and that let you take proactive steps. Figure 6 shows the BAM dashboard with key metrics for the loan flow process.
The optimization phase for the loan flow would involve using actual processing times based on weekly or monthly reports and then running the simulation tool again to generate possible bottlenecks and predict SLAs. This may result in a redesign of the process, such as adding new loan services to meet response-time requirements. Some of these metrics can also be used in real-time. For instance, if one loan agency takes too long to respond, the BPEL process flow can time-out and continue processing with only one loan offer to meet SLA requirements.
Any optimizations to the business process can be fed back to into the modeling tool, where changes can be made to the process using BPMN. Then the new process is exported to BPEL, which is picked up by the developer, who changes the implementation with BPEL and deploys it. Note that many process orchestration engines can run multiple definitions of the same business process concurrently. This is useful because when you change a business process, you may want existing instances to run through to completion on the old definition.
Closed-loop BPM systems are critical for developing efficient and effective business processes that can quickly respond to changing business conditions. A closed-loop BPM solution based on open standards lets organizations rapidly iterate over the complete process lifecycle using standards-based tools. One way to do this today is to use Popkin's tools to model and simulate processes with BPMN, export the definition to BPEL, implement the processes in Oracle BPEL Designer, and deploy them to Oracle BPEL Process Manager.
SIDEBAR
Let's talk briefly about process simulation. Project teams often simulate the modeled process-running hypothetical scenarios or historical information through the model-so they can gauge overall performance and identify possible bottlenecks. Before a team begins this process, which occurs between the BPMN model creation and BPEL implementation, it must assess the amount of time required to execute each activity, the resources required for each task, and the probability that various events or conditions will occur in the flow. Simulations typically:
