Design Guidelines to Derive an

$e^3value$

e3value Business Model from a BPMN Process Model
in the Financial Securities Sector

Isaac Da Torres, Marcelo Fantinato, Gabriela Musse Branco, Jaap Gordijn

► To cite this version:

Isaac Da Torres, Marcelo Fantinato, Gabriela Musse Branco, Jaap Gordijn. Design Guidelines to Derive an

$e^3value$

e3value Business Model from a BPMN Process Model in the Financial Securities Sector. 14th IFIP Working Conference on The Practice of Enterprise Modeling (PoEM), Nov 2021, Riga, Latvia. pp.153-167, 10.1007/978-3-030-91279-6_11. hal-04323858

HAL Id: hal-04323858

https://inria.hal.science/hal-04323858v1

Submitted on 5 Dec 2023

**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 CC BY 4.0 - Attribution - International License
<figure><img src="image_2.png" /></figure>

ifip

International Federation for Information Processing

This document is the original author manuscript of a paper submitted to an IFIP
conference proceedings or other IFIP publication by Springer Nature. As such, there
may be some differences in the official published version of the paper. Such
differences, if any, are usually due to reformatting during preparation for publication or
minor corrections made by the author(s) during final proofreading of the publication
manuscript.
# Design Guidelines to Derive an e³value Business Model from a BPMN process model in the Financial Securities Sector

Isaac da Silva Torres¹³, Marcelo Fantinato²,
Gabriela Musse Branco³, Jaap Gordijn¹

¹ Vrije Universiteit, Amsterdam 1081 HV, Netherlands
{i.dasilvatorres,j.gordijn}@vu.nl

² Universidade de Sao Paulo, 03828-000, São Paulo, SP, Brazil
m.fantinato@usp.br

³ Universidade Federal do Rio Grande do Sul, 90040-060, Porto Alegre, RS, Brazil
gabriela.branco@proplan.ufrgs.br

**Abstract.** Process models, e.g. BPMN models may represent how companies in an ecosystem interact with each other. However, the business model of the same ecosystem, e.g. expressed by an *e³value* model, is often left implicit. This hinders the proper analysis of the ecosystem at the business level, and more specifically financial assessment, for which process models are less appropriate. Therefore, the question is if we can somehow derive *e³value* models from BPMN models. This would not only allow for proper business model analysis but would also facilitate business model mining, similar to the success of process mining. However, although an *e³value* model and BPMN model represent the same ecosystem, their perspectives differ significantly. Therefore an automated derivation of an *e³value* model from a BPMN seems not to be feasible, but we can assist the *e³value* model designer with practical guidelines. We illustrate our guidelines by means of a case study about financial securities trading.

**Keywords:** Ecosystems · Business model · Process model · *e³value* · BPMN.

## 1 Introduction

Trading of financial securities requires a complex ecosystem. Following Moore [11], we define an ecosystem as a collection of companies, institutions and end users that work cooperatively and competitively to satisfy customer needs. In the securities-trade ecosystem, investors, either as buyer or seller, play a role, as well as brokers, exchange markets, custodians, clearing houses, and the central clearing counterparts (CCPs).

To redesign the financial securities ecosystem, e.g. stimulated by disruptive technology such as blockchain, we argue that at least two perspectives of the ecosystem should be revisited: (1) the process perspective (e.g. represented by
a BPMN model), and (2) the business perspective (e.g. depicted by an *e<sup>3</sup>value* model). Although both perspectives differ significantly, and address different stakeholder concerns, there is also overlap between the two points of view. Often, in particular in case of redesign, there is already an understanding of the processes involved. However, the business model is in many cases left implicit.

The question is whether we can derive and/or redesign the business model based on a given process model. We argue that both models are too different to allow for such automatic translation (see e.g. [5] for important differences). Therefore, we propose a design-oriented approach, e.g. in [9], we have presented a method using intermediate models to derive a BMPN model from an *e<sup>3</sup>value* model. This is useful for greenfield situations, that often start with the design of the business model, followed by a process model. In this paper, we are interested in the situation where the processes are already well known, but where the business model is not yet explicit. Such a business model is of use to analyse economic consequences changes in the ecosystem, e.g. as a result of a disruptive technology such as blockchain, and to pave the way for business model mining, similar to process mining.

