|
7.1. Introduction to BPMBusiness 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 BPMSWhen 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 BPMSThe 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?
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 SYSTEMA 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 LanguagesA 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 SystemDepending 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 CAVEATThe 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. |
|