# Generation of Concern-Based Business Process Views

Sara Esperto, Pedro Sousa, Sérgio Guerreiro

► To cite this version:

Sara Esperto, Pedro Sousa, Sérgio Guerreiro. Generation of Concern-Based Business Process Views. 13th IFIP WG 8.1 Working Conference on the Practice of Enterprise Modeling (PoEM 2020), Nov 2020, Riga, Latvia. pp.277-292, 10.1007/978-3-030-63479-7_19. hal-03434653

HAL Id: hal-03434653

https://inria.hal.science/hal-03434653

Submitted on 18 Nov 2021

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
Generation of concern-based
business process views

Sara Esperto¹,², Pedro Sousa¹,²,³, and Sérgio Guerreiro¹,²

¹ Instituto Superior Técnico, University of Lisbon, Portugal
Av. Rovisco Pais, 1 1049-001 Lisboa, Portugal

`{sara.esperto,pedro.manuel.sousa,sergio.guerreiro}@tecnico.ulisboa.pt`

² INESC-ID, Rua Alves Redol 9, 1000-029 Lisbon, Portugal

³ Link Consulting S.A., Av. Duque Ávila 23, 1000-138 Lisboa, Portugal
{pedro.sousa}@linkconsulting.com

**Abstract.** Business processes usually have distinct organizational stakeholders with contrasting concerns regarding it. The multitude of concerns often results in multiple business process models with dominant perspectives in the detriment of others which is common to see among the different departments of an organization such as Human Resources, Information Technology, Risk, and Auditing. To the best of our knowledge, there seems to lack of approaches that explore the generation of concern-based business processes to obtain consistent views shaped by departmental interests. Therefore, this paper fills a gap in addressing organizational stakeholders' needs through concern-based business process decomposition and filtering of process activities applied over a consolidated business process model, expecting as an outcome the support and satisfaction of the complex and contrasting concerns of the distinct organizational departments.

**Key words:** Business process decomposition, modeling, views generation, concern-based process views, BPMN.

# 1 Introduction

Business processes translate the knowledge about how an organization operates, and represent one of its core assets as a result of their direct impact on the attractiveness of offerings, influence on customer's experiences, and ultimately revenue [1, 2].

Their significance justifies that business processes often cross multiple departments and inter-organizational boundaries to improve understanding and communication among them, then being shared across different stakeholder groups, which have distinct perspectives and give contrasting importance to the same business process. This drives stakeholders to create and look for a business process in a modeler's perspective, which means in a way that better fulfills their concerns and special requirements.

However, this can give rise to process models that don't have the same principles applied to all of their parts, meaning they lack consistency due to heteroge-
neous schemes for naming its activities and entities, usage of different modeling
styles and process hierarchies with arbitrary depth and level of detail [1]. These
inconsistencies difficult process understanding by stakeholders as well as hamper
the tasks of process analysis, redesign, reuse, and automation as they may lead
to erroneous interpretations of process content and may neglect information.

One way of providing stakeholders with consistent concern-based business
processes is to generate views from a common business process - consolidated
model - according to the requirements of its stakeholders. This means to have
as a starting point, a model that combines multiple business process views. The
design of this consolidated model is out of the scope of this paper yet is intro-
duced in [3]. A view is a partial expression of a system's architecture concerning
a particular viewpoint. A viewpoint establishes the conventions by which a view
is specified, depicted, and created [4]. Subsequently, this paper's approach can
be considered an application of ISO 42010 [5] to business process modeling.
ISO 42010 addresses the creation, analysis, and sustainment of architectures of
systems whose stakeholders are parties with interests in that system, and their
interests are expressed as concerns. According to ISO 42010, a view is also a
suitable fit to address one or more of the concerns of the system's stakehold-
ers. Thus, we want our business process views to help leverage Business Process
Management (BPM) benefits by giving each stakeholder an appropriate process
representation.

Then, to facilitate the consistent modeling of business processes from differ-
ent perspectives, this paper presents an approach that copes with the multiple
views and goals of the different stakeholders, according to their concerns or
focus. Our approach enables the generation of views shaped by departmental
interests since the practitioners' comments to previous works as [6] led to the
idea that generating views only based on the six interrogatives (5W1H): Who,
Where, What, When, Why, How is too simple and seldom adequate to represent
stakeholders' needs. Additionally to this problem, there's a lack of a method for
presenting these needs in the task of business process modeling, keeping in mind
the consistency required.