In this paper, we propose a series of guidelines to derive an *e<sup>3</sup>value* model from a given BPMN model. We test the guidelines by means of a case study in the financial securities trading sector. We develop a process model for the trade of securities, which serves as input, and by iterative application of our guidelines, we derive the corresponding *e<sup>3</sup>value* model. For testing purposes, we also have constructed an *e<sup>3</sup>value* model for the case at hand, just by interviewing the stakeholders, and not by using the guidelines. We then compare the *e<sup>3</sup>value* model derived by solely applying the guidelines with the *e<sup>3</sup>value* model created with the help of the stakeholders, to understand limitations and to improve our guidelines. Conclusions are presented in Sec. 4.

## 2 Related Work

The relation between process models and value models is the topic of ongoing research. We can characterize this research as (1) work investigating the links between process models and value models in general, and (2) how to derive a BPMN model from an *e<sup>3</sup>value* model (or the other way around) specifically.

Although both *e<sup>3</sup>value* and BPMN models try to capture an artefact in the real world (e.g. an ecosystem), they do so very differently. In [4], we identified that a BPMN model and *e<sup>3</sup>value* model have very different ontological foundations. To mention a few, actors (in *e<sup>3</sup>value* model) and resource lanes (in BPMN model) might look the same at first sight but are not. Actors are (legal) profit-and-loss responsible entities, whereas resource lanes are parties that execute work. Similarly, a value activity is something an actor executes to create a positive economic value flow (e.g., the total value of the objects flowing out is higher than the value flowing out), whereas a BPMN activity specifies some work to be done, which might have costs only.
In [1], formal consistency rules between coordination models (a kind of process model) and e³value models are defined. The idea is that value transfers can be matched with a (set of) message flow(s). An e³value model is, if quantified, an engine that calculates the net value flows based on the number of needs, the number of actors in a market segment, and dependency elements. This gives an indication of whether the e³value model can be executed in an economically sustainable way by all the actors. As [1] assumes that a value transfer always matches with a (set of) message flow(s), the number of message flows can also be found, e.g., by means of simulation. An e³value model is then consistent with a process model is the number of times a transfer occurs, corresponds to the occurrence of (a set of) message flows.

In addition to consistency checking, the e³value model is used to derive other models. Zlatko uses e³value models to elicit goal models [19]. In [15], the e³value model is used to find Resource Agent Event (REA) models [10], and later also coordination models, e.g., cf. UN/CEFACT'S Modeling Methodology (UMM) [8] models [14]. Also, [2] examined conceptual representations (e³value, UML class diagram) in context of value models and their impact to business processes while analyzing and evaluating the expressiveness in terms of ontologic coverage and overlap. The authors refer to the ability to transform the concepts of value models to the process level, not as an overall evaluation, but the proof of appropriateness of value modelling grammars to their potential of an enhanced user understanding. With that in mind, we call attention to the value object, a distinction should be made between the ownership of the product and the logistic transfer [13]. For e³value model, the transfer of ownership is of interest (or the right to enjoy the outcome of a service), whereas the process model focuses on the flow of possession. Possession means physical access to the object (e.g., to transport it), but not ownership. In [17], this is generalized as a right on a certain resource, e.g., lending a book in a library. We tried to integrate all recent work on how to derive a process model based on an e³value model in [9]. In brief, the proposed method distinguishes the two important design decisions: (1) trust, and (2) possession. Trust implies a particular flow, so time ordering of value transfers and the corresponding message flows, for example, whether a buyer has to pay first and then obtains his product, or the other way around. The notion of 'physical possession' is important, e.g., because a logistic provider needs to possess an object for a while in order to physically deliver a product to the customer.

As can be observed, quite some work was done on how to derive a process model given a value model, the opposite is not the case. As many (larger) companies have explicit process models, deriving value models from them is a logical next step, e.g., to do 'value-mining', as opposed to process mining. In this paper, we propose a set of guidelines how to do so. For this paper, we assume that the reader is familiar with both BPMN and e³value. In [3] and [6], tutorials can be found on BPMN and e³value respectively.
## 3 Technical Action Research: A Research Instrument for Design Science

Our research goal is to support the derivation of an *e<sup>3</sup>value* model from a given BPMN model using *design guidelines*. We consider the development of a business model as a design problem, and hence we consider our research as an instance of Design Science [7]. More specifically, we want to learn how, and if, our guidelines work in practice, which is specific for Technical Action Research (TAR) (see e.g. [18]) which we apply (see Fig. 1). The specific case we consider is about trade of financial securities. To understand the problem domain, we have worked with persons affiliated with the Dutch National Bank (De Nederlandsche Bank - DNB).

<figure><img src="image_3.png" /><figcaption>Fig. 1. Research design</figcaption></figure>

