Workflow Management Systems (WMS) and the next step in the development -Business Process Management Systems (BPMS)have their origins in the 90 th . In contrast to traditionally document or data centric ERP-Systems, their main focus is the control of Business Processes. Thus, they are more flexible when enterprises develop new ways of doing business. However, like ERP-Systems they are at the core of the enterprise and hardly to replace. Furthermore, a deep integration with other systems of the enterprise can be expected [1]. With the upcoming of Service Oriented Architectures, Cloud Computing, and Continuous Delivery there is a demand to replace legacy BPMS due to the high maintenance effort. In consequence, a BPMS migration has to be considered.
The aim of this work is to examine ways to predict the effort of product migrations form one BPM system to another. The respective literature offers a wide range of information about business process management, its value and critical success factors. Compared to this, publications towards the systems which implement a key element of BPM, the process automation, are rare. In this work, a systematic literature review is used in section 2 to identify the available approaches to analyse and compare BPM systems. The gathered information will be evaluated regarding its use to estimate the effort of BPM system migration projects in section 3. The scope is to provide an approach which supports the decision process while planning such a project and assessing alternatives.
This aim is limited to the evaluation of the effort of migration projects. Thus, the process of finding a suitable BPM product for the specific needs of a company is not the subject of matter. The assumption of this work is that the examined BPM system suits the requirement of a respective run-time scenario. The last section of this work sheds light on the validation of the proposed approach and provides an outlook.
So far, no work has been found that is directly dealing with the effort estimation regarding the migration of BPMS or WMS. However, having a reference for BPMS comparison could help to identify necessary tasks for the migration and thus to be able to find appropriate work packages. Each of these work packages can then be subject to effort estimation. The complexity of estimation is reduced by the divide-and-conquer principle. Since the technical aspects of migration are in focus, reference architectures for BPMS seem to be a good starting point.
A literature analysis has been conducted in order to find approaches for BPMS comparison. The systematic Literature Analysis (SLA) approach by Kitchenham [2] provided guidelines for this research. Two sources have been selected for SLA:
• BPMJ is published by Emerald Group Publishing since 1995 and aims to '[...] examine how a variety of business processes intrinsic to organizational efficiency and effectiveness are integrated and managed for competitive success.' [3] • Lustratus Research describes itself as '[...] a leading infrastructure software market analyst and consultancy firm' [4]. They provide different kinds of technical reports via their online store at www.lustratus.com. While BPMJ is seen as source for scientific research on the area, Lustratus Research is seen as a more industry oriented source in contrast.
Overall the literature basis of this SLA consisted of 515 papers derived from these sources. The next steps according to Kitchenham are population, intervention, and union followed by the paper selection. The initial population was done by using the following search term:
'Business Process Management Systems' OR 'BPMS' OR 'BPM suites' OR 'BPM solution' OR 'BPM offering' OR 'BPM product' The search string was applied to the title as well as to the abstract of the papers. 76 relevant papers have been identified. The intervention step is used in order to narrow down the selection of papers further on. Here the focus on BPMS comparison of the search was added. The following search term was used:
'compare' OR 'comparing' OR 'comparison' OR 'architecture' For the reasons given in the introduction of section 2, 'architecture' was chosen as a part of the search term. 29 relevant papers haven been identified in this step. The union step forms an intersection of the result sets from population and intervention. After this step 6 papers remained. Table 1 shows the process in an overview. The software application leg contains from top to bottom the blocks: (1) Software Application (2) Software Language (3) Software Notation and Software Grammar (4) Software Formalism, and spanning several layers (5) Technical Infrastructure. Fig. 1. BPMS Pyramid Architecture [5] Especially in the application leg of the pyramid architecture some of the blocks seem to be appropriate for BPMS comparison regarding BPMS migration. However, the architecture seems to be too coarse grained.
As mentioned above, this frame of reference is applied by Craggs in all four reports originating from Lustratus Research between 2009 and 2012. Craggs divides the frame of reference in three main areas (see figure 2):
(1) Functionality (2) Characteristics and (3) Solution extensions. Each area summarizes a set of key categories.
The Functionality area, contains the BPMS functionalities that are considered to be "standard". Thus, these describe the basic BPMS functionalities. It includes the core functionalities of Process Modelling, Execution and Monitoring. The Characteristics area aims at traditional software quality measures, representing non-functional requirements. However, there are also functionalities included. For example Import/Export, Versioning, and Governance provide means for a higher flexibility and efficiency in basic BPMS functionalities. An indirect influence on software quality is assumed here. Solution Extensions provide additional functionalities that are not considered as basic functionalities of a BPMS.
The framework of reference is more detailed compared to the pyramid architecture by Shaw et al. but some of the items especially in the characteristics area do not fit for the purpose of migration effort estimation. They are system inherent characteristics that should be evaluated during system selection before planning the technical implementation of a BPMS migration. Additionally, the mapping of the items to the areas changes over time as well as some the items themselves.
The discussion of the pyramid architecture and the frame of reference showed that both give general ideas how to compare BPMS. However, they do not fit for the task of migration effort estimation. Therefore, this section introduces a framework to compare BPMSs based on the results from the previous sections. The result is shown in figure 3.
The framework is mainly inspired by Lustratus' frame of reference, but it is based on a new structure with a different view on BPMS. The general idea is to divide all functionalities of BPMS in four logical components. In this context logical means that the individual characteristics are considered independently from the architecture of the tools that implement them. This allows analysing BPMS in more detail without increasing the complexity of the result by including irrelevant aspects of its structure. Figure 3 illustrates the four components, which are namely Design, Execution, Integration Infrastructure and Technical Infrastructure. These divide BPMS into three main functional areas that have been derived from the investigation of existing systems like TIBCO Active matrix. Design tools and activities can be examined mostly independent from Execution regarding methodology and architecture. Integration Infrastructure has been seen as an important separate component. Since processes run across functional areas, integration of specialized functional oriented information systems is a main task of BPMS. The Technical Infrastructure represents the common system requirements in order to run a certain BPMS. All components are seen under the umbrella of the Concept of Enactable Business Model. Here, an idea of the pyramid architecture has been adopted. The general question -What is included in the meta-model and what is not? -influences the complete BPMS functionality. For example TIBCO ActiveMatrix in comparison to TBCO iProcess adds organizational and inte-gration related aspects to the model.
The white boxes within the components of figure 3 represent key functionalities while relevant characteristics are displayed using green boxes. The idea behind this is to derive activities for migration from the functionalities and to derive cost drivers in the notion of Boehms work on CoCoMo [11] from the characteristics. The Technical Infrastructure is seen as a special case of a cost driver. The provision of the necessary infrastructure for a BPMS covers activities that are independent from the special task of BPMS implementation and migration. Furthermore, a majority of the costs stems from software licenses, hardware components etc.
Applying these general ideas for example to the Design component of the framework, there are five functionalities considered relevant for migration effort: (1) Process Modelling (2) Data Modelling (3) Form Design (4) Rule Definition (5) Simulation. The characteristics in green boxes can be applied to all these functionalities. Deployment is not considered because most of the characteristics are not applicable. The characteristics are directly inspired by Cragg's frame of reference. Redundant aspects like collaborative design and time-to-value are removed. Collaborative design is by definition based on versioning and the support of business users. Time-to-value is indirectly influenced by all characteristics and all green boxes in the Design component effect time-to-value.
Since this BPMS concept is based on the evaluation of only two approaches, further development steps are likely. However, the general structure allows flexibility regarding future additions and changes in functionalities and characteristics.
Based on the given frame for BPMS comparison, questions (see table 2) have been formulated in order to provide a guide for migration planning and effort estimation. Each question is assigned to a label for further identification purposes. In order to avoid complex answers, the expected answer types for all questions are given in the third column.
Tab. 3. The first four refer to the technical support of design information transfer between start and target system. As a result of answering these questions, one of three action scenarios (AS) can be identified: information transfer using export and import functionalities (AS1, QD1 true), information transfer possible using an adapter technology (AS2, QD1 false and QD2-4 true), information transfer requires manual recreation of the information objects in the target system(AS3, QD1false and one of QD2-4 false). The migration effort f(x) differs between the scenarios: f(AS1i) < f(AS2i) < f(AS3i); i ∈ {Process, Data, Form, Rule, Simulation}.
The remaining questions related to the design component (QD5 to QD9Form) in table 2 aim at estimating the effort in the AS3 situations, which means a transfer of information of an object by recreating it within the target system, e.g. remodelling a process model. Therefore, QD5 and QD6 refer to the notation of respective models. If the start and the target system use different notations for the same information type the migration requires the acquisition of know-how related to the notation of the target system. Commonly, this is possible by either hiring further experts or training the available staff. Furthermore, it can be assumed that knowledge about a standard notation can be acquired easier compared custom notations. This assumption is based on the fact that a larger number of experts for standard notations as well as trainings offerings are available on the market since standards are not limited to a single vendor. In consequence, different Knowledge Demands (KD) generating different effort are identified: the same notation in source and target system (KD1, QD5 true), Different notations and standard notation in target system (KD2, QD5 false and QD6 = 'standard'), Different notations and custom notation in target system (KD3, QD5 false and QD6='custom'). General assumptions regarding effort are: f(KD1i) < f(KD2i) < f(KD3i); i ∈ {Process, Data, Form, Rule, Simulation}. QD7 evaluates if there is support for non-technical users. Craggs [6] argues that nontechnical users such as business analysts provide the knowledge of the business case that should be automated by the BPMS. In AS3 scenarios this knowledge needs to be remodelled. Non-technical user interfaces, such as drag-and-drop capabilities, allow storing business information into a BPMS without expert knowledge about the used notation. This decreases the migration effort for two reasons: the number of required technical users can be minimized by including business analysts in the migration process and less know-how about the notation of the target is needed. This decreases the knowledge acquisition costs.
QD8 aims to include the influence of industry knowledge provided by the BPMS vendor on the migration effort. As mentioned in the application of the frame of reference by Lustratus [7], some vendors of BPMS offer industry knowledge in the form of templates, e.g. business process model templates for common business cases. The answer of QD8 should state how much information does not need to be recreated manually in the target system because of templates that cover this information. Since this statement needs to be relative to the overall size of the information of a certain migration project, it is given in percentages.
QD9Form assesses the existence of generators that can create forms automatically based on data objects. These forms still require customization to be used in production environments, but it can be assumed that form generators decrease the migration effort related to forms. The impact of form generators depends on their quality, thus some measure regarding the generator quality needs to be included in effort estimation.
QI aims at the Integration Infrastructure. QI refers to the available adapter components for the integration of existing information systems. The estimation is based on the ratio of existing adapters to the total number of needed adapters. There is a base effort for adapter configuration. However, effort increases if adapters need to be newly designed and implemented. BPMS support for this task may differ. The supported protocols of the Integration Infrastructure are not further considered since these are reflected in the available adapters and of course are important for strategic decisions.
Architecture is a relevant characteristic of the Technical Infrastructure component. The example of TIBCO iProcess and TIBCO ActiveMatrix BPM shows that two BPMSs can share design and integration tools. Thus, these BPMS parts do not need to be migrated. A big amount of migration effort can be avoided. QT1 to QT3 asses the possibility of shared BPMS components. The other characteristics of the Technical Infrastructure like hard and software requirements are not further considered regarding migration effort because this is not a special issue of BPMS but rather a standard problem of IT management.
However, even if core components are shared between BPMS, a migration remains necessary when the start and the target system do not share the same concept of an enactable business model. This essential aspect is covered in question QC. With the respect to a BPMS migration, different concepts of enactable business models means different demand of information for the start and the target BPMS (cf. section 2.2). Therefore, an additional effort needs to be considered that covers the acquisition and implementation of these business information.
The overall effort of a migration project is based on two main aspects: the effort for transferring the all business information from the start to the target system and the effort of integrating all the required business software into the target system. Moreover, overall effort of a migration project needs to include the installation of the design tools, the integration infrastructure and the tools related to Execution component such as the process engine, analysis tools and additionally business rules or event engine. Another aspect that has not been discussed in the context of this framework is the training effort for the different user groups. Only the costs of knowledge acquisition effort regarding different notations are covered. However, the technical users, the non-technical users and the end user need to become familiar with the respective user interfaces of the target system. In case certain components are shared the training effort for these components would be reduced.
After discussing the general influences on BPMS migration effort based on the provided framework, cost drivers need to be operationalized in order to provide metrics for a calculation of the estimated effort. For reasons of brevity not all of the provided calculation schema can be discussed in detail here. However, the complete set is depicted in the figures 4 and 5.
The total effort ftotal is a function of the information sets Xi (Data, Process, …) that need to be migrated between the BPMS, the vector of involved BPMS bv, the set of available adapters for information transfer A, and the number of users u (ut = technical users and unon-t = non-technical users like business analysts) involved.
f inf ormation calculates the effort of transferring all information of a certain type, which basically means that one of three sub-efforts needs to be determined. f import represents the effort of (AS1 i ), f indirect is related to the effort of (AS2 i ) and f recreate calculates the effort of (AS3 i ). For the AS1 i situations (which mean that matching import and export functionalities are provided by the start and the target systems) the effort can be identified by multiplying the size of a set of information with the sum of the average costs of exporting a single element of this set (ι ex ), copying it to the target system (ι cp ) and importing it (ι im ). In case the respective tools of both BPMS allow importing all elements of a certain information type at the same time, f import can be described as the sum effort of these single export(κ ex ), copy(κ cp ) and import(κ im ) processes.
fadapters calculates the effort for integration. This includes the effort for integration adapter development fdevelop. ftransfer calculates the effort for the manual transfer of information from source to target BPMS. This includes effort savings depending on the existence of templates. Additionally, in the case of forms information, the influence of form generators needs to be considered. fknowledge addresses the need of knowledge acquisition by the users involved in BPMS migration. As stated in the previous section, this effort depends on the existence of interfaces for non-technical users and of course on the number of users. The calculations are based on several values that need expert estimation from past experiences with BPMS maintenance, implementation and use. These values are treated as constants in the calculation model (see figure 5). A special function g(Q*,bv) operationalizes the answers to the questions. A special information type unknown has been added for the case that the concepts of the enactable business model differ.
The framework has been evaluated by using it for a migration scenario having TIBCO iProcess as source BPMS. TIBCO Active Matrix BPM and jBPM have been used as target systems. Migration was done for a small process. A comparison of effort estimated by the framework and of actual effort has been done. However, not all aspects and variables could be evaluated. For example, no training costs have been considered. At the end, the absolute differences of actual and estimated values have been in the range between 2 and 5 hours. Nevertheless, the total migration efforts were too small (13 hours and 9 hours) to allow any interpretation regarding the quality of the estimation. The framework however has been considered useful by the project responsible.
The framework for effort estimation has been proven generally applicable for its purpose based on a small case study evaluating a BPMS migration scenario. The framework is open for additional information sets. One set that needs to be added looking at the case study using TIBCO iProcess and Active Matrix BPM is organizational information. The comparison of BPMS based on the framework is bound to the purpose of migration. Other frameworks may fit better for example if the task of BPMS selection is considered. Effort is strictly related to the technical effort of migration. Maintenance is not being considered. The training costs are only calculated for the staff that is involved in migration. Since the BPMS in the case study did not share execution components (see QT3) this aspect has not been investigated further in the calculations. However, based on existing executable process model standards like BPEL or XPDL there may be the case of a shared execution engine of different BPMS. Overall, the framework provides guidelines and ideas for the estimation of BPS migration effort. However further steps of refinement and validation are necessary. Regarding experience, more functional dependencies may be derived for the data which has been considered as constant here.
Regarding validity of the presented results, there is a limitation due to the small number of publications found. Furthermore, the architecture of more BPMS should be compared to the presented framework and a bigger case study is suggested.