In order to tackle the aforementioned issues, the views generation is based on
stakeholder's concerns by doing business process decomposition according to the
concerns that are involved in the specification of its activities. Decomposition
deals with breaking down a system into progressively smaller subsystems that
are accountable for some part of the problem domain [7]. Thus, the functional
decomposition of a process entails its recursive separation into progressively
less granular activities. The lowest level of decomposition consists of indivisible
atomic activities. Furthermore, the concerns, which have an associated dimen-
sion, are shaped by departmental interests and mapped to each of the process
activities, making it possible to assign to each activity, its level of Risk, Auditing,
Human Resources (HR), and Information Technology (IT). Along with it, there
are various levels of detail in which the activities can be decomposed. This is
accomplished through a hierarchical structure called taxonomy tree, which is as-
sociated with each dimension. It is the tweaking of the dimensions and respective
taxonomies that allows the generation of different views out of a consolidated
business process model.

To this extent, our solution aims to (1) propose a method to help stakeholders in the task of modeling their concerns shaped by departmental interests and (2) provide an approach making use of concern-based business process decomposition and filtering of process activities through a tool that generates business process views specified in Business Process Model and Notation (BPMN) 2.0 [8].

The remainder of this paper is structured as follows: Sect. 2 reviews relevant background and positions this paper with respect to related work, identifying the research gap of interest. Sect. 3 describes the proposed approach for the generation of concern-based business process views. Sect. 4 illustrates intuitively a real scenario that is used to show the presented problem. The discussion of the results is described in Sect. 5. Finally, Sect. 6 concludes the paper and presents the evaluation of user satisfaction and the directions for future research.

## 2 Background and Related Work

With regards to the Background, several definitions for Business Process (BP) have been proposed along the years. In the early 1930s, Nordsieck describes a business process as a sequence of activities producing an output. An activity is then the smallest divisible unit of work performed by a work subject. More recently, Dumas et al. in [2] define a BP as a collection of inter-related events, activities, and decision points that involve a number of actors and objects, which collectively lead to an outcome that is of value to at least one customer.

Therefore, the concepts, methods, techniques, and tools to manage business processes are also defined as BPM which plays a central role at operational, organizational, and technological levels [9, 7, 10]. Since BPM is represented through the BPM lifecycle and our objective is to assist and supply stakeholders with consistent and updated models that convey their concerns, our research is mainly focused on one of the six phases of the BPM lifecycle - process discovery - that, according to [2], documents the current state of the relevant processes in one or several as-is process models. One of the features commonly associated with BPM is its emphasis on the use of process models throughout the lifecycle of business processes. Those process models are easily interpretable descriptions that represent selected process elements that are considered crucial to the purpose of the model and can be enacted by a human [11].

Over the years, there have been efforts to create notations, methodologies, and frameworks to support business process modeling which is defined by Mendling in [12] as the human activity of creating a business process model. Some approaches apply Enterprise Architecture (EA) frameworks, since EA consists of understanding the different elements that compose the enterprise and how those elements are interrelated [13]. Among others, the Zachman Framework [14] is probably the best-known framework to describe the architecture of an enterprise by proposing a two-dimensional matrix-like structure to classify and organize the business and technical models of an organization, and The
Open Group Architecture Framework (TOGAF) [15] is process-driven generic and flexible enough to provide a comprehensive approach for designing, planning, implementing, and governing an enterprise information architecture. Although multiple classification schemes allow categorizing the modeling perspectives, we posit that these always crosscut the six orthogonal primitive linguistic interrogatives (5W1H) that are fundamentals of communication and used as columns in the Zachman Framework.

Despite the number of techniques to support business process modeling, there is no agreement on the modeling criteria to be used by the different organizational stakeholders. Initially, to tackle the existence of conflicting process specifications for the same organizational process, depending on the distinct stakeholder's perspectives and on the modeler's view regarding that particular process, Sousa et al. in [16] apply some properties derived from the six Zachman Framework dimensions to propose a rule for identifying business process activities and then aid the task of different stakeholders consistently modeling the same process. They use the 5W1H as independent concerns for the decomposition of a business process which makes each activity determined by the values of the six dimensions.

