Towards the Identification of Process Anti-Patterns in Enterprise Architecture Models

Abstract

IT processes constitute the backbone of an integrated enterprise architecture (EA). The model thereof sustains the development and management of the EA. Nevertheless, the quality of such models tends to degrade over time due to, e.g. improper modeling practices or inefective evaluation. In this regard, the knowledge of relevant modeling anti-patterns can help identify, mitigate, and prevent the occurrence of sub-optimal or adverse constructs in the model. In the field of business process modeling (BPM), a plethora of BPM anti-patterns has been defined and compiled in various taxonomies. However, these BPM anti-patterns mostly focus on technical issues, which thus are applicable for evaluating workflows but not EA-level processes. We strongly argue that the concept of process anti-pattern in EA domain can facilitate EA analyses on process-related issues. To address this gap, this paper presents a catalogue of 18 EA process modeling anti-patterns, which we derived from the existing BPM anti-patterns. Our result should serve as food for thought and motivation for future research in this context.

Keywords

• eol>enterprise architecture
• process anti-pattern
• model quality

1. Introduction

text of EA modeling, specifically the application thereof in the evaluation of EA models.

IT processes transform fragmented capabilities within an In the field of business process modeling (BPM) reenterprise architecture (EA) into consolidated business search, a plethora of BPM anti-pattern taxonomies have assets. The models thereof often need to be consulted or been proposed [ 1, 3, 4 ]. However, these BPM antieven adapted in the eforts of managing and evolving the patterns mostly address rather technical aspects like the EA. Nevertheless, these process models are often devel- use of syntax or layout in the process model, which are oped with less consideration of quality due to, e.g. time very specific to the modeling notations in use. Moreover, pressure, little awareness of good modeling practices, or discussions of BPM anti-patterns have mostly been preinadequate evaluation of the models. The uncontrolled sented in workflow modeling notations [ 5 ] (e.g. BPMN). development in this manner will eventually render the These situations hinder the application of BPM antiprocess models useless or even misleading [ 1 ]. This sit- pattern to EA practices, in which processes are viewed uation may hamper the sustainability of EA practices from rather strategic perspectives and modeled in EA within the organization. modeling notations. We strongly argue that transferring

To avoid this, the development and evaluation of pro- the existing BPM anti-patterns into process anti-patterns cess models must be guided by the knowledge of relevant in the domain of EA can help improve the development patterns and anti-patterns. In general, the modeling pat- of processes and their quality that underlie the EA. tern is defined as a proven solution to a recurring model- The efort of transferring an existing concept into the ing problem whereas the modeling anti-pattern is defined domain of EA is not new. Salentin and Hacks introduced as a modeling solution that is known to pose risks [ 2 ]. the concept of EA smell, which is defined as a hint to The understanding of these concepts can help identify, a bad habit that impairs the quality of the EA [ 6 ]. In mitigate, and prevent the occurrence of sub-optimal or their work, they transferred the concept of code smell adverse constructs within the models [ 1 ]. In this study, into the context of EA through conceptual derivation and we focus on the concept of process anti-pattern in the con- transformation methodology. Inspired by their work, the same methodology is applied in this study to answer the following research question (RQ): RQ

What process anti-patterns can be defined to support EA modeling activities through the analysis of published process anti-patterns?

The remainder of this paper is structured as follows: Section 2 gives an overview of previous studies on antipattern or other related concepts (e.g. smell) in the fields