We start the TAR cycle with articulating two research questions, which are about guidelines to derive an *e<sup>3</sup>value* model from a BPMN model. We redesign an earlier developed treatment [16] that results in a set of revised guidelines. The revised guidelines are based on guidelines we have found as a result of an earlier TAR cycle (see [16]) and on work to derive a BPMN model from an *e<sup>3</sup>value* model [9]; precisely the other way around. After treatment design, we design a BPMN process for the trade of securities using the standard practices for process model design. This process design is not part of the TAR cycle; how to design the BPMN model is not part of our research question, but serves as an input to derive an *e<sup>3</sup>value* model from. This BPMN model is constructed in cooperation with domain experts. In the treatment step, we apply the revised guidelines on the found BPMN model. We also construct an *e<sup>3</sup>value* model for the trade of financial securities using the normal practices to design an *e<sup>3</sup>value* model for validation purposes. Again, the design of this *e<sup>3</sup>value* model is not part of the TAR cycle. Finally, in the treatment evaluation step, we compare the *derived e<sup>3</sup>value* model by using the guidelines, with the *e<sup>3</sup>value* model we constructed using the *normal* method to design an *e<sup>3</sup>value* model, and we compare them. Using differential analysis, we formulate lessons learned that can be used to improve the guidelines.
**3.1 Problem Statement**

Development of any ICT-enabled ecosystem requires many viewpoints. This also holds for the ecosystem of financial securities. Two of those viewpoints are the business model perspective and the cross-organizational business process, each with their own concerns. In this paper, we use for the business model the *e³value* language and for the process model BPMN. Although there is overlap between both languages, there are also substantial differences. To mention a few, *e³value* has the notion of *economic reciprocity* and supplier/customer side *bundling*. These concepts are not present in BPMN. Conversely, BPMN represents the time ordering in which activities take place, whereas *e³value* represents only causal dependencies. For ecosystem (re)design, both an *e³value* model and a BPMN model are useful. Since both models have some overlap, it is perhaps possible to derive the one model from the other. In [9], we derive a BPMN model from an *e³value*. This is useful in case of *new* ecosystem development, which often starts with the design of the *e³value* model.

In this paper, we propose to use *designed guidelines* to derive an *e³value* model based on a process model. This is particular useful in case of existing ecosystems, where (part of) the BPMN model is already available. This leads to the following research questions:

RQ1 What guidelines are useful to derive an *e³value* model based on a given BPMN model?

RQ2 To what extent is it possible to derive the complete *e³value* model from the BPMN model?

**3.2 Treatment Design: From Process Model to Value Model**

This research is based on our previous work [16], which resulted in a set of preliminary guidelines. We revised this set of guidelines, which is summarized in Table 1. Note that the guidelines indicate *conditional* correspondence between the BPMN- and *e³value* model by means of the verb ‘may’. We explain these conditions per guideline explicitly.

G1 *BPMN start/end events may correspond to e³value consumer needs and boundary elements.*

**Description.** A start event may result in a consumer need or boundary element in *e³value*. The same holds for the end event.

**Conditions.** There are two conditions that should be satisfied for a correspondence.

