Chapter 3. Business Process Management

Business process management (BPM) is a management discipline that focuses on the design of business processes and continuous improvement of the speed, cost, and quality of business operations. BPM emphasizes the documentation of repeatable business processes as the basis for analysis and improvement. This includes both manual and automated business processes.

Information technology provides the ability to model business processes for more precise specifications and the ability to automate processes for controlled execution. Though not all business processes are automated, the speed, reliability, and discipline of automated processes suggests that most business processes should be automated, if possible. In particular, the processes that drive the integration and high-level execution of service unit activities should be automated to support consistent and effective operations. Consequently, though the agile enterprise includes manual business processes, our emphasis here is on the automated business processes that, for the most part, drive the operation of an agile enterprise.

In this chapter, we see how BPM complements and extends SOA to enable the definition, integration, and continuous improvement of services.

SOA brings a fundamental pattern to the design of business processes. Business processes do not exist independent of service units, and processes are confined to management of activities within an associated service unit. Business processes specify how service units produce value. For readers who are familiar with object-oriented programming, service units are like objects and business processes are like methods.

This represents a fundamental change in process thinking: A process is initiated with a request to accomplish some objective. The process and its associated capability belong to a service unit, and the process defines how a capability is applied to achieve that objective. Thus when a customer submits an order, order processing is the responsibility of a service unit.

In a small business, a service unit's responsibilities might include picking the products from bins and packing them and shipping them, whereas billing would likely be performed as a request to a billing process that is the responsibility of another service unit—possibly an outside accounting service.

In a large enterprise, the order-processing service unit has a more limited role so that various order-processing responsibilities can be fulfilled by specialists and may occur at different locations. So the order-processing service unit validates the order and maintains the order information and status but delegates other activities, such as a customer credit check, order fulfillment, and billing. The order fulfillment service unit may check inventory, delegate production to replenish inventory, and delegate packaging and shipment when the products are available. Therefore, from a customer perspective, the order-processing service fulfills the order, ships it, and bills for it, but internally these activities are performed by several different service units.

Each service unit has its own processes by which it receives and processes requests. Each service unit is responsible for the results, the management of the capability that it owns, and the use of other service units for delegated capabilities. Each service unit is a customer of the service units to which it delegates.

As a result, SOA provides an architectural context for business processes that support sharing of optimized processes and the associated capabilities in multiple contexts, producing economies of scale and improved enterprise agility. New standards for business process modeling support this architecture and provide a level of abstraction that enables businesspeople to understand and manage their business processes, including both those that are performed by humans and those executed by computers.

The work of the enterprise is performed by service units and driven by processes. The fully agile enterprise has been achieved when a significant new business opportunity can be addressed by specification or adaptation of a few business processes that extend, engage, or complement existing business services to develop and deliver a new product or service to customers. The introduction of information technology has enabled the execution of business processes to be automated, increasing the efficiency of process coordination and control and adding the ability to more quickly define and change business processes.

Since business processes drive the performance of work and relationships between services, they also are a major factor in the optimization of business performance. They determine the coordination of tasks and thus address factors that are beyond the scope of control of individual task performers. As such, business processes provide an important management perspective on the speed, cost, and quality of enterprise operations as well as the contributions of individual performers.

Information technology can greatly improve process visibility. Business process models expose the design of business processes. Runtime monitoring tools enable workloads and performance to be observed in real time. Operating statistics and audit trails support analysis of processes for process improvement and accountability.

In this chapter we begin by discussing business process concepts and modeling tools. We then consider how processes are used to implement different operating modes that consequently affect the design of services. We then focus specifically on the impact of SOA and the nature of choreography for the specification of service unit interactions.

Business Process Concepts

A business process is an orderly execution of activities to achieve a desired business result in response to a request or event. A process defines the work to be done, who does the work, when the work is done, and why (that is, the process objective). A process starts when there is a need to achieve the process objective in a particular context. We discuss processes initiated by events in Chapter 8.

Figure 3.1 illustrates the definition of a simple order process. The purpose is to respond to customer orders. The circle on the left designates the starting point. The bold circle on the right designates the end. The rounded rectangles in the middle represent activities to be performed. An activity is an element of a business process that defines a unit of work to be done. It may be work done by machine or human or delegated to another process. The arrows designate the sequence in which the activities will occur. The process has three activities: Edit Order, Fulfill Order, and Bill Order. We have not determined in this diagram where the order comes from nor whether the activities are fully automated or performed by humans. We might later decide that the activities use other services to fulfill their responsibilities.

Figure 3.1. A Simple Order Process.

This process is performed for each customer order received. If multiple orders are received, each order follows the same process. We may refer to each of the executions of the process as a process execution (that is, an execution of the process definition). The customer order is an input to the process and defines the context in which the process operates. Typically, instead of referring to the process execution, we refer to the order that is being processed, so order 101 may be completed while order 102 is being filled and order 103 is being edited.

We have not indicated any consideration of the management of resources to process these orders. It could be that each activity is performed by a single person, and thus orders are processed by each activity, one at a time. It could be that due to the cost of getting the orders from the Edit Order activity to the Fill Order activity, the orders are collected in batches. On the other hand, it could be that orders move through the activities, independently, as they are received. Such issues are considered in the implementation of the process based on the technology involved, the resources and optimization of timeliness, cost, and quality. We have not defined the technology used to implement this process; it could be electronic or it could be performed solely by people working with paper orders and voice communications and carrying the orders from one desk to another.

We have also not indicated what happens if the process cannot proceed as expected. For example, the order may have errors that must be corrected before it can be filled, or there could be insufficient inventory to fill the order. These issues must be addressed as the process is developed in greater detail.

Process Context

In Figure 3.1, the order defines the process context—who it is for, the products being ordered, data about the quantities, and prices. Though the process definition describes who, what, when, and why in general terms, the order contains specific data provided by the requester that further defines what is to be accomplished. We may think of this as a document with fields containing the appropriate data. The document has an identifier—for example, the order number—that can be used to refer to the request and the state of the activities performing the request.