of BPM and EA modeling research; section 3 describes our the authors provide a catalog of 45 EA smells that origimethodology for obtaining process anti-patterns for EA nated from code smells. In their approach, they transform modeling problems; section 4 elaborates our findings and a catalog of well-known code smells into EA smells and the analysis thereof; section 6 demonstrates our results categorize the EA smells based on the three concerns of and discusses the implications as well as threats to the EA: business, application, and technology. Furthermore, validity thereof; and section 7 motivates future research they present a tool that can detect 14 EA smells. As an directions and concludes this paper. extension to their work, this study explores the current knowledge about process anti-pattern to obtain a new understanding thereof in the EA domain. 2. Related Work Finally, the idea of looking at diferent abstraction levels in processes to address diferent stakeholders is not new. Several studies have been conducted to decompose processes into diferent abstraction levels. Giachetti proposes to divide the process hierarchy into functions, processes, sub-processes, activities, and tasks [ 5 ]. This study argues that the natural hierarchical attribute of the process should be used. Viljoen, on the other hand, decomposes it into enterprise model, macro, business process, sub-process, activity, and task [ 13 ]. Koschmider and Blanchard propose a semiautomatic detection for different process abstraction levels with processes modeled with Petri Nets [ 14 ]. Their goal is to detect a process hierarchy in a process model. All these studies commonly advocate that the levels of abstraction applied to processes should meet the goals of relevant stakeholders.

The concept of anti-pattern was coined in 1995 by Koenig [ 7 ] to describe a common solution to a recurring problem which poses risks of being counterproductive. Although an anti-pattern may serve as a practical short-term solution, the use of it sets a context in which certain changes may become more expensive or impossible. The (unintentional) use of anti-pattern is highly influenced by, e.g. time pressure, inadequate knowledge of best practices, or unforeseen changes.

The spectrum of studies about anti-patterns covers a wide-range of software engineering topics, such as software development and modeling. In the domain of BPM, a number of taxonomies of process anti-patterns have been proposed, each of the taxonomies addresses a specific area of concern. In 2019, a bibliography of all these taxonomies was published based on a literature review study [ 1 ]. Therein, the collected taxonomies are divided 3. Methodology into seven categories based on the addressed modeling problems. Furthermore, this study suggests several rules To transfer the existing knowledge about process antiof thumb in documenting process anti-patterns. The au- pattern into the EA domain, this study follows the thors of this study advocate the use of this bibliography methodologies proposed by Pefers et al. and Hevner in the eforts to increase the quality of BP models. et al. for the Design Science Research (DSR) [ 15 ], [ 16 ]:

Analogous with the concept of process anti-pattern, a type of research which aims to devise an artifact that the concept of process anomaly is also known in BPM addresses a "heretofore unsolved and important business research. Vidacic and Strahonja present a literature problem" by drawing on the existing knowledge. The review of this concept in which the collected process resulting artifact must be rigorously evaluated in terms anomalies are divided into three categories: structural, of its "utility, quality, and eficacy" and efectively comsemantical, and syntactical anomalies [ 8 ]. They also sug- municated to the relevant audience. gest approaches to the mitigation or prevention thereof. This study is performed as follows: At first, we colSuchenia et al. provide a brief overview of BPM anti- lected knowledge about the 336 already-published BPM patterns, present these in BPMN models, and categorize anti-patterns in scientific literature, which have been these into three categories: syntactic, structural, and compiled in [ 1 ] and are publicly accessible on [ 17 ]. Based control flow anti-patterns [ 9 ]. Trcka et al. present data- on a mapping of modeling notations between BPMN and lfow anti-patterns and an approach to identifying these ArchiMate, we processed these BPM anti-patterns and [ 10 ]. Further in this topic, Sadiq et al. identify seven finally derived 18 process anti-patterns of EA relevance, common data-flow anti-patterns and provide the basic which are then documented in a structured template and algorithm to address these [ 11 ]. Finally, Döhring and exemplified in ArchiMate models. A closer look into this Heublein present a taxonomy of control-flow, rule-based, procedure is provided in the following subsections. and data-flow anti-patterns; demonstrate examples of such anti-patterns in BPMN; and suggest detection as 3.1. Notation Mapping well as prevention mechanisms thereof [ 12 ].

In the domain of EA modeling, the concept of anti- Most BPM anti-patterns have been analyzed and visupattern remained unknown until the recent suggestion alized in BPMN. While BPMN provides a full-fledged of an EA smell taxonomy by Salentin and Hacks. Therein, framework to create graphical business processes mod

BPMN

Business Process Diagram, Pool, Lanes Activities, Task, Sub-Process Collaboration Diagram Event Data Object Lane Sequence flow Data association Inclusive and parallel gateways