Following [16] and since common definitions of business process concepts include a sequence of activities producing “value”, Pereira and Sousa in [17] use the aforementioned decomposition rule and the classification, recursiveness and cell uniqueness rules of the Zachman Framework to define business process equivalence through activity equivalence, by considering that each dimension of the framework is, in fact, a hierarchy of concepts typically presented as a tree. Once processes can be decomposed until the level that one dimension is sufficient to describe that process, the leaves of the process tree can be called activities which means processes that have no further decomposition. Then, using the activity decomposition rule, the authors argue that two activities are dimensional equivalent if, for each of the six dimensions, the concepts that represent them at the chosen level in the dimension's taxonomy tree are the same.

In line with [16] and [17], Pereira et al. [18] state that a business process can be functionally decomposed into a set of individual tasks which formally speaking means that the decomposition results in a hierarchical structure defined as organizational taxonomy which asserts a controlled vocabulary to design business processes and encompasses six business concepts, each associated with one of the six Zachman Framework dimensions. A taxonomy helps to structure, classify, and model the concepts and relationships pertaining to business process design while enabling a community to commit using the same terms in the same ways [18]. For each of the concepts, there is a taxonomy tree, meaning they can be decomposed infinitely into other instances that conceptually belong to the same concept.

Therefore, [18] triggered other works that concentrate on integrating different business process views and generating new views from a common knowledge base.

View integration first emerged in the field of conceptual database design to support the coexistence of different representations of the same real-world
objects [19]. Aware of this difficult task, Mendling and Simon in [20] propose a method for business process design by view integration using Event-Driven Process Chains (EPCs). While techniques such as Petri nets [21], flowcharts [22], statecharts [23], EPCs [24], UML Activity Diagrams [25], and BPMN [26] are valuable for specifying the control-flow associated with a business process, other techniques like entity-relationship (ER) diagrams [27] and data flow diagrams [28] are useful to capture the data handled by a process. Hence, Colaço and Sousa in [3] apply BPMN 2.0 to propose a method for integrating distinct business process views into a consistent and consolidated business process model. For the purpose, they use the business process repository of the *Atlas*<fnref n="1" /> tool from Link Consulting to enable the stakeholders to classify the various elements of their models while uploading them and then building each taxonomy for each view by classifying process activities in accordance with the six Zachman Framework dimensions. It is through this classification that a consolidated model and an organizational taxonomy are created and turn out to be even more detailed as more models are uploaded to the repository.

In terms of generating business process views, Cardoso and Sousa [6] propose a solution in BPMN that benefits from the information uploaded in the *Atlas* business process repository of Colaço and Sousa [3] to do the opposite of what they do, which means to generate business process views from a consolidated process model instead of integrating them.

## 2.1 Related Work

Our research is somehow related to business process variability modeling since more and more process variants are created to portray stakeholder's distinct concerns of the same process. According to [29] a process variability modeling approach is classified based on how it captures the relation between a set of elements of a process and the corresponding elements in its variants. Then, the *activity specialization* classification is the one that most nearly resemble the approach outlined in the next sections, since it only allows variants in process activities and not in other types of elements, which is aligned with the hierarchical abstraction technique that will be used: *functional decomposition*.

Functional decomposition is upheld at a language level by most process modeling languages such as ArchiMate and BPMN. Some approaches make use of them to create hierarchical representations of a process without pretending to obtain consistent concern-based activity decomposition, but generic decomposition structures. Nonetheless, the shortcomings of the absence of consistency in modeling are recently brought up by the aforementioned work of Colaço and Sousa [3] and their strategy for merging distinct views of a business process will support our solution as the resulting consolidated business process models are stored in a process repository that we will make use.

That process repository was later used by Cardoso and Sousa [6] to generate business process views. To achieve that, they made a process view generation

<footnote n="1">¹ http://www.linkconsulting.com/atlas</footnote>
algorithm that we will use and that takes into account the level of detail desired by each stakeholder for each dimension. Also, the editions performed by the stakeholders in terms of rearranging the location of the graphical elements and changing the generated activities' name can also be stored in the repository. However, there was room for further exploration of the viability of their approach in terms of representing stakeholders' needs regarding organizational departments like Risk, IT, Audit, HR, among others, yet these four were the chosen ones by stakeholders once they represent more evidence of concerns in today's organizations'.

