Skip to main content
SpringerLink
Log in

Supporting different process views through a Shared Process Model

  • Regular Paper
  • Published:
Software & Systems Modeling Aims and scope Submit manuscript

Abstract

Different stakeholders in the business process management (BPM) life cycle benefit from having different views onto a particular process model. Each view can show, and offer to change, the details relevant to the particular stakeholder, leaving out the irrelevant ones. However, introducing different views on a process model entails the problem to synchronize changes in case that one view evolves. This problem is especially relevant and challenging for views at different abstraction levels. In this paper, we propose a Shared Process Model that provides different stakeholder views at different abstraction levels and synchronizes changes made to any view. We present detailed requirements and a solution design for the Shared Process Model. We also present an overview of our prototypical implementation to demonstrate the feasibility of the approach. Finally, we report on a comprehensive evaluation of the approach on real Business–IT modeling scenarios.

This is a preview of subscription content, log in via an institution to check access.

Access this article

Log in via an institution

Price excludes VAT (USA)
Tax calculation will be finalised during checkout.

Instant access to the full article PDF.

Institutional subscriptions

Fig. 1
Fig. 2
Fig. 3
Fig. 4
Fig. 5
Fig. 6
Fig. 7
Fig. 8
Fig. 9
Fig. 10

Similar content being viewed by others

Notes

  1. Throughout the text, we indistinctly use ‘model’ or ‘view’ when referring to a particular perspective—Business or IT.

