Friday, August 14, 2009

Selection of Business Partners in Process ChoreographiesThe modelling of organizational aspects in business process managementcan be extended to business partners, which is important in the context ofbusiness-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 role Shipperspecified according to the requirements for shipping goods, it can be bound tospecific enterprises that can perform the work. Additional flexibility is gainedbecause 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 selectioncan be done before a particular process instance starts. This alternative isuseful if sufficient information on the goods to be shipped is available beforethe process starts.In scenarios where only during run time of the process instance are thegoods and the sender and receiver determined, the dynamic selection of ashipper is useful. Based on the information on the shipment and on its additionalproperties—such as dangerous goods—an appropriate shipper can beselected at run time. Before the process choreography can be realized, the broker requires informationon the suppliers available. This information is gathered by the broker in aseparate process choreography, whose message flow is not shown in the figure.The process choreography starts with the creating of an order by the customer.Then, the customer sends a Request Supplier Info message to the broker.The broker receives this message and uses local information to find thesupplier most suitable for fulfilling the order. In the Send Supplier Info message,the broker informs the customer about this supplier.The customer receives this message and uses the information received tosend an order to the selected supplier, Supplier-A in this case. When thesupplier 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, thebroker. While this is a valid option in scenarios where a broker has rich informationon 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 managementsystem, but by a knowledge worker. This task also matches theservice-oriented approach, where a service requestor (the knowledge worker)uses the broker to select from among a set of services (supplier services) theone that is suited best for the task at hand.

Standardized Software Interfaces

Standardized interfaces to existing software systems are another means offlexibility in business process management. A variety of techniques to specifysoftware interfaces are known from software engineering and software architectures.It is a key concept to decouple the use of a software component from itsimplementation, i.e., to hide implementation details from usage information,following the information hiding principle.In the context of business process management, standardized software interfacesare of crucial importance in system workflows, and also in humaninteraction workflows, since the overall process structure can be decoupledfrom the implementation of particular activities realized by software components.A flexible association of process activities with software systems allows usto change the implementation of specific process activities without changingthe overall business process. There are two variations: the software systemrealizing a particular activity can be defined at design time of the process or atrun time of the process instances. We assume that an ERP system is deployed to provide the functionalityof the order management system and of the inventory management system inan integrated, robust, and scalable manner.By standardized software interfaces, the business process activities can usethe functionality of the new system without changing the business process.This enhances the flexibility of the business process implementation, becausethe realization of particular process activities can be changed without modifyingthe business process.This discussion describes an ideal setting, in which activity realizationscan easily be exchanged. However, specific properties of legacy systems makethe definition of clean, standardized interfaces cumbersome, because legacysystems offer their functionality typically by proprietary and often not welldocumented interfaces. In addition, the granularity with which legacy systems provide functionalityoften does not match the granularity required by the business process. Inparticular, legacy systems often realize complex subprocesses rather than individualactivities in a business process. Sometimes, the processes realized bylegacy systems and the modelled business processes are not immediately comparable.These issues have to be taken into account when software interfacesto existing information systems are developed.One option to solving this problem is developing software interfaces thatmake available the functionality provided by legacy systems with a granularitythat allows reuse of functionality at a finer level of granularity. The granularityshould 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 granularityand efficient reuse of functionality is sufficiently high, then partial or completereimplementation can be an option.