Exclusive and event-based gateways els, BPMN is intended for rather detailed business process the various situations of deadlock are addressed by difermodeling, such as the modeling of conversation, chore- ent BPM anti-patterns. While such specialized modeling ography, and collaboration models. However, such busi- problems are indeed identifiable within BPMN models, ness process models constitute only a small area within such detailed problems are not visible through the highthe broad view of EA. Therein, processes are analyzed level notations of ArchiMate. Therefore, we pruned such from rather strategic perspectives, e.g. the connection detailed branches of classification within the selected of all high-level processes to the surrounding organiza- taxonomies, thereby reducing the size of our analysis to tion units to achieve strategic targets. The modeling of 200 BPM anti-patterns. such perspectives has been facilitated by a number of EA Next, this study follows a defined procedure to derive modeling languages; the most popular one is ArchiMate. process anti-patterns of EA relevance, which is as follows: We strongly argue that method supports for analyzing Firstly, BPMN elements found in the names and descripEA processes must be built on top of an EA modeling tions of the BPM anti-patterns are translated into Archilanguage. Therefore, to transfer the existing BPM anti- Mate elements based on the notation mapping shown in patterns into the EA domain, we first need to create a table 1. Secondly, each translated description is evalumapping between BPMN and ArchiMate to figure out ated to determine whether it is comprehensible within the possibilities of deriving something of EA relevance. the context of EA. Through this step, we derived 18 pro

Previous studies have suggested several mappings be- cess anti-patterns of EA relevance, while excluding the tween BPMN and ArchiMate [ 18, 19, 20, 21 ]. They show rest because the translated descriptions thereof do not dethat both modeling languages share some conceptual scribe relevant EA modeling problems (e.g. anti-patterns similarities. Firstly, both provide similar notations for related to syntax errors such as the sequence flow crosses connecting process elements (e.g. the sequence, default, process boundary [ 3 ]). Among the derived process antiand conditional flows) and regulating these with gate- patterns, some are directly applicable in the EA domain ways or junctions. Secondly, both support the modeling only after applying the notation mapping (e.g. the Layout of similar relationships between processes and the related Deficit [ 1 ]), while some other require broad modification elements [ 19 ]. For example, BPMN’s support for creating in the description thereof to depict valid EA modeling relationships between e.g. activities and data objects is problems (e.g. Useless Test). similar to ArchiMate’s support for creating relationships between e.g. business processes and business objects. In table 1, we list the mappings of notations which we use as a basis to conduct the next steps.

4. An initial catalogue of process anti-patterns in EA

3.2. Transformation Design To support the usability of our contribution, we have organized the resulting 18 process anti-patterns in a cataFrom our analysis of related studies in BPM research, logue, which is publicly accessible on our [ 22 ]. Since this we found several taxonomies which collect in total of catalogue is still in its initial stages, we encourage further 336 BPM anti-patterns and classify these based on the extensions and improvements to it. A detailed discussion characteristics thereof [ 1 ] [ 17 ]. From the perspective of on future research directions is given in section 7. our study, we argue that the depth of these taxonomies In this section, we first introduce the categorization stretches beyond the context of EA analysis. For example, used in the catalogue. Next, we provide a deeper look into one process anti-pattern under each category. Lastly, Table 2 we describe the template used to document some general Categories of EA anti-pattern attributes of the process anti-patterns. 4.1. Categorizing process anti-patterns

Category

Semantic Error

To present the proposed catalogue in an organized and systematic manner, we divide the contained process antipatterns into the following five categories that we derived from some selected categories in [1].

The category of semantic error includes process anti- Understandpatterns that address the semantically error or inconsis- ability Problem tent parts of the model under analysis. These problems are commonly caused by the improper or deficient use of modeling notations, which may distort the understanding of the model. It is worth to mention that such semantic errors should not be confused with syntax errors as the Rule-related latter addresses the violation against the rules of assem- Defect bling the notations, whereas the earlier addresses the Data-flow Inconsistent data false or ambiguous impression conveyed by the model related Defect Mismatched data [ 3 ]. Due to the gap between the syntactic rules of BPMN Missing data and ArchiMate, we derived no process anti-patterns of EA relevance under the syntax error category.