As the order is processed, additional data may be accumulated about the manner in which it is processed. For example, there may be a translation of the customer requirements to the actual parts that satisfy the requirement, or there may be a reference to the storage bin from which a part is to be pulled. Such information may become part of the process context—that is, relevant information about the processing of each particular order.

Some of the context data is important for processing the order but is of no interest to the requester. However, the data that come with the order and the data returned to the requester must be meaningful to that requester. These data should be described by a shared data model so that there is no confusion about their meaning. Within an enterprise, these data also should be part of an enterprise logical data model so there is a common understanding of data exchanged even if a service unit implementation uses a different representation internally.

Roles

Processes don't actually do work; they direct the performance of work. To actually accomplish work, the process delegates responsibility to a person or team, to a computer application (for recordkeeping or computations), to a machine (for example, a manufacturing cell controller), or to another service unit that defines how the work is done in greater detail.

To delegate work, a process definition specifies a “role” for the performer. A role is the specification of a relationship that defines expectations, the capability required, and other qualifications that ensure the performer's ability to meet the needs of the process. For some roles, particularly where an internal, shared service is used, there may be only one candidate, but where people are the performers, there typically is more than one candidate. When the process is executed, the selection of performer may be further refined based on the specifications of the particular request.

Figure 3.2 depicts people assigned to roles (this is a non-standard notation for illustration purposes). This might be a process in a small enterprise where two people do the work of processing and filling orders. In this process the roles define the need for persons to do the work of editing and filling orders. There may be several people available to do this work, but the roles specify the qualifications of persons required to do the specific work.

Figure 3.2. Process with Human Roles.

For a particular order in a process execution, a particular person must be assigned to edit the order and a particular person must be assigned to fill the order. Typically, the need to fill a role is posted on work queues of qualified persons, and an available person accepts the assignment.

The Editor role qualifications might also be based on the context of the process execution such as the class of product being offered. So the qualifications might include a requirement that the performer be skilled in editing orders for the particular product group. The same concepts can apply when the performer is a computer application or another service unit. Different applications or specialized processes may be appropriate for editing different product groups.

Particularly where the performer is a human, we give the role a name; in our example, we might name the roles Editor and Filler. This is useful in dealing with humans as shorthand for describing an assignment. Where the performer is an application or another process, we don't necessarily assign a name to the role, because the selection may be predefined, so we just specify the participant (for example, the application or service).

Collaboration

Briefly, a collaboration is an interaction between peers to achieve a result with mutual benefit. We might describe the relationship between a business process and a person that fulfills a role as a collaboration, particularly if the person interacts with the process to perform multiple, related activities. It is more important to formalize the collaboration when the participants are not people but processes of other service units. In both these types of collaborative relationships, the service user's process specifies the role of a service provider and the service provider's process specifies the role of the service user. The collaboration specification defines the interactive relationship between these roles for exchange of information and delivery of value. The roles defined by the user and the provider may each define qualifications for the other participant.

Under some circumstances, the name of a role has additional importance within a single process. Suppose that the process in Figure 3.2 would be more efficient if both roles were performed by the same person for any particular order. We could specify this in the process definition by giving both roles the same name. So when the process executes, John Doe might be assigned as Editor in the first activity. When the process reaches the Fill Order activity, the performer role is specified again as Editor, and John Doe has already been assigned to that role for this process execution. As a result, John Doe is expected to perform the Fill Order activity as well.

John Doe may actually be working on several orders. Each of these orders is being directed by a separate execution of the Simple Order Process. When John is asked to fill an order that he edited earlier, he doesn't necessarily know which order he is now being directed to fill. The process context provides this information, specifically the order number. So John may have a paper file for each order, and when he's asked to fill an order, the order number directs him to the appropriate file. John's relationship with the process is no longer a request-response relationship that ends with completion of a specific activity, but rather we characterize it as a collaboration, a continuing interaction regarding a particular subject matter.

Applications and other processes may also engage in collaborative roles. Let's consider that the Simple Order Process is being used in a large company. The Edit Order and Fill Order activities each may be delegated to specialized service units that focus on particular product lines or geographical areas. The appropriate service unit for each activity can be selected based on request parameters and invoked when that activity is executed. Again, the same specialized service unit may edit the order and fill the order, so it interacts with both the Edit Order and Fill Order activities. The use of the specialized service unit is no longer a simple request-response; it has become a collaboration.

For further discussion of the nature of roles, see the discussion of choreography later in this chapter and role-based access control (RBAC) in Chapter 6.

Organizational Context

Processes not only direct the performance of work, they also provide the opportunity for control. Figure 3.3 illustrates an Expense Report Process whereby one of the activities is approval of an expense. This same process might be used throughout a large corporation. The Expense Approver role may be filled by many different managers. For a particular expense report, however, acceptable approvers are very limited because the Expense Approver role specification restricts approvers to people with a specific relationship to the expense submitter.

Figure 3.3. Expense Report Process.

For expense approval, as with many other approval actions, the appropriate approver is determined by reference to the organization structure. Generally, the preferred approver is the manager of the person reporting the expense. If that person is not available, the manager's manager may be the alternative approver. Furthermore, the amount of the expense may be a factor. Approval may be required by the manager, and if the manager does not have sufficient authority, the expense may be referred up the chain of command for approvals until it reaches a manager with sufficient authority.

Thus approval is most likely a subprocess or a separate service. Different kinds of approval may involve different approval processes. Approval for a capital expenditure may require review of the details of the proposal by another organization and review of budget considerations by yet another organization. The approval process is a critical aspect of accountability and control. We might define the approval process as a process of a shared approval service to implement consistent controls throughout the enterprise. In the case of the expense report, the expense submitter and approver are participants in the approval process, but they are most likely not employees of the service unit that owns the approval service.

Process Modeling

The design and refinement of business processes is fundamental to management of an enterprise. Managers should be able to participate in the design of processes and understand the operation of the business in terms of the process specifications. When something is late, a cost is excessive, or there are frequent defects in a product, a manager should be able to understand the source of the problem in terms of the processes and the service units responsible for those processes in order to ensure a prompt problem resolution.

Modeling Languages