Afterwards, due to a relative scarcity of available methods and techniques to generate consistent and furthermore organizational concern-based business process models, our approach differs as we focus on developing a method by which the stakeholders may generate business process views with the same peculiarities of [6], but having their concerns shaped by departmental interests rather than only focused on answering the 5W1H interrogatives. We choose BPMN as modeling language since it is the most used in the industry and it allows the creation of expressive models due to its variety of elements. Also, once it enables user-centered perspectives while fulfilling IT needs, we found it as a sharp fit.

Fig. 1 resumes the existing relationship between this work and the ones that triggered significant research efforts leading to the solution presented in the following section.

# 3 Proposed Solution

## 3.1 The Big Picture

In the current state of affairs, our research is an add on to the work recently performed by [3] and [6], as illustrated in Fig. 1. The existing approaches guide process stakeholders in constructing taxonomy trees by classifying process activities according to the Zachman contextual dimensions (5W1H) and allow the generation of views by providing the level of detail desired for each dimension.

<figure><img src="image_2.png" /><figcaption>Fig. 1. Illustration of the relation between [3] and [6] works and our research.</figcaption></figure>
Notwithstanding the above, aiming to meet organizational stakeholders' needs, our solution goes further to present them with a method that enables the generation of departmental business process views such as HR, IT, Risk, and Auditing. For that purpose, our approach considers each department as a dimension, and departmental concerns such as departmental functions, roles, and areas, as the criteria for process decomposition instead of the six Zachman contextual dimensions. This means each decomposition step separates a different departmental concern from the other concerns that specify the activity. Hereupon the activities' classification performed by the stakeholders is made according to departmental interests, and the decomposition steps are automatically performed by choosing the level of detail desired for each dimension (i.e. department).

## 3.2 The Process Repository

As a crucial component of our solution, there is a need to disclose the content of the *Atlas'* repository that is relevant to our work. It is structured as it follows:

- the dimensions that allow the visualization of different views;

- an organizational taxonomy for each dimension, which contains a collection of concepts organized into a hierarchical structure - taxonomy tree - and consequently a level of depth that increases proportionally with the level of detail desired;

- the consolidated BPMN process models;

- the mapping between the activities of the consolidated process models and the leaf nodes of the taxonomy trees.

The existing *Atlas'* repository metamodel is shown in Fig. 2 through a simplified UML class diagram. As shown, a Process is composed of Flow Elements that can be Activities, Gateways, or Events. Flow Elements are bidirectionally connected by sequence flows, making these connections represent the position of a Flow Element relative to another. A Process also has organizational taxonomies represented by Taxonomy Nodes whose aggregation with each other conceptually creates a taxonomy tree, illustrating a Dimension. Each organizational taxonomy has a single Taxonomy Root to which all the respective Taxonomy Leaves are attached as it is elucidated in the Taxonomy Node class's self-association. The leaves of the taxonomy trees classify each Activity of the Process.

However, the current repository's state dictates a few modeling constraints:

1. a small subset of BPMN elements such as activities, gateways, non-boundary events, and swimlanes is supported. Both pools and lanes are inferred from the associations between the taxonomy trees' leaf nodes and the process activities. The correspondent taxonomy tree root is depicted in the poll whereas its descendants in lanes;

2. only well-structured consolidated models are allowed. The splits and joins should be paired into single-entry-single-exit (SESE) blocks, respectively;

3. a standalone process activity appears in all views unless it is aggregated with other activities, thus forming a different activity.
<figure><img src="image_3.png" /><figcaption>**Fig. 2.** UML class diagram of the Atlas tool’s process repository metamodel.</figcaption></figure>

### 3.3 The Generation Method

The existing algorithm in the process repository supports the generation of views based on the criteria for activity decomposition presented in [16]. Those criteria have one aggregation condition for each Zachman contextual dimension, yet the set of conditions is not fixed to those six dimensions. The choice of dimensions and their respective structure is configurable, then since there are as many conditions in the repository as there are dimensions, stakeholders can easily define new ones. However, in our approach, we concentrate on departmental dimensions, and our rule for decomposing process activities given a consolidated process model are presented below:

One activity $\delta$ can be decomposed into two activities $\alpha$ and $\beta$ if and only if for every dimension 'd1' one of the following three conditions applies:

- the activity $\delta$ is not deemed atomic, meaning it can be further decomposed because all of its concerns are not effectively separated;

- the activity $\delta$ has different taxonomy concepts within dimension 'd1';

- the activity $\delta$ has equal taxonomy concepts within dimension 'd1', but different taxonomy concepts in other dimension 'd2' at the chosen level of detail of the latter.

For instance, given a consolidated process model of a Bank Credit Granting Process, if one chooses the HR dimension at level of detail 3 and the Risk dimension at level of detail 1, a given activity $\delta$ is decomposed if it is performed by different stakeholders at level 3 of the HR organizational taxonomy. However, if another chooses the HR dimension at level of detail 3 but the Risk dimension at level of detail 2, the activity $\delta$ could be even more decomposed if it has different types of Risk associated at level 2 of the Risk organizational taxonomy.

Nevertheless, considering the constraint number 3 enumerated in Sect. 3.2, the views obtained from the iterations of the aforementioned rule to the consolidated process models, may contain activities that, even though they are correctly mapped into a taxonomy concept (i.e. taxonomy node of an organizational taxonomy) within that view, they may not be needed to represent stakeholders departmental interests. This translates into filtering each activity's relevance to a determined view. Algorithm 1 is manually performed in the upload and modeling phase of a consolidated model in the process repository (left side, Fig. 1).
As described in Algorithm 1, an activity $\alpha$ is of concern to a view $V$ if one of the following two conditions is verified:

- the activity $\alpha$ is performed by $V$;

- the activity $\alpha$ is of interest to $V$ because that knowledge is relevant to get other tasks done.

<table><caption>**Algorithm 1** Ascertain if an activity $\alpha$ is a concern of a View $V$</caption><tr><td>1:</td><td><b>procedure</b> ISACONCERN(V, α)</td></tr><tr><td>2:</td><td><b>if</b> (α is performed by V)</td></tr><tr><td>3:</td><td><b>or</b> (α is of interest to V)</td></tr><tr><td>4:</td><td><b>then</b> return true</td></tr><tr><td>5:</td><td><b>else</b></td></tr><tr><td>6:</td><td><b>return</b> false</td></tr></table>

Hereupon, as an add on to the already existing generation algorithm, Algorithm 2 is the pseudocode of a method that uses (1) Algorithm 1 as a condition to exclusively pick the activities required to serve the stakeholder's needs regarding a specific view, and for that purpose, the activities also need to (2) find a Taxonomy Node (i.e., departmental function, role, area, or other) in the organizational taxonomy of V that suits them. Otherwise, if both conditions are not met, the activities are mapped into a Taxonomy Outsider Node that becomes part of the taxonomy tree of V but is not of interest to V.

<table><caption>**Algorithm 2** Picks the relevant activities for a View.</caption><tr><td>1:</td><td><i>P</i> ← <i>Process</i></td></tr><tr><td>2:</td><td><i>V</i> ← <i>View</i></td></tr><tr><td>3:</td><td><i>T</i> ← <i>TaxonomyTreeOfV</i></td></tr><tr><td>4:</td><td><i>A</i>[<i></i>] ← <i>ActivitiesOfP</i></td></tr><tr><td>5:</td><td></td></tr><tr><td>6:</td><td><b>procedure</b> ACTIVITIESPICKER(P, V, T, <i>A</i>[<i></i>])</td></tr><tr><td>7:</td><td><i>AV</i>[<i></i>] ← <i>ActivitiesOfV</i></td></tr><tr><td>8:</td><td><i>O</i>[<i></i>] ← <i>OutsiderOfV</i></td></tr><tr><td>9:</td><td></td></tr><tr><td>10:</td><td>For α in <i>A</i>[<i></i>]:</td></tr><tr><td>11:</td><td><b>if</b> (α finds a <i>T</i> node where it fits)</td></tr><tr><td>12:</td><td><b>and</b> (<i>IsAConcern</i>(V, α))</td></tr><tr><td>13:</td><td><b>then</b> add α to <i>AV</i>[<i></i>]</td></tr><tr><td>14:</td><td><b>else</b></td></tr><tr><td>15:</td><td><i>add α to O</i>[<i></i>]</td></tr><tr><td>16:</td><td><b>end if</b></td></tr><tr><td>17:</td><td></td></tr><tr><td>18:</td><td><i>show V</i> ← <i>AV</i>[<i></i>] + <i>O</i>[<i></i>]</td></tr><tr><td></td><td>▷ relevant + irrelevant activities to V</td></tr></table>
## 4 Motivating Example