The category of control-flow problem includes pro- Furthermore, to give a closer look into the catalogue, we cess anti-patterns that address the flawed concurrency of elaborate one process anti-pattern under each category process flows which raises unpredictability in the final and provide an example thereof. outcome. Such issue occurs when the modeled processes Under the category of semantic error, the end event are split or joined without properly considering the in- missing occurs when the modeled process does not lfuence thereof to the final outcome. clearly specify the end events [ 3 ] [23], which then causes

The category of understandability problem in- confusion or misinterpretation about the valid conditions cludes process anti-patterns that address the excessive or to finalize or abort the process execution. An example lack of complexity within the model, thereby requiring of this problem is when multiple high-level processes of excessive eforts to understand the process under analy- diferent organization bodies are integrated within the sis in its full context. Such an issue is commonly caused EA model without specifying the points when the collabby the improper/inconsistent level of information gran- orative outcomes have been achieved or any disruptions ularity or inadequate/imprecise coverage of the actual have to be handled. A solution to this anti-pattern would process in reality. be to simply introduce end event elements that clearly

The category of rule-related defect includes process signal all possible ways to end the process. anti-patterns that address the contradictions among the Under the category of control-flow problem , the lack rules specified within the model. Such an issue may of synchronization refers to the situation when the occur when e.g. the actual process is not well-defined, modeled process does not specify a proper synchronizawell-communicated, or well-understood among some tion among concurrent process flows, thereby showing contributors to the rules specification in the model. no predictable outcome. An example of such a situation

The category of data-flow related defect includes is when the modeled process is split by an AND junction process anti-patterns that address the proneness to con- and later joined by an OR junction [24, 25]. A solution to lficts when the same data object is concurrently used this anti-pattern is to ensure the highest test coverage of for diferent kinds of transactions. These issues are com- all points of synchronization specified in the model. monly caused by the overlapping data responsibilities Under the category of understandability problem, the among diferent processes or the centralization of too useless test is identified when the modeled process fulmany data in a single data object. iflls only some of all the possible cases in reality [ 26], thereby making it impossible to identify and test the 4.2. Demonstrating process anti-patterns real extent of the supported problem domain. An example thereof is when the handling of possible mistakes or Next, we name the 18 process anti-patterns and map these disruption during the process execution is not specified under the aforementioned categories, as listed in table 2. within the model. As a solution, the model should be

Attribute

Name Problem Consequences Solution Graphical Definition

Meaning

Gives the anti-pattern a meaningful designator Describes why the anti-pattern leads to problems Describes what the consequences of the anti-pattern are Describes a solution to the anti-pattern Shows a graphical representation of the anti-pattern to reduce misinterpretations incrementally and iteratively developed along with the continuous identification of relevant test cases until it reaches a reasonable level of complexity and covers the complete problem domain [27].

Under the category of rule-related defect, the contradiction in input occurs when some rules applied to the modeled process may contradict with each other, thereby hindering the process execution to continue as intended [ 12 ]. An example thereof is when a certain data object passes the input validations specified on a junction despite being actually invalid for the supplied process. A solution to this anti-pattern is to continuously perform a rigorous combinatorial testing of all possible input types and all the rules applied to the modeled process.

Under the category of data-flow-related defect , the inconsistent data describes the situation in which data objects (e.g. customer records or insurance claim) are accessed by concurrent process flows, thereby making it prone to data handling mistakes. An example thereof is when multiple processes work on duplicates of the same data object, and a (manual) synchronization procedure between the duplicates is required after every modification on one side. To mitigate this, the strategy of handling the data must be carefully defined and implemented. 4.3. Documenting process anti-patterns In general, the documentation of modeling anti-patterns includes many attributes of modeling patterns [28] together with some other attributes like cause and detection [29]. To document the process anti-patterns identified in this study, we derive some attributes from the templates for documenting BPM anti-patterns introduced in [ 1 ], as shown in table 3. Please note that, at the time of this writing, not all attributes have been completed for each process anti-pattern due to the need of further information and analysis.