1. A customer need is a lack of something valuable that the actor wants to acquire [6]. A boundary element scopes an *e³value* model [6], e.g. the boundary of value transfers. Consequently, for correspondence, an event should either relate to something of value an actor wants, or should mark that no further value transfers occur. Many BPMN events are not related to customer value creation at all, but rather focus on operational aspects only (e.g. trigger an administrative process, such as sending a bill). Such events do not have a direct counterpart in *e³value*.
<table><caption>**Table 1.** Guidelines – from BPMN model to *e<sup>3</sup>*value model</caption><thead><tr><th>ID</th><th>BPMN element</th><th>e<sup>3</sup>value element</th><th>Guideline description</th></tr></thead><tbody><tr><td>G1</td><td>Start event<br>End event</td><td>Consumer need<br>Boundary element</td><td>BPMN start/end events may correspond to e<sup>3</sup>value consumer needs and boundary elements.</td></tr><tr><td>G2</td><td>Pool</td><td>Actor<br>Market segment</td><td>BPMN pools may correspond to e<sup>3</sup>value actors or market segments.</td></tr><tr><td>G3</td><td>Lane 1<br>Lane 2</td><td>Value activity</td><td>BPMN lanes may correspond to e<sup>3</sup>value value activities.</td></tr><tr><td>G4</td><td>Activity<br>Subprocess</td><td>Value activity</td><td>BPMN activities and sub-processes may correspond to e<sup>3</sup>value value activities.</td></tr><tr><td>G5</td><td>Message flow</td><td>Value transfer</td><td>BPMN message flows may correspond to e<sup>3</sup>value value transfers.</td></tr><tr><td>G6</td><td>Activity<br>Sequence flow</td><td>Value transfer</td><td>BPMN activities and sub-processes and their sequence flows may correspond to e<sup>3</sup>value value transfers.</td></tr><tr><td>G7</td><td>Message flow<br>Sequence flow</td><td>Value interface</td><td>Following a BPMN sequence message flow may lead to an e<sup>3</sup>value value interface.</td></tr><tr><td>G8</td><td>Message flow<br>Sequence flow</td><td>Value offering</td><td>Following a BPMN sequence message flow may lead to an e<sup>3</sup>value value offerings.</td></tr><tr><td>G9</td><td>Message flow<br>Sequence flow</td><td>Dependency path</td><td>Following a BPMN sequence message flow may lead to an e<sup>3</sup>value value dependency path.</td></tr><tr><td>G10</td><td>AND Gateway</td><td>AND dependency</td><td>BPMN AND gateways may correspond to e<sup>3</sup>value AND dependencies.</td></tr><tr><td>G11</td><td>XOR Gateway</td><td>OR dependency</td><td>BPMN XOR gateways may correspond to e<sup>3</sup>value OR dependencies.</td></tr><tr><td>G12</td><td>OR Gateway</td><td>AND dependency<br>OR dependency</td><td>BPMN OR gateways may correspond to a combination of e<sup>3</sup>value AND/OR dependencies.</td></tr><tr><td>G13</td><td>Task 1<br>Task 2<br>Loop</td><td>Cardinality dependency</td><td>BPMN loops may correspond to e<sup>3</sup>value cardinality dependencies.</td></tr></tbody></table>

2. A start event may map onto a customer need or a boundary element. The same applies to the end event. A sequence flow in BPMN represents *time-ordering*, whereas in *e<sup>3</sup>*value a dependency path represents *causal dependencies*. For example, a book store’s start event may trigger ordering of a book at a publisher, followed by delivery, displaying the books, and finally selling the books, concluded by an end event. In *e<sup>3</sup>*value however, the end event (representing the sale) would map onto a customer need, whereas the start event translates into an *e<sup>3</sup>*value boundary element. Note that in case of an electronic book store (e.g. Amazon) the opposite happens in terms of BPMN: first selling, then printing, and finally distributing.
G2 *BPMN pools may correspond to e³value actors or market segments.*

**Description.** Pools in BPMN map one-to-one onto actors or market segments in *e³value*.

**Conditions.** There are two conditions that should be satisfied for a correspondence.

1. Following the definitions in *e³value*, pools can only be mapped into actors if they are capable of taking their own economical and legal decisions. Sometimes, in BPMN pools are distinguished to represent resources capable of doing work but do not make their own economic and legal decisions. Then the pool can not be mapped, but perhaps the supervising agent for that pool can.

2. While considering a pool, one party (e.g. a single company) can be associated with the pool, or there can be more than one (possibly alternative) agent. In the first case, the pool results in an *e³value* actor, in the second case the pool corresponds to a market segment.

G3 *BPMN lanes may correspond to e³value value activities.*

**Description.** Lanes in BPMN can model a role that a certain entity performs. The value activity construct in *e³value* comes semantically closest to the notion of role.

**Conditions.** In *e³value*, a value activity requires that at least one party should be able to generate a net cash flow by executing the activity. In BPMN, a lane represents a collection of activities and their sequence flow, which may result in a net cash flow. However, in BPMN a lane may only result in expenses. In such a case, a lane can not be mapped on a value activity.

G4 *BPMN activities and sub-processes may correspond to e³value value activities.*

**Description.** This guideline is actually a refinement of guideline G3. Rather than considering a full lane, now the focus on a subset of BPMN activities and/or activities (e.g. in a pool), and their sequence flow.

**Conditions.** Although one activity in BPMN may correspond to precisely one value activity in *e³value*, the relation is often *n*-to-one. e.g. a combination of BPMN the activities result into one *e³value* activity. Similarly, the condition of G3 applies.

G5 *BPMN message flow may correspond to e³value value transfers.*

**Description.** In BPMN, message flows between pools transfer 'content of communication' [12] (pg. 93). In *e³value*, a value transfer is a transfer of ownership, the right to enjoy a service outcome, or even a valuable experience, collectively called value objects. So, ontologically, message flows in BPMN are very different from value transfers in *e³value*.

**Conditions.** There are three conditions that should be satisfied for a correspondence.