To promote the reader's understanding of the research problem, this section describes a simplified example of a Bank Credit Granting Process. This scenario is the one used throughout the paper.

‘The Credit Granting Process starts when the client needs funding and requests it. At this point, the Bank is responsible for making a proposal and finding the offer that suits the client the best. Once the proposal is drafted and analyzed, an intervention can be required. Otherwise, there is a final decision and an agreement between all the parties involved. Before the granting of the credit, there is also an agreement’s check, and the dispatch is handled. At the same time, during the execution of the whole process, there is an examination of compliance with the Bank’s credit policies and an evaluation of the efficiency of workflows.’

<figure><img src="image_4.png" /><figcaption>**Fig. 3.** BPMN process views of the Bank Credit Granting process, designed by HR (top) and Risk (bottom) departments.</figcaption></figure>

Fig. 3 illustrates two models specified in BPMN 2.0, representing the business process views from two out of several departments that monitor the aforementioned process: the HR and Risk departments. To perform this monitoring, each department models their own view of the process based on the concerns of their interest and on the resources that each has to manage. The HR's interests are focused on the management of all the parties involved in the process, while Risk's interests are related to the Risk associated with each activity of the process.
At this level of detail, this simplified Bank process is performed by three distinct parties (functional, strategic, and administrative) and has three types of risk associated (financial, business, and operational). On the one hand, HR department do not aggregate the 'Ask for client's info' activity with 'Evaluate the procedures against illegal acts' activity once they are performed by people of different areas: administrative and strategic, respectively. On the other hand, the Risk department aggregate the 'Check agreement's validation' and 'Handle Dispatch' activities since they have both an operational risk associated. Also, the Risk view has only 7 activities while the HR view has 10 activities because the Risk view has more activities aggregated and it is not interested in the 'Evaluate the efficiency of workflows' activity.

In the scope of our problem, we want to make possible to generate views with the peculiarities described above, and to model additional and more elaborate views. To the best of our knowledge, there is no existing method that allows to generate concern-based business processes to obtain consistent views from the perspective of departmental stakeholders interests.

# 5 Results Discussion

In this section, we show and explain the results of applying our method to a real-life case study performed in a Bank, so that we can demonstrate and test the usefulness of our research. Firstly, the departmental stakeholders with interest in getting their views portrayed in the *Atlas* tool upload a consolidated process model in the process repository. This step is portrayed in blue in Fig. 1. Then, the stakeholders create taxonomy trees by classifying each process activity according to their concerns which, in the particular case of our work, are departmental. Finally, by providing the level of detail desired for each dimension and through the process view generator represented in green in Fig. 1, our method is automatically applied, and it generates the business process views of Fig. 4. For the purpose, we recall the Bank Credit Granting Process example whose description is in the previous section. We will show an upgrade of the HR and Risk views in Fig. 4 with more activities and a highest level of detail (taxonomy level 3) thus taking advantage of the dynamic taxonomies to help the reader's understanding our solution since the views illustrated in Fig. 3 are considered too simple due to practitioners' comments to previous works.

In Fig. 4, the swimlanes of the top and bottom views are used to represent the HR and Risk dimensions respectively, and each activity of the Bank Credit Granting Process is mapped into a taxonomy concept regarding the HR and Risk organizational taxonomies that we present below:

- HR dimension ⇒ Bank HR (level 1):

* Administrative (level 2)

* Employee Customer Service (level 3); Board Authority (level 3); Financial Advisory (level 3); Maintain Employee Data (level 3)

* Functional (level 2)
* Performance Management (level 3); Technology (level 3)

* Strategic (level 2)

* Compliance (level 3); External Relations (level 3)

- Risk dimension = Bank Risk (level 1):

* Strategic/Business (level 2)

* Technological/Obsolescence (level 3); Commercial (level 3)

* Financial (level 2)

* Credit (level 3); Market (level 3)

* Operational (level 2)

* BPM - service delivery, client, business practices (level 3); Legal (level 3); Security (level 3); People (level 3)