Before computer-based modeling tools, managers and systems analysts would draw diagrams on paper with boxes and arrows to depict the flow of control or work products, or they would write “playscripts” expressing the sequence of “who does what” in a tabular structure. These models were cumbersome and inflexible.

Computer-based tools were developed to help design and manage these models. The computer can draw the boxes and arrows more quickly and precisely, the boxes and lines can easily be moved, and the computer can do some basic checks to see that the diagrams are consistent with process concepts.

These tools can provide specifications of processes that can be automated. Some tools provide high-level “business” views of processes. These high-level process models might be viewed as “requirements” for process automation specifications. Some tools are designed to specify process details, to resolve exceptions and abnormal terminations that must be precisely defined for automated processes.

Standards of the Object Management Group (OMG), an international standards organization, have been developed to provide robust modeling for business processes, including both those performed by humans and those that are automated. Business process modeling notation (BPMN) was developed to give businesspeople standard graphical modeling elements so that they could share and collaborate on business process diagrams.

The BPMN graphics have been implemented in many business process modeling systems (BPMS) for specification of automated processes. However, due to differences in interpretation and technical approaches along with proprietary extensions, BPMN diagrams are not entirely consistent from one tool to the next. Until recently, there was no standard for exchange of BPMN diagrams. XML Process Definition Language (XPDL) was developed by the Workflow Management Coalition for this purpose. However, though XPDL may repeat the same diagrams in the new tool, due to variations in interpretation of the graphics a process model transferred from one tool to another still may not produce the same runtime result.

The Business Process Definition Metamodel (BPDM) was developed by OMG as a computer-based representation of BPMN diagrams to provide a platform-independent modeling (PIM) language for business-level process modeling. The rigor of designing the computer language clarifies the meaning of BPMN graphics. Insights on modeling processes for SOA have made BPDM more robust than BPMN, particularly for reconciling an internal process with a specification for interaction with another process (that is, a choreography). Finally, BPDM supports XML for Metadata Interchange (XMI) a standard form of model exchange, so business process models can be exchanged between tools and interpreted consistently. At the time of this writing, an OMG initiative is under way to reconcile BPMN and BPDM to a single language specification, called Business Process Model and Notation (BPMN) 2.0, preserving the BPMN brand.

Some tools translate BPMN models to languages designed for automation. For example, Business Process Execution Language (BPEL) is an alternative language used for specification of automated processes. It is likely that tools relying on BPEL will be phased out in favor of tools that implement BPMN models more directly and display the processes in terms of BPMN graphics during actual execution. This will simplify BPMN application and will improve understanding and control of the business processes.

BPMN 2.0 will provide full representation and integration of choreography. Choreography provides a shared specification of the interaction between participants in a collaboration. BPEL and XPDL do not address choreography. There are currently two alternative choreography specification languages: Web Services Choreography Definition Language (WS-CDL) from the World Wide Web Consortium (W3C) and e-business Business Process (ebBP) from the Organization for Advancement of Structured Information Systems (OASIS). Both these languages are based on XML. It may be appropriate to transform the choreography specification of a BPMN model to a choreography specification in one of these languages for runtime specification of service interactions.

Process Modeling Notation

BPMN has been widely accepted as a business process modeling notation (that is, a form of expression) even though in practice there are some variations in the interpretation as well as some proprietary extensions. However, with the more robust capabilities developed through BPDM, it is unlikely that another standard graphical notation will emerge in the near future. The following subsections provide a brief presentation of BPMN that enables managers to participate in process design and understand the specification of processes that drive the enterprise.

Figure 3.4 provides examples of the use of some BPMN elements. Participants in the overall process are designated by the separated boxes (pools) with the names of the participants at the top. The focus of the diagram is on the process of the Seller. The Seller process (contained in the Seller pool) is started by a message from the Buyer. The Seller is partitioned into “lanes” representing different internal responsibilities. The Order Management organization (lane) edits the order, notifies the Buyer of acceptance or rejection, and obtains payment through the Biller after the order is shipped. The Warehouse (lane) fills and ships the order using the Carrier. Messages are exchanged between the Seller and the other participants. The Seller process ends if the order is rejected or after the Seller receives payment from the Biller.

Figure 3.4. Seller Internal Process.

Figure 3.4 indicates exchanges between participants that could be expressed in a choreography, but the sequence of exchange is defined by the internal process of the Seller, and a choreography would not expose that detail. In addition, a choreography would include the sequencing of exchanges of the Biller and Carrier with the Buyer along with the relationships of those exchanges with the Seller exchanges.

BPMN has 11 basic graphical shapes, as shown in Figure 3.5. The figure also shows examples of frequently used variations on the basic shapes. Each of these shapes and some of their variations are discussed briefly in the following sections.

Figure 3.5. BPMN Graphical Elements (Abbreviated).

Event

An event causes a process flow to start or stop. There are three basic types: a start event designated with a simple circle, an end event designated by a bold circle, and an intermediate event designated by a double circle. A default process start is an empty circle, and a default process end is an empty bold circle. Icons appearing within the circle define specialized types of events—for example, an envelope designates a message, a clock designates a timer, a lightning bolt designates an error. A message can start, delay, or end a process. A timer can start or delay a process. An error can interrupt or end a process. There are other less commonly occurring events.

Activity

An activity is where work is done. The default is a task, which denotes that there is no more detailed specification of the activity. A subprocess, designated with a plus sign (+) in a small box, indicates that the activity is performed by a more detailed process. The process may be embedded and the activity can be expanded to show the detail, or the subprocess can be independent, meaning that it exists outside the current process and may be shared with other processes. Other activity specializations represent activities with repeated or concurrent executions.

Gateway

A gateway is a point in the process where flows converge or diverge. The default gateway (empty diamond) is an exclusive or. It provides for inputs from alternative paths to proceed on a single output path. If there are multiple output paths, only one can become active as specified by conditions on the outgoing paths. The exclusive or may also be designated with an X in the box. An and gateway, on the other hand, requires all inputs (from concurrent paths) to be active before it proceeds, and multiple outputs proceed concurrently, creating parallel paths. It may be called a fork for multiple outputs or a join for multiple inputs. The and gateway is designated by a plus sign (+) in the box. There are other less frequently used gateway types designated with other icons.