1. In *e³value*, a value object requires that it is (1) of economic value for at least one actor and (2) satisfies a need directly or indirectly (through
another value object) [6]. For correspondence, the *object* transferred via a BMPN message flow in BPMN should qualify as an value object in *e<sup>3</sup>value*. Often, this is not the situation,e.g. a 'bill' does not correspond to a value object directly (but the subject of the bill does).

2. There is correspondence if the message flow represents a transfer of ownership (see e.g. [13,9]), or the right to enjoy the outcome of a service. In BPMN models, often the flow only transfers possession. We interpret 'possession' as the right to have physical access to an object, but not necessarily to use that object. E.g. a logistic provider needs to have access to book for transportation, but may not use/read the book. Ownership does not necessarily imply physical possession; e.g. oil is transferred many times to a new owner (while transported), without having the owner ever seen the oil physically.

3. A value transfer in *e<sup>3</sup>value* denotes the *willingness* of actors to transfer ownership [6]. Usually, an actor is only willing to transfer ownership (e.g. of a book) if there is a *reciprocal* transfer (e.g. of money). Message flows in a BPMN model corresponding to a reciprocal value transfer in *e<sup>3</sup>value* often can not be easily identified but are a required condition. See also guideline G7.

G6 *BPMN activities and sub-processes and their sequence flows may correspond to e<sup>3</sup>value value transfers.*

**Description.** In some cases, a part of a BPMN model executed by a pool, e.g. a series of activities and sub-processes elements as well as their sequence flows, can be seen as a commercial service for which someone is willing to pay. This results in at least one value transfer representing the service outcome, and one reciprocal value transfer, e.g. a payment. Value transfers representing service outcomes by executing activities often do not have corresponding message flows, and only can be found by understanding the semantics of the activities and sequence flows in the BPMN model.

**Conditions.** The part of the BMPN model that may result in a value transfer should produce a service outcome for which at least one actor, market segment, or value activity wants to pay.

G7 *Following a BPMN sequence message flow may lead to an e³value value interface.*

**Description.** By following the sequence flow, and the associated message flow(s), a value interface can be found. In *e<sup>3</sup>value*, a value interface consists of value ports, and value offerings and are connected by means of value transfers. A value interface models *atomicity: all* value transfers connected to a value interface should transfer their corresponding value object or none at all. Also, the value interface models *economic reciprocity* as an interface should have at least one ingoing value transfer and at least one outgoing value transfer. BPMN does not have a construct to express economic reciprocity. However, the sequence flow can be followed and all resulting message flows can be listed. These flows
are candidates for a (reciprocal) value transfers and hence value interfaces.

**Conditions.** There are two conditions that should be satisfied for a correspondence.

1. The found message flows that are candidate for triggering the creating of a value interface need to correspond to one or more value transfers (see guideline G5).

2. A value interface represents that an actor is *willing* to exchange an in-going value object (e.g. a product) for an outgoing value object (e.g. a payment). Consequently, the transfers implied by the found message flows should be reciprocal, meaning that the object of the one transfers serves as an *economic compensation* for the object of the other transfer.

G8 *Following a BPMN sequence message flow may lead to an e³value value offerings.*

**Description.** By following the sequence flow, and the associated message flow(s), one or more value offerings can be found. In *e³value*, a value offering groups all equally directed value ports in a value interface, and models *bundling*, e.g. a McDonalds Happy Meal consisting of various products. The sequence flow may indicate that multiple message flows should occur, for example by using an AND gateway.

**Conditions.** There are two conditions that should be satisfied for a correspondence.

1. The found message flows that are candidate for triggering the creation of a value offering need to correspond to one or more value transfers (see guideline G5).

2. A value offering represents *economic bundling*. The message flows corresponding to the transfers grouped into a value offering should all happen as a result of the execution of the sequence flow.

G9 *Following a BPMN sequence message flow may lead to an e³value dependency path.*

**Description.** By following the BPMN sequence flow, reciprocal value transfers can be found (see guideline G6), but also dependent value transfers and/or fragments of an *e³value* dependency path. In *e³value*, the dependency path relates dependency elements (customer need, boundary element, value interfaces, AND-, OR- and cardinality dependencies, leading to the more specific guidelines G9, G10, G11, G12 and G13 respectively)

**Conditions.** There are two conditions that should be satisfied for a correspondence.

1. The sequence flow should have as start point(s) a start event (guideline G1), or a message flow that results in value transfer (guideline G5), and should have as end point(s) an end event (guideline G1) or a message flow that results in value transfer (guideline G5).