* Outsider (level 2)

As required, the higher the dimension's level of detail, the more the process activities are decomposed, so if the lowest level of detail is chosen for all dimensions, there is no activity decomposition which corresponds to the consolidated model. The name of the composed activities is simply the aggregation of the names of the activities that originated it.

On the one hand, the HR view in Fig. 4 shows a scenario where all the activities (1) have a taxonomy node (in the HR organizational taxonomy) where they fit and (2) are a concern of the HR department who is interested in knowing all the parties and knowledge needed to perform each activity of the process. Also, as the level 2 of Risk was chosen in the HR View (highlighted in purple as Risk: 2), activities like: 'Price the loan and deposit interest rates' and 'Evaluate the conditions in which the client will be able to pay' are decomposed because even if mapped into the same taxonomy concept at level 3 (Financial Advisory) within the HR dimension, they are part of different taxonomy concepts at level 2 of the Risk dimension (Commercial and Credit, respectively).

On the other hand, the Outsider lane in the Risk view (highlighted in orange) represents the taxonomy node where all the activities that are not of interest to the Risk view will be mapped. Hereupon, applying our method we conclude that all the activities highlighted in green (1) have a taxonomy node (in the Risk organizational taxonomy) where they fit and that relation is written in brackets, and (2) are not a concern of the Risk department since those activities are mostly performed by the Auditing department, and they are not of interest to Risk because the knowledge they provide is not relevant to get Risk activities done. Nevertheless, those activities are necessary to keep the process' flow and in case that process fails, the stakeholders are easily aware of the problem's origin.

Then, reducing the number of relevant process activities is fundamental, especially when stakeholders are dealing with intricate processes like this. Afterwards, HR and Risk departmental stakeholders are presented with more enriched but less complex views that better suit them by centering and only showing the concerns stated by them in the first instance.
<figure><img src="image_5.png" /><figcaption>**Fig. 4.** Screen of the *Atlas* tool after the generation of HR (top) and Risk (bottom) business process views at level 3 of detail.</figcaption></figure>

# 6 Conclusions and Future Work

The decomposition of business processes, when keeping stakeholder's concerns in mind, makes concern-based views an excellent mechanism to purposefully convey information about an architecture and in our particular case to an organization that wants to see their departmental interests modeled.

This research aimed to expose the problem of the nonexistence of an approach that represents and benefits the multiple organizational stakeholder's needs, always remembering the consistency required. Our contribution to this problem is grounded on the development of a method that supported by a business process repository offers to the research community a solution that can be applied to tackle those organizational needs making it possible to obtain concern-based
views based on existing consolidated models and organizational taxonomies. By continuing to use the organizational taxonomies together with the proposed dimensions and the possibility of choosing different levels of detail, we also expect to aid departmental stakeholders in communicating and expressing their distinct concerns when engaging in business process design.

As a work in progress, the main limitations are imposed on the consolidated business process models that have some constraints (presented in Sect. 3.2), which means that even if still compliant with BPMN 2.0 [8], the represented views assume various simplifications such as discarding the use of elements like data objects, data stores, message flows, and boundary events, and they are limited to process models with a single pool.

Furthermore, despite these limitations that are intended to be extinguished in the future, this method differentiates itself from the other proposals as it consists of an incremental approach that can adapt to the growth of organizations and their business, by embedding time into the business process models.

Finally, as future work, we aim to integrate our method in the *Atlas* tool to fully automate our solution. Besides that, we aim to decompose business processes in notations other than BPMN. Also, to evaluate the effectiveness and applicability of our approach, we will apply it in real-life case studies performed within real organizations and several stakeholders. After having a consolidated business process model (chosen by the stakeholders) populated in the *Atlas* process repository, they will let us know what are the dimensions of their interest as well as the respective taxonomy tree. Hereafter, the stakeholders will be requested to state their concerns, and our approach will automatically generate the views that better suit them. Lastly, they will comment on the usefulness of the generated views, thus fulfilling the requirement of evaluation of our work.

## ACKNOWLEDGMENT

This work was supported by the European Commission program H2020 under the grant agreement 822404 (project QualiChain) and by national funds through Fundação para a Ciência e a Tecnologia (FCT) with reference UIDB/50021/2020 (INESC-ID).