5. Applying process anti-patterns in EA

In order to illustrate the concept and the usage of process

anti-pattern in the context of EA, we analyze a slightly modified ArchiMate EA model and annotate it with antipattern information. The model used, depicted in fig. 1, is contained in a publicly accessible collection of ArchiMate example EA models [30]. This model defines how new orders are processed. After a new order is received, planning the order and evaluating the customers’ credibility are done in parallel. After an approved proposal is available, the customer signs the respective contract to accept the proposal.

When analysing the model, it can be observed that the processes Evaluate customer credit and Plan order do not wait for each completion before continuing to the Develop approved proposal process, which may lead to undesired results (e.g. the contract does not consider the customer’s credibility). These are consequences of the lack of synchronization anti-pattern.

When analyzing the usage of the Order Data element, we identify the inconsistent data anti-pattern because this data can be changed without rerunning dependent processes (e.g. Evaluate customer credit).

Furthermore, the Evaluate customer credit process exhibits the useless test anti-pattern, as only the positive test result is modeled.

Next, we can identify the anti-pattern end event missing because no clear termination is defined for this EA process model. The process could end in Refuse proposal or in Accept proposal.

Finally, we detect the contradiction in input antipattern at the Or-Junction that splits the control flow after Develop approved proposal. There, the incorrect condition will never lead to the Refuse proposal process and therefore makes it a dead process.

6. Discussion

Some of the main goals of applying the EA discipline within an enterprise is to ensure the business-IT align

Contradiction in input

Develop approved proposal

Contract Customer signature

Refuse proposal Accept proposal

Process does contain end event New order received

Enter order

Useless test

Evaluate customer credit

Lack of synchronization

Plan order Order Data

Inconsistent data CRM

ERP patterns in an EA model, as has been drafted in a program that currently detects 14 EA smells [ 6 ]. 6.2. Threats to validity ment [31] and to develop solid IT strategies that can help achieve strategic targets [32]. For this reason, this section seeks to answer the ultimate question of this study: "how can enterprise architects benefit from the contribution of this study?" In this section, we describe the use of the proposed process anti-patterns to support both research and practice of EA methods. Following to this, we discuss the threats to the validity of our results.

The results of this study have to be seen in the light of some limitations. The limitations that afect the results of this paper are the lack of previous research and bias during the anti-pattern transformation. 6.1. Implication for researchers & Lack of previous research. There is little research on transforming low-level process methods to be applicapractitioners ble for high-level processes and even much less on bringThe concept of EA debt has recently been introduced as ing together the modeling notations for such processes. the deviation between the current state and the hypo- In addition, the already suggested mappings between the thetical ideal state of the enterprise [33]. Factors to such modeling notations for low-level and high-level processes deviation in EA (e.g. sub-optimal or adverse solution are rather described as informal and lack of theoretical design) are likely to be identifiable within the EA models foundations, thereby leaving room for interpretation or created or used during the planning, development, eval- diferent mapping solutions. This might reduce the vauation, or communication of the EA [ 6 ]. Therefore, the lidity of our results because our approach relies on the ability to recognize the existence of such deviation in EA existing mapping between BPMN and ArchiMate. models is needed, and the concept of process anti-pattern Bias during the anti-pattern transformation. To proposed in this study is intended to support such ability reduce bias when selecting the relevant BPM antiwith sharp focus on processes. In this case, practitioners patterns to be transformed, we first need to establish obcan use the process anti-patterns catalogue to scan the jective selection criteria. Thus, we defined a mapping of EA models for potential EA Debt. In any case, it is bene- notations and apply it on the collected BPM anti-patterns ifcial that the practitioners are aware of the potentially to prune the ones that do not fit in the new domain. vulnerable parts of the EA Model as further development Despite this, subjective assessment is still inevitably incould be hindered if these remain ignored [ 6 ]. volved during the process, thereby leaving room for in