References

  1. Recker, J., Mendling, J.: On the translation between bpmn and bpel: conceptual mismatch between process modeling languages. In: Proceedings of 11th International Workshop on Exploring Modeling Methods in Systems Analysis and Design, 2006

  2. Branco, M.C., Xiong, Y., Czarnecki, K., Küster, J., Völzer, H.: A case study on consistency management of business and IT process models in banking. Software and Systems Modeling, March 2013

  3. Weidlich, M., Barros, A.P., Mendling, J., Weske, M.: Vertical alignment of process models—how can we get there? In: Proceedings of Enterprise, Business-Process and Information Systems Modeling, 10th International Workshop, BPMDS 2009, ser. Lecture Notes in Business Information Processing, vol. 29, pp. 71–84. Springer, Berlin (2009)

  4. Weidlich, M., Decker, G., Weske, M., Barros, A.: Towards vertical alignment of process models—a collection of mismatches. Hasso Plattner Institute, Tech. Rep., 2008. [Online]. http://bpt.hpi.uni-potsdam.de/pub/Public/MatthiasWeidlich/collection_of_mismatches.pdf

  5. De Castro, V., Marcos, E., Wieringa, R.: Towards a service-oriented MDA-based approach to the alignment of business processes with it systems: from the business model to a web service composition model. Int. J. Coop. Inf. Syst. 18(2), 225–260 (2009). [Online]. http://doc.utwente.nl/68172/

  6. Luftman, J., Papp, R., Brier, T.: Enablers and inhibitors of business-IT alignment. Commun. AIS, vol. 1, March 1999. [Online]. http://portal.acm.org/citation.cfm?id=374122.374123

  7. Herrmannsdoerfer, M., Benz, S., Jürgens, E.: Cope - automating coupled evolution of metamodels and models. In: Drossopoulou, S. (ed.) ECOOP, ser. Lecture Notes in Computer Science, vol. 5653, pp. 52–76. Springer, Berlin (2009)

  8. Giese, H., Wagner, R.: From model transformation to incremental bidirectional model synchronization. Softw. Syst. Model. 8(1), 21–43 (2009)

  9. Diskin, Z.: Model synchronization: mappings, tiles, and categories. In: Proceedings of the 3rd international summer school conference on generative and transformational techniques in software engineering III, ser. GTTSE’09, pp. 92–165. Springer, Berlin (2011). [Online]. http://portal.acm.org/citation.cfm?id=1949925.1949929

  10. Diskin, Z., Xiong, Y., Czarnecki, K.: Specifying overlaps of heterogeneous models for global consistency checking. In: Proceedings of the first international workshop on model-driven interoperability, ser. MDI ’10, pp. 42–51. ACM, New York (2010). [Online]. doi:10.1145/1866272.1866279

  11. Kolb, J., Kammerer, K., Reichert, M.: Updatable process views for user-centered adaption of large process models. In: Liu, C., Ludwig, H., Toumani, F., Yu, Q. (eds.) ICSOC, ser. Lecture Notes in Computer Science, vol. 7636, pp. 484–498. Springer, Berlin (2012)

    Google Scholar 

  12. Küster, J.M., Völzer, H., Favre, C., Branco, M.C., Czarnecki, K.: Supporting different process views through a shared process model. In: 9th European Conference on Modelling Foundations and Applications, ECMFA, 2013, pp. 20–36

  13. Tran, H., Zdun, U., Dustdar, S.: View-based integration of process-driven SOA models at various abstraction levels. In: Kutsche, R.-D., Milanovic, N. (eds.) 1st International Workshop on Model-Based Software and Data Integration. Springer, Berlin (2008)

  14. Winkler, S., von Pilgrim, J.: A survey of traceability in requirements engineering and model-driven development. Softw. Syst. Model. 9(4), 529–565 (2010)

    Article  Google Scholar 

  15. Czarnecki, K., Helsen, S.: Feature-based survey of model transformation approaches. IBM Syst. J. 45(3), 621–645 (2006)

    Article  Google Scholar 

  16. Branco, M., Troya, J., Czarnecki, K., Küster, J.M., Völzer, H.: Matching business process workflows across abstraction levels. In: France, R. B., Kazmeier, J., Breu, R., Atkinson, C. (eds.) MoDELS, ser. Lecture Notes in Computer Science, vol. 7590, pp. 626–641. Springer, Berlin (2012)

  17. Weidlich, M., Mendling, J., Weske, M.: Efficient consistency measurement based on behavioural profiles of process models. IEEE Transactions on Software Engineering, vol. 99, no. PrePrints (2010)

  18. Bergstra, J.A.: The Linear time — branching time spectrum I. The semantics of concrete, sequential processes. In: Ponse, A., Smolka, S.A. (eds.) Handbook of Process Algebra, Chap. 1. Elsevier Science Inc., New York (2001)

  19. Vanhatalo, J., Völzer, H., Leymann, F.: Faster and more focused control-flow analysis for business process models through SESE decomposition. In: Krämer, B.J., Lin, K.-J., Narasimhan, P. (eds.) ICSOC 2007, ser. LNCS, pp. 43–55. Springer, Berlin (2007)

  20. Küster, J.M., Gerth, C., Förster, A., Engels, G.: Detecting and resolving process model differences in the absence of a change log. In: Dumas, M., Reichert, M. (eds.) BPM’08, ser. LNCS, vol. 5240, pp. 244–260. Springer, Berlin (2008)

    Google Scholar 

  21. Favre, C., Küster, J., Völzer, H.: Recorded demo of shared process model prototype. http://researcher.ibm.com/view_project.php?id=3210

  22. OMG, Business process model and notation (BPMN) version 2.0, omg document number dtc/2010-05-03, Tech. Rep., 2010

  23. Branco, M.C., Wider, A.: Generating preliminary edit lenses from automatic pattern discovery in business process modeling. In: CAiSE Forum, 2013, pp. 65–72

  24. Diskin, Z., Xiong, Y., Czarnecki, K., Ehrig, H., Hermann, F., Orejas, F.: From state- to delta-based bidirectional model transformations: the symmetric case. In: MoDELS, ser. Lecture Notes in Computer Science, vol. 6981, pp. 304–318. Springer, Berlin (2011)

  25. Hofmann, M., Pierce, B., Wagner, D.: Symmetric lenses. In: POPL. ACM, pp. 371–384 (2011)

  26. Cicchetti, A., Ruscio, D.D., Pierantonio, A.: Managing dependent changes in coupled evolution. In: Paige, R.F. (ed.) ICMT, ser. Lecture Notes in Computer Science, vol. 5563, pp. 35–51. Springer, Berlin (2009)

  27. Cicchetti, A., Ciccozzi, F., Leveque, T.: A solution for concurrent versioning of metamodels and models. J. Object Technol. 11(3), 1–32 (2012)

  28. Finkelstein, A., Gabbay, D., Hunter, A., Kramer, J., Nuseibeh, B.: Inconsistency handling in multi-perspective specifications. In: ESEC, ser. Lecture Notes in Computer Science, vol. 717, pp. 84–99. Springer, Berlin (1993)

  29. Egyed, A.: Instant consistency checking for the UML. In: ICSE 2006, pp. 381–390. ACM, New York (2006)

  30. Weidlich, M., Dijkman, R., Mendling, J.: The ICoP framework: identification of correspondences between process models. In: CAiSE, ser. LNCS, vol. 6051, pp. 483–498. Springer, Berlin (2010)

  31. Buchwald, S., Bauer, T., Reichert, M.: Bridging the gap between business process models and service composition specifications. Methods, Trends and Advances, Int’l Handbook on Service Life Cycle Tools and Technologies (2011)

  32. Werth, D., Leyking, K., Dreifus, F., Ziemann, J., Martin, A.: Managing SOA through business services—a business-oriented approach to service-oriented architectures. In: ICSOC Workshops, ser. Lecture Notes in Computer Science, vol. 4652, pp. 3–13. Springer, Berlin (2006)

  33. Thomas, O., Leyking, K., Dreifus, F.: Using process models for the design of service-oriented architectures: methodology and e-commerce case study. In: HICSS. IEEE Computer Society, 2008, p. 109

  34. Schumm, D., Leymann, F., Streule, A.: Process viewing patterns. In: EDOC. IEEE Computer Society, 2010, pp. 89–98

  35. Branco, M., Xiong, Y., Czarnecki, K., Küster, J., Völzer, H.: An empirical study on consistency management of business and IT process models”, Generative Software Development Laboratory, University of Waterloo, Technical Report GSDLAB-TR 2012–03-22, 2012, accepted for publication in Software and Systems Modeling, draft available at http://gsd.uwaterloo.ca/reportstudybpm

