Section 7.1. Introduction to BPM


7.1. Introduction to BPM

Business process management has a number of predecessors. Following the Total Quality Management wave of the late 1980s, a new paradigm emerged in the early 1990s: Business Process Reengineering (BPR). In 1993, Michael Hammer and James Champy published their New York Times bestseller Reengineering the Corporation [HC93], which was followed by a plethora of other management books on the topic of process-orientation and reengineering. The promise of reengineering was to deliver dramatic business performance improvements in a relatively short period of time by completely reinventing existing business processes, that is, starting from scratch with new, optimized ways of doing business, throwing out the old, encrusted, inefficient procedures of the past.

However, after the initial BPR boom (and millions of dollars spent on management consultancies to lead BPR projects in Fortune 500 companies), the process movement became idle. Many projects resulted in complete failure, with experts claiming that between 60% and 70% of reengineering efforts failing to achieve expected results. Hammer and others attribute these failure rates to resistance to change, lack of understanding of the business models and underlying processes, and failure of nerve on the part of the client companies.

Almost ten years after BPR, you can observe a revival of the process movement under the umbrella term business process management (BPM), as advocated by Howard Smith and Peter Fingar in BPM: The Third Wave [SF03]. When comparing BPR and BPM, it appears as if one thing has fundamentally changed: While in the 1990s reengineering meant "starting from scratch," process management builds on and transforms that which already existsit recommends incremental change and evolutionary optimization. However, BPM is still about processes, which are the main competitive differentiator in all business activity.

BPM is a general management topic that focuses on the strategic and operational aspects of process orientation in a given business area. Mapping a BPM model onto an enterprise IT landscape is a challenging task, which has some interesting technical as well as IT management-related aspects.

7.1.1. BPM VERSUS BPMS

When discussing BPM, it is important to differentiate between the business and IT sides. When looking at the business side of BPM, you will often find related keywords such as ISO 9000 and Six Sigma. The IT side of BPM is often accompanied by keywords such as process modeling and workflow management (see Figure 7-1).

Figure 7-1. IT and business people have different views of the processes of an organization.


A BPMS (Business Process Management System) provides the technical platform for realizing BPM management initiatives. It comprises several parts including a BPM engine, facilities for business process monitoring, design tools and facilities for simulation. A BPMS installation can include several products or custom made software components. Closing the gap between the business and IT sides of BPM (or other process-oriented approaches) has been something of a holy grail in IT for two decades. Currently, it seems that the solution might be a conversion between more software engineering approaches such as CASE (Computer Aided Software Design) and MDA (Model Driven Architectures) on one hand, and workflow management and BPM approaches on the other (see [Fra03]).

BPM introduces the concept of "process processing" and stresses that this concept is not limited to the automatic execution of digital process models, but "encompasses the discovery, design, and deployment of business processes, as well as the executive, administrative, and supervisory control over them to ensure that they remain compliant with business objectives" [SF03]. This describes at a high level the features that are typically included in BPMS, a new software category that supports the entire lifecycle of modeling, executing, and monitoring business processes.

7.1.2. WHEN TO CHOOSE A BPMS

The cost and complexity of introducing a BPM engine or platform should not be underestimated. Most BPM products are fairly complex and require a mixture of highly skilled developers and administrators for installation, implementation, and maintenance. Thus, the decision for a BPM solution is a critical one. When does it actually make sense to consider a technical BPM solution, and what are the decision criteria?

IT and business must work hand-in-hand. You must understand that the introduction of a BPM software solution will not enable the process-oriented enterprise on its own. If the enterprise is not prepared for a process-oriented operation at the business level, a BPM platform will always be limited to covering very small sections of the enterprise. On the other hand, if an enterprise has gone through the process of defining and documenting key business processes, for example as part of an ISO 9000 certification or a Six Sigma quality management project, it is likely that the introduction of a BPM engine will be widely accepted at both the technological and business levels. See Chapter 12 for a more detailed discussion.