Furthermore, we also intend to impart food for thought terpretation and may not produce unique results. into the EA research community and provide a basis for further research works in this topic. For example, the process anti-patterns identified in this study might help researchers to extend the automatic detection of EA anti

7. Conclusion & Future Works

The concept of anti-pattern has been long known to help

recognize common solutions that are not sustainable for the future development. However, little emphasis has been put on studying this concept in the context of EA. The first step in this direction has recently been made to transfer the existing code smells into the EA domain, out of which an initial catalogue of 45 EA smells has been developed and proposed [ 6 ]. To pursue a meaningful extension to this result, this study focuses on transferring the existing BPM anti-patterns [ 1 ] into process anti-patterns for EA modeling problems, with reference to a mapping between the notations of BPMN and ArchiMate.

The process anti-patterns identified in this study are compiled in a catalogue that is publicly accessible on our [ 22 ]. Therein, the process anti-patterns are categorized and documented in a well-known template to ease the use or extension thereof by EA practitioners and researchers. The practical use of this catalogue covers a broad range of topics, starting from the identification of flaws in EA models to the identification of EA debt. Nevertheless, this catalogue is still in its initial stages. Much more information and analyses are needed before this catalogue can be evaluated in real industrial contexts. Therefore, to motivate further research in this topic, the rest of this section outlines some ideas of future research directions.

The future research directions in this topic can be divided into three main topics: to pursue diferent methods for defining new EA anti-patterns, to perform empirical studies for improving both conceptual and practical knowledge in this context, and to develop tool supports for the automatic detection of the anti-patterns in EA models. In terms of analyzing more methods to find EA anti-patterns, we suggest to investigate new domains (e.g. documentation, data, or requirement anti-patterns) to extend the catalogue with adapted or new EA anti-patterns. Also, the investigation of cause-and-efect relationships among the identified EA anti-patterns may provide insights on the possible propagation of impacts thereof. In terms of empirical studies, evaluations using real EA models from diferent business domains can help to verify and improve the quality of the catalogue and the proposed method supports. Finally, tool supports can be developed to support the continuous detection of EA anti-patterns or the (early) signs of their occurrences.

References

[1] A. Koschmider , R. Laue , M. Fellmann , Business process model anti-patterns: a bibliography and taxonomy of published work , in: J. vom Brocke, S. Gregor , O. Müller (Eds.), 27th European Conference on Information Systems - Information Systems for a Sharing Society , ECIS 2019 , Stockholm and Uppsala, Sweden, June 8-14, 2019 , 2019 . URL: https://aisel.aisnet.org/ecis2019_rp/157.

[2] M. Fellmann , A. Koschmider , R. Laue , A. Schoknecht , A. Vetter , Business process model patterns: State-of-the-art, research classification and taxonomy , Business Process Management Journal ( 2018 ). doi: 10 .1108/BPMJ-01-2018-0021.

[3] T. Rozman , G. Polančič, R. V. Horvat , Analysis of most common process modelling mistakes in bpmn process models , in: EuroSPI 2007 , Industrial Proceedings , 2007 , pp. 1 . 21 - 1 .31. URL: https://2020.eurospi.net/images/proceedings/ EuroSPI2007-ISBN-978-3-9809145-6-7.pdf .

[4] S. Von Stackelberg , S. Putze , J. Mülle , K. Böhm , Detecting data-flow errors in bpmn 2.0 , Open Journal of Information Systems (OJIS) 1 ( 2014 ) 1 - 19 .

[5] R. E. Giachetti , Design of Enterprise Systems: Theory, Architecture, and Methods , 1st ed., CRC Press, Inc., USA, 2010 .

[6] J. Salentin , S. Hacks , Towards a catalog of enterprise architecture smells , in: N. Gronau , M. Heine , H. Krasnova , K. Poustcchi (Eds.), Entwicklungen, Chancen und Herausforderungen der Digitalisierung: Proceedings der 15. Internationalen Tagung Wirtschaftsinformatik, WI 2020 , Potsdam, Germany, March 9- 11 , 2020 . Community Tracks, GITO Verlag, 2020 , pp. 276 - 290 . doi: 10 .30844/ wi∖_ 2020 ∖ _y1-salentin.