Download references

Acknowledgments

We would like to thank the Bank of the Northeast of Brazil (Banco do Nordeste – BNB) for granting us full access to people and artifacts, fundamental for conducting the evaluation of the approach. This work was partially supported by an IBM Ph.D. CAS Fellow Scholarship, the Ontario Research Fund’s Research Excellence Project on Model-Integrated Software Service Engineering.

Author information

Authors and Affiliations

  1. Bielefeld University of Applied Sciences, Bielefeld, Germany

    Jochen Küster

  2. IBM Research — Zurich, Zurich, Switzerland

    Hagen Völzer & Cédric Favre

  3. Generative Software Development Laboratory, University of Waterloo, Waterloo, ON, Canada

    Moisés Castelo Branco & Krzysztof Czarnecki

Authors
  1. Jochen Küster
    View author publications

    You can also search for this author in PubMed Google Scholar

  2. Hagen Völzer
    View author publications

    You can also search for this author in PubMed Google Scholar

  3. Cédric Favre
    View author publications

    You can also search for this author in PubMed Google Scholar

  4. Moisés Castelo Branco
    View author publications

    You can also search for this author in PubMed Google Scholar

  5. Krzysztof Czarnecki
    View author publications

    You can also search for this author in PubMed Google Scholar

Corresponding author

Correspondence to Moisés Castelo Branco.

Additional information

Communicated by Dr. Pieter Van Gorp.

Appendix

Appendix

In this appendix, we summarize the correspondence patterns (CPs) described in previous work [2]. All correspondence patterns are illustrated by an ATM system example shown in Fig. 11. More details can also be found in a technical report [35].

Fig. 11
figure 11

ATM process models. a Business specification, b technical specification, c executable process

Full size image

1.1 CP1: add properties

Description Parameters for grounding the executable model on top of the underlying IT infrastructure are added during the implementation.

Motivation Several properties of tasks, gateways, flows, events, etc., are added to the implementation-level model, such as application or service URLs, protocol types (e.g., http or https), transactional behavior (e.g., commit before, commit after, participates, etc.). Such properties do not change the workflow and may be tool or platform-specific.

Example Each ISO8583 sending or receiving task shown in Fig. 11 (e.g., Identify Customer Card 9300 and Get Card Identification 9310) has parameters that include the message queue, authentication method, security protocol, and message encoding.

1.2 CP2: add manual task

Description Some tasks on the business side are not subject to automation.

Motivation Manual tasks are used for non-automated (typically human-performed) actions of a process, such as transporting assets via postal service, stowing retrieval, visual inspection, etc. Manual tasks are commonly used solely on the business view, since they have no counterpart on the company’s IT infrastructure.

Example A credit process can contain a task to send a hard copy of a contract to the customer, via postal service.

1.3 CP3: add script task

Description Script tasks are used to initialize variables and implement business rules and non-functional requirements that access or transform business objects data, e.g., logging steps of the workflow.

Motivation This type of task is frequently used because it has significantly better performance than calling external services.

Example Figure 12 shows a task created in the ATM application for initializing several parameters of a transaction object, which controls user actions across the workflow. Such kind of task in the IT model does not have any correspondence in the business model.

Fig. 12
figure 12

Add script task

Full size image

1.4 CP4: add protocol task

Description An asynchronous service can be implemented by a connectionless request or reply protocol.

Motivation It is common to implement a business task by using an asynchronous connectionless service. In such cases, the protocol needs to compose and send a message and, after that, wait for a response.

Example Figure 13 shows an example where the business task Identify Customer Card is implemented on top of the ISO8583 protocol by sending a identification request message (9300) and waiting for a validation message (9310).

Fig. 13
figure 13

Add protocol task. a Business and technical specifications, b executable

Full size image

1.5 CP5: add boundary event

Description Boundary events are used to divert the normal flow under special conditions, for example, because of a particular action performed by the operator on a human task.

Motivation The reason to divert the flow can be merely technical or too low level to be represented in the business model. Such conditions can be implemented as result of requirements and use cases that describe a human task in detail.