Utilize process templates. It is interesting that some BPM vendors are starting to bundle their BPM platforms with process templates for several different vertical industries, such as banking, insurance, and manufacturing. Although a process definition, such as claims processing in insurance, is likely to be different for every single company, the provision of a template for specific processes as a starting point can be extremely valuable. This can be particularly interesting if you consider that the BPM concepts are not about starting from scratch (like in business process reengineering) but rather are about incremental changes: starting a project for defining and implementing process definitions from scratch imposes significantly higher risks than a project that can start from a working process template, even if this template must be adapted to fit the individual needs of the enterprise.

Match the right technology to your problem. To determine whether it makes sense to choose a BPM engine to support a particular business process, you should understand the nature of the business process itselfdifferent types of processes are best addressed using different types of technologies. Two key characteristics of a business process are its complexity and dynamism (frequency of change) on one hand, and the degree of coordination the particular process requires on the other (see Figure 7-2).

Figure 7-2. Different types of processes are best addressed using different types of technologies, such as EAI, application servers, or BPM/Workflow.


Adopt the development model. A BPM platform can also provide significant benefits at the level of software development processes: It provides a complete development model that enforces a clean separation between business logic and low-level technical code. This can be a major benefit, especially if a team has highly heterogeneous skills. BPMs are also particularly useful in situations where people have made many ad-hoc changes to the business model and a transparent runtime management of process instances is required.

However, given the high resource requirements of a BPM introduction, you must carefully evaluate the real need for BPM. Generally, you should avoid using BPM if the workflows or business processes are of a simple to moderate complexity because a team with knowledge of an existing development platform would be significantly faster in developing developing these workflows or business processes using an ordinary programming language.

7.1.3. OVERVIEW OF A BPM SYSTEM

A BPM software product should enable business analysts, software developers, and system administrators to model and deploy business processes (at development time) and to interact with, monitor, and analyze process instances (at run-time). The following looks at actual modeling and execution of business processes in a BPMS.

7.1.3.1 Modeling Languages

A number of competing modeling languages have been proposed by a variety of different industry consortia, although the final shoot-out has yet to happen. However, almost all these process modeling languages are based on or at least influenced by the theoretical concepts of Petri [Rei 1992] and or the more recent work of Milner [Mil80].

Two of the most popular approaches are Business Process Execution Language for Web Services (BPEL4WS) and Business Process Modeling Language (BPML). BPEL4WS is based on IBM's Web Service Flow Language (WSFL) and Microsoft's XLANG. BPML is developed by the Business Process Management Initiative (see BPMI.org), which is supported by vendors such as Intalio, SAP, SeeBeyond, Sun, and others.

While process definition languages such as BPEL4WS and BPML are designed to enable the exchange of process definitions between process engines from different vendors, graphical modeling languages exist that enable human users to understand, create, and modify process definitions more easily. The BPMN (Business Process Modeling Notation) is a language that has been defined by the BPMI in order to support a standardized, graphical representation of business process diagrams. In a way, the BPMN approach is similar to the UML approach, in that it provides a graphical representation of object models that is independent of the implementation language. In fact, many similarities exist between UML activity diagrams and BPMN. However, BPMN is specifically designed with BPM engines in mind. Consequently, it includes a mapping of its graphical objects to BPML. We use BPMN at various points in this book to graphically illustrate business processes.

Figure 7-3 shows how BPMN is positioned at the interface between business and IT: While UML is widely used within the IT organization as a means to communicate abstract concepts and models, BPMN aims to become the de facto standard used between IT and business to discuss the scope and functionality of processes and applications.

Figure 7-3. BPMN is positioned at the interface between business and IT.


Another feature of many modern BPM systems is the capability to provide different views of a process definition, including a more abstract view designed for business analysts and a much more detailed view for technical staff.

7.1.3.2 Architecture of a BPM System

