I would recommend this one.

---

Product Description

Ten years ago, groupware bundled with email and calendar applications helped track the flow of work from person to person within an organization. Workflow in today's enterprise means more monitoring and orchestrating massive systems. A new technology called Business Process Management, or BPM, helps software architects and developers design, code, run, administer, and monitor complex network-based business processes. BPM replaces those sketchy flowchart diagrams that business analysts draw on whiteboards with a precise model that uses standard graphical and XML representations, and an architecture that allows it converse with other services, systems, and users. Sounds complicated? It is. But it's downright frustrating when you have to search the Web for every little piece of information vital to the process. "Essential Business Process Modeling" gathers all the concepts, design, architecture, and standard specifications of BPM into one concise book, and offers hands-on examples that illustrate BPM's approach to process notation, execution, administration and monitoring. Author Mike Havey demonstrates standard ways to code rigorous processes that are centerpieces of a service-oriented architecture (SOA), which defines how networks interact so that one can perform a service for the other. His book also shows how BPM complements enterprise application integration (EAI), a method for moving from older applications to new ones, and Enterprise Service BUS for integrating different web services, messaging, and XML technologies into a single network. BPM, he says, is to this collection of services what a conductor is to musicians in an orchestra: it coordinates their actions in the performance of a larger composition. "Essential Business Process Modeling" teaches you how to develop examples of process-oriented applications using free tools that can be run on an average PC or laptop. You'll also learn about BPM design patterns and best practices, as well as some underlying theory. The best way to monitor processes within an enterprise is with BPM, and the best way to navigate BPM is with this valuable book.

---

Product Details

• Amazon Sales Rank: #241590 in Books
• Published on: 2005-08-18
• Original language: English
• Number of items: 1
• Binding: Paperback
• 332 pages

From the Publisher
Monitoring workflow today can involve orchestrating massive systems. Business Process Management (BPM) helps developers design, code, run, administer, and monitor enterprise business processes. This guide explains BPM concepts, architecture and specifications, and then teaches you how to develop process-oriented applications using free tools.

About the Author
Michael Harvey is an architect of several major BPM applications and author of magazine articles on BPM and process-oriented applications. In addition to being interested in the foundational concepts of BPM, Michael has spent much of his career working for companies that sell BPM product solutions (BEA with Weblogic Integration and IBM with Websphere Business Integration).

Excerpted from Essential Business Process Modeling by Mike Havey. Copyright © 2005. Reprinted by permission. All rights reserved.
Chapter Two Prescription for a Good BPM Architecture

BPM standards abound, each with a distinct design and feature set. This chapter scavenges these approaches in search of a general BPM application architecture that is conceptually comprehensible and meets real-world requirements. A good architecture uses the technique of divide-and-conquer to reduce a difficult problem to smaller, more manageable parts, and where possible, it solves each part not by inventing new technology but by reusing an existing approach. Applying this technique, we ask: in a BPM architecture, what is the problem to be solved, what are its parts, and which standards, if any, solve them?

The architecture presented here is intended as a reference model—with similarities to the WfMC’s model (see Chapter 7) and the proposed stack of the BPMI (see Chapter 6) — targeted at product and services architects alike. The appeal for product architects is obvious: the model, though lacking the level of detail for a micro design, has the same form as a BPM product, and can help guide the overall construction. Services architects, who typically advocate buying a good vendor solution and customizing it rather than building the entire solution from scratch, need to comprehend the essential nature of the base product. Rather than treating it as a black box, these architects should have a sense of curiosity analogous to that of a driver who lifts the hood of a car and seeks to grasp the basic mechanics of all those belts and gears. There are a number of reasons why:

• BPM is an emerging subject, and in the current morass of vendors, standards, hype, and theory, having a crystal-clear notion of a good solution (whether built or bought) gives an architect a competitive advantage over the many who are still learning.

• Customers know the essential architecture of some of their IT products and technologies (e.g., database, operating system, network router), but they probably have a fuzzier notion of BPM, and they expect the services architect to help explain it to them and guide them through adoption.

• Vendor documentation seldom distinguishes clearly between standard and proprietary features. (The architecture in this chapter tries to avoid the second of these.) If the customer has been sold on BPEL, the XYZ foundation classes, BAM, and the Intel process optimizer, the services architect needs to know that BPEL and BAM are standard solution-building blocks, and to avoid the proprietary XYZ and optimizer if the customer foresees migrating to another vendor implementation someday. The customer probably does not know the difference.

• The architecture for the customer’s application must use and extend the out-of-the-box features of the stack. To know how to do this, the architect needs to understand those out-of-the-box features. For example, what tools are provided to support process development and deployment? What is the strategy to patch or upgrade live production processes? What is the data model, and how can customer data entities be worked into it? How are external systems interfaces built, and how are they called from processes? How can the monitoring subsystem be customized to serve the customer’s business and operational requirements?

Designing a Solution

To 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.

Understanding the Problem

To 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:

Design
The design of a business process is intuitively a flowchart that outlines the steps performed over time in the resolution of a business problem. Unlike most object-oriented designs, whose audience is the technical team of a project, a process design is crafted and comprehended by both business and technical analysts. Business analysts are involved because they understand the business aspects of the process best; the design is simply a rigorous expression of what they frequently draw on paper or on a whiteboard. The level of rigor, plus the anticipation of implementing a software solution to the design, draws in technical analysts. Thus, business and technical designers require a common design notation that is at once business-oriented and amenable to computer processing. They also require a graphical editor in which to sketch their design.

Run
The early workflow engines that were actually able to run designed processes, and thus to automate the execution of formerly manual procedures, must have been perceived as miraculous. Today, this miracle is a core requirement: "Run what I just drew!" But conceived more dispassionately, the executability of a process is a matter of having a runtime engine and an executable language that the engine knows how to run. Moreover, a mapping is required between the design notation and the executable language, enabling the automated generation of executable code from the design. The manual coding of a process is undesirable because it slows the development cycle and ensures gaps between the design and the execution.

Monitor and administer
Monitoring, the ability to watch the progress of running processes, is crucial for production applications for two reasons: the detection of exceptions (ensuring processes are progressing as expected and not getting stuck), and real-time ad hoc querying (e.g., finding all active processes for customers in a particular account range). Administration is the management of, and the ability to effect changes on, processes on the runtime engine. It includes the ability to install, shut off, or turn on process designs, and to suspend, resume, or terminate running processes. Monitoring and administration require a management language and a graphical management console that can watch and modify the BPM system.

---

Customer Reviews

Excellent detailed discussion of SOA standards
As an experienced SOA architect I found this one of the best books on the standards which underpin SOA, BPM and to some extent EAI. Ranging from the theory right down into the practical aspects of applying process standards this is an excellent way to come up to speed on the acronym soup. Because it is not a methods book it does not attempt to cover the 'how to' of process modelling, nor does it cover generic business process management (BPM). However, as a reference and background book this is top class.