Sequence Flow

The solid arrow designates the sequence of execution of activities, events, and gateways. The arrow enables the execution of a target activity, event, or gateway when the activity, event, or gateway at the start of the arrow is completed. Where there are alternative paths, as from an exclusive-or gateway, the default path may be designated by a hash mark across the arrow.

Message Flow

A message flow is designated by a dashed arrow. A message flow comes into or goes out of a business entity (that is, a pool, discussed in a moment). Messages may be exchanged between processes or between a process and another system. With BPDM, the agreed-upon specification of the sequence of message flows can be expressed in choreography.

Association

A document or other object may be associated with the process elements using a dashed line or arrow. The arrowhead is optional and may be used to indicate whether the object is an input or output to the associated process element.

Pool

A pool designates a business entity responsible for the process contained in the pool. Processes are bounded by the boundary of the pool. Actions that cross pool boundaries must be represented with message flows. In Figure 3.4, Buyer, Seller, Carrier, and Biller are pools because they represent independent organizations. The Buyer, Carrier, and Biller pools are shown as empty because the focus of the diagram is on the Seller process, but the diagram implies that they have processes that send and receive messages, even though details of the processes are not known from the perspective of this diagram.

Lane

A lane is a segment of a pool that represents a organization or person within the pool organization that is responsible for the process elements contained in the lane. Lanes represent the roles of various participants in a process within a pool. In Figure 3.4, Order Management and Warehouse are lanes within the Seller pool. They represent roles within the Seller organization. The Seller has overall responsibility for the process. The Warehouse has responsibility for the activities in its lane—Fill Order and Ship Order—and Order Management has responsibility for the activities in its lane.

Data Object

A data object is a unit of information that may be produced or used by a process element within a pool.

Group

A group is a graphical representation of a shared characteristic of the process elements it contains. A group is not expected to have functional significance to the process flow but is used essentially for documentation.

Text Annotation

A text annotation is information added to a diagram to clarify the intent. It is documentation only. It is usually linked to a model element with an association line.

Attributes

BPMN also defines attributes associated with the graphical elements. These attributes are additional data that do not appear in the diagram but would typically be accessed in a BPMN tool by selecting the graphical element (for example, in a popup window).

Business Process Management Systems

BPMS manage the automation of business processes. Some of these have evolved from workflow management systems where the focus was replacement of paper flow for coordination of human activities. BPMS became the popular terminology as business process management (BPM) became a popular management discipline and automated processes became a more integral part of enterprise integration and electronic commerce.

Business processes should first be modeled at a business level where both manual and automated processes can be modeled without concern about the details of process execution in the particular implementation technology that is used. It is desirable to have a single modeling language to design business processes across the enterprise. A modeling tool that is BPMN compliant is recommended for this purpose. A tool that is also BPDM compliant supports robust modeling capabilities, where complementary executable processes (orchestration) and exchange processes (choreography) can be represented and where the models can be exchanged in a standard form between different modeling tools.

However, when processes are to be automated, it may be necessary to transform the process models to the language and design constraints of a particular BPMS product. Most enterprises already have one or more BPMS. Some BPMS will support BPMN and BPDM directly so that no transformation is necessary, and it will only be necessary to extend the process models to deal with all variations in the process that may result from unusual requests, violations of business rules, or error conditions. In other cases, the process models must be transformed to a proprietary language and may require adjustments to accommodate different design constraints imposed by the BPMS. With the development of BPDM, BPMS vendors are more likely than before to provide automated transformation capabilities from BPMN/BPDM models to their proprietary languages. There may still be manual involvement in design decisions required in the transformation as well as the development of additional process detail.

Where processes are not already automated or systems are being replaced, a BPMS should be selected that not only minimizes the work of transformation but also provides additional capabilities that improve the ability to analyze and improve business operations and to rapidly implement significant business changes. The following list highlights some important capabilities:

• Active processes can be displayed in a form equivalent to the models developed at a business level for monitoring current activities.
• A specific process execution (for example, the process for a particular customer order) can be examined and modified for that order, online if necessary, to resolve a problem.
• Statistics on process execution can be captured for process monitoring and analyzed to identify delays, bottlenecks, and possible sources of defects.
• Limits can be set on the duration of specific processes or activities to raise alarms when individual process executions are delayed.
• Process execution can be simulated using statistics derived from actual operations and assigned parameters, to evaluate problems or alternative process designs.
• Complex decisions should be implemented as rules (for example, order editing or claims processing). These rules may be incorporated directly into the BPMS, or a rules engine product may be invoked at points in the process where such decisions are made.

The BPMS marketplace is continuing to evolve as a result of emphasis on BPM, the development of standards, the need for integration of processes that span the enterprise, and the implementation of SOA.

Design Objectives

As an enterprise moves toward an implementation of SOA, business processes are analyzed, formalized, and redesigned. In addition to the design objectives specific to particular business activities, general process design objectives should be considered. Examples of process design objectives are as follows:

• Process visibility. Business processes should not be embedded in application code but should be expressed and deployed in a form consistent with the business process models that are meaningful to the businesspeople that own and use the business processes. The BPMS should expose the status of executing processes in terms of the processes as modeled.
• Minimum coupling. The purpose of a process should be clearly defined and should minimize dependencies on other processes, such as shared data or complex message exchanges.
• Separation of duties. An action that could personally benefit a participant must be approved by an authorized person who does not have personal gain or other conflict of interest associated with the action.
• Service boundaries. A business process must be owned by the service unit responsible for capabilities the process applies, and the process must begin and end within the service unit. The process may use other, shared, external services through defined interfaces, but the owner remains responsible for the overall result.
• Continuity of roles. A business process should minimize the transfer of responsibility among people within the same service unit, to reduce individual orientation overhead and improve accountability for results.
• Participant discretion. Actions delegated to human participants should avoid unnecessary limitations on discretion to enable the individual to optimize his or her performance and deal with circumstances that cannot be anticipated in the design of the process.
• Accountability. Individuals and external entities (for example, business partners) must be accountable for the actions they take and the data they provide when supporting or participating in a business process through electronic signatures.
• Request-response structure. In general, interactions between processes should be based on initiation by a request, with a response when the request has been satisfied or the action has been otherwise terminated. In this way the requestor retains responsibility and can take appropriate actions if the request is not satisfied or the response is not timely.
• Process-level integration. Integration of services and applications should occur only through the interactions of business processes. Service requests and responses are interactions between service requesters and service units and should be mediated by business processes that can be monitored and controlled by service unit personnel.

