Objective Based Flexible Business Process Management Using the Map Model

INTRODUCTION

Business Process Integration and Management are important for transforming today’s business enterprises. Enterprises require end-to-end solutions in order to effectively link internal and external business applications, systems and staff so that they can respond with flexibility and speed to changing business conditions. The technologies for business integration have evolved over the last twenty years.

Most early integration solutions were focused on connecting systems. Vendors have provided various Enterprise Application Integration (EAI) adapters (as iWay) to help create links among different applications (e.g., SAP**, SQL Server and DB2*) (Zhu et al., 2004). Such solutions tend to establish relationships among systems in an ad hoc point-to-point manner. Usually, it gives complex interaction network among systems and business units and leads to problems in areas such as performance, maintenance, lack of scalability, extensibility and stability (Zhu et al., 2004).

The concept of an integration hub has been widely adopted by today’s leading business application integration solutions, such as IBM WebSphere* Business Integration (WBI), Microsoft BizTalk Server** and BEA Weblogic** Integrator (Zhu et al., 2004). These solutions connect different systems through a centralized integration engine, hub or platform, where the integration logic resides and executes. This kind of solutions is based on the Business Process (BP). A BP is a set of linked activities which collectively realize a business objective or policy goal, normally within the context of an organizational structure defining functional roles and relationships. As a result, creation, maintenance and changing of integration logic can be managed in a more efficient way.

However, the most challenging part that remains unsolved is how to plan, build, maintain and utilize the integration hub or platform for real flexible business cases, when highly predictable processes are subject to change when organizations adjust their activities in response to influences such as new legislation, innovations and competitive pressures (Mangan and Sadiq, 2002). Another pressure on the rigid process definition comes from the need for support of exceptional cases, in particular unforeseen scenarios that are not suitably addressed by the existing process definition. Moreover, it has been proven that customizing the BPs and updating them with the enterprise evolution are time consuming and expensive.

The differentiation of today’s business integration and management solutions is raised to the design and analysis of high-level flexible business strategies and processes and the way in which they can be enacted. From this perspective, an integration hub or platform is insufficient. In fact, an integration and management platform is required to guide the end-to-end solution lifecycle and to bring the missing flexibility to the processes.

Flexible business process management problem has been researched by various groups at different phases of the BP lifecycle. Bhat and Deshmukh (2005) and Jingsheng et al. (2008) attempt to address different requirements in BP modeling. Bhat and Deshmukh (2005) have studied different models for designing flexible business process and proposed a consensus of these models. They were very interested in the modularity aspect in the followed methods.

The map model has been largely used for modeling flexible Business process (Duan and Huadong, 2005; Nurcan and Edme, 2005; Regev and Wegmann, 2005). It seems to be appropriate for the flexible modeling of BP. The Map is also used for organization modeling into enterprises (Nurcan, 2004). An execution of a map representation of BP is proposed to construct a guidance system (Edme, 2004).

To meet this research, this study presents a promising approach that consists of regarding the flexible BP as a dynamic collection of cooperating processes defined at built time and which can be dynamically re-orchestrated according to the current context at execution time. To reach this definition, a flexible business process management platform for managing flexible BP during all its lifecycle is proposed. Based on the Map intentional modeling, it starts from the analysis phase that focuses on the BP objective and then proposes a modular design that refines the BP modeling from a macro model to a micro one. An execution engine for the map model is presented to allow the execution.

The proposal management was tested in Numidia Travel which is a travel agency. We studied the organizational objectives to emphasize the company’s BPs modeling based on the Map model.

BUSINESS PROCESS FLEXIBILITY

Flexibility is the capacity of making compromise between, first, satisfying rapidly and easily the business requirements in terms of adaptability when organizational, functional and/or operational changes occur; and second, keeping effectiveness (Regev and Wegmann, 2005).

The flexibility can be ensured by various manners and at different moments in the BP lifecycle. It can be required at built time or at run time:

In this latter, two main classes of flexibility are indexed:

Flexibility by adaptation is divided into two kinds (Duan and Huadong, 2005):

Differences between the two types of flexibility depend on the nature of the variability of the environment and the underlying reason. This can be classified in the following dimensions (Bhat and Deshmukh, 2005):

THE MAP MODEL

The map model is described by Nurcan and Hicheur (2005). Key concepts are presented here. The map model is an intentional representation model. It consists of a declarative and flexible orchestration of intentions and strategies.

Fig. 1:	Map meta-model (Nurcan, 2004)