[7] A. Koenig , Patterns and antipatterns, J. Object Oriented Program. 8 ( 1995 ) 46 - 48 .

[8] T. Vidacic , V. Strahonja , Taxonomy of Anomalies in Business Process Models, 2014 , pp. 283 - 294 . doi: 10 .1007/978-3- 319 -07215-9_ 23 .

[9] A. Suchenia , T. Potempa , A. Ligęza , K. Jobczyk , K. Kluza , Selected Approaches Towards Taxonomy of Business Process Anomalies , volume 658 , 2017 , pp. 65 - 85 . doi: 10 .1007/978-3- 319 - 47208- 9 _ 5 .

[10] N. Trcka , W. M. P. van der Aalst , N. Sidorova, Data-flow anti-patterns: Discovering data-flow errors in workflows , in: P. van Eck, J. Gordijn , R. J. Wieringa (Eds.), Advanced Information Systems Engineering , 21st International Conference, CAiSE 2009 , Amsterdam, The Netherlands, June 8- 12, 2009 . Proceedings, volume 5565 of Lecture Notes in Computer Science, Springer, 2009 , pp. 425 - 439 . doi: 10 .1007/978-3- 642 -02144-2∖_ 34 .

[11] S. W. Sadiq , M. E. Orlowska , W. Sadiq , C. Foulger , Data flow and validation in workflow modelling , in: K. Schewe, H. E. Williams (Eds.), Database Technologies 2004 , Proceedings of the Fifteenth Australasian Database Conference, ADC 2004 , Dunedin, New Zealand, 18 - 22 January 2004 , volume 27 of CRPIT, Australian Computer Society , 2004 , pp. 207 - 214 . URL: http://crpit.scem.westernsydney.edu.au/ [23] C. Dias , V. Stein Dani , J. Mendling , L. Thom, abstracts/CRPITV27Sadiq.html. Anti-patterns for Process Modeling Problems: An

[12] M. Döhring , S. Heublein , Anomalies in rule-adapted Analysis of BPMN 2.0-Based Tools Behavior , 2019 , workflows - a taxonomy and solutions for vbpmn , pp. 745 - 757 . doi: 10 .1007/978-3- 030 -37453- in : 2012 16th European Conference on Software 2_59. Maintenance and Reengineering , 2012 , pp. 117 - 126 . [24] Z. Han , P. Gong , L. Zhang , J. Ling , W. Huang, Defi-

[13] S. Viljoen , Reflections on business process nition and detection of control-flow anti-patterns levelling , white paper , 2012 . URL: https: in process models , in: 2013 IEEE 37th Interna//realirm.com/sites/default/files/whitepapers/ tional Computer Software and Applications Conreflections_ on_business_process_leveling_0.pdf . ference Workshops (COMPSACW) , IEEE Computer

[14] A. Koschmider , E. Blanchard, User assistance for Society , Los Alamitos, CA, USA, 2013 , pp. 433 - 438 . business process model decomposition , in: Proceed- doi:10.1109/COMPSACW. 2013 . 111 . ings of the 1st IEEE International Conference on [25] R. Laue , A. Awad , Visualization of business proResearch Challenges in Information Science , 2007 , cess modeling anti patterns , ECEASST 25 ( 2010 ). pp. 445 - 454 . doi: 10 .14279/tuj.eceasst. 25 .344.

[15] K. Pefers , T. Tuunanen , M. Rothenberger , S. Chat- [26] R. Laue , W. Koop , V. Gruhn , Indicators for open terjee, A design science research methodology issues in business process models , in: International for information systems research 24 ( 2007 ) 45 - 77 . Working Conference on Requirements Engineering: doi:10.2753/MIS0742-1222240302. Foundation for Software Quality, Springer, 2016 , pp.