Operating Modes

Business processes can have different operating modes to achieve different kinds of business objectives. These modes affect the overall design of the process and may require specialized BPMS capabilities. Examples of a number of different process modes are discussed in the following sections.

Workflow

The traditional workflow mode moves a request through a predefined ordering of activities. This is typical of a paper-driven process in which an order moves from one activity to the next or often one desk to the next, where the necessary tasks are performed. Some workflow processes will provide for sequences of activities to occur in parallel.

Case Management

Case management represents a variation on the workflow mode. Here a case represents an ongoing, long-term obligation to manage services. The case manager may initiate a variety of processes (that is, services) as particular needs arise and is responsible for ensuring that the desired result is achieved in a timely manner. Typically, the process is tailored for the particular case and may be modified, ad hoc, as new requirements arise. Requests for services for a patient in a hospital might be handled in this way. The patient's hospital stay is an overall process that manages the specific services required for admission, diagnosis, treatment and discharge. The overall hospital-stay process is part of the inpatient service provided to the patient.

Job-Shop Mode

In a job-shop mode, a unique, one-time process may be defined for each incoming request. For example, let's say that a special machine tool is to be built, and sequences of tasks are defined for each part and for the final assembly. This may be viewed as a schedule of fine-grained services, each contributing their specialty as required to produce the desired, final result. Each of the services may be capable of a wide variety of outputs, defined by input specifications and confined to the associated resources and skills of that service.

Provisioning of some services in a telecommunications enterprise may take this form. In this case, the customer order may be translated to a schedule of installations and activations of service. Though the bulk of customer orders may be the same, the enterprise is capable of delivering a wide variety of service combinations.

This mode may be implemented using a rule-based system that configures a unique schedule based on requirements. This is distinguished from the rule-driven mode, discussed in a moment.

Production-Line Mode

In production-line mode, tasks are driven by the movement of the production line. The duration of each task is bounded by the length of production line allocated to the participant's station and the speed of the production line. Essentially, each station may be viewed as providing a service. Each unit of production may have specifications for the tasks to be performed at each station.

The ordering of units on the production line affects each participant's ability to complete his or her tasks since some units may require more or less work and some operations build on previous results. Production optimization is achieved by optimal “line balancing” of the order of production units so each operator can complete his or her work within his or her workstation.

Relay Mode

In relay mode, there is a defined sequence of services, but the overall process is driven by completion of processes. As each process completes, its work product is made available to the next service with no continuing responsibility. Typically, work products accumulate in buffers between services so that disruption of one service does not immediately affect continued operation of the other services. This mode is often used in combination with the production-line mode, where there are multiple production lines separated by staging areas.

There is an implicit process that drives the sequence of services, but there may be no organization responsible for managing the overall process to ensure timely completion of the sequence of services. Generally, progress will be reported to a monitoring activity that tracks completed orders at either the completion point or at relay points along the way. Orders not completed may be resolved by backtracking to identify the points of delay.

Rule-Driven Mode

Rule-driven processes use automated reasoning to determine the ad hoc ordering of activities based on requirements and circumstances encountered during the process. This might be viewed as managing a trip. As the traveler proceeds along the trip, different routes may be selected depending on road conditions, availability of overnight accommodations, and unforeseen problems.

A rule-driven process might be used where each customer order requires a unique product configuration that reflects consideration of dependencies between components such as configuration of a computer, an automobile, or an insurance policy. It also might be appropriate for field service operations where there may be a number of service requests outstanding and the work required for each may not be apparent until the technician arrives to diagnose the problem. In this case the focus of the process may be on managing the technician assignments to minimize travel time while ensuring a reasonably timely response to each service request.

Rule-driven processes are not common and require special tools, but they can be very effective where the operations are well defined but highly variable.

Development Projects

Development projects include product engineering and software development processes. These processes have the following characteristics: (1) each project has a distinct process, (2) they are typically long-running—months or sometimes years, (3) segments of the process may be iterative, converging on a solution, (4) specification changes may be common, resulting in rework, and (5) resource allocation is a significant management responsibility. Time and cost are subject to a number of factors, and completion is often driven by a target date. The process requires extensive planning and continuous monitoring and revision. The activities and processes are nonrepetitive so they are difficult to optimize.

The Systems Engineering Process Metamodel (SPEM) from OMG defines modeling elements for definition and management of such projects. Eclipse Process Framework (EPF), an open-source product from the Eclipse Foundation, is based on SPEM. These solutions support construction of projects from method libraries that specify common patterns. This is a still-evolving field.

Such processes apply to enterprise transformation initiatives. By structuring the enterprise as a composition of service units, SOA helps reduce the scope of transformation efforts and provides a structure, based on service units, to partition the work.

Product Configuration

Service units are expected to be shared by different value chains. The capability requirements may be the same, but the actual work done may differ. Product design often has a significant impact on process design. For example, in assembling a complex product, there is usually a logical order in which parts can be added. In some cases, there may also be collaborations with a customer or with other participants in the value chain where the collaboration requirements restrict the process design.

Differences in product configurations may be accommodated at three different levels: (1) the product components differ but operations are the same or equivalent, (2) each product has different requirements for the activities to be performed, or (3) different products or product categories require different processes. Some or all of these approaches may be required.

Where a single process is used for different products, the service unit accepts different request parameters and/or product specifications. The parameters and specifications may alter the process flow or the specifics of tasks performed. The objective of the service unit should be to support the implementation of product variations without tailoring processes for particular products.

The use of different processes for different products or product groups may be necessary, but it increases service unit complexity and reduces flexibility. Some of the operating modes discussed previously provide ways of addressing product diversity without defining specialized processes.

