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 modelwith 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?



    Essential Business Process Modeling
    Essential Business Process Modeling
    ISBN: 0596008430
    EAN: 2147483647
    Year: 2003
    Pages: 122
    Authors: Michael Havey

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net