ÐÏࡱá > þÿ þÿÿÿ e æ g ª « é j ë l
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿì¥Á M ø¿ ž bjbjâ=â= À €W €W ë I ' B ÿÿ ÿÿ ÿÿ l j j j
t Ð Ð Ð ä ò6 ò6 ò6 8 *7 ” ¾7 ¬ ä Ô} ò v8 n ä= ( > > > “? £C D çD ¤ dv fv fv fv S ¹v ` z ` y} Æ æ v y} Ð ‹E q? " “? ‹E ‹E y} ÉO € € > > e Ž} ÉO ÉO ÉO ‹E º € 8 > Ð > dv ÉO ‹E dv ÉO : ÉO X 6 t à ¸ Ð dv > j8 Â*ÖZÃä 0 ò6 EG èt dv ¤} 0 Ô} u ` \‚ _O j \‚ dv ÉO ä ä € € € € Ù
INFS 770 – Methods for Information Systems Engineering: Knowledge Management and E-Business
Spring 2003
Dr. Larry Kerschberg
Information Systems Department
George Mason University
Abstract. In his seminal article, “A Framework for Information Systems Architecture”, J.A. Zachman cut through the confusion and ambiguity surrounding the concept of system architectures by realizing that no single model could capture all the important features of an enterprise or its systems. Instead, a different model is required depending both on who the model is for and on what question that individual wants answered about the system. The initial framework consisted of three perspectives; the owner, the designer, and the builder, and three questions; what, how, and where. Later, Zachman expanded the framework to include the additional questions of who, when, and why.
For each combination of perspective and question, there are can be several competing methodologies for modeling the important features of the system. Some methodologies are arguably better than others at capturing and communicating pertinent information. This project will focus in on the owner’s view of how the organization works; business process models. We will examine various process modeling techniques, such as IDEF, UML, and BPMN, to determine their suitability, specifically for modeling the business processes of an e-business. We will examine how process models capture business rules and how they relate to other components of the architecture, such as ontologies. We will also investigate how well various process models support the documentation and development of web services.
Contents
TOC \o "1-3" \h \z HYPERLINK \l "_Toc38274635" Business Process Models PAGEREF _Toc38274635 \h 3
HYPERLINK \l "_Toc38274636" Process Modeling Benefits PAGEREF _Toc38274636 \h 3
HYPERLINK \l "_Toc38274637" Business Process Architecting PAGEREF _Toc38274637 \h 4
HYPERLINK \l "_Toc38274638" Modeling Criteria PAGEREF _Toc38274638 \h 4
HYPERLINK \l "_Toc38274639" Business Process Modeling Methodologies PAGEREF _Toc38274639 \h 5
HYPERLINK \l "_Toc38274640" Process Modeling Methodologies PAGEREF _Toc38274640 \h 5
HYPERLINK \l "_Toc38274641" Flow Charts PAGEREF _Toc38274641 \h 5
HYPERLINK \l "_Toc38274642" Data Flow Diagrams PAGEREF _Toc38274642 \h 6
HYPERLINK \l "_Toc38274643" Control Flow Diagrams PAGEREF _Toc38274643 \h 6
HYPERLINK \l "_Toc38274644" Functional Flow Block Diagrams PAGEREF _Toc38274644 \h 7
HYPERLINK \l "_Toc38274645" Gantt / PERT Diagrams PAGEREF _Toc38274645 \h 8
HYPERLINK \l "_Toc38274646" IDEF PAGEREF _Toc38274646 \h 8
HYPERLINK \l "_Toc38274647" The Modern Methods PAGEREF _Toc38274647 \h 9
HYPERLINK \l "_Toc38274648" Unified Modeling Language (UML) PAGEREF _Toc38274648 \h 10
HYPERLINK \l "_Toc38274649" Business Process Modeling Notation (BPMN) PAGEREF _Toc38274649 \h 10
HYPERLINK \l "_Toc38274650" Business Process Management PAGEREF _Toc38274650 \h 11
HYPERLINK \l "_Toc38274651" Business Process Management System PAGEREF _Toc38274651 \h 11
HYPERLINK \l "_Toc38274652" Pi Calculus and Process Modeling PAGEREF _Toc38274652 \h 13
HYPERLINK \l "_Toc38274653" Business Process Management Initiative (BPMI) PAGEREF _Toc38274653 \h 14
HYPERLINK \l "_Toc38274654" Business Process Modeling Language (BPML) PAGEREF _Toc38274654 \h 15
HYPERLINK \l "_Toc38274655" Business Process Modeling Notation (BPMN) PAGEREF _Toc38274655 \h 16
HYPERLINK \l "_Toc38274656" Business Process Query Language (BPQL) PAGEREF _Toc38274656 \h 18
HYPERLINK \l "_Toc38274657" Process Status Communication PAGEREF _Toc38274657 \h 18
HYPERLINK \l "_Toc38274658" A Case Study using BPML PAGEREF _Toc38274658 \h 18
HYPERLINK \l "_Toc38274659" BPMN Representation PAGEREF _Toc38274659 \h 20
HYPERLINK \l "_Toc38274660" BPEL4WS PAGEREF _Toc38274660 \h 20
HYPERLINK \l "_Toc38274661" ebXML BPSS PAGEREF _Toc38274661 \h 22
HYPERLINK \l "_Toc38274662" Ontologies PAGEREF _Toc38274662 \h 22
HYPERLINK \l "_Toc38274663" Ontologies and Process Modeling PAGEREF _Toc38274663 \h 22
HYPERLINK \l "_Toc38274664" Ontological Engineering and E-Business PAGEREF _Toc38274664 \h 23
HYPERLINK \l "_Toc38274665" Linking E-business to Operating Processes PAGEREF _Toc38274665 \h 24
HYPERLINK \l "_Toc38274666" Process Modeling and Web Services PAGEREF _Toc38274666 \h 24
HYPERLINK \l "_Toc38274667" Web Services for Business Process Design PAGEREF _Toc38274667 \h 25
HYPERLINK \l "_Toc38274668" Web Services and Business Process Management PAGEREF _Toc38274668 \h 26
HYPERLINK \l "_Toc38274669" Conclusion PAGEREF _Toc38274669 \h 26
HYPERLINK \l "_Toc38274670" Works Cited PAGEREF _Toc38274670 \h 27
HYPERLINK \l "_Toc38274671" Other References PAGEREF _Toc38274671 \h 28
Business Process Models
Before we can adequately discuss the pros and cons of various business process modeling methodologies, it will be helpful to discuss some generic attributes of business process models, as well as identify some of the features that one might like in a business process modeling methodology.
As mentioned above, business process models describe how a business works, or more specifically, how they accomplish missions, activities, or tasks (henceforth referred to as tasks). A single model shows how a business accomplished a single task. It would take many process models to fully detail the “hows” of most real world enterprises.
A single process can be quite involved. It can consist of many actors (people, organizations, systems) performing many tasks. In order to accomplish the overall task, the actors must complete specified sub-tasks in a coordinated manner. Sometimes, these sub-tasks can be performed in parallel. Sometimes they are sequential. Some processes require repetition of sub-tasks. Most processes have decision points where process flow can branch depending on either the condition of the system or the particular process execution. In cooperative processes actors must pass information. This information transfer can be the trigger for an actor to begin a sub-task. Other triggers are possible, such as time or interrupts. Some processes are ad-hoc. That is, the sub-tasks do not have well defined triggers. Actors may not need to complete all of a subtask before they or another actor start work on another dependent subtask. Finally, a process can look differently when described from the viewpoint of different actors. A business process modeling methodology needs to be able to represent these different aspects of a process description. A good methodology will present the representation in a manner that is easily transferred into the tacit knowledge of the viewer.
Process Modeling Benefits
There are many potential uses of process models [Browning 2002]:
Program planning
Baseline for continuous improvement
Knowledge retention and learning
Process visualization
Training
Framework for metrics
Compliance, audit, and assessments
Program execution
Even though there are many benefits to modeling business processes, it is rarely done, and when done at all, not done very well. Many companies have made efforts to document their processes, but very few have “built (and committed to improve and learn from) useful process models.” [ibid] The process models that do exist are often not well integrated and leave out key information that would fully describe the process. There is a need for better tools and techniques for modeling business processes and keeping them in synch with actual business activities.
Even when a project has a good, well-documented process, it is often too difficult to capture lessons learned from the on-going project and immediately update the process model. [Fagerstrom et al 2002] “Knowledge in the project is added as the project progresses. As a result, earlier-made decisions can be considered unreasonable at a later stage. It is important that the process supports exchange of design knowledge.” [ibid]
This is very true in conventional projects, but even more difficult to accomplish in web-based enterprises where the activities occur in “Internet” time and the activity interfaces often lie at the boundary between e-businesses. Since the e-business is more abstract than a conventional business, it is more difficult to do management by “walking around” (MBWA). Instead you will need a process model to do the “walking.” Later we will describe a Business Process Management System (BPMS) approach that will facilitate the MBWA technique of making a business better meet its goals and objectives.
Business Process Architecting
An architecture is the “arrangement of function and feature that achieves a given objective.” [Ring 2001] It is claimed that a business process must not merely be engineered, but should be “architected” given the very complex and fuzzy nature of business processes. [Biemans et al 2001] They go on further to say:
Engineers are trained to design systems such as bridges, computers, and aircraft in a well-structured manner. However, the design of business processes has not yet matured to this level. We argue that the complexity of business processes is the major cause…. Business process “architecting,” the high-level, functional design of business processes, is more an art than a science. [ibid]
They give several reasons for this extraordinary complexity of business processes:
they involve several knowledge domains
they operate on “vastly different” time scales
they are often “nearly independent”
people need years of training before they can understand them or “reason about them”
a common “frame of reference” among the many stakeholders does not exist
they have many “uncontrolled modifications”
Further complicating the problem is the fact that “business processes can change autonomously: The people that are part of a business process might modify this process, without any explicit design.” [ibid] In their paper, they give three elements needed for constructing business process models. First, we need a more on this later development strategy that “determines the order in which design steps are taken.” Second, we need mechanisms to “structure a model.” (Their paper is unclear on exactly what they mean by “mechanisms.” They make reference to “modeling styles” but this appears to be a non sequitur.) Third, we need a modeling language. The rest of their paper describes different techniques for developing the process model.
They describe three different modeling “strategies” that can be employed: process-oriented, resource-oriented, and data-oriented. Process-oriented strategy starts with the workflow of an organization (i.e., the behavior). The resources or “roles” within an organization are modeled first in the resource-oriented approach. The data-oriented strategy starts by first describing the data items that comprise the inputs and outputs of the business process. The paper does not suggest one strategy that is “best” but rather that the appropriate strategy will depend on the situation and often a hybrid strategy works well.
Modeling Criteria
Stefan Haberl has developed a set of seven criteria for evaluating process modeling methodologies [Haberl]:
It must be able to model all the complexities of business processes listed above, to include:
Sequencing
Branching
Looping
Concurrency Constructs – fork and synchronize
Timeouts
Deadlines
Faults
Aggregation
It must have a means of distinguishing roles and assigning them the various tasks.
There must be an unambiguous graphical representation of the language.
It must have a transaction model that allows for the description of how a process can be undone.
It must specify how process instances will be triggered and identified throughout their execution
It must have a means of specifying the characteristics of the business process that would be of interest to external users. This would include things like quality of service and pricing.
The language should not mix in details of communications protocols.
The first three criteria are important for obtaining the first seven benefits identified by Browning. The second group of three is essential for automating process execution between cooperating, yet separate organizations. The last criterion keeps the process models at the right level of abstraction.
Business Process Modeling Methodologies
People have been modeling processes for many years. They have not always called their models “Business Process Models” because often, they were not describing what they thought of as business processes. That said, the techniques they used can and have been applied to describing “how” organizations perform their work. These models can be used to train new employees. They can be as aids in re-engineering processes. They can be used to develop simulations to test the processes on inputs that have not occurred in real life. Finally, they can be used to develop systems to automate the processes they model. In the last case, programmers may use the process model as a guide in developing the information system or more recently, some process models can be run though process execution engines that automate the process directly from the model.
In addition to having many uses, process models can be created or presented using many different methodologies. Each methodology has a different history. Many have a different way of looking at processes based upon the purpose they were originally created for. Some are more or less readable by nonprofessionals. Some are more or less useful for business process modeling.
The following is a brief description of some of the more prominent process modeling methodologies.
Process Modeling Methodologies
Flow Charts
Flow charts originated in, or were adopted very early by, the programming community. Programmers used them to describe the logic, or path of execution, within an executing program. Flow chart symbology and semantics is restricted to the limited number of atomic control structures available to programmers. Flow charts were developed to depict the path of execution within a single process. They do not have the expressive power to properly model groups of cooperating processes.
Figure 1 – ANSI Flow Chart Example
[deming.eng.clemson.edu/pub/tutorials/qctools/flowm.htm]
Data Flow Diagrams
Data Flow Diagrams (DFDs) have their birth, or at least their coming of age, in Tom DeMarco’s book, Structured Analysis and Systems Specifications (Yourdon Inc., 1978). As can be inferred from the name, DFDs concentrate on the data in an information system. They show the sequence of processing steps traversed by the data. Each step documents an action taken to transform or distribute the data. DFDs are easy to read, making it possible for domain experts to create and or validate the diagrams. DFDs do not provide the capability to describe process sequencing or process control mechanisms.
Control Flow Diagrams
Control flow diagrams (CFD) are similar to Data Flow Diagrams except they are commonly used where the application is more event-driven than data-driven. They are an enhancement to the DeMarco style data flow diagrams. The most common style of CFD is perhaps the Hatley-Pirbhai diagram. [Hatley et al 2000, and also see http://www.psare.com/] The CFD approach is based on classical structured analysis techniques and finite state machine theory and merges the two together into a unified whole. Additional information is contained in control specifications (CSPECs) that contain the finite state machine structures. The finite state machines are used to control the behavior of the companion data flow diagrams (DFDs). An example of a combined DFD/CFD is shown in Figure 2. The solid lines represent data flows while the dashed lines represent control flows.
EMBED MSPhotoEd.3
Figure 2 – Combined Data/Control Flow Diagram (DFD/CFD)
[http://www.turbocase.com/features.html]
Functional Flow Block Diagrams
The functional flow block diagram (FFBD) is widely used in classical systems engineering to show the order of execution of system functions. As such, it shows the proper sequencing in terms of precedence (function A must happen before function B) and concurrency (function C can occur at the same time as function D). The concurrent functions can be either parallel (AND gate) or alternative paths (OR gate). A typical format for the FFBD is shown in Figure 3.
Figure 3 – Functional Flow Block Diagram (FFBD) Format
[DAU 2000]
Gantt / PERT Diagrams
Henry Gantt invented the chart that bears his name in 1917. He was working for the Navy and wanted a method to schedule the tasks associated with ship construction. His charts depicted each task as a horizontal bar who’s length was determined by the expected duration of the task. These simple charts showed both logic and sequencing.
The US Navy created PERT charts in the 1950s. They basically capture the same information as Gantt charts, but where the Gantt charts provide a good visualization of task durations, PERT charts do a better job presenting sequencing, especially when the sequencing is complicated.
In general, both Gantt and PERT charts are used for project management. They are seldom used for process modeling. They have no means to describe any information about a process than the sequencing of tasks, although some modern tools allow the association of resources to tasks. They do not support the modeling input / output information or material nor do they provide a means to model control mechanisms.
IDEF
Probably the most common technique of traditional business process modeling is IDEF. There are several types of IDEF models. The most familiar is IDEF0. IDEF0 models are activity models. They model the tasks performed by an organization, to include the inputs, outputs, and controls of each task. Tasks, or activities, can be shown as high level tasks which decompose into sub-tasks. Inputs, outputs, and controls can also be aggregated into groups. While IDEF0 models can appear to show the sequence of activities, this is only a perception. No temporal relationship is implied by the arrangement of activities in the diagram. Process details are captured in IDEF3 diagrams. Figure 4 shows an example of an IDEF3 diagram.
Figure 4 – example IDEF3 Diagram
One of the unique features of IDEF modeling is that IDEF explicitly recognizes the fact that process descriptions can vary depending on the point of view from which they are generated.
The Modern Methods
The above represent just a fraction of the methodologies used over the last thirty years to document business processes. As part of his PhD research, Bart-Jan Hommes has identified twenty different techniques and over 350 different process modeling tools. While many of these techniques are still used in practice, most do not meet even the first three of Haberl’s criteria, let alone the criteria essential for modeling processes for automated execution. A new set of methodologies is under development to meet the needs of modern e-businesses. ebPML.org identifies these methodologies as ebPML, BPML, XLANG, WSFL, BPEL4WS, EDOC, XPDL, and UML 2.0, however BPEL4WS is a collaboration between the developers of XLANG (Microsoft) and WSFL (IBM), so XLANG and WSFL are really no longer contenders.
The World Wide Web Consortium (W3C) is dedicated to developing the full potential of the Web. To this end, they are proponents of Web Services. Web Services are an operating system and programming language independent method of distributed computing. They are an application-to-application protocol. The Web Services Activity of W3C is working to publish specifications for Web Services that will speed their deployment and improve their chances of success. Within the Web Services Activity, there are four working groups; the Web Services Architecture Working Group, the XML Protocol Working Group, the Web Services Description Working Group, and the Web Services Choreography Working Group. The Web Services Choreography Working Group is working towards a standard for orchestrating the interaction of various web services in the completion of a business process.
Unified Modeling Language (UML)
The UML came from the works of Object Oriented Analysis and Design proponents. In the early 90’s, several researchers had developed similar, yet incompatible representations for describing object oriented software systems. Several of the leaders in the field got together, formed the Object Modeling Group (OMG) and fused their competing methodologies into a unified one. Hence the name. The UML actually consist of a number of different, loosely coupled types of models. Each model is for a different purpose. Class model are used to capture relationships among the entities in the domain. Use Case diagrams are used to capture requirements. Sequence diagrams capture process flow. Package diagrams capture details of deployment. Of all the different diagrams, UML Sequence diagrams are best for capturing process descriptions. While originally developed for software engineering, UML sequence diagrams meet many of the criteria identified by Haberl. Their biggest drawback however is the lack of an aggregation construct.
Figure 5 – Example UML Sequence Diagram
[http://www.smartdraw.com/resources/examples/software/uml6.htm]
Business Process Modeling Notation (BPMN)
The Business Process Modeling Notation (BPMN) is a relatively new technique for developing process models. It was recently published by the Business Process Management Initiative (BPMI) as a draft specification specifically for modeling business processes. The BPMN has a corresponding formal XML-based language called Business Process Modeling Language (BPML). Since this technique is the main focus of this paper, the BPMN and BPML
are described in much greater detail in a later section.
Business Process Management
Welcome to the world of Business Process Management (BPM), where grandiose claims are being made how BPM is going to save the world of business—it will succeed where all other initiatives have failed (like Computer Aided Manufacturing (CAM), Total Quality Management (TQM), Business Process Reengineering (BPR), Six Sigma, the Fifth Discipline, and so on). [Smith and Fingar, Internet World, May 2002] The latest book by Howard Smith (Business Process Management—The Third Wave, and see also www.bpm3.com) is chock full of pronouncements on the wonders of this new approach. Of course, he fails to provide much evidence to back up his assertions. [Ring 2003]
We will explore this world of BPM to discover how it will benefit the world of E-Business and how it impacts the domain of Knowledge Management. Business Process Modeling (another “BPM”) is key to making BPM (the management type) live up to its expectations. Unlike previous approaches, it is claimed that BPM can create a “single definition of a business from which alternative views of that process can be crystallized.” [Max More, book review on amazon.com for BPM-The Third Wave] BPM claims to move us from “data processing” to “process processing.”
One of its multiple strengths is that it synthesizes and extends previous process representation and collaboration technologies and techniques—such as reengineering, EAI, workflow management, service-oriented architecture, XML and Web services, TQM, Six Sigma, and systems thinking—into a unified approach. The entire approach is founded on process calculus, in particular one form of this called Pi-calculus. [ibid]
This paper will attempt to sift through the hype and give an overall assessment of how BPM can and should support an E-Business. We will be looking at the various products from the Business Process Management Initiative (BPMI)—namely the Business Process Modeling Language (BPML) and the Business Process Modeling Notation (BPMN) [www.bpmi.org]. We will also look at other methods and tools for modeling a set of business processes.
Business Process Management System
The so-called Business Process Management System (BPMS) is central to this revolution in the way businesses will operate in the future. Howard Smith describes a BPMS as “a single, unified modeling, integration, and execution environment that can be applied to the implementation of literally any business process.” [Smith and Fingar, Internet World, May 2002] He says that BPMS can be “thought of as an ‘engine for processes’ ” and that:
The BPMS provides the mechanisms to stitch application components together to automate and share strategic and operational business processes, in a manageable and flexible way. By comparison, in the way that the Relational Database Management System (RDBMS) enables the sharing of business data among applications and companies (using a common language called SQL), the BPMS enables the sharing of business processes (using a common language called BPQL). [ibid]
Figure 6 shows how the BPMS brings together “legacy integration with next generation business process collaboration, joining these two worlds with business process automation.” [ibid] This will bring together workflow management applications and the human activities while the business processes are being managed and directed by the BPMS. New applications can be “written that interact with and transform the whole process, from end to end, without requiring software engineering.” [ibid, emphasis added] In the new world of “process-centric” information technology, applications will conform to software architectures that align “more readily with business activity—even across business boundaries.”
Figure 6 – The Business process management system
[Smith and Fingar, Internet World, May 2002]
Enterprise Application Integration (EAI) supports discrete application events, whereas Business Process Integration (BPI) handles “extended activity sequences, long-lived processes, compensating transactions, failures and cancellations driven by business requirements, or conditions outside the control of IT.” These integrated processes include “simple mechanisms to back out of failure conditions even when such rollbacks are not supported by back-end ERP systems.” [ibid]
In the future it will be necessary to integrate the BPMS with a Business Ontology Management System (BOMS), but according to Howard Smith, “the time was not quite right” to standardize this aspect of the problem since further innovation is required. [private communication] He further says that “We took a step, from data, to process (some say that’s a huge step and some say it’s a small step) but we could not take a larger step to the ontology model.” The BPM approach is about “reengineering reengineering”:
Instead of reengineering processes in one fell swoop and then cementing the new models in code, companies should design processes that can be changed on the fly and software that's flexible enough to support those changes. In the "third wave of business-process management," the authors write, implementing a new process is as easy as querying a database. [INC Magazine, ref tbd]
BPM is about creating a “process-managed enterprise.” GE seems be striving towards this goal: “Digitization [of process] represents a revolution that may be the greatest opportunity for growth that our company has ever seen.” [GE 2001 Annual Report] “Do not mistake BPM for some new ‘killer app’ or some fashionable new business theory. It is a foundation upon which companies can depend as surely as they depend on database management today.” [Smith et al 2003]
By placing business processes on center stage, corporations can gain the capabilities they need to innovate, reenergize performance and deliver the value today’s markets demand. A process-managed enterprise makes agile course corrections, embeds six sigma quality and reduces cumulative costs across the value chain. [bpm3.org, “about the book” page]
There are some high praises for BPM, an example being the nine reviews on amazon.com giving Smith’s Third Wave book a perfect five stars. However, there is one reviewer who gave it only one star: “This book converges an amazing number of buzz words into an overly long sales brochure that lacks substance, rationale or proof regarding the benefits of BPM. Dangerously (for you) it ignores the threats of BPM.” The single negative review goes on further to say:
Similar to BPM's three predecessors COBOL, CIM, and BPR, this "third wave" claims that a higher order of computerized logic is the key to continual adaptation for maximizing customer value. Unfortunately (for you) it does not clarify how value is to be created also for investors, suppliers and employees. Further, in declaring "business is process" it potentially diverts your employees from leveraging your only strategic asset --- employee learning and collaboration. Thirdly, while extolling the benefits of highly malleable processes, it ignores the problem of managing multiple changes while ensuring enterprise integrity --- a critical problem addressed by the industrial process control industry more than three decades ago. [Ring, amazon.com book review]
As you can see, there is a large degree of enthusiasm for the BPMS approach. But there is also a cautionary flag being waved. There have been many promised “silver bullets” in the past, and it would be wise to take this road slowly and carefully to avoid the pitfalls of the past. As Steve Towers says in his review of this book on amazon.com, this is “the biggest thing to hit the process scene since 1993.”
Pi Calculus and Process Modeling
Business Process Management is reportedly based on “pi calculus.” The pi-calculus provides a “conceptual framework for understanding mobility, and mathematical tools for expressing systems and reasoning about their behavior.” [Sangiorgi 2001] The pi-calculus differs from other techniques for modeling behavior mainly in its treatment of mobility:
The movement of a piece of data inside a computer program is treated exactly the same as the transfer of a message - or indeed an entire computer program - across the internet. One can also describe networks which reconfigure themselves. The calculus is very simple but powerful; its most prominent ingredient is the notion of a name. Its theory has two important ingredients: the concept of behavioral (or observational) equivalence, and the use of a new theory of types to classify patterns of interactive behavior. The internet, and its communication protocols, fall within the scope of the theory just as much as computer programs, data structures, algorithms and programming languages. [Milner 1999]
According to Howard Smith, “Pi-calculus has been chosen as the foundation for the new ‘business computer.’” [Smith et al 2003] Pi calculus (or “process” calculus) is an extension of the “lambda” calculus that has been the basis for computing for decades.
Previous theories in computer science, notably the Lambda calculus, focused on the behavior of much simpler computer systems, where there is either a single thread of execution or a set of parallel but non-interacting tasks. Such algorithms are procedural, sequential, goal-oriented, hierarchical and deterministic. All of today’s well-known programming languages can be studied using Lambda-calculus…. By contrast, in process theories such as Pi-calculus, the main focus is on systems that interact and interrupt one another, where there are many deeply nested independent, but coordinated, interacting threads of execution. Business processes are an example. The differences between these theories are striking, for even our notion of what constitutes a common-sense interpretation of data and value has changed utterly.
In conventional computer languages there exists the concept of a “type.” …integer…string…. By contrast, in languages derived from Pi-calculus, types represent behavioral patterns…. it identifies the concepts that underpin a wide variety of concurrent systems….where process is the new first-class entity…. This perspective gives the third wave of process management its inherent ability to capture, describe, and manage whole processes – not just integration between existing algorithmic procedures written in conventional software languages…. [ibid, emphasis in original]
The key to making processes manageable under this new scheme of BPMS is to make the software applications “process-aware” as opposed to being “data-aware.” This traditional focus on data “limits the ability of the software engineer to provide tools to the supply chain manager to help manage real businesses.” [ibid] The new software engineer needs to incorporate the concepts of pi-calculus to achieve this process-awareness for their applications.
Business Process Management Initiative (BPMI)
The BPMI is involved in activities to develop technologies that support the enterprise in becoming “process-oriented.” BPMI.org was started by Intalio, Inc. in August 2000.
BPMI.org (the Business Process Management Initiative) is a non-profit corporation that empowers companies of all sizes, across all industries, to develop and operate business processes that span multiple applications and business partners, behind the firewall and over the Internet. The Initiative's mission is to promote and develop the use of Business Process Management (BPM) through the establishment of standards for process design, deployment, execution, maintenance, and optimization. BPMI.org develops open specifications, assists IT vendors for marketing their implementations, and supports businesses for using Business Process Management technologies. [bpmi.org]
BPML and BPQL are two open standards developed by BPMI that will enable the management of e-business processes using a Business Process Management System (BPMS). The scope of BPMI is shown in Figure 7.
EMBED MSPhotoEd.3
Figure 7 – Scope of BPMI
[BPML 101: Implementing the BPML Specification]
Business Process Modeling Language (BPML)
The Business Process Modeling Language (BPML) is a “meta-language for the modeling of business processes.” [bpmi.org] It is compared to XML which is a meta-language for the modeling of business data. “BPML provides an abstracted execution model for collaborative & transactional business processes based on the concept of a transactional finite-state machine.” [ibid]
The essential feature of BPML is that it has a common public interface and private implementations. The public interface is exposed to business partners to allow the exploitation of the strengths of each separate company in a larger collaborative effort. The “crown jewels” of the corporation are embedded in the private implementations within BPML. The public interface of BPML can be described as ebXML business processes or RosettaNet Partner Interface Processes, independently of their private implementations.
The BPML represents business processes as the “interleaving of control flow, data flow, and event flow, while adding orthogonal design capabilities for business rules, security roles, and transaction contexts.” [ibid] BPML offers explicit support for synchronous and asynchronous distributed transactions. There is provision for using it as an execution model. In other words, the BPML for the business is what “runs” the business while in its execution mode. This is what allows for its great flexibility in adapting to changing business situations.
The BPML was developed by the Business Process Management Initiative (BPMI) and is documented in a 96 page “proposed recommendation.” BPML has an XML syntax as shown in Figure 8.
Figure 8 – BPML code example
[BPML 101: Implementing the BPML Specification]
BPML has the following unique features [ibid]:
end-to-end process modeling
control-flow/data-flow separation
produce/consume messaging
dynamic control-flow
transparent persistence
embedded business rules
nested processes
distributed transactions
process-oriented exception handling
underlying mathematical model
Its underlying mathematical basis is pi-calculus. Pi-calculus is also used by Microsoft’s XLANG and has the following features:
consistency checking
deadlock detection
bottleneck detection
enable process optimization
Since BPML is executable, it bridges the gap between traditional process modeling and business execution. It can be used by both business analysts and software engineers. Since BPML is based on XML it is really not intended to be used directly as a “programming language.” Instead it is intended that human analysts would use the corresponding Business Process Modeling Notation (BPMN) which provides the easy-to-use front-end to facilitate human understanding. Since the BPMN is directly tied to the underlying BPMN, there is nothing lost in the translation from the model diagram to the process execution.
Business Process Modeling Notation (BPMN)
The Business Process Modeling Notation (BPMN) is what a business process analyst will use to design executable business processes. The BPMN directly translates into BMPL that is then executed using an execution engine. Figure 9 shows an example of how BPMN and BPML relate to each other.
Figure 9 – Mapping from BPMN to BPML
[BPML 101: Implementing the BPML Specification]
Figure 10 shows an example of a relatively complex business process that involves order management, inventory management, production management, and logistics management. Figure 11 shows a simple example of an e-mail voting process using BPMN.
Figure 10 – BPMN example
[BPML 101: Implementing the BPML Specification]
Figure 11 – E-Mail Voting Process in BPMN Style
[BPMN Specification]
Business Process Query Language (BPQL)
The BPQL specification is still under development and is not available for public review yet. Therefore it is difficult to say much about it. However, here is what the BPMI webpage says about BPQL:
The Business Process Query Language (BPQL) is a management interface to a business process management infrastructure that includes a process execution facility (Process Server) and a process deployment facility (Process Repository). The BPQL interface to a Process Server enables business analysts to query the state and control the execution of process instances managed by the Process Server. This interface is based on the Simple Object Access Protocol (SOAP). The BPQL interface to a Process Repository enables business analysts to manage the deployment of process models managed by the Process Repository. This interface is based on the Distributed Authoring and Versioning Protocol (WebDAV). Process models managed by the Process Repository through the BPQL interface can be exposed as UDDI services for process registration, advertising, and discovery purposes. [bpmi.org]
Process Status Communication
Wf-XML from WfMC is another technology like BPQL that addresses the dynamic communication between processes. Why would a business want processes to communicate with each other? If a business has a large process that consists of Web Services from different organizations, decision makers may want to know how far along the process has progressed towards its expected outcome. The BPQL can be used to make this query of an on-going process. The Web Services themselves can use BPQL to query the status of other Web Services. Process metrics can be collected form various instantiations of processes to determine which process is working more efficiently. Process improvement initiatives can use these metrics to identify areas for improvement or when to shut down obsolete processes. The “business intelligence” gathered using BPQL can be used to dynamically manage the enterprise in a matter of hours compared to the old way which could takes weeks or months.
A Case Study using BPML
In 2001, the Software Engineering Center of the Federal CIO Council sponsored several pilot projects in e-government. E-government is the public sector equivalent of e-business. Government business processes are as complex and as diverse as corporate processes and for the most part, what is true for e-business holds true for e-government. In the area of process modeling, there are no significant differences. Using an e-government example allows us to get access to more detail than might be available for a real world e-business case.
One of the pilot programs involved the development of a Federal Grants Architecture. The federal government oversees the annual distribution of billions of dollars of grants to universities, foundations, corporations, and individuals. This oversight is distributed throughout dozens of federal agencies and departments. Each organization has its own unique procedures for the application, awarding, tracking, and payment of grants. This duplication of function makes the system confusing and wasteful. The Federal Grants Architecture is an attempt to create an e-government solution that standardizes and streamlines the management of federal grants.
The MITRE Corporation developed a Federal Grants Pilot Architecture using DoD’s C4ISR Architecture Framework. MITRE did not produce any process models for this architecture. Instead, they chose to do activity modeling using IDEF0. As discussed in the section on IDEF, IDEF0 models are very similar to process models. They show tasks and task sequences, but they do not show logic. Figure 12 shows the activity hierarchy created by MITRE.
Figure 12 – Federal Grants Activity Hierarchy Chart (MITRE 2001)
Figure 13 – Federal Grants Activity Diagram (MITRE 2001)
BPMN Representation
Modeling this system in BPMN is not a straightforward activity. The modeler must make many decisions, such as what level of detail to show on a given chart, what pools and lanes to create, how to lay out the individual components. This is a diagram of the overall process of grant administration. Additional details for sub-processes will be provided in additional diagrams. Note that the Federal Commons, as envisaged by MITRE, does not provide much functionality.
Figure 14 – Federal Grants Activity Modeled Using BPMN (top level) (MITRE 2001)
A more interesting and arguably sounder architecture would be for the Federal Commons to be the sole interface of the public to the Grants process. The Commons could communicate via Web Services to FedBizOpps, the Grant Administrators, and the Payment Agents.
BPEL4WS
Probably the biggest contender to BPML for the crown of Web Services Choreography Language is BPEL4WS. Its heavyweight backing from IBM and Microsoft, give it an excellent chance of success.
Web services by themselves just perform atomic actions. They take in a group of inputs and provide some output. In order to have Web Services cooperate to provide a greater degree of service, there needs to be a means of specifying the interaction of cooperating services. BPEL4WS provides this means. It specifies the order in which the web services will be invoked. It provides a mechanism for recovering from faults. It provides consistency and reliability for Web service applications [Leymann, Roller].
BPEL4WS is based on XML. A business process, adequately described in BPEL, is executable by a BPEL engine, just like a process modeled in BPML is executable by a BPML engine. A process defined in BPEL can include Web services from partners that do not use BPEL.
Figure 15 is an example of BPEL from Leymann and Roller.
1