Example Figure 14 depicts an example of boundary event added to human tasks to capture the customer’s decision to cancel the transaction at any time. Another example can be seen in Fig. 11, where boundary events were added to asynchronous receiving tasks (e.g., Get Statement 9010) to cancel the transaction in the case of a timeout of 8s.

Fig. 14
figure 14

Add boundary event. a Business specification, b technical and executable

Full size image

1.6 CP6: add technical exception flow

Description Technical exception flows are included to divert the flow in case of technical exceptions, such as an unavailable service or a permission denied.

Motivation Technical exceptions are not expected to be represented in the business model, because they implement non-functional requirements elicited during the elaboration phase of the development process.

Example Figure 15 shows examples of technical exceptions flows added for dealing with service errors, in which the transaction parameters are saved and the system administrator is notified to complete the transaction later.

Fig. 15
figure 15

Add technical exception flow. a Business specification, b technical and executable

Full size image

1.7 CP7: change activity name

Description The name of a business activity can be changed to facilitate the identification of an IT service that has a similar but different name.

Motivation IT specialists can decide to use technical names in model elements for facilitating maintenance.

Example Figure 16 shows an example.

Fig. 16
figure 16

Change activity name. a Business and technical specifications, b executable

Full size image

1.8 CP8: change activity type

Description The type of a model element can be changed because of an implementation decision.

Motivation It is easier for business people to stick with basic modeling constructs (such as plain tasks and gateways), while other types of model elements are more suitable to implement the business intent.

Fig. 17
figure 17

Change activity type. a Business specification, b technical and executable

Full size image

Example Figure 17 shows an example were a human task represented in the business model was implemented by an event.

1.9 CP9: suppress specification activity

Description Business elements can be suppressed during the implementation.

Motivation Some elements of the business specification may be considered redundant, not subject to automation, or subsumed by a particular task at the implementation level. Typical cases for observing this pattern are:

  • Combine several business tasks into a single service call (the service provided is coarser than the business steps described),

  • Combine human tasks into a single human task, with the separate steps of the human task being described elsewhere as a screenflow, for example.

  • Ignore manual business tasks, for example, “Send contract to the post office.”

Example Figure 18 shows a case where the two human tasks described in the business model were collapsed into a single human task in the technical and implementation levels.

Fig. 18
figure 18

Suppress specification activity. a Business specification, b technical and executable

Full size image

1.10 CP10: split task into block

Description A single business task can be implemented by a combination of services.

Motivation To implement a specification task, it may be necessary to combine several existing services, including additional control flow logic to organize the way the services should be called to achieve the specified functionality.

Example Figure 19 illustrates such scenario, where a technical specification task, Authorize Transaction, is split into a block of ISO8583 service calls, organized as an exclusive gateway that controls the type of authorization required for each transaction type.

Fig. 19
figure 19

Split task into block. a Technical specification, b executable

Full size image

1.11 CP11: split workflow

Description The specification workflow can be split into smaller workflows that should be orchestrated by a main flow.

Motivation The typical reason for this pattern is the creation of specialized and reusable workflows, such as for logging and auditing purposes.

Example In Fig. 20, the task Cancel Transaction was implemented by a specialized subflow that includes fraud control and is reused by other projects. It is common to use web service interfaces or event triggering for calling the subflows.

Fig. 20
figure 20

Split workflow. a Business and technical specifications, b executable

Full size image

1.12 CP12: refactor gateway

Description A business-level gateway may need to be refined to take into account the technical behavior of the services involved.

Motivation IT services may impose constraints on the control flow. For example, the business model may specify tasks executing in parallel; however, in the implementation the corresponding IT services are called in sequence to avoid deadlocks.

Example Figure 21 shows an example where the business specification has a rule for checking the maximum number of times that a customer can enter a wrong PIN. In the actual implementation, checking the validity of the PIN is a particular result of the transaction authorization. In this particular project, some of the other cases where the transaction is not authorized are also relevant to the business (e.g., insufficient funding). However, since the business analysts did not know how the systems were implemented, they specified such cases as part of business rules of three business tasks: Process Withdraw, Consult Balance, and Consult Statement. Business rules documents are produced together with business process models. The business analysts did not consider necessary to change the business model to approximate it to the actual system, at which point the workflows became different.

Fig. 21
figure 21

Refactor gateway. a Business specification, b technical and executable

Full size image

Rights and permissions

Reprints and permissions

About this article

Check for updates. Verify currency and authenticity via CrossMark

Cite this article

Küster, J., Völzer, H., Favre, C. et al. Supporting different process views through a Shared Process Model. Softw Syst Model 15, 1207–1233 (2016). https://doi.org/10.1007/s10270-015-0453-5

Download citation

  • Received:

  • Revised:

  • Accepted:

  • Published:

  • Issue Date:

  • DOI: https://doi.org/10.1007/s10270-015-0453-5

Keywords

Search

Navigation