2.1. Designing a SolutionTo design a good BPM solution, you must first step back and examine the project's environment: understanding the problem, noting the local and larger-scale perspectives, and only then creating a design and testing your solution. 2.1.1. Understanding the ProblemTo understand what a good solution looks like, you must first understand the scope of the problem to solve. The main requirement of a BPM application is the ability to design, run, and monitor and administer business processes that incorporate human and system interactions, described as follows:
The model architecture must also smoothly accommodate both human and computer interaction:
2.1.2. The Local Perspective Guided by the Global ContractThe job of a BPM architecture is to describe the local perspective of one company, not the global view of all partner interactions. True, the designers must be aware of the nature of partner interactions but only to ensure that the company is compliant with interprocess protocols. As Figure 2-1 illustrates, a company that is a Seller must know the rules of interaction with Buyer, Inventory, and Credit card company partners, but its main concern is the construction of its own Seller processes. Figure 2-1. Isolate the client company from its partnersOn the other hand, how can the designers be certain that their local processes interact exactly as they should with partners? Several years ago, the "global contract" governing this communication would have been documented in writing by a third-party body. As they modeled their processes, the designers would have kept a close eye on the documentation to ensure that their communications were compliant. But with the advent of web services choreography languages, notably WS-CDL, the contract can be coded in a formal language, around which a tool (considered in greater detail in the section "Local View of Choreography: WS-CDL Toolkit") can be built to generate, or to validate the compliance of, local processes. The first cut of the Seller process, for example, can begin as code generated by a tool that interprets the choreography covering Seller, Buyer, Inventory, and Credit card company. Or, supposing the first cut had been written manually, at any subsequent stage of development, the code can be run through the tool to validate that Seller interfaces correctly with Buyer, Inventory, and Credit card company. Such a tool simplifies process design, and eliminates the eyeball approach. 2.1.3. Components of a Good DesignFigure 2-2 shows the main pieces of the BPM architecture and their relationships. Figure 2-2. A good BPM architectureIn the centerand at the heartof the system is the runtime engine, which executes processes written in BPEL. Business and technical analysts design the processes using a graphical editor that supports BPMN. The editor includes an exporter that generates BPEL XML code from BPMN diagrams. Human and computer interactions drive the execution of processes in the engine. The people who participate in the process use a human workflow graphical application that connects to the engine through a programmatic worklist interface. The interface allows the user to view and execute pending manual activities. There are two types of computer interactions: internal and external . Internal applications, which reside on the company's network but are outside of the engine's address space, are accessed by integration technologies such as web services, J2EE, or COM, with XML as the probable message format; internal interactions can also be more lightweight inline code snippets written in programming languages such as Java or C#. External interactions are typically web service-based communications, governed by choreographies or business-to-business collaborations, with the processes of other companies. BPM system administrators use a graphical administration and monitoring console to maintain and track the state of the engine's processes. The console uses a management language to interface with the engine. The runtime engine maintains persistance of a process state to a database; the console hits the database directly, rather than using the management language, to perform ad hoc process queries. For applications involving complex interactions with external participants (e.g., a B2B process), a WS-CDL choreography toolkit generates a basic BPMN model that captures the communications required of the local process; it can perform a validation, or choreography compliance check, of that model. 2.1.4. Run It on an Application ServerNever build a BPM application from scratch. Instead, run it on an application server, to leverage built-in application server facilities such as security, transactions, system management, and the pooling of client connections and resources. Table 2-1 summarizes a possible J2EE application server implementation of the BPM architecture.
This solution is a combination of out-of-the-box product functionality and custom development, as shown in Figure 2-3. The application server layer, for example, might require custom EJBs to provide functions to call from processes and custom JSPs to use in custom management consoles. The BPM layer might require extensions to the process data model and the development of reusable processes. Figure 2-3. BPM on an application server |