2. Dependency paths are always restricted to a single actor, market segment or value activities.
G10 *BPMN AND gateway may lead to an e³value AND dependency.*

**Description.** By following the BPMN sequence flow, AND gateways can be encountered. In *e³value*, the AND dependency has similar semantics as the AND gateway in BPMN. An AND dependency *fork* spans off outgoing dependency paths that happen precisely the same number of times as the incoming dependency path. Similarly, an AND dependency *join* represents that the incoming paths to the AND dependency join should happen the same number of times.

**Conditions.** AND gateways result only in AND dependency elements if they influence the number of times the corresponding dependency path is executed. Often, a BPMN model contains more detail, needed to specify to process. Some of the AND gateways are part of the more detailed model and do not affect the number of times an *e³value* path is executed.

G11 *BPMN XOR gateways may correspond to e³value OR dependencies.*

**Description.** By following the BPMN sequence flow, XOR gateways can be encountered. In *e³value*, the OR dependency has similar semantics as the XOR gateway in BPMN. In *e³value*, and OR dependency is evaluated per execution of the dependency path, and the selection of a particular disjunct is based on a (probability) distribution. This corresponds to the XOR gateway that makes a selection between disjuncts to decide which sequence flow to follow.

**Conditions.** See guideline G10.

G12 *BPMN OR gateways may correspond to a combination of e³value AND/OR dependencies.*

**Description.** By following the BPMN sequence flow, OR gateways can be encountered. In *e³value*, there is not a direct related construct. Instead, the semantics of the OR gateway (one or more sequence flows connected to disjoints of the gateway continue) should be simulated. This is possible but does not lead to an elegant *e³value* model. This should be solved by having an explicit OR and XOR dependency element in *e³value*, which is subject of further research.

**Conditions.** See guideline G10.

G13 *BPMN loops may correspond to e³value cardinality dependencies.*

**Description.** A BPMN model may contain repetition (loops) in the sequence flow. Essentially, a BPMN model can be considered as a *cyclic* directed graph. An *e³value* model however is an *acyclic* directed graph, e.g. it may not contain loops. Consequently, repetition in BPMN can not be mapped in *e³value* directly. However, *e³value* has the cardinality dependency, resulting in the execution of the dependee (dependency path) a number (*n*) of times, given the number of times (*m*) the dependent dependency path is executed. With the cardinality dependency element, the effect of a loop in BPMN can be simulated, e.g. by mapping out all loop executions
explicitly.

**Conditions.** See guideline G10.

## 3.3 Treatment: Trading of Financial Securities

Based on a BPMN model (Fig. 2), we derive an e³ value for the financial trade of securities in The Netherlands. To construct and validate the BPMN model, we have consulted experts affiliated with the Dutch National Bank (De Nederlandsche Bank - DNB). The construction of the BPMN model is outside the scope of the treatment, and is done via a normal knowledge acquisition process.

<figure><img src="image_4.png" /><figcaption>Fig. 2. BPMN model of securities trading</figcaption></figure>

We briefly summarize the BPMN model. The process start with Investor(s) placing an order request (to buy/sell) for securities with brokers. Orders can be placed either as market orders (buy/sell at market price) or limit orders (buy/sell for a minimum/maximum price). For each case, the broker analyzes
the best course of action, e.g. based on the size of the trade. After matching (left implicit in this model), the order details are sent for clearing and settlement. Every investor engages the services of a custodian to assist them in clearing and settlement activities. The Clearing House(CH)/Central Clearing Counterparty (CCP) is an entity that takes the credit risk between parties and provides clearing and settlement services for trades. CCPs calculates and informs the members of what their obligations are on the funds side (cash) and on the securities side. After the clearing corporation informs all members of their obligations, the clearing members should make available their securities (shares and money). Finally, settlement takes place. Payments are done and investors have their securities in their demat account.

We then constructed the corresponding *e<sup>3</sup> value* model by applying solely the guidelines (see Sec. 3.2) until they could not be used anymore. The resulting *e<sup>3</sup> value* model is in Fig. 3 (a).

<figure><img src="image_5.png" /><figcaption>Fig. 3. *e<sup>3</sup> value* models derived by using the guidelines and a normal elicitation process</figcaption></figure>

1. G2 results in the actor - ‘Clearing House’, and the market segments - ‘Investors’, ‘Brokers’ and ‘Custodians’.

2. G3 brings value activities with the same names as the lanes.

3. With guideline G4, we can not find additional value activities.