The intentional view of the business represents the process from the point of view of its objectives disregarding the considerations of the operational level. The map model is intention-oriented. The BP model is described in term of intentions to be achieved and strategies to be followed. A business map constitutes a strategic business plan. It expresses the missions with regard to the business intentions or objectives they should achieve and the possible strategies. The map meta-model shown in Fig. 1 is a process model, in which non deterministic ordering of intentions and strategies has been included (Nurcan and Edme, 2005). Map consists of sections. A section is an aggregation of two types of intention, a source one and a target one and of a strategy. It can be represented as a triplet made up of these intentions and the strategy <Source intention Is, target intention It, strategy Sst>. Every section corresponds to a strategy which can be used to realize a target intention, when the source intention is reached.

The map is represented by a directed and labeled graph. The intentions are nodes and the strategies are edges. The directed aspect of the map translates the stream from the source intention to the target intention via the strategy. A section is so represented by two nodes connected by an oriented edge. An intention is an objective which can be achieved by the execution of one or more processes. Each map has two particular goals, start to begin and stop to finish the execution of the chart. A strategy is an approach, a manner or a means to carry out an intention.

Fig. 2:	Example of a map representation

Table 1:	List of sections

Table 2:	Interpretation of intentions

Table 3:	Interpretation of strategies

The map in Fig. 2 shows a process of selling a trip. Its goal is confirm booking. This map comprises a set of 5 intentions {start, Ii, In, Ik, stop} and a set of 7 strategies {S1starti, S2starti, S1ik, S2ik, Skn, Sin, Snstop} that compose 7 sections shown in Table 1.

The interpretation of each intention and each strategy is respectively shown in Table 2 and 3.

THE FLEXIBLE BUSINESS PROCESS MANAGEMENT

The main feature of this approach is that the map model is used as the key element to drive the construction of the flexible BP from the analysis phase down to the execution and monitoring ones. For each major phase of the solution lifecycle, guidelines are given to specify how to act according to the layered modeling concept.

The problem is that, nowadays, the organizations require periodic extensions and changes, for their functionalities, having to be realized and effectively installed within the shortest possible time. Consequently, the business practices are prone to continuous changes. That’s why BPM must focus on providing management for flexible BPs, in order to allow the companies to quickly adapt their processes.

The management of flexible BP that is proposed in this work is founded on two key principles.

A traditional BPM can define, execute, coordinate and maintain BPs. It manifests its capability through distributed applications and, into a single platform that manages the process lifecycle, starting from analysis and design, through deployment, execution, monitoring and optimization.

Analysis: At this phase, the company needs are analyzed in order to assemble the whole of its activities to get business processes.

Design: At this phase, the various BPs are designed and modeled in a chosen model.

Deployment: This phase supports the Binding and creation of explicit models clearly indicating BPs quoted in the phase of design.

Execution: This phase ensure the execution of BPs.

Monitoring and optimization: This phase follows BP execution and improves them relatively to the analysis of the preceding executions.

Each phase will be redefined to allow the management of flexible BP abstracted by its goal and represented using the map model.

The analysis phase: The analysis phase focuses on the ideas that it is important to start with a BP model which fully considers the objectives of the BP when defining a new one. The concept of objective or goal in a process is a stable character, that’s why it will be used like a key concept to more abstract the definition of a BP (Bentellis and Boufaida, 2007). This choice allows a direct mapping of the organizational objectives of the company to the appropriate BPs.

Business process management is requiring greater understanding of the process goals. Further, we assert that full acknowledgment of goal-oriented BPs leads to a more comprehensive design that better meets user requirements.

The aim of this analysis phase is to comprehensively map out the desired BP, defining goals and identifying issues.

The analysis starts by defining the organizational goals of the company that should be modeled and implemented. This allows to breaking down them into sub-goals, each one will deal with a BP.

The collection of goals is a complex activity, but there must be an agreement on the overall goals before starting analysis. The latter is comprehensively refined through the following stages:

The goal must be well defined and standardized to be uniformly expressed in order to facilitate the transition to the design phase. At the current phase, the goal has to be seen as a combination of a verb and an object of the verb, in addition, a possible indication on the approach to follow, the manner or the means to use to achieve it. The object can be a business document, or an item. Figure 3 shows clearly the standard structure that the expression of a goal must have at the end of this analysis phase.

Fig. 3:	Goal structure

Table 4:	Goals expression

In the case study of the travel agency Numidia Travel, an example of analysis result is, firstly, the identification of the organizational objective: creation of a new trip catalogue, then secondly, the identification of its sub-goals. These are:

According to the structuring shown in Fig. 3, goals can be expressed, like shown in Table 4.

The design phase: The analysis phase defines the goal a process must reach with all its possible sub-goals. The aim of the design phase is to specify and represent the possible plans that are capable of achieving this goal. The map model which is an intentional representation is chosen to capture the goal dimension in the process modeling.

The choice of the map model is very appropriate because it brings a degree of flexibility to the representation of the business process. Indeed the map does not only represent one way to be followed to achieve a goal but represents all the possible ways.

By analogy, to arrive at a place, one can ask for his way and get exactly the route to follow to arrive there, but if a map is given, he will get all the possible ways to arrive directly or indirectly. It clearly appears that the Map model guarantees flexibility by selection to the process which it represents.

The problem which can appear at this level is the combinative explosion that can result from representing all possible cases. To avoid this problem, we have proposed, by Bentellis and Boufaida (2008), a modular conception of the map. This method is used to capture the flexibility dimensions of a BP at it design phase. Its purpose is to provide a flexible modeling that allows companies to quickly adapt their BPs. It is inspired from modularity concept in the object oriented paradigm. It establishes a hierarchical construction of the BP modeling. This is ensured by a top-down method that starts from a macro description of the BP and then refines it. Thus, the map model is hierarchized and modeling task is spread on steps.

The first step gives a macro map modeling of a BP as a section with a global source intention, a global strategy and a global target intention <Is_global, It_global, S_global>.

The second step gives a more detailed representation. This latter is obtained by planning and orchestring sub-goals previously identified. Sub-goals will be connected by oriented edges which will bear a name. This name is, specifically, the name of the strategy which will make us pass from a sub-goal towards another. This step, is constructing the sections of a map. Sub-goals are giving source and target intentions, according to whether it is on start or end of the oriented edge. The strategy derives from the indication concept of the preceding phase. Each section located by a triplet < Is, It, S> can describe a BP part of the dynamic collection of cooperating BPs reused for constructing the BP modeling in progress.

Other steps will refine, in a recursive way, sections in the modeling, by giving a more finely representation on new Maps that model sub-processes of the constructed BP. Thus, the latter will not be represented, by a flat map, but by a hierarchy of maps that refine for giving the micro map modeling. Figure 4 shows a hierarchy of maps that represent a BP.

It is an established fact, from object oriented paradigm, that modularity is the key for managing complexity and providing flexibility. Modularity reduces interdependencies, facilitates maintenance and updates without affecting the whole system (Bhat and Deshmukh, 2005). In this study, the resulting BP modeling will be easy to maintain and to change. Changes can be applied to parts of the BP modeling without affecting the whole model. That will assist in analysis of the BP during process redesign and improvement.

Fig. 4:	Modular representation of a business process

Fig. 5:	Extracting intention and strategy from the goal structure

The development of the map will be made from the result of the analysis phase, which has allowed identifying the principal goals and the sub-goals which allow reaching them without specifying the plans. The general structure of the goal given in the earlier phase will be used to emphasize the intentions and the strategies for the map. The goal will be broken up to emphasize the target intention and the strategy. The target intention will include the verb and the object whereas the strategy will be the indication. The latter gives the approach, the manner or the means to use to reach the target intention. The source intention will express the pre-conditions of the BP in a macro form and will be given by the previous target intention in a micro one. The transition from the goal structure towards the identification of the target intentions and the strategies is shown by Fig. 5.

The proposed Map model does not use constraints because this will restrict the stream and consequently this will reduce flexibility. On the other hand we will define for each map an initial trace which will give the nominal scenario of execution under general terms.

Fig. 6:	Map modeling of the BP creation of new trip catalogue

This initial trace will be updated and will evolve by training through the various executions.

To add flexibility to the model we propose to use white intention and white strategy for which we can ignore the contents at design time and which can be full at execution time. This is very useful for the ill-defined processes.

A white strategy gives a triplet section <Is, It, Swhite>. This kind of section expresses a sub-goal in a BP for which the strategy is ignored at design time and it is let open to be fixed at run time. Several BPs will be candidates for the execution of this section.

A white source intention gives a triplet section <Iswhite, It, S>. This kind of section expresses a sub-goal in a BP for which the pre-conditions are not identified. The main indication is carried by the goal to reach which is the target intention. This latter will be operationally reached starting from various source intentions. The target intention can not be white.

The design of the example given earlier gives as a macro model the triplet:

This latter is refined in a map that gives all the possible orchestrations of the identified sub goals. This will be given by the map in Fig. 6. Interpretation of the various strategies is shown in Table 5.