Note that service units may participate in different value chains and not all value chains produce end-customer products. Value chains for product development, support services, and executive staff services may also have variations that should be driven by request parameters and “product” specifications. Variation in purchase requests is a good example.

Generally, it is desirable for variations to be based on generic parameters either expressed in a service request or in referenced product specifications. Service parameters may be used to indicate differences in the context of the request, such as the originating country or language, whereas product differences should be expressed in parameters of referenced product specifications. The processes should be designed to operate correctly for all combinations of parameters unless some are defined as impossible or always unacceptable.

In all cases, agility is enhanced by the ability to change a value chain or create a new one by defining new parameter values and product specifications, but without changing the implementations of participating service units.

Processes in SOA

SOA brings new dimensions to the design, management, and technical support of business processes. The fundamental concepts of business processes have not changed, but SOA brings a discipline for composition, security, accountability, and sharing of capabilities. SOA brings the fundamental design principle that a process begins and ends within its associated service unit so it is under the control of the service unit manager. Capabilities delegated to other service units are engaged by requests to the other service units, invoking their internal processes.

While SOA defines an architecture for processes, processes define how services are performed and interact. A service unit is not implemented with a single process but is a bundle of processes that provide access to its capability in different ways, provide information to service users, and internally manage its capabilities. Processes support the exchange of messages between service units that is required for loose coupling and different modes of interaction. Finally, services sharing creates the need for control of access to processes. These concepts are discussed further in following sections.

Process-Driven Services

In general, the manner in which a service unit functions is driven by its business processes. These business processes, where appropriate, engage other services by initiating the business processes of the other service units. Consequently, the integration of service units is typically a relationship between business processes. Note that not all business processes are implemented with a BPMS—some may be manual and some may be embedded in applications.

These relationships are depicted in Figure 3.6. Service Unit A accepts two kinds of service requests (two arrows entering from the top). These invoke two different business processes, M and N. Process M has an activity that invokes an application, an activity that invokes another service, and an activity that invokes a shared subprocess. The activity that invokes another service has a role filled by that service (designated by the small, pentagon element). The shared subprocess is used by different processes within Service Unit A but is not shared outside Service Unit A, so it is not a service offered by Service Unit A. It is not selected from alternatives, so it is not filling a role that would be selected based on a role capability specification.

Figure 3.6. Processes Within Service Units.

Process N shares the subprocess with process M. It also has an activity that contains an embedded subprocess and another activity performed by a person. The embedded subprocess is essentially a bounded set of activities within Process N that supports treating those activities as a unit for such actions as termination and compensation (reversing the effects when a failure occurs). The person fills a role (again designated by the small pentagon element).

The key point of this diagram is to show the relationship of processes and service units. Service units contain one or more processes, and processes within service units may invoke other services, so the integration of service units occurs through processes. This is important for agility so that the use of service units can be defined and changed through the specification of processes.

Multiple Services of a Service Unit

The general concept of a service is commonly interpreted as accepting a request and providing a result. This is consistent with the concept of a process, in which a request initiates a process and a result is returned when the process is completed. However, a service unit provides a capability that may be offered in different ways; that is, requests may invoke different services. Different services initiate different processes within the service unit. So a service unit is not a single business process but rather a bundle of processes that provide access to a shared capability.

There may be one process that reflects the primary purpose of the service, but in many cases that is not enough, particularly if the requested process is long running or the same capability is used in different ways. The request requirements are more likely to change during a long-running process. For any requested service, the service user may want to change or cancel the request, or the user may want to obtain information on the request status. A service unit may offer the ability to obtain a price quote or forecast of delivery date prior to sending a request for its primary service. Complex processes are likely to involve specialized subprocesses within the service unit.

Services such as change, cancel, or status check, however, are dependent on a pending request. The initial request establishes a context and an identifier for reference to that context, such as an order number. Subsequent requests related to that original request contain the context identifier and are expected to perform appropriate actions in the identified context. The process maintains data regarding that context until the request is either completed or otherwise terminated. Afterward, historical data may be accessed using the same identifier.

A service may also accept different forms of request for different categories of customers or different product lines. Though this may increase the complexity of the service, it can improve the service's usability for service users. Different forms of request may also be used to enable a transition when technology or changing business requirements call for modification to the service interface. A new form of service request can be made available to transitioned service users while the old form of service request continues to be available for those service users who have not yet implemented the change. Internally to the service unit, it might be necessary to define different business processes for each of the input forms, but those may invoke shared internal business processes to drive the internal activities.

Loose Coupling

Loose coupling is commonly used to describe a store-and-forward, messaging linkage for integration where the relationship is defined by the messages exchanged. Service units generally interact through loose coupling to enable autonomy of participants. For a service unit to most effectively manage its resources and processes, it should not be driven immediately and directly by the processes of its users nor controlled by the processes of the services it uses. And from the service user's viewpoint, there may be delay between the receipt of a request and action taken on the request. Therefore, the service user should consider proceeding with related work rather than stopping to wait for the requested service to be completed. Loose coupling also enables a service user to abandon a request if there is not a timely response, although this assumes that actions can be taken to compensate for activities already completed.

Service users should anticipate that a service provider may encounter disruptions or delays and should design their operations to minimize the impact of these problems, depending, of course, on the level of service commitment of the service provider. In some cases, a service user may want to be prepared to switch to an alternative service provider to maintain desired levels of performance and continuous business operation.

Loose coupling also enables continuous improvement of a service. The expectations of service users should create minimal constraints on how the service is performed. The service provider should be able to design its internal processes with an understanding of the types of requests it will receive to support optimization, but it should not need to know how its users are performing their processes. The service provider should be able to continuously improve its processes without requiring changes by its users. It should also design its services to support future users addressing new business needs.

A higher degree of coupling implies limited autonomy. It may affect performance, quality, and flexibility of the user, the provider, or both. The following list describes aspects of a relationship that affect the degree of coupling:

• Serialization. Serialization refers to a relationship where the service must be completed before the user activity can proceed. This is often the case. The alternative is for the user to proceed and reconcile the result later. This may create a risk that the result of the service adversely affects the additional work done by the user, thus causing rework and possible defects.
• Collaboration. Collaboration occurs when the user and provider continue to interact during the performance of the service activity. This implies that some activities on each side are waiting for responses before proceeding and/or there may be a need for rework. Figure 3.7 depicts a collaboration relationship where the requesting process interacts with the requested service as the service is being performed. The dashed arrows represent messages exchanged between the processes executing in different organizations, depicted by pools. Changes to either the service requester or the service provider are constrained by the degree of coupling in this interaction. Such interactions may be specified with choreography, discussed later in the chapter.

  Figure 3.7. Collaboration Coupling.

  

• Shared work product. If the service user and service provider concurrently work on the same work product, there is a risk that there could be conflicting changes or competing access requirements that could delay progress. Certainly the processes of each are constrained by the need for cooperation and coordination.
• Shared resources. Shared resources could include equipment, people, or other facilities that must be scheduled or require coordinated use. It may be more difficult to ensure performance if a service unit does not control all its resources, but sharing can reduce costs through better utilization of the shared resource. Sharing is less likely to occur between a service user and service provider than is sharing between peer services that have similar capabilities or multiple executions of the same process. Requirements for liaison or progress review may involve sharing personnel and schedules for certain activities.

Transfer of Value

In Chapter 2, we discussed the relationship of a value chain to service units. The most straightforward transfer of value occurs when a service requester provides the required work product and materials with a request and the resulting work product is returned with the result. Then the value chain dependency corresponds to the request-response transfer.

However, service units often receive materials from sources other than a service requester—thus another dependency, and the resulting value or work product is often delivered to a recipient other than the service requester, in other words to a different destination than the service response—to satisfy another dependency. These transfers of value may take a variety of forms from a business process perspective. They are essentially exchanges with other service units.

The transfers could be implemented as request-response exchanges with the other services units. For example, a warranty repair service may receive a product with a request for repair and then after it is repaired give it to a shipping service to send it back to the customer. The response to the original request would confirm that the product was returned to the customer. To make the repair, the warranty repair service may diagnose a problem and then request replacement parts from other sources, potentially from a spare parts inventory activity or from an outside source. This is input of materials that did not come with the request but are required to comply with the request. These exchanges can be modeled with the business process modeling capabilities discussed earlier. Requests for parts can be assumed to obtain value to be added to the work product, but these are not explicitly different from the request for shipment except in the direction of movement of the physical work products.

On the other hand, a typical manufacturing operation does not use request-response exchanges for these transfers of value. Parts are produced in batches and delivered to designated assembly stations. The delivery of parts does not initiate a process to perform the next stage of production; the parts are available when the next stage of production occurs. A product being assembled is delivered to the next activity for subsequent work. This may or may not initiate a process in the next stage.

An operation performing assembly may have different instructions for assembling each unit of production, essentially a request for assembly, but probably not in the form of a typical service request. The completed assembly is then moved to the next station. These transfers of value are more like exchanges of business process events; the producer sends the work product to the next consumer.

In either case, these represent value chain links and service unit inputs and outputs. Each consumer depends on one or more producers to provide their work products before the consumer can proceed with its activity. As of this writing there is no standard way to represent these value transfers in a business process model.

A local convention can be adopted for designating messages or events that transfer input materials or output work products. These then provide the linkage from the business process models to the service unit inputs and outputs as well as the value chain dependencies. It may also be appropriate to distinguish the delivery of commodity materials. By viewing these as support activities rather than value chain activities, we avoid superfluous detail in the value chain model.

Security

Sharing services increases security risks. Services may be engaged by many more people from across the enterprise and possibly from business partners. Systems of many different organizations may submit requests, and a service unit may submit requests to services in many different organizations. Some of these other organizations may be external to the enterprise, and it is possible that service units that are internal today could be outsourced tomorrow.

A requester of a service as well as the provider should be authenticated to each other, their authorization to participate should be determined, data exchanged should have protection from disclosure or alteration, and accountability and control may require that electronic documents be signed. These issues are discussed in detail in Chapter 6. They affect both the requirements for BPMS support and the design of the processes.

Choreography

Some services are used through a simple request-and-response interchange. The service user requests information and the information is returned, and there is no need to specify the interaction further. However, many transactions, particularly in an e-business context, are more complex and take the form of a collaboration. Often the exchange involves negotiation and possibly the participation of multiple organizations such as for financing and transportation after a sale.

Sequence of Exchange

In these more complex exchanges, it is important that participants in the exchange agree on the sequence of exchange and possible alternative responses. A specification of the agreed-on sequence of exchanges is called a choreography. A choreography is an essential part of a business-to-business agreement between service users and service providers. Again, the parties may understand the default choreography to be a request followed by a response.

Figure 3.8 depicts a choreography for a simple order placement. The notation is compatible with BPMN but is not yet adopted as a standard. The choreography is a description of the interactive behavior of the participants. The interaction is a product of the internal operations of both parties. The choreography is not executed like a typical business process but instead defines an agreement between the parties.

Figure 3.8. Order Placement Choreography.

The choreography has a start and end the same as other processes. The rounded boxes designate interactions, that is, a message exchange as opposed to work being done. The solid arrows between interactions define the sequence of exchanges. A dashed line indicates the communication of a message from one participant to another. Note that BPMN also uses a dashed line or arrow to depict an association. Order Place and Order Taker are roles in the choreography representing participating entities. The choreography starts with a message containing an order from the Order Placer to the Order Taker. The Order Placer is the service user since it initiates the exchange and sets the context with the order content. The Order Taker receives the order and either accepts it or rejects it. The gateway (diamond-shaped) element in the choreography indicates alternative paths. The path taken is determined within the Order Taker's internal process that is private. The choreography only specifies that there are two possible responses to receipt of the order.

A choreography specification defines only the interactions between the parties and not how the parties perform their responsibilities, internally. Each party is free to define their internal processes as they like as long as they comply with the requirements established by the choreography. Of course, the content of the exchange or other agreements between the parties defines obligations of each as a result of the exchange, such as an obligation of the provider to deliver a product and the obligation of the requester to pay for it. This example choreography is quite trivial, but more complex choreographies may involve additional exchanges and participation of multiple parties that are coordinated to accomplish a shared result.