## References

1. Caetano, A., Silva, A.R., Tribolet, J.: Business process decomposition-an approach based on the principle of separation of concerns. Enterprise Modelling and Information Systems Architectures (EMISAJ) 5(1) (2010) 44–57

2. Dumas, M., Rosa, M.L., Mendling, J., Reijers, H.A.: Fundamentals of Business Process Management, 2nd ed. Springer Publishing Company, Incorporated (2018)

3. Colaço, J., Sousa, P.: View integration of business process models. In: European, Mediterranean, and Middle Eastern Conference on IS, Springer (2017) 619–632

4. Maier, M.W., Emery, D., Hilliard, R.: ANSI/IEEE 1471 and systems engineering. Systems engineering 7(3) (2004) 257–270
5. for Standardization, I.O.: ISO/IEC/IEEE 42010:2011 - systems and software engineering - architecture description, 1st edn (2011)

6. Cardoso, D., Sousa, P.: Generation of stakeholder-specific BPMN models. In: Enterprise Engineering Working Conference, Springer (2019) 15–32

7. Dietz, J.: Enterprise ontology: Theory and methodology. (2006)

8. Group, O.M., et al.: Business process model and notation (BPMN) version 2.0. Object Management Group (2011)

9. Davenport, T.H., Short, J.E.: The new industrial engineering: information technology and business process redesign. (1990)

10. Hammer, M., Champy, J.: Reengineering the Corporation: Manifesto for Business Revolution, A. Nicholas Brealey Publishing (2001)

11. Curtis, B., Kellner, M.I., Over, J.: Process modeling. Communications of the ACM 35(9) (1992) 75–90

12. Mendling, J.: Foundations of Business Process Modeling, in Handbook of Research on Modern Systems Analysis and Design Technologies and Applications. IGI Global (2008)

13. Weske, M.: Business process management: Concepts, languages, architectures, lo ed. springer-verlag, berlin heidelberg. (2007)

14. Zachman, J.A.: A framework for information systems architecture. IBM systems journal 26(3) (1987) 276–292

15. Group, T.O.: TOGAF standard version 9.2. (2018)

16. Sousa, P., Pereira, C., Vendeirinho, R., Caetano, A., Tribolet, J.: Applying the zachman framework dimensions to support business process modeling. In: Digital Enterprise Technology. Springer (2007) 359–366

17. Pereira, C.M., Sousa, P.M.A.: Business process modelling through equivalence of activity properties. In: ICEIS (3-1). (2008) 137–146

18. Pereira, C.M., Caetano, A., Sousa, P.: Using a controlled vocabulary to support business process design. In: Workshop on Enterprise and Organizational Modeling and Simulation, Springer (2011) 74–84

19. Navathe, S.B., Schkolnick, M.: View representation in logical database design. In: Proceedings of the 1978 ACM SIGMOD international conference on management of data. (1978) 144–156

20. Mendling, J., Simon, C.: Business process design by view integration. In: International Conference on Business Process Management, Springer (2006) 55–64

21. Petri, C.: Kommunikation mit automaten (in german)’. Schriften des Instituts für instrumentelle Mathematik, University of Bonn, Germany (1962)

22. Schriber, T.: Fundamentals of flowcharting. Wiley, New York, USA (1969)

23. Harel, D.: Statecharts: A visual formalism for complex systems. Science of computer programming 8(3) (1987) 231–274

24. Keller, G., Scheer, A.W., Nüttgens, M.: Semantische Prozeßmodellierung auf der Grundlage” Ereignisgesteuerter Prozeßketten (EPK)”. Inst. für Wirtschaftsinformatik (1992)

25. OMG: Unified modeling language specification: Superstructure, version 2.0, revised final adopted specification. (2004)

26. OMG: Business process modeling notation specification, version 1.1. (2008)

27. Chen, P.P.S.: The entity-relationship model—toward a unified view of data. ACM transactions on database systems (TODS) 1(1) (1976) 9–36

28. Gane, C., Trish, S.: Structured systems analysis: Tools and techniques. Englewood Cliffs (1979)

29. Rosa, M.L., Aalst, W.M.V.D., Dumas, M., Milani, F.P.: Business process variability modeling: A survey. ACM Computing Surveys (CSUR) 50(1) (2017) 1–45