# Domain Model Based Design of Business Process Architectures
## 1 Introduction  
Work carried out in an organization can be conceptualized as a set of business processes [1]. A business process is a set of interrelated and partially ordered decisions and tasks for providing value to an internal or external customer, cf. [2]. Interconnections between processes have become a topic of interest due to their impact on organization performance [3] and service level [4].  
The present work focuses on the design of a Business Process Architecture (BPA), namely the fundamental concepts or properties exhibited by a system of business processes. The BPA is also a key component of the Enterprise Architecture [5, 6], which includes other related components such as data and technology architecture. A BPA can be graphically represented by a BPA model showing a set of processes and their relations from a high level of abstraction.  
A BPA model is a valuable input for managing the BPA of a given organization systemically in terms of process understanding, performance, and control [7]. The BPA model is useful for articulating BPM initiatives in a holistic fashion [8]. In fact, the BPA model should be used as the starting point for the Business Process Management (BPM) cycle [9] and, in this sense, it plays a key role in the strategic alignment cycle [10].  
Attending to the relevance of BPAs, a number of BPA design methods have been proposed to guide the structured design of a BPA that is represented by a BPA model [1, 11]. Despite the strengths of currently available BPA design methods, these approaches usually lack the rigor found in other BPM tools. Particularly, [PERSON] and [PERSON] [11] identified the following prevalent issues among BPA design methods: (i) lack of structured business knowledge inputs, i.e., BPA design methods usually rely exclusively on unstructured inputs such as expert knowledge and a company's documents; (ii) limited consideration ofbusiness process relations, i.e., most BPA design methods support only one or two process relations types; and (iii) restricted use of industry-standard languages, i.e., dedicated notations are typically used for BPA models instead of standard ones.  
For addressing the previously described issues, the present work proposes a new method termed the domain-based Business Process Architecture (dBPA) method. The dBPA method tackles the aforementioned limitations of available BPA design methods by (i) using domain models as structured input for generating the BPA models, (ii) considering a wide range of relation types within the generated BPA models (i.e., composition, specialization, trigger, and resource flow), and (iii) using the well-known ArchiMate industry-standard notation for BPA models.  
The research lead to proposing the dBPA method followed the Design Science Research Methodology (DSRM) by [PERSON] et al. [12]. The proposed method aims to support BPM practitioners, particularly process architects or, more generally, workers of a BPM Center of Excellence that provides the service of process architecture maintenance [13]. The dBPA method was assessed over multiple evaluation activities. An experiment with soon-to-be BPM practitioners provided evidence that the dBPA method was perceived as useful and also as an improvement with respect to an assessed alternative. A later experiment with BPM practitioners allowed gathering perceptions on the suitability of the method to aid companies in their BPA endeavors. Prospective users of the dBPA method found it useful, objective, and clear while allowing to create a complete and understandable BPA models that enable to integrate processes and the software that automates them.  
The remainder of the paper is structured as follows. Section 2 discusses the background and related work. Section 3 describes the methodology for developing the dBPA method. Section 4 presents the foundations of the method, which is then formalized and exemplified in Section 5. Section 6 reports on the evaluation of the method. Finally, a discussion is provided in Section 7 and conclusions are presented in Section 8.