4. According to G1, the start event ‘Request to buy/sell securities’ represents a consumer need in the *e<sup>3</sup> value* model. The second start event ‘Trade Details’, serves as an operational input to and does not satisfy condition 1 of guideline G1. Two of the five end events relate directly to economic effects: ‘Trade completed’ and ‘Request executed’ and result in boundary elements in their respective value activities (‘trading’ and ‘settlement’). The other events indicate only non-approvals or dead-ends.
5. Guidelines G9, G10, G11, G12 and G13 discover dependency elements. The AND gateway after the activity 'Execute settlement' results in an AND dependency in the settlement value activity (G10). None of the other gateways influence the number of times a dependency path occurs and hence G11/G12/G13 do not apply.

6. With G9, the start event 'Request to buy/sell securities' has as an end event and a message flow that results in value transfer ('money/securities'). This results in a dependency for the consumer need (buy securities). Also, because the BPMN model shows the custodians as a black pool, a lot of information is missed and some dependencies are disconnected.

7. G5, G6, G7 and G8 are used to discover value transfers, value interfaces and value offerings. G5 checks all the message flows in the BPMN for potential value object transfers. In BPMN, economic reciprocity is not a concept present and so what comes back of economic value is usually hidden. e.g. to satisfy the 'trade request', the investor likely has to pay a fee (money) (G6). There are explicit value transfers between the 'custodians' and 'investors' with the 'clearing house' (via the value activity 'settlement'). Unfortunately with G8, the relation was not found.

## 3.4 Treatment Evaluation

**Observations Extracted from the Case.** For validation purposes, we construct the *e³value* model, called the normative model (Fig. 3 (b)), using the normal *e³value* elicitation process, so without taking the BPMN model into consideration. Again, the model is validated by experts from the DNB, and is briefly explained below. There are two 'Investors' market segments with the consumer need 'Buy securities' (Buyer) and 'Sell Securities' (Seller). Both 'Investors' market segment use (optionally) 'Brokers' for trading service and they use also a custodian (bank) to real-time check their valuables (optionality is not represented). The 'custodians' are also removed since investors do have a bank to store their financial means. The trade is then submitted to a 'Trade Platform' who performs 'Order Matching' of buyers and sellers. The 'Trade Platforms' are e.g. a Multilateral trading facility (MTF), an Exchange, etc. The 'Clearing' is performed by the CCP to protect against a defaulting buyer or seller. 'Settlement' is done to make the trading executable, which is performed by the Central Security Depository (CSD).

After a differential analysis between both *e³value* models (Fig. 3 (a) and (b)), we observe the following.

1. In Fig. 3, the 'Clearing House' actor (a) in reality are two parties: CCP and CSD (b). Still the same value activities (clearing and settlement) are performed. This is not due to the guidelines, but a result of the granularity of the earlier made BPMN model.

2. The market segment 'Trade Platforms' is according to the experts important and was not found in the BPMN model, but not considered relevant at that time. Perhaps taking a business model perspective stimulates experts to
bring up the platforms. Again, omission in the derived *e<sup>3</sup>value* model is not
caused by the guidelines.

3. The market segment ‘Custodians’ is present in the derived model, but not in the model constructed in a session with the experts. The experts put forward that in traditional process descriptions, the custodian is still mentioned due to historic reasons but in practice they do not play a significant role anymore.

4. The AND dependency and boundary element in ‘Trading’ is moved to ‘Order matching’ to represent matching, which is a best practice in *e<sup>3</sup>value*.

5. Both *e<sup>3</sup>value* models are semantically correct and illustrate properly the real-world scenario of the case. However, the model based only on the guidelines missed some important information due to the fact that the BPMN model failed to report it.

**Limitations.** The differential analysis has some limitations: Both the *e<sup>3</sup>value* model as derived by the guidelines and the normative *e<sup>3</sup>value* as elicited by using the conventional model elicitation process are executed by ourselves. By doing the model elicitation process, we obtained knowledge about the *e<sup>3</sup>value* model which may influence the application of the guidelines to find the *e<sup>3</sup>value* model using the set of guidelines. We tried to mitigate this bias by strictly applying the guidelines only. In follow up research, we want to separate the construction of the normative *e<sup>3</sup>value* model and the construction of the *e<sup>3</sup>value* model based on the guidelines by using a separate group of persons applying the guidelines. Also, our evaluation did not consider the time and cognitive load needed, which would show the practicability and usability of the method in real-world settings.

4 Conclusion