Some sections in the related map, like the section <select destination, select hotel, according to the nature of the trip> can be refined in a map that gives all the possible sub-goals to achieve the goal select hotel.

The deployment phase: In the proposal, the BP modeled is directly interpreted and executed without passing by a deployment phase in order to avoid increasing rigidity at execution by a preliminary binding of the process.

Table 5:	Interpretation of strategies of the map in Fig. 6

Fig. 7:	Platform architecture

The execution phase: To carry out such a BP modeling, two solutions are possible:

We chose to propose a prototype of a platform for flexible business process management based on the map model. The main modules of the platform architecture are shown in Fig. 7.

The platform supports two principal functionalities: the definition of the process and its implementation and execution.

The definition of the BP passes by the following actions:

There is no dependence between the maps of the various processes. The only existing link is a reference link. A process refers, during its execution to another process; each one, being identified or more precisely abstracted by the triplet <Is, It, S>.

The definitions of all these processes are kept in the module maps memory. To each BP created, an initial trace is attached, which is nothing other than the nominal scenario giving its execution under the general terms. This trace is saved in the trace memory.

The execution of the BP begins with the invocation of a BP by its goal, which is the composition of its target intention with its strategy. The switch module then carries out a research at the maps memory for identifying all the processes presenting the same goal. Several sections can be candidates and when one section is selected. If an intention source or a strategy is white, several BPs sharing the same partial triplet can be candidates. It is necessary to proceed to a resolution of conflict at each level to arrive to decide which BP will be selected. The analyst can intervene to guide the stream. In this selection the switch module communicates with the maps memory via the supervisor and also with the trace memory which has the central role in this resolution. Once the process is selected, its map is charged for execution. At its termination, the stream passes to the next target intention in the original map. And so on, in a recursive way, the process will be carried out in a more flexible manner considering that the selection is done in real-time at run time. At the same time, all data concerning the process support will be transmitted to the generator of Code BPEL in order to generate the necessary code for starting up the process execution.

Modules of the architecture
The modeler: Assists the business expert and IT expert in the construction of the various maps representing a new BP. It transmits the maps read as well as the initial traces to the supervisor in order to save them in the appropriate modules.

The maps memory: it is a database that contains description of all BPs indexed or lately created in the company.

Fig. 8:	Class diagram of the database

The class diagram of UML that represents the schema of this database is shown in the Fig. 8. It expresses that a map is a set of sections. The section is a composition of a source intention, a target intention and a strategy. Each of them is identified in a single way. The triplet can be made operational by several BPs which share the same definition, but which run on various applications.

The switch: This module will resolve possible conflicts and direct the stream of execution at two levels. The first one comes from the fact that the map is an indeterminist graph; so at one source intentions various strategies are candidates for achieving various target intentions. This first conflict is resolved by analyst guidelines or by referring to the trace memory. At this level it is possible to utilize the expert business to help with shunting. When a triplet <Is, It, strategy> is selected, the second conflict comes from the fact that various BPs can share the same triplet <Is, It, strategy>. The resolution is basically founded on the analysis of the execution trace of BP maintained in the trace memory and on the context of execution.

The BPEL code generator: Generates the BPEL code for the invocation of the Bp to be executed.

The trace memory: It contains the execution traces of BPs and the resulting parameters analysis.

The executor: Receives the BPEL code then starts and supervises the execution. It updates and maintains information in the trace memory.

Supervisor: Supervises the course of operations and mainly it manages the maps memory by saving the different maps and answering the requests coming from of the switch module.

Table 6:	Evaluation of objective based flexible business process management

A prototype of an engine for executing and monitoring the BP Map modeling is under construction. JAVA is the implementing language. It is selected for its excellent portability; it is a multi-thread language, well adapted for applications requiring various connections. JAVA is used under Eclypse JEE. The map memory whose class diagram is shown in Fig. 8 is implemented in ORACLE and the JDBC tool is used for connectivity.

Monitoring and improvement: Based on the collection of the parameters resulting from the various executions and maintained in the trace memory, it makes a training to maintain in the trace of each BP the most suitable course. It will be presented in future study.

EVALUATION

The framework whose purpose is to evaluate methods’ capacity in designing flexible business processes proposed by (Daoudi and Nurcan, 2005) is used in the evaluation of the proposal management. A business process design and development method is described according to four different aspects: way of thinking, way of working, way of modelling and way of supporting. Each of these views is described using various criterions. In Table 6, the evaluation of the objective based flexible business process management is shown.