Activity
Software Layer
*
*
AnalyzeOrder
Ord23x24
Hardware Node 1
Hardware Node 2 Technical Infrastructure Layer
*
*
_ERP0092
Node 3 Node 4
Order_324 Analyze Order Service
Service
*
*
EAI Middleware
Ord23x24 Adapter
_ERP0092 Adapter
atomic services composite
service
Fig. 3.31. Detailed view on service-enabling, with atomic services and composed services
atomic services provided either by enterprise application integration middle- ware or by a service-enabled software system.
As the current realization of service-oriented architectures, Web services are discussed in Chapter 7, including service composition, which is the tech- nique to define and enact system workflows in service-oriented environments.
According to Wikipedia, flexibility refers to the “ability to easily bend an object or the ability to adapt to different circumstances.”
In todays dynamic market environments, “different circumstances” are induced by changes in the market environment of the company. Business pro- cesses are objects that need to adapt easily to changes. Since products that companies provide to the market are generated by business processes, flexible business processes are an important asset for coping with market changes in an effective manner.
Different aspects have to be taken into account when considering flexibil- ity. First of all, flexibility is provided by explicit representation of business processes, because adaptations of explicit, graphically specified business pro- cesses is much easier than adaptation of written organizational procedures or business policies buried in software code. Flexibility through explicit process representation will be discussed in Section 3.10.
Enactment platforms, such as workflow management systems, provide powerful mechanisms for enacting business processes in diverse technical and organizational environments. One area specific to human interaction work- flows is the assignment of knowledge workers to process activities. These or- ganizational aspects will be discussed in more detail in Section 3.10.
In typical workflow environments, such as system workflows and human interaction workflows, information systems are required for enacting workflow activities. The interfaces to these systems might be hardcoded in the adapters of the workflow management system. In dynamic software landscapes, where functionality is provided through standardized interfaces, the ability to change the binding of particular software to workflow activities is another source of flexibility. Flexibility at the operational level where interfacing to information systems is addressed is considered in Section 3.10.
Explicit Process Representations
Business process management systems are created to narrow the gap between business goals and their realization by means of information technology. The main way to provide this flexibility is based on explicit representations of business processes at different levels. While organizational business processes have a coarse-grained structure and are typically specified textually by forms, operational business processes consist of process activities, and execution con- straints that relate them.
Graphical notations, such as the ones discussed in Chapters 4 and 5, are well equipped to support communication about these operational business processes between different stakeholders involved in the design and realization of business processes.
Explicit process representations provide flexibility, since changes to the current process can be discussed and agreed upon by the different stakeholders involved in the design of the business process. In this context, flexibility is
achieved by changes at the business process model level that are immediately translated to actual business process instances.
Store Order Check Inventory
Receive Funds
Prepare
Invoice Ship Goods Prepare
Shipment
Send Invoice
Archive
Fig. 3.32. Sample business process model
A simple ordering process is shown in Figure 3.32, illustrating the concepts introduced. This process features a sequence of activities, where the first ac- tivity to store the order is preceded by a start event. After the order is stored, the inventory is checked. This version of the business process rules that the shipment is prepared only after the invoice is sent and the funds are received.
Finally, the goods are shipped and the process terminates.
Due to the somewhat cautious policy realized by the business process—
prepare shipment only after receiving the funds—business process instances based on this process model might suffer from long processing times, resulting in insufficient customer satisfaction.
In order to solve this problem, the process owner starts a review of this business process by inviting process participants and process consultants to a joint workshop. The business process model is used as a communication platform for these stakeholders at this workshop.
Discussing the problem of the process instances, the stakeholders find out that concurrency can be exploited within the process. If activities can be executed concurrently, their order of execution is irrelevant. For instance, the preparation of the invoice can be started before the shipment is handled. The new and improved version of the business process is shown in Figure 3.33.
Although in this example the deficits of the business process are obvious, the improvement of the process by introducing concurrency shows quite well how an explicit process model can foster response to change.
The translation of the business process model to the actual operational environment can be realized in different ways. If the business process is re- alized by a human interaction workflow, then the modified business process model needs to be deployed in the workflow management system. Deployment typically includes enrichment of the business process model with information to make the process executable.
In particular, there needs to be a translation from the graphical model to an executable format that is specified in a particular workflow language or—
in case the system workflow is realized in a service-oriented environment—
Store Order
Check Inventory
Ship Goods
Archive Prepare
Invoice
Receive Funds
Send Invoice Prepare Shipment
Fig. 3.33.Sample business process model, improved version with concurrency
in a service composition language. In any of these realizations, the explicit representation of business process models provides the flexibility to change the process and to finally enact the modified process.
New process instances would then follow the new, improved business process model. If, on the other hand, business processes are enacted without any system support, then the business process model is translated manually to a consistent set of procedures and policies that the knowledge workers need to follow.
The flexibility resulting from the explicit modelling of business processes is fundamental to business process management applications. In Section 7.2, looking at flexible workflow management, advanced flexibility properties will be discussed that allow us to change the structure of running workflow in- stances, providing an even higher degree of flexibility.
Organizational Modelling
The modelling of organizational aspects also provides flexibility in business process management. In this section, role resolution in an intra-company set- ting is discussed, in which different approaches are investigated to associate knowledge workers with business process activities. This section uses concepts introduced in Section 3.8 in the context of resource patterns.
In the case of human interaction workflows, the enactment environment of the business process has to take into account the organizational structure of the company that runs the business process. Flexibility in organizational mod- elling is achieved by assigning roles to process activities, and not to specific individuals.
By associating roles with activity models at design time and mapping roles to personnel that is skilled, competent, and available to perform the activity at run time, flexibility is improved, because changes in the personnel structure of the organization do not affect the business processes.
For instance, absent knowledge workers are not with associated with spe- cific activity instances, as are persons who are currently available. Thereby, the
dynamic aspect in the organization—knowledge workers might be temporar- ily absent or there might be changes in the work force—can be represented at the model level. Consequently, changes in the personnel are hidden from the process, as long as the roles defined in the model can actually be filled by persons in the organization.
Enter credit request
Analyze client
Finalize Decision Propose
Decision
Clerk Manager
Fig. 3.34.Simple business process model with role information
Consider a business process with a set of activities that need to be executed sequentially. An example of such a business process in a banking environment is in shown in Figure 3.34. These activities involve entering a credit request (Enter Credit Request), gathering information on the financial situation of the client (Analzye client), proposing a decision on the credit request, and reviewing and submitting the decision.
A subset of these activities is assigned the same role. In the example, a clerk is responsible for the first three activities, whereas the clerk’s boss finally decides and submits the decision. This situation can be represented in a business process model by associating the roleClerk and the roleBoss with their respective activities.
For each process instance by role resolution, the system offers these activi- ties to knowledge workers who can fulfil the respective role. Figure 3.35 shows a situation in which three different knowledge workers with the roleClerkare associated with the activity instances of that role.
While this role resolution is correct from a formal point of view, this situ- ation is undesirable in most cases because each clerk needs to understand the context of the case, which leads to longer process durations and potentially incorrect decisions.
In the example, the handover of work from Peter to Charles and from Charles to Anne leads to delays in process executions and should therefore be avoided. In addition, Charles needs to get familiar with the case entered by Peter, and Anne needs to get familiar with the case that Charles analyzed beforehand.
This figure also shows that at the business process instance level, knowl- edge workers are associated with activity instances, while at the business process model level, roles are associated with activity models.
To provide adequate support through role resolution, the business process model needs to contain the information that whoever conducted the first clerk
Enter c.r.
(r017, Miller, 10000)
Analyze client (r017, Miller)
Finalize Decision (r017, Miller) Propose
Decision (r017, Miller)
Charles Jane
Peter Anne
Clerk Manager
Fig. 3.35.Simple business process instance with knowledge workers associated with activities
Enter c.r.
(r017, Miller, 10000)
Analyze client (r017, Miller)
Finalize Decision (r017, Miller) Propose
Decision (r017, Miller)
Charles Jane
Peter Anne
Clerk Manager
Fig. 3.36.Simple business process instance with one knowledge worker associated with clerk activities
activity also has to conduct the other two clerk activities. In this case, all clerk activities are associated with Charles, who then can perform them much quicker than the three persons in the previous setting. This beneficial role resolution is shown in Figure 3.36. It is realized by the case handing resource pattern, discussed in Section 3.8.
This advanced role resolution works well if the same knowledge worker is available during the whole business process instance—or at least during the steps that the person conducts. But there are cases where a person has started on a process instance by conducting the first activity, but then becomes unavailable.
In this case, a decision needs to be made: either the process is delayed until the person returns to work or the case is transferred to another clerk.
This clerk needs to understand the overall context of the case before he can start processing the activity. This decision is influenced by multiple factors, such as the type of business process, the expected delay, and the effect of the delay, and therefore cannot be performed automatically in general.
Selection of Business Partners in Process Choreographies
The modelling of organizational aspects in business process management can be extended to business partners, which is important in the context of business-to-business processes.
Consider a business process choreography with multiple business partners, each of which plays a specific role in the choreography. If there is a roleShipper specified according to the requirements for shipping goods, it can be bound to specific enterprises that can perform the work. Additional flexibility is gained because the organizations participating in a choreography are not hardwired, but represented at the model level.
There are different options for selecting a particular shipper. The selection can be done before a particular process instance starts. This alternative is useful if sufficient information on the goods to be shipped is available before the process starts.
In scenarios where only during run time of the process instance are the goods and the sender and receiver determined, the dynamic selection of a shipper is useful. Based on the information on the shipment and on its addi- tional properties—such as dangerous goods—an appropriate shipper can be selected at run time.
Customer
Create Order
Request Supplier Info
Receive Supplier Info
Send Order
Receive Goods
Broker
Receive Request
Send Supplier
Info
Supplier-A
Receive Order
Send Goods Process
Order
Fig. 3.37.Business partner selected at run time, using a broker
An example involving a customer, a broker, and a set of suppliers is shown in Figure 3.37. In this example, a customer uses a broker to select a supplier.
Before the process choreography can be realized, the broker requires informa- tion on the suppliers available. This information is gathered by the broker in a separate process choreography, whose message flow is not shown in the figure.
The process choreography starts with the creating of an order by the cus- tomer. Then, the customer sends aRequest Supplier Info message to the bro- ker. The broker receives this message and uses local information to find the supplier most suitable for fulfilling the order. In theSend Supplier Info mes- sage, the broker informs the customer about this supplier.
The customer receives this message and uses the information received to send an order to the selected supplier, Supplier-A in this case. When the supplier has processed the order, the supplier sends the goods to the customer, and the process completes.
In the example shown, the selection is performed using a third party, the broker. While this is a valid option in scenarios where a broker has rich infor- mation on a set of business partners, the selection can also be done locally, i.e., without the involvement of a third party.
In this case, the actual selection can be performed as a manual activity, using information on suppliers available and capable of fulfilling the order.
Role resolution in this case is not performed by the business process man- agement system, but by a knowledge worker. This task also matches the service-oriented approach, where a service requestor (the knowledge worker) uses the broker to select from among a set of services (supplier services) the one that is suited best for the task at hand.
Standardized Software Interfaces
Standardized interfaces to existing software systems are another means of flexibility in business process management. A variety of techniques to specify software interfaces are known from software engineering and software architec- tures. It is a key concept to decouple the use of a software component from its implementation, i.e., to hide implementation details from usage information, following the information hiding principle.
In the context of business process management, standardized software in- terfaces are of crucial importance in system workflows, and also in human interaction workflows, since the overall process structure can be decoupled from the implementation of particular activities realized by software compo- nents.
A flexible association of process activities with software systems allows us to change the implementation of specific process activities without changing the overall business process. There are two variations: the software system realizing a particular activity can be defined at design time of the process or at run time of the process instances. The first variant is discussed in this section;
the dynamic binding of software services to activity instances is discussed in Section 7.4.
An example of changes in the implementation of business process activities is represented in Figure 3.38. In the original implementation, an inventory management system is used to realize the Check Inventory activity, and an order management system is used to realize theStore Order and thePrepare Invoice activity.
Fig. 3.38. Business process uses ERP systems functionality to realize process ac- tivities, while the business process remains unchanged
This situation is depicted in Figure 3.38 by gray shaded, dotted lines be- tween the business process activities and the information systems that realize them.
We assume that an ERP system is deployed to provide the functionality of the order management system and of the inventory management system in an integrated, robust, and scalable manner.
By standardized software interfaces, the business process activities can use the functionality of the new system without changing the business process.
This enhances the flexibility of the business process implementation, because the realization of particular process activities can be changed without modi- fying the business process.
This discussion describes an ideal setting, in which activity realizations can easily be exchanged. However, specific properties of legacy systems make the definition of clean, standardized interfaces cumbersome, because legacy systems offer their functionality typically by proprietary and often not well documented interfaces.
This technological problem is also addressed by enterprise application inte- gration systems, where adapter technology is in place to cope with this issue, as discussed in Chapter 2.
In addition, the granularity with which legacy systems provide functional- ity often does not match the granularity required by the business process. In particular, legacy systems often realize complex subprocesses rather than in- dividual activities in a business process. Sometimes, the processes realized by legacy systems and the modelled business processes are not immediately com- parable. These issues have to be taken into account when software interfaces to existing information systems are developed.
One option to solving this problem is developing software interfaces that make available the functionality provided by legacy systems with a granularity that allows reuse of functionality at a finer level of granularity. The granularity should match the granularity required at the business process level.
Depending on the legacy system, its complexity, software architecture, and documentation, as well as the availability of knowledgeable personnel, the required effort can be very high. If the need for finer-grained granularity and efficient reuse of functionality is sufficiently high, then partial or complete reimplementation can be an option.