“retain familiar” allocation scheme is very similar to case handling; however, not all activity instances of a case are allocated to one specific knowledge worker, but rather only a subset of them.
History-Based Allocation
The idea of history-based allocation is that a person is allocated to an activity instance based on what this person worked on previously, i.e., on the history of the activity instance that he or she completed. This includes other business process instances. The goal is to allocate work to persons according to their personal experiences and expertise that is not represented in the role infor- mation. While this is not part of a role specification, this information needs to be represented in the business process management system so that it can decide on the allocation based on the history and personal experiences. This allocation scheme is useful for realizing a “one face to the customer” strategy, in which for each customer there is a dedicated individual responsible for all aspects of communication with it.
Organizational Allocation
If organizational allocation is used, not roles but the positions within the overall organization are used to allocate activity instances. For instance, to authorize expenditure, the manager of the organizational unit that requested the expenditure needs to approve. Depending on the particular language used to express organizational allocation, complex allocation rules can be realized, all of which take advantage of the organizational structure of the company.
specific activity, the respective application program is started, and the input data as specified in the process model is transferred to that application pro- gram. When the knowledge worker completes that activity, the output data generated is collected in the output parameters. These parameter values can then be stored in the application program. They can also be transferred by the business process management system to the next activity, as specified in the business process model.
Business process modelling aims at mapping high-level and domain-specific features of the application process; the technical details—the main compo- nents of the operational perspective—are taken into account in the configura- tion phase of the business process management lifecycle. The heterogeneous nature of information technology landscapes led to various kinds of interface definitions, most of which did not prove to be compatible. With the advent of service-oriented computing, the operational aspects of business processes are represented by services, providing the required uniformity.
This section discusses how activities realized by software functionality can be modelled. Conceptually, the same levels of abstraction apply to modelling the operational perspective as to modelling the other perspectives: at the metamodel level, interface definition languages reside. They describe specific interface definitions at the model level. At the instance level executing software code is categorized.
This approach fits the modelling of activity instances (and, therefore, also to process instances) well, because activity instances can be realized by exe- cuting software code. It also fits the organizational perspective in which per- sons reside at the instance level. Persons are—at least in human interaction workflows—responsible for performing activity instances.
In order to automatically invoke this software functionality, business process management systems require concepts and technology to access these systems. The operational perspective of business process modelling provides the information that equips a business process management system with in- formation required to invoke the functionality of external application systems.
The operational perspective includes the invocation environment of ap- plication programs, the definition of the input and output parameters of the application program, and their mapping to input and output parameters of business process activities. Therefore, functional requirements need to be de- tailed in order for us to evaluate whether a certain software system provides the required functionality in the context of a business process.
This perspective is not limited to functional requirements. Non-functional requirements also need to be represented, for instance, security properties and quality of service properties of the invoked applications or services, such as execution time and uptime constraints. In service-oriented architectures, these properties are typically specified in service-level agreements between collaborating business partners. These service-level agreements are part of a legal contract that the parties sign.
M2: Metamodel (Interface Definition Languages)
M1: Model (Interface Definitions)
M0: Instance (Executing Software providing
Defined Functionality) describes
describes
Notation (IDL specifications)
exp resse
s Instance-of
Instance-of
Fig. 3.29.MOF levels of operational perspective
Interface definition languages are used to specify the usage of procedures and functions, implemented by software system. They are also essential to connect software systems that have been developed independently from each other. Therefore, they are essential for middleware systems. Middleware based on service-oriented architectures play an increasingly important part as real- ization platforms for enacting business processes. The reminder of this section discusses aspects of service-oriented architectures that are relevant for busi- ness process management.
The creation of service wrappers that encapsulate business-relevant func- tionality of existing information systems is called service-enabling. While there are environments in which one service is realized by one information system, the typical case is where business functionality is realized by the interplay of multiple existing application systems, making service-enabling a costly and complex matter.
Service-enabling closes the gap between business process activities and the technical infrastructure for realizing them. This situation is depicted in Figure 3.30, where the business process activityAnalyzeOrderis realized by a service calledAnalyze Order Servicewhich combines the functionality of three underlying software systems that run on a technical infrastructure. While the definition and realization of theAnalyze Order Service is a complex and challenging task, this book assumes that dedicated business functionality is available and can be used to realize activities in business processes.
Service-oriented computing also facilitates the dynamic binding of services to particular business process activities. This situation is represented in the conceptual model of these layers by a many-to-many relationship between activity and service. This means that a given activity can be realized by mul- tiple services. Advanced concepts in service engineering facilitate the dynamic binding of a business process activity to a service at run time, providing the
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
*
*
Fig. 3.30.Service-enabling closes gap between technical infrastructure and business processes
potential to increase fault tolerance by selecting from a set of possible services a service that is currently operational.
A more detailed picture is provided in Figure 3.31, where enterprise appli- cation integration middleware is explicitly shown. Two legacy systems provide their functionality via enterprise application integration middleware. For each of these systems, an adapter is realized that hides the heterogeneity of the legacy systems from higher levels. But there can also be existing software systems that do not require the enterprise application integration middleware layer.
In the example shown in Figure 3.31, the software component Order 324 does not require the enterprise application integration middleware. This is the case if the system exposes an interface with a suitable and well-documented interface, such as a Web services interface.
Different types of services are also shown in Figure 3.31: Atomic services provided by individual legacy systems via service-enabling or via enterprise application integration middleware subsystems and composed services, which are built on top of atomic services.
These composed services provide a high-level abstraction layer to be used in the business process layer. In particular, theAnalyzeOrderbusiness process activity is realized by theAnalyze Order Service, a composed service that uses
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.