Revisiting our research questions, we have presented and used guidelines to de-
rive an *e<sup>3</sup>value* model from a BPMN model (RQ1). The model constructed us-
ing the normal *e<sup>3</sup>value* process however shows some important differences from
the developed by using only the guidelines, most notably the introduction of a
new market segment ‘Trade platforms’. Although different time frames and re-
searchers were used while constructing both models, this acts as a limitation of
our research, which leads to the observation that, before applying the guidelines,
it is important to understand the bias taken on, and completeness of the BPMN
model itself. All differences can be explained by missing elements in the BPMN
model (e.g. to different perspectives taken by the experts, not asking the right
questions, etc.) and not by the guidelines themselves. How to test properly the
BMPN model for suitability to apply the guidelines is subject of further research.
Once solved, more can be said about the completeness of the guidelines (RQ2).

***Acknowledgements.*** The authors are thankful to Menno Broos, Ellen Naudts and Timothy Aerts, affiliated with the De Nederlandsche Bank (DNB), for explaining us how financial securities trading works, and for validating the models we have created. We also extend our thanks to Felix Fueyo for his help with the designed BPMN model.
## References

1. Bodenstaff, L.: Managing Dependency Relations in Inter-Organizational Models. Ph.D. thesis, University of Twente (2010)

2. Buder, J., Felden, C.: Ontological analysis of value models. In: 19th European Conference on Information Systems, ECIS 2011, Helsinki, Finland, June 9-11, 2011. p. 22 (2011)

3. Dumas, M., Rosa, M.L., Mendling, J., Reijers, H.A.: Fundamentals of Business Process Management. Springer, 2nd edn. (2018)

4. Gordijn, J., Akkermans, H., van Vliet, H.: Business modelling is not process modelling. In: Int'l Works. on Concep. Modeli. Approac. for E-Busin. pp. 40–51 (2000)

5. Gordijn, J., Akkermans, H., Vliet, H.V.: Business modelling is not process modelling. In: Conceptual Modeling for E-Business and the Web, ECOMO 2000. LNCS, vol. 1921. Springer (2000)

6. Gordijn, J., Wieringa, R.: E3value User Guide - Designing Your Ecosystem in a Digital World. The Value Engineers, 1st edn. (2021)

7. Hevner, A., March, S., Park, J., Ram, S.: Design science in information systems research. MIS Quarterly: Management Information Systems 28(1), 75–105 (2004)

8. Hofreiter, B., Huemer, C., Liegl, P., Schuster, R., Zapletal, M.: UN/CEFACT'S modeling methodology (UMM): A UML profile for B2B e-commerce. In: 2nd Int'l Works. on Best Practices of UML. pp. 19–31 (2006)

9. Hotie, F., Gordijn, J.: Value-based process model design. Bus. Inf. Syst. Eng. 61(2), 163–180 (2019)

10. McCarthy, W.E.: The REA accounting model: A generalized framework for accounting systems in a shared data environment. The Accounting Review 58(3), 554–578 (1982)

11. Moore, J.F.: The Death of Competition: Leadership and Strategy in the Age of Business Ecosystems. Harper (1996)

12. OMG: Business process model and notation, version 2.0 (2011), https://www.omg.org/spec/BPMN/2.0, Object Management Group (OMG)

13. Pijpers, V., Gordijn, J.: Bridging business value models and business process models in aviation value webs via possession rights. In: 20th Annual Hawaii Int'l Conf. on System Sciences (2007)

14. Schuster, R.: Requirements Management for B2B Processes: a Worksheet Driven Approach from e3-Value and REA to UMM. Ph.D. thesis, Vienna University of Technology (2010)

15. Schuster, R., Motal, T.: From e3-value to rea: Modeling multi-party e-business collaborations. In: IEEE Conf. on Comme. and Enterpr. Compu. pp. 202–208 (2009)

16. da Silva Torres, I., Gordijn, J., Fantinato, M., da Fountoura Vieira, J.F.: Designing an ecosystem value model based on a process model - an empirical approach. In: The Practice of Enterprise Modeling - PoEM 2020, Riga, Latvia, Proceedings. pp. 293–303. Lecture Notes in Business Information Processing, Springer (2020)

17. Weigand, H., Johannesson, P., Andersson, B., Bergholtz, M., Edirisuriya, A., Ilayperuma, T.: On the notion of value object. In: 18th Int'l Conf. on Advanced Information Systems Engineering. pp. 321–335 (2006)

18. Wieringa, R.: Design science methodology for information systems and software engineering. Springer (2014). https://doi.org/10.1007/978-3-662-43839-8, 10.1007/978-3-662-43839-8

19. Zlatev, Z.V.: Goal-Oriented Design of Value and Process Models from Patterns. Ph.D. thesis, University of Twente (2007)