Complementary Internal Process

Figure 3.9 depicts an internal process of the Order Taker that supports the choreography of Figure 3.8.

Figure 3.9. Order Taker Process.

Within the Order Taker's internal process, the Order Placer is a role. Up to this point, roles have designated the need for a capability to meet a requirement. Here, the Order Taker is the service provider, and its process interacts with a service user that takes the role of Order Placer. Although the Order Placer has initiated the exchange, the Order Taker may still have restrictions on the qualifications of the entity that fills the Order Placer role. The Order Taker's process is aligned to the choreography, but its internal process is actually more complex involving two decisions and fulfillment and billing activities.

This use of role may seem inconsistent with the earlier discussion of a role as a specification for delegation. Essentially the Edit Order activity depends on receipt of a message from an external participant. There could be different external participants involved, such as a transportation carrier, and they would each be assigned different roles for their interactions with the process. These are peer relationships, but they depend on each other and define roles to specify their expectations and relationships with each other.

The Order Taker internal process contains a determination of whether the order specification and customer credit are valid. This process is where the decision is actually made, and it determines the response to be sent to the Order Placer. These decisions correspond to the alternative flows of the choreography.

Extended Choreography

The Order Placement choreography may reflect only part of an overall business transaction. The complete service of the Order Taker, assuming the order is accepted, is to fill and deliver the order and receive payment. The Order Placement choreography may be viewed as a predefined component of a more complex choreography that we might call the Purchase choreography, shown in Figure 3.10. In the Purchase choreography, the Order Placer role of the Order Placement Choreography will be associated with the Buyer role, and the Order Taker role will be associated with the Seller role.

Figure 3.10. Roles in a Complex Choreography.

The Purchase choreography may involve additional roles. The product may be delivered by a transportation carrier, and the payment could be handled as a credit sale where the payment is collected by a bank.

Figure 3.10 depicts the Purchase choreography that includes the aforementioned Order Placement choreography, along with two additional choreographies: Credit Sale Choreography and Shipment Choreography. The illustration does not show the individual exchanges, but it does show the relationships of the parties to the choreographies and to each other. The component choreographies are depicted as ovals between the participants because they describe the interactive relationships between the participants.

The arrow goes from the Buyer (the service user), which initiates an order to the Seller using the Purchase choreography. The Seller fills the order and engages the transportation carrier using the Shipment choreography. The transportation carrier engages the Buyer identified in the shipment order for delivery of the product, thus filling its role as Carrier in the original Purchase choreography. The Seller also contacts the Credit Billing service for payment. The Credit Billing service sends a bill to the Buyer identified in the credit payment transaction, performing its role as Biller in the original Purchase choreography.

The complex Purchase choreography of Figure 3.10 involves participants in four different roles. The Credit-Sale and Shipment choreographies are independent of the Purchase choreography. The Purchase choreography contains three different pair-wise relationships: the buyer-seller relationship, the biller-buyer relationship, and the carrier-buyer relationship. In each case, a service user initiates the interaction and defines the context for the exchange. When the Buyer is contacted by the Carrier and then the Biller, the context of these relationships is tied back to the original purchase order, based on the order number, so the Buyer knows the basis for delivery and billing.

The Purchase choreography defines how these four participants interact to accomplish a sale, delivery, and payment. Three of the roles, Seller, Carrier, and Biller, could be performed by the organization acting as Seller. The Purchase choreography allows the Seller, Carrier, and Biller to be separate business entities but does not require it. The delegation of responsibility from the Seller to the Carrier and the Biller are not visible in the Purchase choreography, because those relationships are established independently. The Seller could perform the Biller and Carrier capabilities internally and still comply with the Purchase choreography, but there might be no Credit Sale choreography or Shipment choreography.

The three choreographies define interactive relationships between independent business entities. If these were interactions between service units within an enterprise, the interactions would likely be simpler, and there might even be informal agreements on the protocol. However, in a e-business relationship there must be a more formal basis for the collaboration. The choreography provides a formal specification of what is exchanged and when. The content of the exchanges or other business commitments must establish the necessary obligations and trust to support the business transaction.

Also notice in Figure 3.10 that the Buyer requests goods with an order and receives goods delivered by the Carrier, so the Buyer experiences the satisfaction of the request. This is not a simple request-response interaction with the Seller because there are several interactions through the Purchase choreography. However, the Buyer receives closure.

The Seller may have a somewhat different relationship with the Carrier. In this case, the Seller could transfer the goods to the Carrier with a shipping order and consider the delivery done, trusting the Carrier to complete delivery to the Buyer. This is often the case with goods delivered by mail. For some goods, and for time-critical deliveries, however, buyers may expect the Seller to keep track of the shipment and take action if delivery is not completed within a reasonable time.

The Seller has yet another relationship with the Biller. Here the Seller may request and receive payment from the Biller before the Biller takes any action to receive payment from the Buyer. The Seller's requirement for payment is satisfied, but the Seller has passed the obligation of the Buyer and burden of collecting payment to the Biller. The Biller must request payment from the Buyer, so the Buyer responds to the Biller's request with a payment and satisfies the obligation held by the Biller.

The Purchase choreography along with the Credit Sale and Shipment choreographies describe a complex set of relationships where choreography is essential to achieve orderly interactions.

It is important to note that although the examples have involved business-to-business interactions, choreography applies to interactions within an enterprise as well. Two departments may have processes that involve interactions over a period of time as the work progresses.

As noted earlier, simple request-response interactions don't require explicit choreography, but conceptually they have a choreography as well. Essentially, every relationship between processes has a choreography, though it may not be explicit.

Often a process interacts with the same person several times, as defined by the role assignment. This sequence of interactions with the person can be described as a choreography, and this specification may be useful for understanding the responsibilities of the person assigned to the role. Often, what at first appears to be a simple request-response relationship evolves to a more complex interaction, particularly if the request is not immediately followed by the response.

Choreography essentially defines the restrictions participants must observe to achieve a mutually beneficial outcome from a relationship. In the next chapter we will discuss business rules that are used to specify other forms of restriction on business operations.