[16] A. R. Hevner , S. T. March , J. Park, S. Ram, Design 102-116. science in information systems research , MIS Q. 28 [27] P. Desfray , G. Raymond, Chapter 5 - key mod( 2004 ) 75 - 105 . URL: http://misq.org/design-science - eling techniques , in: P. Desfray, G. Raymond in-information-systems-research .html. (Eds.), Modeling Enterprise Architecture with TO-

[17] Business process model patterns classification , GAF, The MK /OMG Press, Morgan Kaufmann, 15 . 11 . 2020 . URL: http://www.bpmpatterns.org/. Boston, 2014 , pp. 67 - 91 . doi:https://doi.org/

[18] Archimate® 3.1 specification , 27 . 06 . 2020 . 10 .1016/B978-0 -12-419984-2 . 00005 - 7 . URL: https://pubs.opengroup.org/architecture/ [28] E. Gamma , R. Helm , R. Johnson , J. Vlissides, Design archimate3-doc/. Patterns, volume 47 of Addison Wesley Professional

[19] D. Orlovskyi , A. Kopp , Enterprise architecture Computing Series , 1995 . modeling support based on data extraction from [29] J. Bogner , T. Boceck , M. Popp , D. Tschechlov, business process models , in: S. Subbotin (Ed.), S. Wagner , A. Zimmermann , Towards a collaboProceedings of The Third International Workshop rative repository for the documentation of serviceon Computer Modeling and Intelligent Systems based antipatterns and bad smells, in: 2019 (CMIS- 2020 ), Zaporizhzhia, Ukraine, April 27-May IEEE International Conference on Software Ar1 , 2020 , volume 2608 of CEUR Workshop Proceed- chitecture Companion (ICSA-C) , 2019 , pp. 95 - 101 . ings, CEUR-WS.org, 2020 , pp. 499 - 513 . URL: http: doi:10.1109/ICSA-C. 2019 . 00025 . //ceur-ws. org/ Vol- 2608 /paper38.pdf . [30] P. Beauvoir , A collection of archimate® models .,

[20] M. Lankhorst , Combining archimate® 3.0 27 .06. 2020 . URL: https://github.com/archimatetool/ with other standards - bpmn, 6.9 . 2016 . ArchiModels . URL: https://bizzdesign.com/blog/combining- [31] J. Gøtze , The changing role of the enterprise archiarchimate-3-0-with-other-standards-bpmn/ . tect, in: 2013 17th IEEE International Enterprise Dis-

[21] L. Penicina , Linking bpmn, archimate, and BWW: tributed Object Computing Conference Workshops, perfect match for complete and lawful business 2013 , pp. 319 - 326 . doi: 10 .1109/EDOCW. 2013 . 42 . process models?, in: J. Grabis , M. Kirikova , [32] C. Strano , Q. Rehmani , The role of the enterprise J . Zdravkovic , J. Stirna (Eds.), Short Paper Pro- architect, Inf. Syst. E-Business Management 5 (2007) ceedings of the 6th IFIP WG 8 .1 Working Confer- 379 - 396 . doi: 10 .1007/s10257-007 -0053-1. ence on the Practice of Enterprise Modeling (PoEM [33] S. Hacks , H. Höfert , J. Salentin , Y. C. Yeong , 2013 ), Riga, Latvia, November 6- 7 , 2013 , volume H. Lichter , Towards the definition of enterprise 1023 of CEUR Workshop Proceedings , CEUR-WS. org, architecture debts , in: 23rd IEEE International 2013 , pp. 156 - 165 . URL: http://ceur-ws. org/ Vol- Enterprise Distributed Object Computing Work1023/paper15.pdf . shop, EDOC Workshops 2019 , Paris, France, Oc-

[22] B.-D. Lehmann , Enterprise process anti- tober 28-31 , 2019 , 2019 , pp. 9 - 16 . doi: 10 .1109/ pattern, 05. 10 . 2020 . URL: https://ea-anti - EDOCW . 2019 . 00016 . pattern.pages. rwth -aachen.de/process-antipatterns/.