Enabling Flexible Integration of Business and Technology Using Service-based Processes Jelena Zdravkovic, University of Gävle/Royal Institute of Technology (KTH) Martin Henkel, Stockholm University/Royal Institute Of Technology (KTH) Sweden

Business and Technical Processes When designing executable enterprise processes, the alignment between business and technical requirements is still one of the main problems. From the business perspective, a process (i.e. business process ) is modelled to closely follow the business activities, events and message exchanges. From the technical perspective, the process design must be aligned with constraints of existing systems and implemented services.The final process ( technical process ) is influenced by both the business and technical perspectives. If there are no constraints from existing services, the technical process will directly correspond to (i.e. realize) the business process.

A Way to Align Business and Technology In the majority of cases, business and technical processes will differ. This misfit can result in a technical process that does not support all aspects of the business. For a system designer it is important to avoid service designs that may not be aligned with requirements of business processes. We have examined criteria that system designers should adhere to when designing services, to be able to construct a technical process that may realize a business process.

Case Study - Sandvik

Compared to the business process, the technical process must adhere to a set of system constraints: The customer profile is retrieved with two activities, as the customer contact and order history information are located in different ERP systems. The customer price cannot be concurrently obtained with the stock information, because the first activity requires the stock value as an input. Based on the customers service ability product information may be sent as a HTTP message or a FTP file. Storing and sending of product information may be managed by the internal systems only as a long-running transaction, because the services that implement the activities do not support the two-phase commit. Case Study - Sandvik

To make a structured examination of differences between bussiness and technical processes, we use a conceptual framework that identifies five aspects of process design - functional, behavioural, informational, organizational and transactional. When designing a business as well as a technical process, each of the process aspects must be considered. Based on the considerations of the design aspects, we have identified rules for transformations from business to technical processes. We have used those rules as a basis to define criteria for design of system services. Our Approach

The functionality of an activity is determined by the activity name, which describes the goal to be fulfilled, exchanged messages, and input and output constraints. In a business process, the functionality of activities is governed by business rules. When realizing the business process, the functionality of existing services will be the base for selecting the activities for inclusion in a technical process. Due to that, activities in the technical process may be designed to aggregate exchanged messages differently than business process activities, or they might specialize them, or impose different input/output constraints. Functional Aspect

FUNCTIONALAggregationSpecialisationConstraints Transformation rule Activities should be aggregated such that the message exchange of an activity in the technical process contributes to the message exchange of at most one activity in the business process. Activities in the technical process may specialize the activities in the business process as long as the goals of those business activities are fulfilled. The input constraints of activities in the technical process must be the same or weaker, while the output constraints must be the same or stronger. Service design Support finer granularity of activities, or support several levels of granularity. Example: ”Get customer profile” is realized with two activities “Get customer contact” and “Get customer orders”. Specialization to different systems should be offered. Example: “Send product information” is specialized into sending with both the FTP and HTTP protocols. Design services with minimal input constraints and maximal output constraints. Example: “Get customer price” should support required currencies.

The behavioural aspect addresses the process control flow. Three basic control flow construct are used to express the order of activities (i.e. sequence and parallel execution) and conditional branching. In a business process the use of the control flow constructs are governed by business rules, for example stating that the payment should be done before the product is delivered. When realising a business process as a technical process, existing services may impose different control flow due to existing dependencies and supported conditions. Behavioral Aspect

Behavioural Aspect BEHAVIOURALOrderingConditional Branching Transformation rule The ordering of activities in the technical process must be designed such to support the orders specified in the business process. This ensures that the required ordering of the business states is realized. Every branch in the business process corresponds to at least one branch in the technical process. Otherwise it is not possible which branch of the BP is executed. Service design Design services by avoiding ordering dependencies. Example: the customer- based product price cannot be obtained concurrently with the stock information, because the Order system requires the stock value to calculate the price. Design services to avoid implementation of conditional choices, and in addition, to support at least the choices discerned by the required cases.

The informational aspect is related to the concepts needed for representing process internal data and the data that the process exchanges with the external environment. In a business process the concepts are modelled to resemble business concepts such as customers, orders etc. In the technical process, the business concepts are represented by well-defined information structures, for example by using the XML Schema standard. Those structures might include some technical concepts such as system identifiers. Informational Aspect

INFORMATIONALInformation inclusion Transformation rule Business concepts must be included in the technical process. This requirement means that it should always be possible to trace information concepts in a business process to their equivalent concepts in the technical process. Service design Design services to support more business concepts than required. Example: the CRM system in Figure 1 should be designed to support broad customer information.

The organizational aspect concerns the responsibility for executing activities. When designing a business process the responsibility is assigned to business roles. In a realization of a business process, i.e. in the technical process, these roles have their correspondence in the responsibility to execute services. Organisational Aspect

ORGANISATIONALRole Mapping Transformation rule The activities in the technical process must be owned by, or under supervision of the parties that are responsible for the corresponding business activities. Service design Design services with well- described interface descriptions. These descriptions allow several parties to implement the same service, thereby enabling inclusion of new parties in the process when the business requires it.

The transactional aspect rules consistent execution of a set of activities. In the business processes, the loosely coupled process activities may have short or long duration, and thereby process transactions comply with two different models - the atomic transaction model or the long-running model. In the technical process, transactional properties of existing services might impose constraints for implementation of a particular transaction model. Transactional Aspect

TRANSACTIONALModel Mapping Transformation rule The activities in the technical process must support at least those transactional properties that are defined for the activities in the business process. Service design Design services to support both atomic and long-running models. Example: the business process requires that storing of the product information should not be done unless the information is sent successfully to the customer. In the technical process, the activities for sending of FTP/HTTP messages cannot be designed as atomic due to used non-transactional message protocols.

In this study we have discussed the gap between business processes and their realization in a technical system environment. With the Sandvik’s example, we have shown how existing services change realizations of business process. Based on the transformation rules that must be followed to successfully realize a business process, we defined criteria that system designers should adhere to when designing services. The notion of technical and business processes, along with the notion of the realization rules are a fundament for process designers to discuss and manage both business and technology. The abilities of the existing services to support realization of a business, is one of the major concerns in that context. Conclusion