Depending on the BPM product at hand, processes are usually modeled graphically (e.g., based on a graphical notation such as BPMN), stored in a block-structured model (e.g., in BPEL4WS or BPML), and executed by a process engine. What is common to most pure-play BPM engines is their foundation on a mixture of Pi-Calculus [Mil80] and Petri Net models [Rei1992]. BPM tools vary in their support for different modeling languages, application integration, process monitoring, and so forth. However, we provide an overview of a generic BPM system architecture in Figure 7-4. At the heart of a BPM is the process engine, which creates and interprets runtime instances of formal process definitions. Process definitions (development time) and process instances (runtime) are stored in repositories, and the system provides appropriate interfaces to design, deploy, and configure process definitions and to monitor and manage process instances.

Figure 7-4. Overview of a generic BPM system architecture.


7.1.4. VISION AND CAVEAT

The BPM vision is a strong oneinstead of hard-coding information and rules regarding important business processes directly into the application code, we take this information out of the application systems and put it under the control of a BPM system. The BPM facilitates the modification, reconfiguration, and optimization of process definitions with graphical tools that can be used by less technology-oriented business analysts.

As depicted in Figure 7-5, this BPM vision and our SOA vision are a very good fit. The SOA provides the backend functionality that is required by a BPMS in order to implement its process functionality. All the concepts discussed with respect to SOAincluding the evolutionary development of basic, intermediary, and process layersmake sense in light of this picture. SOA becomes the enabling infrastructure for the process-oriented enterprise.

Figure 7-5. Roundtrip engineering at the business level: The SOA provides the enabling business infrastructure.


However, there is one caveat to all this: Remember the hub-and-spoke model as it was proposed by late-nineteen-ninetieth EAI-products? In the hub-and-spoke model, a centralized hub connects a variety of different applications, enabling the seamless interplay of different transactions in these sub-systems. A picture similar to the central hub is the famous "software bus" promoted by the CORBA community. This never worked out in your enterprise? There was never one centralized software bus or hub, but rather a multitude of competing integration and EAI products and projects? Does this BPM vision not resemble the central hub/bus vision and cause a major concern? Would this BPM vision not require the centralization of all business process definitions, as depicted in Figure 7-6?

Figure 7-6. The topologies of BPM and hub-and-spoke systems look similar.


In a way, you are right if you experience déjà vu. The chances that your enterprise will standardize on just one BPM platform and migrate all its core business processes onto this centralized platform are indeed fairly slim. However, we believe that there is still light on the horizon and that BPM could play an important part in your enterprise's transition toward a more agile and flexible IT infrastructure with an underlying SOA. In Figure 7-7, we show a more realistic scenario: Individual departments or organizations will adopt SOA and BPM. The integration across these organizational boundaries will not be based on centralized hub, bus, or BPM architectures for a variety of reasons. The cloud in the figure represents the void between the different organizations, a void that will not be filled by a centralized technology standard controlled by a single political unit. Instead, the connections between the different organizations will continue to be ad-hoc and often short-lived. A number of common (sometimes conflicting) standards, such as SOAP and CORBA IIOP, enable basic communication between the different organizations. In some cases, higher-level protocols such as ebXML or RosettaNet might play a role. However, organizations will have to cope with the fact that the integration with external organizations (or other business units, subsidiaries, etc.) will still need protocols and logic that require more flexibility than within a well controlled, intra-organizational environment. If the organization hooks into this "cloud" using a BPM, the organization receives a very powerful tool for reacting to frequently changing requirements for integration with third parties.

Figure 7-7. The scope of a BPMS is generally limited to a single business unit. Crossing the borders of the organization requires distributed process control and largely heterogeneous standards.


Although this vision does not promise to unravel the enterprise system integration "spaghetti," it provides a chance for individual organizations to react to the realities of intra- and extra-company system integration in the most flexible manner, shielding the systems under their own control from outside dynamics and at least providing a cleaner architecture that is extensible and adaptable.



    Enterprise SOA. Service-Oriented Architecture Best Practices
    Enterprise SOA: Service-Oriented Architecture Best Practices
    ISBN: 0131465759
    EAN: 2147483647
    Year: 2003
    Pages: 142

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