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
], 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
]. Despite the strengths of currently available BPA design methods, these approaches usually lack the rigor found in other BPM tools. Particularly, Gonzalez-Lopez and Bustos [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 of business 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 Peffers 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
2. Background and Related Work
Multiple definitions of the concept of BPA are available in the literature, e.g., [1
]. Altogether, these definitions emphasize that a BPA: (i) offers a general perspective on the business process structure, and (ii) defines business process relations. Thus, this work considers that both processes and process relations are the constituting elements of a BPA. The present work adopts a view of the BPA and related concepts that conform with the ISO/IEC/IEEE 42010 standard for architecture description [14
], cf. [15
]. As shown in Figure 1
, a BPA is expressed by a BPA description, which, in turn, is composed of one or more BPA views; each of which, in turn, is composed of one or more BPA models. A key BPA view is the one that is concerned with the high-level structure of the system of business processes known as process map [15
], process landscape [2
], process cartography [20
], or process architecture (model) [10
]. The remainder of this paper refers to it as the BPA model
When the modeling task is complex, having a method—moreover if it is at least partially automated—eases the task, e.g., [25
]. A method can be defined as the concepts, notation, and procedure that guide the structured execution of a complex task [26
]. Accordingly, the present work understands a BPA design method
as the concepts, notation, and procedure that guide the structured design of a BPA that is represented by a BPA model.
Following historic trends, the development of a BPA was one of the most common BPM projects carried out by companies during 2019 [28
]. Having a BPA model eases the task of managing large collections of business processes, which can easily reach several hundreds of processes [1
] in an integral manner. In line with this interest, a number of BPA design methods have been proposed over the last decades by both academia and consulting firms. According to Dijkman et al. [1
], some of these approaches are based on goals (e.g., hiBPM [29
]), actions (e.g., SCOR [30
]), objects (e.g., the unfolding procedure [31
]), reference models (e.g., PCF [32
]), or functions (e.g., BPTrends Associates (BPTA) Methodology [10
Some of the previously cited BPA design methods are described in detail in the following. This is expected to provide the reader with a set of examples of the available BPA design methods.
The Riva method [8
] was developed and improved in time due to academic and consulting efforts. By first understanding the business an organization is in, the Riva method allows building a BPA model that is meant to represent the respective business domain. The domain knowledge is captured in a Unit of Work (UOW) diagram, which is then transformed via a repeatable technique into a BPA model. The inputs of the method are distributed organizational (domain) knowledge and data models; however, the steps of the method lack guidelines on how to use such inputs. The output of Riva is a BPA model referred to as Process Architecture Diagram, which depicts two types of processes (i.e., case processes and case management processes) and their relations (i.e., interaction and instantiation). In terms of its notation, the Riva method uses a non-standard one supported by a dedicated MS Visio
The BPTA methodology [10
] is an integral BPM methodology developed by the 2006-founded training and consulting firm BPTrends Associates (BPTA). The input of the method is, again, organizational knowledge, which is found across different documents, databases and know-how distributed among members of the company. The output of the method is a two-level BPA model that is developed based on a number of meetings where the value chains and stakeholders of the company are analyzed. The first-level BPA model shows value streams relating identified processes and stakeholders, while the second-level BPA model shows hierarchical decomposition relations between the identified processes. Both of these models use a dedicated notation as well.
The unfolding procedure [31
] is a method for creating a model called the Fractal Enterprise Model (FEM). According to its authors, the unfolding procedure is rooted in systems thinking, fractal models, enterprise modeling frameworks focusing on resources, and consulting experience. The FEM is a variation of a BPA model that shows business processes and their indirect relations by connecting processes to the assets (i.e., enterprise resources) they use and manage based on two types of patterns (i.e., process-assets archetypes and asset-processes archetypes). The inputs of the method are organizational (domain) knowledge and documents, yet no precise guidelines are provided on how to use such inputs. The output of the unfolding procedure is the FEM, which uses a dedicated notation supported by Insight Maker
The previously described BPA methods, while illustrating available and used BPA design methods, also exemplify some common issues of these approaches as identified in [11
]: (i) lack of structured business knowledge inputs, (ii) limited consideration of business process relations, and (iii) restricted use of industry-standard languages. As will be discussed in further detail in Section 3
, these issues constitute the problem that motivates the design of the BPA method proposed in our work: the dBPA method. In the following, we outline the position of our proposal with respect to available BPA design methods and their named issues.
First, regarding its inputs and unlike many approaches (e.g., [8
]), the dBPA method does not solely rely on the knowledge of domain experts, but instead it also uses domain models as inputs. In this sense and following [1
], the dBPA method can be categorized as an object-based approach. The use of domain models has been previously suggested as an input for BPA design methods in [8
], but only in general terms and without precise guidelines of how to use their information. Second and in contrast to the few process relation types found in BPA models generated with current approaches (e.g., [8
]), the dBPA method considers four types of process relations (i.e., composition, specialization, trigger, and resource flow). Third and unlike competing methods (e.g., [8
]), the dBPA method uses the ArchiMate standard language for BPA models. The latter serves not just the purpose of facilitating tool support and standardization, but also allows for integrating the resulting BPA model with other elements within the enterprise architecture.
The evaluation of the dBPA method involved conducting a set of evaluation activities. These activities had increasing realism in terms of tasks, systems, and users [56
]; evolving from more artificial to more naturalistic approaches [57
This section reports the two last evaluation instances used for developing the dBPA method. Each evaluation followed a rigorous design whose details are summarized in Table 2
. The following subsections provide an overview of the experiments and findings of the named evaluation instances.
The subject matter of the evaluation is, on the one hand, the method itself and, on the other hand, the BPA models generated by the method. Both the method and its output are challenging to assess due to their inherent complexity and due to the restricted amount and availability of potential users.
6.1. Comparative Evaluation
A quantitative design with soon-to-be users of the method was conducted for assessing the dBPA method and comparing it with an alternative one, i.e., the BPTrends Associates (BPTA) methodology [10
]. This alternative was selected because it is widely used in the industry, well-documented, and significantly different from the dBPA method (i.e., modeling paradigm and notation).
Subjects. The subjects were 25 Industrial Engineering senior undergraduates of the Pontificia Universidad Católica de Valparaíso in Chile. They represent, to some extent, the original context because of: (i) having a background in conceptual modeling due to a previous System and Business Process modeling course; (ii) being familiarized with Business Process Management (BPM) in the context of their current enrollment in a Business Engineering course.
Data were collected using a post-task questionnaire adapted from [60
]. The questions (before randomization) are shown in Table 3
and were to be answered according to a 5-point Likert scale from 1 for strongly disagree
to 5 for strongly agree
. After rejecting observations of subjects producing incomplete questionnaires, a total of 23 observations were used for the analysis. Scores for questions formulated in a negative form (i.e., PEOU3
) were inverted.
The validity of the questionnaire was analyzed via the Spearman coefficient [−1,1] for inter-item correlation, due to the small sample size and ordinal data. This analysis led to removing PEOU6 since it held significant negative correlations to other observable variables for Perceived Ease of Use. The reliability of the questionnaire was assessed using Chronbach’s alpha coefficient due to its suitability for summated scales such as the Likert one used in the questionnaire. After removing PEOU6, the coefficient for all latent variables, as well as for their combination, lay around this lower limit of adequate reliability (i.e., 0.7).
Six hypotheses were formulated (H1 to H6) whose p
-values are provided in Table 4
. On the one hand, hypotheses H1 to H3 (
) assess the perceptions of subjects about the dBPA method
regarding perceived ease of use, perceived usefulness, and intention to use. Testing each of these hypotheses required checking whether the observed median score of the respective variable significantly differed from the zero point of the 5-point Likert scale (
). One-sample Wilcoxon signed rank tests were used [58
]: the null hypothesis states that observed median scores are smaller or equal than the zero point and the alternative hypothesis states that observed median scores are greater than the zero point. On the other hand, hypotheses H4 to H6 (
) compare the dBPA and BPTA methods. This required contrasting the observed median scores for each variable between two different treatments (i.e. A: BPTA and B: dBPA) as reported by the same subjects. The paired Wilcoxon signed rank test [58
] was used: the null hypothesis states that observed median scores of treatment A
are equal or smaller than those for B
, and the alternative hypothesis states that observed median scores of treatment A
are greater than those for B
The results of this evaluation instance are summarized in Figure 8
. Statistical analysis of the results supports, on the one hand, that the dBPA method was perceived as useful (
) but not easy to use (
), and there was intention to use it in practice (
). On the other hand, results suggested that the dBPA method outperforms the BPTA methodology in the aforementioned aspects (
). This constitutes preliminary evidence in favor of the method being an improvement with respect to currently available BPA design methods.
The findings of the comparative evaluation need to be considered within a number of limitations. First, the dBPA method is compared to a single method. This was a design decision for avoiding the fatigue of the subjects. Additionally, we argue that proving that our proposal outperforms—in at least one aspect—one alternative method would justify designing the new method. Second, the use of the same scenario for the sequential application of the treatments involves the risk of a learning effect. A design aspect that partially counterbalances this is the significant difference between the two tested methods. Third, the use of soon-to-be practitioners as proxies for the final users of the method challenges the external validity of the evaluation to some extent. However, though chosen subjects lacked vast practical experience, they have the technical qualifications of such practitioners. Fourth, a convenience sample was used instead of a probabilistic one, which risks statistical bias [61
]. This decision was based on the scarce availability of subjects with the needed profile.
6.2. Individual Evaluation
A mixed-method design was conducted for assessing the dBPA method with its prospective users.
The population under analysis is BPM practitioners. This population is small and our sample comes from a community of BPM practitioners named Club CPO
. This 2009-founded community is a meeting point for BPM practitioners from (inter)national organizations operating in Chilean ground: it hosts regular events for sharing process-related experiences and training. We invited 43 members of the most active companies within the cited community to participate in an activity for the evaluation of the dBPA method. A total of six BPM practitioners participated in the activity, i.e., a 14% response rate. An overview of the participants is shown in Table 5
Quantitative data were collected using a post-task questionnaire whose questions (before randomization) are shown in Table 6
. Qualitative data were gathered next via an interview designed to assess the same aspects that were probed in the questionnaire. We conducted semi-structured group interviews guided by the open questions shown in Table 7
. These interviews were recorded—after informed consent was provided by the participants—leading to 1 h 20 min of recording (40 min per each of the two groups, approximately).
Quantitative data were analyzed using descriptive statistics. Table 8
shows the median values for each of the analyzed variables.
To analyze qualitative data, we used the affinity diagramming technique. This technique allows organizing and making sense of unstructured, far-ranging, and seemingly dissimilar qualitative data into an artifact called the affinity diagram [59
]. The affinity diagram consists of a hierarchical organization of verbal data generated during the interviews: taking this into consideration not only answers the questions asked but also other topics that emerged during the interviews.
The steps for creating an affinity diagram are creating notes, clustering notes, walking the wall, and documenting [62
]. In the creating notes
step, two or more researchers individually play the recording and write down (into sticky notes) short sentences, descriptions, or citations that capture the essence of the different portions of data generated by each participant. During the clustering notes
step, researchers bring together their notes and jointly organize them into preliminary categories (using additional sticky notes) by moving the notes around in a dedicated board, i.e., the wall. The walking the wall
step has the goal of iterating over the previous step by rearranging notes and categories and building the category hierarchy (using arcs that connect them). The output of this step is the affinity diagram that is, finally, described in the documenting
In the present evaluation, the affinity team—i.e., researchers taking notes as well as building the affinity diagram—consisted of two of the paper authors. Data were analyzed in the mother tongue of researchers and participants, namely Spanish. Due to the sanitary context, their work was conducted in a digital fashion by using a dedicated template of the Miro software. Each of the generated notes had an identifier of the participant from whom it was generated (P1, P2,…, P6), as well as from the researcher that generated it. A total of 156 notes were generated, from which 15% were discarded due to reporting contextual information (cf. [62
]). The English version of the resulting affinity diagram is shown in Figure 9
According to quantitative results summarized in Table 8
, the highest-ranked aspect of the dBPA method was operationality (
) followed by ease of use (
), efficiency (
), and generality (
). Whereas the resulting models of the method were best ranked in terms of completeness (
) followed by fidelity (
). Results also showed that the reuse of structured knowledge as an input (DO1) had a favorable impact, which was highest for operationality and completeness (
). The consideration of multiple process relation types (DO2) had a favorable impact, which was highest for efficiency, operationality, and completeness (
). Finally, the use of an industry-standard language (DO3) had a favorable impact as well, which was highest for completeness (
For qualitative data analysis, recordings of the interviews were analyzed by creating the affinity diagram in Figure 9
, and described in detail in Table 9
and Table 10
. To illustrate the results, we provide quotes from participants, translated to English. According to this analysis, practitioners agreed that the method was useful to achieve its goal of building a BPA model. The ease of use of the method was positively influenced by its clear procedure, to the point that the potential for automation was discussed. Additionally, a learning curve was identified by the fact that not all interviewees were experts on domain models. However, there was a consensus that having an interdisciplinary team with IT experts would facilitate this issue. Moreover, practitioners identified a salient value of the dBPA method for integrating the work of process experts and IT professionals automating those processes. In terms of efficiency and generality, the dBPA method seems to be more adequate for core processes of mid-size companies with in-house IT capabilities and a small portion of manual processes. The resulting BPA models generated by using the dBPA method were perceived as complete and correct. The latter was seen as a by-product of the clear procedure where consistency was continuously verified. Regarding the impact of design decisions in the dBPA method and its resulting models, the following was observed. Overall, though the use of domain models as inputs presented some challenges (i.e., learning curve and maintainability), it had the great benefit of making the method more reality-based and objective. The consideration of multiple process relation types was seen as a key factor for the completeness of the resulting BPA models; however, this also might lead to cluttered models, for which the use of alternative/dynamic views might be advisable. Finally, it was perceived that the use of the ArchiMate language was not a problematic issue among participants, who mostly found it easy to understand.
The individual evaluation of the method needs to be understood within a number of limitations. First, the small sample size can be seen as a threat to external validity. However, we argue that the population of users of the method is quite small as well. Moreover, a positive aspect of the sample is its inter-subject variability in terms of levels of experience and the organization in which the subjects work. Second, the qualitative data analysis technique (i.e., affinity diagrams) cannot be fully reproduced because of the subjectivity of the members of the affinity team. However, the use of a team—instead of a single person—in the analysis provides a counterbalance for individual subjectivity. In the same line, a mixed-method technique for data gathering was used [63
] to counteract this and other internal validity issues.
A DSR project was conducted for designing a novel method for BPA design. The use of such an approach was a suitable strategy for generating and validating an artifact that tackles some issues of currently available alternatives. The dBPA method was designed for addressing three design objectives derived from the literature [11
]: reuse of structured business knowledge as input (DO1); consideration of multiple process relation types (DO2); and use of an industry-standard language (DO3).
First, the reuse of structured business knowledge was implemented by using domain models as inputs for the BPA design method (DD1). This constitutes an entity-centric approach and, as such, it relies on the assumption that the structure and behavior of things that are important for a given organization (i.e., business entities), which set the ground for the process structure to be found in the organization. However, unlike other entity-centric BPA approaches—e.g., [8
]—this proposal provides precise guidelines on how to use domain models to convey information for building the BPA model. In broad terms, the dBPA method uses domain model classes for the identification of business entities, and domain model associations together with object lifecycles (OLCs) for the identification of business process relations.
Second, the resulting BPA models of the dBPA method consider composition, specialization, trigger, and resource flow process relations (DD2). Though discussed in the literature of business process relations, see [1
], these four types of relations have been rarely simultaneously incorporated in BPA design approaches so far. The integration of the variety of possible process relations allows providing a more realistic picture of the structure of business processes: in terms of model quality, this contributes to improving the model completeness. Additionally, as posited by [64
], the extent to which a business process is interconnected to other business processes in a BPA can be used for prioritizing process improvement initiatives in an organization.
Third, a dedicated ArchiMate viewpoint—designated the BPA viewpoint—was proposed for the BPA models of the dBPA method (DD3). Though some recent works relate BPA models with ArchiMate, e.g., [65
], no BPA design method has, so far, has used ArchiMate for the specification of BPA models. It is usually the case that BPA design methods use ad hoc languages. An advantage of using standard notations is the availability of tool support. In this work, for instance, Signavio Process Manager 14.3
was used for building domain and BPA models (Figure 3
and Figure 6
), and Visual Paradigm 16.1
for building OLCs (Figure 4
), yet there are other tools for these purposes in the market. The paper shows the use of UML class diagrams for domain models, state machine diagrams for OLCs, and an ArchiMate viewpoint for BPA models. However, the method is not language-dependent and, for example, entity-relationship diagrams, Petri nets, and other model types could be used alternatively. The notations presented in the paper are, however, widely used and thus recommended for the target users of the dBPA method.
The comparative evaluation reported in this paper is a step towards justifying that the dBPA method might be an improvement in comparison to other available BPA design methods. However, this conjecture might be better backed up by further research. The evaluation of the dBPA method with BPM practitioners revealed they perceived it as useful to achieve its goal with the benefits of being objective and clear and allowing to create complete and understandable BPA models that enable the integration of processes and the software that automates them.
Regarding future empirical work, it would be interesting to complement user perceptions with more objective measures. For instance, the Method Evaluation Model (MEM) [67
] is an adaptation of [60
] that measures the actual usefulness and ease of use of methods. In a similar vein, the BPA models resulting from applying the dBPA method might be analyzed further. For example, it would be interesting to assess the cognitive effectiveness of BPA models to complement the information about perceptions. Furthermore, a model quality approach such as the SEmiotic QUALity framework (SEQUAL) [68
] might be used to compare BPA models generated using alternative BPA design methods.
In addition to further empirical work, two main future research topics are envisioned. On the one hand, a new version of the dBPA method could explore further aspects of domain models, e.g., association multiplicity (cf. [69
]), and their impact on the resulting BPA model. In line with this, it would be interesting to perform a sensitivity study for assessing the impact of the variations of different parameters of domain models in the resulting BPA models. On the other hand, the dBPA method adopts some simplifications. First, it considers a one-to-one relation between a business process and an OLC transition. However, in some cases there might be a one-to-many relation between a business process and OLC transitions. For the sake of flexibility, future versions of the dBPA method should address this issue. Business process decomposition under the entity-centric paradigm has also been discussed in approaches such as [70
]. Second, the dBPA method does not differentiate between the most general composition and the most specific aggregation process relations. The latter, which would allow representing processes that can be reused, is not included in the dBPA method in its current version but might be considered in the future.