See discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/319833220 A MDE-based framework to improve the process management: The EMPOWER project Conference Paper · July 2017 DOI: 10.1109/INDIN.2017.8104832 CITATIONS 9 READS 118 5 authors, including: Some of the authors of this publication are also working on these related projects: POLOLAS- Guided solutions for the systematization of early quality assurance in software engineering View project Diseño de un marco de trabajo basado en herramientas para mejorar la gestión de guisas clínicas y procesos asistenciales (IDE4ICDS) (RTC-2016-5824-1) View project J.A. Garcia-Garcia Universidad de Sevilla 56 PUBLICATIONS395 CITATIONS SEE PROFILE J.G. Enríquez Universidad de Sevilla 40 PUBLICATIONS147 CITATIONS SEE PROFILE L. García-Borgoñón Universidad de Sevilla 19 PUBLICATIONS152 CITATIONS SEE PROFILE Carlos Arévalo Universidad de Sevilla 10 PUBLICATIONS49 CITATIONS SEE PROFILE All content following this page was uploaded by J.A. Garcia-Garcia on 16 September 2017. The user has requested enhancement of the downloaded file.
A MDE - based framework to improve the process management: The EMPOWER project J. A. Garc i a - Garc i a (1) , J.G. Enr i quez (1) , L. Gar ci a - Borgoñon (1) , C. Ar e valo (1) , E. Morillo 2 (1) Computer Languages and Systems Department. University of Seville. Av. Reina Merc edes s/n, 41012, Seville, Spain. { julian.garcia, jose.gonzalez, laura.garcia}@iwt2.org ,
[email protected], 2 Servinform, Seville, Spain emoril
[email protected] Abstract — Today’s world economic situation is ruled by issues such as reducing cost, improving quality, maximizing profit and improving and optimizing production processes at any kind of organization. In this context, BPM ( Business Processes Management ) can be an essential strategy. However, there are business situations where is necessary to define innovation solutions to apply BPM in a proper way (e.g., needs of interoperability between process modeling languages, mechanisms to ge nerate the executable model of the process maintaining the traceability with the definition model of the process, mechanisms to manage the measurement of process es from early stages, etc . ). This paper describes and analysis some of these situations and pro poses a framework based on MDE ( Model - Driven Engineering) t o support these needs . This MDE - based framework is also supported by the EMPOWER platform which has been developed in an innovation project carried out by Servinform Company and our research group ( IWT2 , University of Seville, Spain). This platform allows applying advanced MDE techniques to improve the application of BPM in business environments. Keywords — innovation project in enterprise, business processes management, model - driven paradigm I. I NTRO DUCTION Business Process Management (BPM) can be considered as a business strategy that helps improve productivity, reduce costs and increase the quality of performance of any organization [1] [2]. For this purpose, BPM includes methods, techniques and to ols to support the processes lifecycle [3] through a cycle of continuous improvement. In fact, some studies such as [4] conclude that the reasons for adopting BPM can be grouped into three main needs: understand and assimilate the intrinsic knowledge of bu siness processes (i.e., the organization’s know - how); supervise the staff’s performance during execution processes; and finally, monitor and measure processes. Controlling these needs improves ROI (Return on investment) parameter through reducing productio n costs [5]. Although BPM is a practice followed by a large number of companies in all areas of business [5], there are business situations where it is necessary to define innovation solutions to integrate BPM in a proper way. Some of these situations are : needs of interoperability among process modeling languages, mechanisms to generate the executable model of the process maintaining traceability with the definition model of the process, continuous improvement of BPM lifecycle and mechanisms to manage the measurement of the process from early stages, among other needs. They are justified in next sections but it is important to mention that they have been identified as real needs in companies and in specific scenarios by our research group, IWT2 (Web Engine ering and Early Testing 1 research group, University of Seville, Spain), thanks to our close relationship with important public and private national companies as well as our extensive experience in R&D projects. In order to support the previous mentioned n eeds, our research group carried out an innovation project together with Servinform Company 2 . This project was named EMPOWER and provided solutions based on the Model - Driven Engineering (MDE) paradigm [6] to improve the use of BPM. MDE is one of the most e ntrenched paradigms within software engineering area, which helps us define our approach and manage the conceptual complexity the process engineering area entails. This paper describes the EMPOWER platform w hich is the result of the mentioned project . For this purpose, it is organized as follows: after this introduction, Section 2 justifies the needs of the EMPOWER platform. Then, Section 3 and Section 4 describe the foundations of EMPOWER and its conceptual model, respectively. Finally, Section 5 and Sect ion 6 describe some successful cases and a set of conclusions , respectively . II. CONTEXT AND NEED At present, there is a great amount of proposals that provides languages to define processes [7]. In [7], authors identify large number of Process Modeling Langua ges (PMLs) what reflect on the fact that there is no ideal language for modeling processes. As concluded that paper [7], e ach language has its advantages and disadvantages depending on the requirements of the company at a specific time. In addition, no mod eling language is better than another at all times. The main challenge for an organization is to choose the best and most suitable PML to meet its requirements. This decision is very important and it should be critical because once a 1 IWT2 research gr oup. Website: www.iwt2.org 2 Servinform. Website: http://www.servinform.es/ 978-1-5386-0836-4/17/$31.00 ©2017 IEEE 553
specific PML is chosen , a very close dependency is created. In fact, if the company requires using another modeling language, it is necessary to migrate the notation of each process model, what is a complex and costly task in itself. Currently, there is no mechanism to work sim ultaneously with processes modeled with different PMLs where each of them is chosen as the most appropriate one to satisfy a specific client’s need. Below, we will describe five situations that demonstrate the existence of a real need to support interoper ability among PMLs, in order to clarify the problem or need of interoperability among them : SITUATION 1. Two departments of the same organization model their processes using different PMLs. However, both departments must start and collaborate together bec ause of changes in the organization's internal policies, internal restructuring or other reasons. In this situation, both departments should combine processes and they must finally interoperate jointly . SITUATION 2. This situation is related to the evoluti on and maintainability of an organization’s processes over time. In this case, it uses a specific PML to represent such processes. Nonetheless, this company decides to migrate processes to another PML that provides new features. This migration must be exec uted losing the smallest possible information and acting in the most automatic possible way . SITUATION 3. Several different companies decide to work and collaborate together to provide a third company with more competitive services. In this case, both com panies must merge and unify their own processes without incurring large expenses. This new situation requires interoperability among processes modeled with different PMLs. This situation is very common in the context of public administration, where several companies are temporarily united to offer a common and improved service to public work. SITUATION 4. This situation is related to the technological migration of the process execution engine. At present, there is a great variety of Business Process Manage ment Suites (BPMSs) and each one has advantages and disadvantages [8]. However, when a company chooses a specific process engine, strong coupling and dependency is produced. This relationship is very expensive to break, if the company decides to change its process engine due to economic, functional, strategic or commercial reasons, among others. Although this situation is not directly related to the interoperability of PMLs, it is a situation to be taken into account to improve process management and mainte nance . SITUATION 5. The previous situation is directly linked to the implementation of a BPM solution in an organization whose workflows are well implemented in Enterprise Management Systems (EMSs), such as ERP, CRM or ECM, for instance. This is a real n eed because over the last decade organizations use more and more different interconnected tools to run their business processes [9]. Consequently, it is important to propose mechanisms to integrate and orchestrate 3 these EMSs into BPMSs. They must also be non - intrusive mechanisms in order to reduce implementation costs and the probability of errors when integration layers among tools are encoded. The problems or needs priory mentioned about the interoperability between PMLs and process engines are solved b y the EMPOWER platform using the MDE paradigm. EMPOWER provides systematic and automatic mechanisms based on the MDE paradigm to break the relationship organization - PML - process engines , so as to facilitate use, interaction and interoperability of business processes modeled with diverse PMLs. These systematic mechanisms avoid inconsistencies and loss of information. III. THEORETICAL FOUNDATIONS SUPPORTED BY A BPM LIFECYCLE AND MDE BPM can be considered a process - oriented management strategy [1] with a clear mul tidisciplinary nature, as it can be applied to different contexts or domains and can be used by different user profiles [10]. This situation has conditioned the appearance of different views, definitions and perspectives of BPM lifecycles as well as their continuous improvement [1][3], which define a management model for continuous business implementations and incremental problem solving. However, these BPM lifecycles do not lend importance to the process orchestration that is key to implement a BPM soluti on, like the one we propose, within a consolidated organization since it probably has many software systems running. Therefore, it is necessary to support, in a theoretical way, process orchestration in continuous improvement BPM lifecycle. Considering th e aforementioned arguments, the EMPOWER platform is based on a BPM lifecycle whose four phases are supported by the MDE paradigm: (1) modeling, (2) execution and orchestration, (3) monitoring and (4) continuous improvement. Figure 1 conceptually shows this lifecycle. Below, these phases are further described . 1. MODELING PHASE . At this phase, process engineer is able to model and describe his/her business processes using the P M L s/he wants taking into account the requirements of his/her company and in a struct ured manner (i.e., identifying roles, activities, deliverables generated during the process, deliverables required, etc.). In addition, our framework provides model - driven mechanisms in this phase in order to translate between different P M L. 3 The process orchestration is understood in this paper as the centralized coordination of events that allows conditioning the evolution and execution of process flow. 554
For this purp ose, after conducting a detailed study on PML [7], we have defined a minimum process definition metamodel which guarantees the consistency and integrity of any process model. This metamodel is called INROMA [11] and comes in the form of a MOF - compliant me tamodel, but it also incorporates required attributes normalized according to ISO/IEC TR 24744 4 [12]. In addition, our framework includes bidirectional model - to - model (M2M) transformations between each PML metamodel supported by EMPOWER and INROMA. These t ransformations have been theoretically defined using QVT [13] and they are described in detail in [11]. Figure 2 . Bidirectional M2M transformations between PMLs Thus, if a process has been modeled conform to a metamodel A , it is possible to automatically obtain the same process conform to the metamodel B . using the INROMA metamodel as intermediate notation, and not directly between the specific metamodels. Figure 2 shows this idea. In this context, we achieve to increase the le vel 4 ISO/IEC TR 24744 presents guidelines to model consistency and uniformity when processes are defined. of abstraction in interoperability because ( i ) this one is always established from a semantic point of view and ( ii ) the number of metamodels that can be interoperated is as wide as desired. Thus, if it is necessary to include a new PML in our framewor k then the complexity increases linearly and not exponentially. This procedure is shown in Figure 1 and is closely related to the first three situations identified in the previous section. 2. EXECUTION AND ORCHESTRATION PHASE . Today, this phase is critical a nd essential because companies are being driven by the need to extensively automate their processes in order to execute and orchestrate them with EMS. At this phase, the process defined by the process engineer at previous phase must be executed and orchest rated in a process engine. For this purpose, the process engineer must specify execution parameters as well as parameters for the communication and integration with external systems. Nevertheless, most of these engines have inflexible PMLs, that is, these tools do not allow executing processes that have been defined conformed to other PML [8]. This problem involves high overheads in case of technological migration as mentioned in Section 2 (Situation 5). To solve this situation, our framework provides Mode l - Driven mechanisms to support this phase within this technological context. On the one hand, an execution and orchestration metamodel has been defined to support this phase. This execution metamodel also comes in the form of a MOF - compliant metamodel and it is compliance with ISO/IEC TR 24744. In addition, our execution and orchestration metamodel is systematically obtained using M2M transformation rules from the Figure 1 . Theoretical MDE - based framework of the EMPOWER platform . 555
INROMA metamodel. These rules have been also formalized using QVT. On the other hand, a system atic and automatic transformation protocol has been defined to generate executable code from the mentioned execution metamodel. This protocol is based on model - to - text (M2T) transformation rules [14] . The execution metamodel and our transformation protocol will not be explained here, since they are out of the scope of this paper and it would become too extensive. Nevertheless, both ones are explained in detail in [15]. In addition, a practical application of this protocol applied to eHealth environment can be read in [16]. Taking into account this procedure, the process engineer is able to specify execution and orchestration parameters. The process engineer should be able to instance and run processes into any process engine when the process execution contex t is defined. 3. MONITORING PHASE . Once deployed the process into the execution engine, it is time to evaluate its effectiveness. This evaluation provides a granular view of the overall productivity of each process and it is based on the definition of key p erformance indicators. In this case, our framework provides two types of mechanisms to support this phase. Firstly, INROMA includes concepts such as metric and indicator that help the process engineer measure processes. Indicators are defined during the modeling phase. Secondly , and after identifying each indicator, our framework defines M2T transformation rules to systematically generate code scripts which are de ployed into the EMPOWER platform and allow calculating each indicator . At present, this trans formation is not completely automatic because it is necessary to manually setup particular parameters from the process engine. 4. CONTINUOUS IMPROVEMENT PHASE . Finally, after evaluating processes performance (through assessment indicators and metrics), an o rganization should start an internal improvement process to achieve higher quality, efficiency, effectiveness and performance levels during processes execution. If necessary, the organization can iterate over our BPM lifecycle as many times as it is necess ary in order to achieve business goals. IV. THE EMPOWER PLATFORM The EMPOWER platform is the result of an innovation and R&D project carried out by Servinform in liaison with the IWT2 research group. This project was developed from 2014 to 2016 and was financ ed by CDTI 5 with a total budget of approximately 510,000 euros. The EMPOWER project aimed to innovate in the implantation of BPM and proposed a MDE - based technology solution to support the framework shown in Figure 1. For that purpose and in order to achie ve the previous goal, the EMPOWER platform provides five functional modules (Figure 3 ) as follows: 5 The Centre for the Development of Industrial Technology (CDTI) is a Public Business Entity, answering to the Ministry of Economy and Competitiveness, which foste rs technological development and innovation of Spanish companies. It is the entity that channels the funding and support applications for national and international R&D& I projects of Spanish companies The first one is the Process Definition & Traceability Module (M1) , which aims to support all PMLs included in EMPOWER and implement all M2M bidirectional t ransformation rules between these PMLs and INROMA. On the one hand, our platform includes a UML Profile of each PML and INROMA. These have been implemented in Enterprise Architect (EA) [19]. On the other hand, all M2M transformation rules have been coded a s a plugin into EA, what allow controlling and managing consistency and integrity of each process model generated by this functional module of EMPOWER. Finally, we obtain well - defined models. Figure 3 . Functional modules of EMP OWER The second module is the Execution & Orchestration Module (M2) , where the process is executed and orchestrated with other Information Systems of the Organization (ISO). To begin with, EMPOWER supports ( i ) the execution and orchestration metamodel usin g a UML Profile that is also deployed into EA and ( ii ) all M2M and M2T transformation rules coding a plugin into EA. This way, the process engineer is able firstly to define execution parameters of the process and secondly to generate executable code (base d on BPMN - XML) from the execution model. We generate BPMN - XML because most BPMSs support this standard format (this conclusion is stated in [8]). Once the executable version of the process is obtained, it is automatically deployed by this module of EMPOWER into its process execution engine based on BonitaOS [20]. This tool is chosen according to the requirements of the EMPOWER project and taking into account the characterization scheme proposed in [8], which was very useful. However, it is important to ment ion that our MDE - based framework is independent of the platform. 556
Therefore, other process engines could be chosen within great efforts. Our framework does not provide support for the situation five shown in Section 2, but it is technically resolved. For t his purpose, EMPOWER includes a Source Systems Control Module (M3) which allows non - intrusive monitoring of ISO. This module is composed of software robots which periodically control any event happened in each monitored ISO (such as, new purchase order gen erated, change of status of a task, waiting date exceeded, etc.). These events are also related to transitions within the process. Then, the performance of the robot is briefly: ( i ) it identifies each event happened in each monitored ISO; ( ii ) a new instan ce of the process in BonitaOS is created when an event happens; ( iii ) once open the instance of the process, the robot continues to control each ISO to evolve the instance workflow within BonitaOS. Moreover, the fourth module is the Monitoring Module ( M4) . This module has been specially developed for the project using web technology ( cake PHP, HTML5, CSS3, jQuery, etc.). Once modeled the process using the M1 module, the process engineer can execute the set of M2T transformations to generate PHP code from definition and execution models of the process. This PHP code allows calculating each indicator associated with the process. For this purpose, a communication canal between the monitoring module and the execution engine is established using web services. Once calculated each indicator, this module provides scorecards, timelines with the evolution of each indicator, and alarms/notifications, among other functions. Finally, the last module is the Traceability Module (M5) . An important aspect when MDE is use d is to ensure traceability among generated process models. This is essential in the context of EMPOWER because it enables maintaining the identity of a process among all the modules. In addition, traceability allows enhancement points such as version mana gement of a process. Figure 4 shows some screenshots of the EMPOWER platform (s pecifically its de finition and monitoring modules). V. S UCCESSFUL C ASE S Along this paper, we are aiming at providing a powerful and innovate software platform (named EMPOWER) in order to facilitate and improve the application of BPM using MDE . As a result of achieving this goal, we are getting positive and successful experiences dealing with applying EMPOWER to real projects framed into different business area and validating it. Giving details of all our experiences is out of the scope of this paper. However, we have selected o ne of our projects in order to demonstrate how we have behaved in a real environment. Th is project was the soaADAPT project [16] which aim ed to adapt the e - Health web platform of the Andalusian Regional Ministry of Health and Social Welfare to SOA - based processes architecture so as to allow better modularity, independence, maintainability and reusability of developed services. It mainly consists in setting m echanisms to combine a Healthcare Processes (HP) and healthcare data models. The first challenge of the soaADAPT project was to change the used PML because although this one was very expressive , it does not have features of execution [11] . In this context , it was necessary to apply the EMPOWER platform to obtain systematically and automatically an executable model of HP defined by the health entity. Thanks to EMPOWER , we were able to reduce project costs because it was not necessary to carry out consulting tasks to redo HP according to an executable PML . Finally , once these executable HP have been obtain ed, we Figure 4 . Screenshots of the definition and monitoring module s of EMPOWER. 557
have been able to automatically generate a web application from these models (HP and healthcare data models ) . This web application allows healthcar e professionals to execute the process step by step and monitor each HP . VI. C ONCLUSIONS Today’s world economic situation is ruled by issues such as reducing cost, improving quality, maximizing profit and improving and optimizing production processes at any k ind of organization. In this context, BPM can be an essential strategy. This paper has presented the EMPOWER project, providing a solution based on the MDE paradigm to improve the application of BPM. The EMPOWER platform developed in the project helps achi eve all the objectives of the project. It is based on a BPM lifecycle composed of four phases: modeling, execution and orchestration, monitoring and continuous improvement. In the modeling phase, the process engineer is able to model processes in a concret e PML. Besides, s/he has the possibility of translating the modeled process into another one with a different PML automatically. In the execution and orchestration phase, the process engineer can specify the execution and orchestration parameters to instan ce and run processes into any process engine. Then, the monitoring phase aims to evaluate the effectiveness of the process, which is carried out in two ways: (i) INROMA, including the concepts of metric and indicator that enable the process engineer to me asure processes and (ii) a set of model - to - text transformation rules to systematically generate PHP scripts deployed into the platform. Finally, the goal of continuous improvement phase is to iterate our BPM lifecycle as many times as necessary in order to achieve the business goals defined by the organization The phases presented in the BPM lifecycle are covered in the EMPOWER platform by different functional modules: ( i ) the Process Definition Module which aims to support all PML included in EMPOWER and i mplement all M2M bidirectional transformation rules between these PML and INROMA (this module is presented as an EA plugin); ( ii ) the Execution & Orchestration Module which goal is to execute the process and orchestrate it with other management system of t he organization (this module is covered by the use of BonitaOS); ( iii ) Source Systems Control Module which allows non - intrusive monitoring of system s of the organization ( t his module has been developed using software robots which analyzes events happened i n the systems of the organization ) ; ( i v ) the Monitoring Module through which it is possible to visualize a series of key performance indicators to show the performance of the organization's processes that are running (this module is presented as a CakePHP web application); and ( v ) the Traceability Module wh ich ensure traceability between generated process models. Finally, It is important to mention that our EMPOWER has been successfully applied on real situations as this paper describes. Giving details of a ll our experiences is out of the scope of this paper. However, Section 5 describes one of our projects in order to demonstrate how we have behaved in a real environment. These results allow us to open new lines of work to further investigate and improve th e application of BPM using the MDE paradigm. A CKNOWLEDGMENT This research has been supported by the POLOLAS project (TIN2016 - 76956 - C3 - 2 - R), by the SoftPLM Network (TIN2015 - 71938 - REDT) of the Spanish the Ministry of Economy and Competitiveness. Moreover, this paper has also been funded by the EMPOWER project via CDTI and the VI PPIT - US of the University of Seville ( Spain ) . R EFERENCES [1] Hill, J.B., Kerremans, M. and Bell, T. Cool Vendors in Business Process Management, Gartner Research, Stamford, CT. 2007. [2] Ri chardson C., Miers D. The Forrester Wave™: BPM Suites, 2013. [3] Van - der - Aalst, W.M.P. Business process management: a personal view. Business Process Management Journal, vol.10, no.2, p.5, 2004. [4] Malinova, M., Mendling, J. A Qualitative Research Perspective o n BPM Adoption and the Pitfalls of Business Process Modeling. In Business Process Management Workshops (pp. 77 - 88). 2013. [5] Trkman, P. The critical success factors of business process management. International Journal of Information Management, 30(2), 125 - 13 4. 2010. [6] Schmidt, D. C. Model - Driven Engineering. IEEE Computer, Computer Society, vol. 39, no. 2, pp. 25 - 31, 2006. [7] García - Borgoñón, L., Barcelona, M.A., García - García, J.A., Alba, M., Escalona, M.J.: Software process modeling languages: A systematic lite rature review. Inf. Softw. Technol. 56, 103 – 116. 2014. [8] Meidan, A., García - García, J.A., Escalona, M.J., Ramos, I.: A survey on business processes management suites. Comput. Stand. Interfaces. 2016. [9] Bosch, J. From Software Product Lines to Software Ecosyste ms. SPLC '09 Proceedings of the 13th International Software Product Line Conference, pp. 111 - 119, 2009. [10] Ryan K.L. Ko, Stephen S.G. Lee, Eng Wah Lee. Business process management (BPM) standards: a survey. Business Process Management Journal, Vol. 15 Iss: 5 pp. 744 - 791. 2009. [11] Borgoñón, L.G.: A framework to facilitate the interoperability and maintainability of software process models - Thesis, https://documat.unirioja.es/servlet/autor?codigo=3895499. 2016. [12] ISO/IEC. ISO/IEC TR 24744:2007 Software and systems engineering Lifecycle management Guidelines for process description. International Organization for Standardization, 2007. [13] OMG. Query/View/Transformation. www.omg.org/spec/QVT/1.0/. 2017. [14] OMG.MOF Model to Text Transformation Language (MOFM2T). Http://ww w.omg.org/spec/MOFM2T/1.0/. 2017. [15] García - García , JA. A proposal for the use of the model - driven paradigm (MDE) for the definition and execution of business processes. PhD tesis. URL: Https://documat.unirioja.es/servlet/autor?codigo=3722430. 2015. [16] García Ga rcía, J.A., Escalona, M.J., Martínez - García, A., Parra, C., Wojdyński, T. Clinical Process Management: A model - driven & tool - based proposal. 2015. [17] Domínguez - Mayo, F. J., Escalona, M. J., Mejías, M., Ross, M., & Staples, G. (2012). A quality management bas ed on the Quality Model life cycle. Computer Standards & Interfaces, 34(4), 396 - 412. [18] Domínguez - Mayo, F. J., Escalona, M. J., Mejías, M., Ross, M., & Staples, G. (2012). Quality evaluation for model - driven web engineering methodologies. Information and Soft ware Technology, 54(11), 1265 - 1282 [19] SparxSystems. Enterprise Architect. www.sparxsystems.com.au 2017. [20] Bonitasoft. Website: http://es.bonitasoft.com/ . 2017. [21] Golding, D. Beginning CakePHP: from novice to professional. Apress. 2008 . 2008 558 Powered by TCPDF (www.tcpdf.org) View publication statsView publication stats