Guidelines to derive an $e^{3}value$ business model from a BPMN process model: an experiment on real-world scenarios

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^{3}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^{3}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^{3}value$ model and BPMN model represent the same ecosystem, their perspectives differ significantly. Therefore an automated derivation of an $e^{3}value$ model from a BPMN seems not to be feasible, but we can assist the $e^{3}value$ model designer with practical guidelines. We explore and test our guidelines in two real-world settings, we then analyze and evaluate its application to better understand their limitations and how to improve them.

1 Introduction

Most businesses operate in an ecosystem, which we define as a collection of companies, institutions and end users that work cooperatively and competitively to satisfy customer needs [1]. As the businesses themselves, this ecosystem is in continuous change, for example, as a result of technological innovation, repositioning of parties in the ecosystem, changes in rules and regulations, and many more causes. Consequently, the ecosystem is subject to (re)design, followed by various kind of analyses, to see if the change brings the desired effect.

To redesign complex ecosystems, 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^{3}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., [2] for important differences). Therefore, we propose a design-oriented approach, e.g., in [3], we have presented a method using intermediate models to derive a BMPN model from an $e^{3}value$ model. This is useful for greenfield situations, which 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 analyze 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 extend the proposal and testing of a series of guidelines to derive an $e^{3}value$ model from a given BPMN model [4]. We explore these guidelines by using a Technical Action Research (TAR) cycle in a real-world case: the financial securities trading sector. We develop a process model for the the trade of securities, which serves as input, and by iterative application of our guidelines, we derive the corresponding $e^{3}value$ model. We then test the guidelines by means of a single-case experiment to further investigate our findings from the TAR cycle and improve our artifact (guidelines). We have asked two knowledgeable persons in the field of both BPMN 2.0 and $e^{3}value$ to derive an $e^{3}value$ model for the ecosystem using our guidelines only. The experiment uses a real-life case in the field of international Intellectual Property Rights (IPR) clearing.

We also have constructed an $e^{3}value$ normative model for both cases at hand, just by interviewing the stakeholders, and not by using the guidelines. We then compare the $e^{3}value$ model derived by solely applying the guidelines with the $e^{3}value$ model created with the help of the stakeholders. Conclusions are presented in Sect.  7.

2 Background

2.1 Business process modeling and notation

Business Process Model and Notation (BPMN) is a standard for specifying business processes in organizations [5]. It is simple, common to most part of process modeling users, and has a wide-diffused graphical notation. It can represent the complex behavior of systems. The notation is in version 2.0. BPMN 2.0 [6] summarizes an industrial standard for the IT support of business processes and business process management. It provides a combination of symbols to define the central artifact of a business process life cycle [7].

In the last years, BPMN has acquired a clear relevance among the notations used to model business processes in both academia and industry. Muehlen and Recker [8] have show that although BPMN 2.0 has a variety of elements, only 20% of them is regularly used when designing business process models. Our research was attained to the elements found in the BPMN process model from the case. They are as follows: swim pools (black rectangles) correspond to the actors involved in the process (e.g., customer). The tasks/activities (blue rectangles) represent how the process is operationalized, transforming inputs into outputs. Events (green, yellow, and red circles) describe the state or situation when an activity is executed (before or after). The sequence flow (black connectors) indicates the order of how each element is activated, and message flow (black-doted connectors) shows how actors communicate with each other. Gateways (yellow diamonds) define the routing rules of the operation. Basically, there are three types of connectors— the logical AND for concurrency, XOR for exclusive paths, and OR for inclusive choices.

2.2 $e^3$ value modeling

The $e^3$ language [9] is an approach in the field of value modeling. Other approaches include the Resource Event Agent (REA) [10] ontology and value stream mapping [11]. E$^3$ value is particularly strong at representing and analyzing the ecosystem, or (as called in e$^3$ value) the networked value constellation [12] of enterprises that jointly meet one or more needs of an end user.

Fig. 1

An educational $e^3$ value model

We briefly explain, by means of an educational example (Fig. 1), the $e^3$ value constructs relevant for this paper; for a more detailed discussion, see [9]. Actors such as Amazon.com are profit-and-loss responsible and often legal entities. In many cases, it is useful to talk about multiple actors of the same kind, market segments, who assign economic value in the same way. Examples are readers (people who want to read a book) and publishers. Actors and market segments do value transfers which each other; the subject of such a transfer is the value object (e.g., book, transportation, money), which of economic value to at least one of the actors/market segments. The latter transfer value object via value ports, which are grouped into value interfaces. These interfaces represent economic reciprocity; hence a value interface contains at least one in-going value port and one out-going value port. Actors/market segments perform value activities to earn money (companies) or increase economic utility (end users). Customer needs (read book) indicate a state of felt deprivation [9] by an actor that will be satisfied by one or more value objects, indicated by dependency connection elements. At the end of the dependency chain, there are one or more boundary elements to indicate that further value transfers are not considered anymore. This does not imply that they are not there (e.g., the publisher needs to do transfers with writers); they are only considered out of scope for the model. Hence, boundary elements specify the model boundary.

3 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^{3}value$ model (or the other way around) specifically.

Although both $e^{3}value$ and BPMN models try to capture an artefact in the real world (e.g., an ecosystem), they do so very differently. Gordijn, Akkermans and van Vliet [13] identified that a BPMN model and $e^{3}value$ model have very different ontological foundations. To mention a few, actors (in $e^{3}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.

Fig. 2

Research design

Bodenstaff [14] defined formal consistency rules between coordination models (a kind of process model) and $e^{3}value$ models. The idea is that value transfers can be matched with a (set of) message flow(s). An $e^{3}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^{3}value$ model can be executed in an economically sustainable way by all actors. As Bodenstaff [14] 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^{3}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^{3}value$ model is used to derive other models. Zlatko [15] uses $e^{3}value$ models to elicit goal models. Schuster and Motal [16] used the $e^{3}value$ model to find Resource Agent Event (REA) models [10] and later also coordination models, e.g., cf. UN/CEFACT’S Modeling Methodology (UMM) [17] models [18]. Also, Buder and Felden [19] examined conceptual representations ($e^{3}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 modeling grammars to their potential of an enhanced user understanding. With that in mind, Pijpers and Gordijn [20] call attention to the value object, a distinction should be made between the ownership of the product and the logistic transfer. For $e^{3}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. Weigand et al. [21] generalized this 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^{3}value$ model in Hotie and Gordijn’s work [3]. 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 seen, quite some work was done on how to derive a process model from 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^{3}value$. Dumas et al. [7] and Gordijn and Wieringa [22] present tutorials on BPMN and $e^{3}value$, respectively.

4 Research design

Our research goal is to support the derivation of an $e^{3}value$ model from a given BPMN model using designed guidelines. We consider this goal as a design problem, and hence, we consider our study as an instance of Design Science Research [23]. For this, we carried out a building iteration of our artifact (i.e., the guidelines), which had a two-step evaluation phase, with different research designs for each step. More specifically, we want to learn how, and if, the guidelines work in practice, which is specific for (1) Technical Action Research (TAR) (see e.g., [24]) which we apply (see Fig. 2). Furthermore, using a (2) single-case experiment, we test the validity and evaluate how to improve the guidelines even more. In order to accomplish this, we consider two real-world scenarios: the financial securities trading and the IPR music clearance. To understand the problem in both domains – financial securities trading and International IPR clearing – we have worked with persons affiliated with the Dutch National Bank (De Nederlandsche Bank – DNB) and IPR society NL, respectively. All BPMN and normative $e^{3}value$ models were validated with these domain experts.

We start the TAR cycle with articulating two research questions, which are about guidelines to derive an $e^{3}value$ model from a BPMN model. We redesign an earlier developed treatment [25] 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 [25]) and on work to derive a BPMN model from an $e^{3}value$ model [3]; 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^{3}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^{3}value$ model for the trade of financial securities using the normal practices to design an $e^{3}value$ model for validation purposes. Again, the design of this $e^{3}value$ model is not part of the TAR cycle. Finally, in the treatment evaluation step, we compare the derived $e^{3}value$ model by using the guidelines, with the $e^{3}value$ model we constructed using the normal method to design an $e^{3}value$ model, and we compare them. Using differential analysis, we formulate lessons learned from the outcome of the TAR cycle and use it to further develop our guidelines.

The second step on our Research Design is the application of the single-case experiment. The objective within using this research method is to analyze, in a deeper and more efficient way, the guidelines. Using a different real-world case and test subjects, we check the validity of the model generated by our guidelines. Also, we use their feedback to improve and expand our artifact even further. We start by modeling the International IPR music clearance BPMN and $e^{3}value$ normative model using the usual knowledge acquisition process. The test subjects were instigated to make comments and think aloud during their sessions on deriving the corresponding $e^{3}value$ model using solely our guidelines. Lastly, we compare their models with the normative models and with each others model. We expect that the differences and/or similarities between these models will help us investigate improvement points for our guidelines.

4.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^{3}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^{3}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^{3}value$ represents only causal dependencies. For ecosystem (re)design, both an $e^{3}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 [3], we derive a BPMN model from an $e^{3}value$. This is useful in case of new ecosystem development, which often starts with the design of the $e^{3}value$ model.

In this paper, we propose to use designed guidelines to derive an $e^{3}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^{3}value$ model based on a given BPMN model?

• RQ2. To what extent is it possible to derive the complete $e^{3}value$ model from the BPMN model?

• RQ3. Is it possible to derive a valid $e^{3}value$ model using a given BPMN 2.0 model?

• RQ4. How can the guidelines to derive $e^{3}value$ model from a BPMN 2.0 model be improved?

5 Applying the TAR cycle

To answer the research questions RQ1 and RQ2, we execute an exploratory TAR cycle [24]. This research is based on our previous work [25], which resulted in a set of preliminary guidelines.

5.1 Treatment design: from process model to value model

In order to answer to RQ1, we revised this set of guidelines, which is summarized in Table 1. Note that the guidelines indicate conditional correspondence between the BPMN- and $e^{3}value$ model by means of the verb ‘may.’ We explain these conditions per guideline explicitly.

Table 1 Guidelines – from BPMN model to $e^{3}value$ model

• G1. BPMN start/end events may correspond to $e^{3}value$ consumer needs and boundary elements. Description. A start event may result in a consumer need or boundary element in $e^{3}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 [22]. A boundary element scopes an $e^{3}value$ model [22], 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^{3}value$.

  • 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^{3}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^{3}value$ however, the end event (representing the sale) would map onto a customer need, whereas the start event translates into an $e^{3}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^{3}value$ actors or market segments Description. Pools in BPMN map one-to-one onto to actors or market segments in $e^{3}value$. Conditions. There are two conditions that should be satisfied for a correspondence.

  • 1. Following the definitions in $e^{3}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 cannot 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^{3}value$ actor, in the second case the pool corresponds to a market segment.

• G3. BPMN lanes may correspond to $e^{3}value$ value activities Description. Lanes in BPMN can model a role that a certain entity performs. The value activity construct in $e^{3}value$ comes semantically closest to the notion of role Conditions. In $e^{3}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 cannot be mapped on a value activity.

• G4. BPMN activities and sub-processes may correspond to $e^{3}value$ value activities. Description. This guideline is actually a refinement of guideline G3. Rather than considering a full lane, now the focus is on a subset of BMPN 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^{3}value$, the relation is often n-to-one. e.g., a combination of BPMN activities result into one $e^{3}value$ activity. Similarly, the condition of G3 applies

• G5. BPMN message flow may correspond to $e^{3}value$ value transfers Description. In BPMN, message flows between pools transfer ‘content of communication’ [6] (pg. 93). In $e^{3}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^{3}value$ Conditions. There are three conditions that should be satisfied for a correspondence.

  • 1. In $e^{3}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) [22]. For correspondence, the object transferred via a BMPN message flow in BPMN should qualify as an $e^{3}value$ value object in $e^{3}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., [3, 20]), 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. For example, 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^{3}value$ denotes the willingness of actors to transfer ownership [22]. 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^{3}value$ often cannot 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^{3}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^{3}value$ value interface. Description. By following the sequence flow, and the associated message flow(s), a value interface can be found. In $e^{3}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 ingoing 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^{3}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^{3}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^{3}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^{3}value$ dependency path. In $e^{3}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 lead5 to an $e^{3}value$ AND dependency. Description. By following the BPMN sequence flow, AND gateways can be encountered. In $e^{3}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^{3}value$ path is executed.

• G11. BPMN XOR gateways may correspond to $e^{3}value$ OR dependencies. Description. By following the BPMN sequence flow, XOR gateways can be encountered. In $e^{3}value$, the OR dependency has similar semantics as the XOR gateway in BPMN. In $e^{3}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^{3}value$ AND/OR dependencies. Description. By following the BPMN sequence flow, OR gateways can be encountered. In $e^{3}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^{3}value$ model. This should be solved by having an explicit OR and XOR dependency element in $e^{3}value$, which is subject of further research. Conditions. See guideline G10.

• G13. BPMN loops may correspond to $e^{3}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^{3}value$ model however is an acyclic directed graph, e.g., it may not contain loops. Consequently, repetition in BPMN cannot be mapped in $e^{3}value$ directly. However, $e^{3}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.

5.2 Treatment: trading of financial securities

Based on a BPMN model (Fig. 3), we derive an $e^{3}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). There were always three participants (two males and a female) during the interviews. Two of these were from the Payment and Market infrastructure division of the DNB, and the other from the IT department. All of them with more than 10 years of experience on their domain. The construction of the BPMN model is outside the scope of the treatment and is done via a normal knowledge acquisition process.

Fig. 3

BPMN model of securities trading

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. CCP 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^{3}value$ model by applying solely the guidelines (see Sect.  5.1) until they could not be used anymore. The resulting $e^{3}value$ model is in Fig. 4(a).

• 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 cannot find additional value activities.

• 4. According to G1, the start event ‘Request to buy/sell securities’ represents a consumer need in the $e^{3}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.

We also built the $e^{3}value$ model, called normative model here (Fig. 4(b)), following the usual $e^{3}value$ elicitation process (i.e., talking to stakeholders, considering neither the BPMN model nor the guidelines). To avoid as much bias as possible, an author who had not previously worked on either validating the BPMN model or generating the guideline-based $e^{3}value$ model was selected to work on this step. The normative model was validated by DNB experts. This model is briefly explained as follows. There are two ‘Investors’ market segments with the following consumer needs: ‘Buy securities’ (‘Buyers’) and ‘Sell securities’ (‘Sellers’). Both ‘Investors’ market segments use ‘Brokers’ for ‘Trading’ service, as well as optionally a ‘Custodian’ (‘Bank’) to check their valuables in real time (optionality is not represented in the model). ‘Trading’ is submitted to ‘Trading platforms’ that perform ‘Order matching’ from ‘Buyers’ and ‘Sellers.’ ‘Trading platforms’ are, e.g., multilateral trading facilities (MTF), Exchange, etc. ‘Clearing’ is carried out by the CCP as protection against defaulting ‘Buyers’ or ‘Sellers.’ ‘Settlement’ is carried out by the Central Security Depository (CSD) to make the trading executable.

Fig. 4

$e^{3}value$ models derived by using the guidelines and a normal elicitation process

5.3 Treatment evaluation

5.3.1 Observations extracted from the case

We then perform a differential analysis by comparing both $e^{3}value$ models with each other, i.e., the one generated by the guidelines (Fig. 4(a)) and the one generated from talking to the stakeholders (Fig. 4(b)), from which we observe the following:

• 1. In Fig. 4, the ‘Clearing House’ actor (Fig. 4(a)) in reality are two parties: CCP and CSD (Fig. 4(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^{3}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^{3}value$.

• 5. Both $e^{3}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.

Revisiting our research questions, we have presented and used guidelines to derive an $e^{3}value$ model from a BPMN model (RQ1). The model constructed using the normal $e^{3}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 researchers 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).

6 The single-case experiment

To answer the research questions RQ3 and RQ4, we execute a single-case experiment [24]. In brief, we offer test subjects the guidelines and a business process model in BPMN 2.0 as input, and ask the subjects to construct a corresponding and valid $e^{3}value$ model (RQ3) and to learn from the results (RQ4).

6.1 Experiment protocol

This research approach comprises the following protocol:

• 1. Selection of test subjects. We have selected two experts who both are knowledgeable on both BPMN 2.0 and $e^{3}value$. In follow-up research, we (a) will select more test subjects and (b) execute pre-tests on the subjects to measure their knowledge concerning BPMN 2.0 and $e^{3}value$. The two selected test subjects for this experiment are coming from our personal contact network, and we are confident that both experts have sufficient knowledge on both methods to use the guidelines meaningfully. One test subject is from Brazil, professor in Information Systems at Universidade São Paulo (USP), with more than 10 years of experience in Business and Process Modeling. The other is a fourth-year PhD Candidate from the Kybele Research Group of Rey Juan Carlos University of Madrid, with 5 years of experience in Model Driven Engineering (MDE) techniques applied to business and process modeling.

• 2. Selection of the case. The experiment requires a BPMN 2.0 model of a specific case / problem domain. We selected here the case on international Intellectual Property Rights (IPR) clearing, because we know this domain extensively (see, e.g., [3]), and we have an ongoing relationship with a Dutch IPR society. It is important to stress that the two test subjects are not knowledgeable on this domain and also not have/had contact with the IPR society.

• 3. Construction of the BPMN 2.0 model for the case at hand. In cooperation with the IPR society, and based on [3], we construct a BPMN 2.0 process model for the case at hand. The resulting BPMN model is validated with the IPR society for descriptive validity. Note: Construction of the business process model is outside the scope of our guidelines, but the model serves as input for the $e^{3}value$ model derivation and will be used by the test subjects.

• 4. Construction of the normative $e^{3}value$ model. In order to evaluate the results produced by the test subjects, by applying the guidelines, we construct a normative $e^{3}value$ model ourselves, in close cooperation with the IPR society. Most of this model is based on earlier work [3] and adapted to reflect recent changes in the environment of the IPR society. Again, this $e^{3}value$ model is validated with the IPR society for descriptive validity. Also, this $e^{3}value$ model is constructed by a normal elicitation process, so not by using the proposed guidelines, and therefore not part of the guidelines-driven $e^{3}value$ model construction task.

• 5. Thinking aloud experiments with the test subjects. With two test subjects, we execute thinking aloud experiments. The subjects receive the guidelines, which are briefly explained, Also, the subjects are given the input BPMN 2.0 model of the IPR case. Then, the subjects use the guidelines to derive the corresponding model, and while doing so verbally tell what they think and do, which is recorded by us for further analysis. As said, the subjects have no upfront knowledge about the case at hand and cannot ask questions.

• 6. Differential analysis of the resulting $e^{3}value$ models with the $e^{3}value$ normative model. First, we compare and analyze the $e^{3}value$ models constructed by the test subjects with the normative $e^{3}value$ model we constructed ourselves for deviations (see 4.). We use our knowledge of the case study domain to analyze whether the deviations in relation to the normative model are descriptively (in)valid. The purpose of this analysis is to find out to what extent our guidelines can produce a valid $e^{3}value$ model, to find new guidelines (by looking for missing parts in the models constructed by the test subjects, and by considering elements in the constructing models, which are not present in our normative $e^{3}value$ model). Second, we execute a differential analysis by comparing the two models constructed by the test subjects, to understand why the same guidelines may still result in different models constructed by the test subjects. This may be useful to improve the formulation of our guidelines to prevent ambiguous interpretation. The recordings of the thinking aloud sessions help us to understand how the guidelines are interpreted and applied.

• 7. Improvement of the guidelines. Part of the experiment is to do reflective learning and to improve the guidelines.

6.2 Construction of the BPMN 2.0 model

We briefly summarize the BPMN 2.0 model in Fig. 5. This model is constructed by us using a normal (e.g., interviews) requirements elicitation process. The model is used as input for our guidelines-supported design process for $e^{3}value$ model and supposed to exist before applying the guidelines. Construction of this BPMN 2.0 model itself therefore is out of scope of our guidelines-supported design process.

Fig. 5

BPMN 2.0 process model of IPR using normal elicitation process

The process can start from three different ways: (1) when a new music track is released by its owner; (2) when there is a need for music usage information; and (3) when a playlist is needed. (1) When a new track is released the IPR Society NL has to register the Right To Make Public (RTMP) (the specific right cleared by the IPR society). If the new track originates abroad, IPR Society NL has to acquire the RTMP from the foreign country, which has its own registration process; if not, the process continues by allocating money, payed by the IPR user (e.g., a restaurant), to the track, based on available playlists, and waits for payment. Meanwhile, the RTMP is delivered to the IPR users who play the music . All the payments are processed via the Bank. (2) IPR Society NL also needs statistical information to monitor the usage of music in the Netherlands. For that purpose, the Market Research company receives a request and is paid accordingly for providing that service. (3) Whenever a playlist is needed by TV/Radio stations, the Audio Recognition Agency is asked to provide this service.

6.3 Construction of the normative $e^{3}value$ model

We then construct the normative $e^{3}value$ model, (Fig. 6), using the normal $e^{3}value$ elicitation process, so without taking the BPMN 2.0 model and the guidelines into consideration. It serves as a means to compare the $e^{3}value$ models created by test subjects with. The normative $e^{3}value$ model is a valid model, validated by the IPR society. The model was constructed before the BPMN 2.0 process we developed and hence also before the guidelines were applied. Most of the model is based on earlier work in [3].

Fig. 6

$e^{3}value$ model derived using normal elicitation process

As show by the model in Fig. 6, the IPR Society NL transfers value objects to/from the following six actors: (1) the IPR user, (2) the Audio Recognition Agency (Radio/TV stations), (3) the Market Research company, (4) the IPR Sister Society, (5) IPR owner (Artist and/or Producer), and (6) the Bank. Note that the Bank is modeled three times and the Audio Recognition Agency two times in Fig. 7 because of pragmatic quality reasons (structured layout).

IPR user – There are multiple users (restaurants, museums, etc.) that play background music in the Netherlands. Therefore, the IPR user actor is modeled as a market segment. A Restaurant, for example, has to clear IPR for the background music played in public. To do so, the Restaurant pays a certain amount of money to the IPR Society. In return the Restaurant receives the RTMP. Note that the IPR Society NL clearing activity does not exchange value objects (payment service and money) with the Bank. The Restaurant pays money to the IPR Society NL, thus the Restaurant has to pay the Bank for the payment service. The music stream for the background music in the Restaurant is obtained by a background music provider, but for the sake of simplicity this actor is omitted in the value model. Between the clearing and the distribution activities money and the RTMP value objects are transferred. The clearing activity gives the collected money, obtained from the Restaurant, to the distribution activity.

IPR Sister Society – In addition, the IPR Society NL might obtain money from the IPR Sister Society for the international use of music. The IPR Society NL provides the RTMP on behalf of the Dutch Artists and Producers in return. There are a number of IPR Sister Societies, hence the actor is modeled as a market segment. The IPR Sister Society provides the RTMP on behalf of the IPR owners abroad as well. The IPR Society NL transfers the collected money from the IPR users in return. This payment is done per transaction via a Bank. Thus, the IPR Society pays a transaction fee to the Bank for the payment service. The IPR Sister Society divides the obtained money between the IPR owners abroad. We assume that the international distribution works the same way as the national distribution, though not modeled.

IPR owners (Artist and/or Producer) – Furthermore, the distribution activity divides the collected money over the IPR owners, in particular the Artist and the Producer. Both actors are modeled as market segments since there are numerous Dutch artists and producers. The money is divided between x artists and y producers. For the actual payment per transaction, the Bank provides a payment service. Besides the payment to the IPR owners, the IPR Society NL pays the Bank a transaction fee also.

Audio Recognition Agency and Market Research company – In order to properly divide the collected money over the right holders, the IPR Society NL requires play lists from, e.g., Radio Stations. The play lists show the number of times a music track has been played, thus which national IPR owners, Dutch Artists and Producers, or IPR owners abroad need to be paid. As there are multiple radio stations, the Radio station actor is denoted by a market segment. The Audio Recognition Agency is responsible to concentrate the playlist service requests from the IPR Society NL, of course the IPR Society NL pays a fee for that service. Since, e.g., Radio Stations also makes music content public, therefore the Audio Recognition Agency is also responsible to centralize the requests for the RTMP. Moreover, a Market Research company provides information about the music usage once a year. With the aid of the music usage info, the IPR Society NL gains more insight into the played music tracks by the IPR users. In return the IPR Society NL pays money to the Market Research company via a Bank. To this end, the IPR Society NL is charged for the use of the payment service by the Bank.

6.4 Results

6.4.1 Resulting $e^{3}value$ models and thinking aloud results

We now execute our experiment: The BPMN 2.0 model in Fig. 5 and the guidelines in Table 1 are given to the two test subjects, and they are asked to develop a corresponding $e^{3}value$ with only the provided information. The subjects have no other information, and they do not know the case study domain. We asked them to think aloud, and we recorded the sessions.

The respective $e^{3}value$ models of both test subjects can be found in Fig. 7. The most important remarks of the test subjects are summarized and briefly analyzed below:

Test subject 1

• G2: ‘Maybe sometimes (without knowing the process logic) is not easy to distinguish if a pool should be an actor or a market segment. Specifically, I had doubts about Audio Recognition Agency.’– The subject refers to the market segment ‘Audio recognition agency’, which can be a radio or a TV station, according to the BPMN model. It should be practical to infer there could be more than one radio/TV station, which should consequently lead to the conclusion that it is a market segment and not an actor. The word ‘agency’ in the singular may have confused the expert. However, this is the usual pattern for BPMN models. In any case, we need to address this issue properly in the G2 to avoid similar issues.

• G4: ‘I understand that G4 is a necessary guideline, but maybe it could be misinterpret: someone would think there is a new value activity when another person would not. I didn’t find any value activity following this guideline.’– We ascertain from this feedback there may be overlapping information in G3 and G4, as both deal with the derivation of value activities. The possibility of merging both guidelines should be analyzed.

• G5, G6, and G7: ‘If we discover a value transfer, don’t we immediately also have the correspondent value interface and value offerings? I believe they are associated.’ – It is important to remember that message flows in BPMN may or may not contain value transfer. In the first case, you can have the value object. However, message flows act as information couriers (something is delivered and nothing is returned). If there is no reciprocal value exchange, it should not be considered and therefore would not result in a value interface.

• G10, G11, and G12: ‘I tried to understand the conditions to transform gateways, but they are not that clear to me. Better explanation and examples would be essential.’ – The guidelines should make it easier and not create more burden on the modeler. Conditional description would benefit from practical examples showing how to do the derivation.

• General Comments: ‘The guidelines set is complete, meticulous, and useful. I think that many of the rules could even be implemented for semi-automatic transformations (assisted by the user). However, the main concern is that you need to understand the BPMN 2.0 process logic to follow the guidelines, which would of course make it difficult for a complete automation. Another idea would be some kind of training so that the users would follow, in a more strict way, the guidelines. It would be good to have some small examples step-by-step. Finally, I think it could be better to order the guidelines following a logical process: current G2 (actors and market segments) as the first guideline, current G3 and G4 (value activities) as the second guideline, then current G1 (customer needs and boundary elements), G5 and G6 (value transfers), and so on. This would be more practical and teachable.’

Fig. 7

$e^{3}value$ models derived using the guidelines by Subject 1 (a) and Subject 2 (b)

Test subject 2

• G1: ‘I felt a lack of information on this guideline. The decision on whether the elements would derive into boundary or customer needs was a bit confusing (i.e., the relation is n-to-n). The example helped, but it was way harder in practice. The subjectivity on this guideline was higher than expected. For the pools that were black-boxes on the BPMN 2.0 model, it was difficult to ascertain if they would have or not customer needs and boundary elements.’ – The lack of information about BPMN negatively affects the derivation process, which is expected, since BPMN is used as input. The guidelines should address how to proceed when black boxes are found.

• G2: ‘The order of the guidelines should be exchanged. One can only start putting other elements in the model after having Actor(s) and/or Market segment(s). Thus, G2 should become the first guideline, and then, following a logical sequence also for the other guidelines, G2 should be followed by G3 and G4 (the second and third guidelines, respectively), and then G1.’ – Reordering for practical perspectives makes sense and augments clearness.

• G3 and G4: ‘I had a lot of trouble trying to fully understand in the BPMN 2.0 whether or not the activity(ies) or lanes would deliver value. First, because BPMN 2.0 is not responsible for showing value, and second, because a group of activities in BPMN 2.0 may be present in different lanes. In that case, which part would the value activity address in the derived $e^{3}value$ model?’ – The guidelines should make it easier and not create more burden on the modeler. Conditional description would benefit from practical examples showing how to do the derivation.

• G5, G6, G7, G8, and G9: ‘The issue here was mainly that, in BPMN 2.0, an entity rarely needs to pay back for something that was delivered to it by another entity. However, by shifting this mindset to a more service-oriented process model (i.e., assuming the message flow acts as providing a service to another pool), a payment for that service will logically have to be made. This is implicit in those BPMN 2.0 to $e^{3}value$ mapping guidelines, but I believe this should actually generate another guideline (i.e., a more generic guideline).’ – The idea of having a service-oriented perspective when analyzing the BPMN model is entirely useful for deriving the $e^{3}value$ model. We should evaluate separating the guidelines into different layers/clusters.

• G10, G11, G12, and G13: ‘This guideline was easy to follow. However, I had to be careful when selecting which gateways would be present in the derived model and which would not. The conditions must also apply to the other variety of gateways that exist in BPMN 2.0.’ –This is object for further discussion. The focus should be first on the most basic elements of BPMN.

• General Comments: ‘The guidelines followed a practical and logical path, which makes them more teachable and understandable. There were some guidelines that I had to put a lot of effort into to fully understand their meaning (e.g., G1 and G7). The conditions for the guidelines should be further explained. Visual examples for each guideline would provide much more assistance to the modeler (especially those with conditions).’

Higher-level analysis

The thinking aloud method helped us observing the following:

• The ontological differences between these two modeling notations make it difficult to measure the completeness of the proposed guidelines.

• BPMN models with ‘black boxes,’ i.e., pools without any information inside them, should not be taken as input to the derivation process for $e^{3}value$ models.

• Non-expert modelers would have difficulty using the guidelines; this must be resolved before further applications.

• The high-level of subjectivity of some guidelines (e.g., G10, G11, and G12) should be reduced for a more accurate derivation.

6.4.2 Differential analysis

We then compared both $e^{3}value$ models (Fig. 7(a) and Fig. 7(b)) with the normative $e^{3}value$ model (i.e., created using the normal elicitation process – Fig. 6), and we observed the following:

Test subject 1 vs. normative $e^{3}value$ model

• 1. Both models had the same actor(s) and market segment(s) names. This may show that G2 is not only complete but also accurately self-explained for the derivation. There were differences in the number of times some actors and market segments were illustrated, however it was more of a pragmatic design choice than a derivation problem when going from BPMN 2.0 to $e^{3}value$ model and the guidelines itself.

• 2. The subject 1 model’s representation of customer needs and boundary elements were quite similar when compared to the normative $e^{3}value$ model, with some differences on the labels. The main difference was inside the market segment IPR Sister Society, since the normative model describes when a foreign country needs the RTMP from a track that orginates in NL. The model derived from the guidelines did not take this into account. Also, inside the IPR User market segment, there is a boundary element where in the normative model we have a customer need. That may incur that G1 lacks some extra information, or since the BPMN model had IPR Sister Society and IPR User as a black-box, the subject had difficulties deriving from it (check Test subject 2 G1 analysis).

• 3. Both models have the same value activities designed, which may imply that G3 is well elaborated. The main value transfers (which correspond to G7, G8, and G9) were like the ones in the normative model. The only differences were the value transfers that occur between the value activities (distribution and clearing) inside IPR Society NL. This is not a significant problem, since it is implicit that value activities inside the same actor should correlate somehow.

• 4. The model shows some differences in AND/OR dependencies. These differences seem much more related to the design style adopted by the modelers than guideline-related. For example, instead of illustrating an AND dependency inside the clearing value activity, the subject used three consumer needs. Aside from that peculiarities, there were no major mistakes caused by guidelines G10, G11, G12, and G13.

Test subject 2 vs. normative $e^{3}value$ model

• 1. Actors and market segments were almost the same in these models. For better illustration, some market segments on the normative model were repeated. Even the labels given were similar, which gives G2 a good overall evaluation.

• 2. There are some differences in customer needs and boundary elements from one model to the other. There is again an error when describing IPR Sister Society customer need and boundary elements. The modeler represented a customer need with a boundary element. This implies that G1 has to be reviewed in order to remove what seems to be an ambiguity in its description.

• 3. The derived $e^{3}value$ model from the guidelines showed an extra value activity – New Track Release – inside the market segment – IPR Owner. It has to be evaluated if this was actually a misguidance of the guidelines, or if the author thought that the collection of activities in the BPMN 2.0 model would provide this derivation.

• 4. There are no major differences between the value transfers between the models. There was a lack of completeness on the model derived by the guidelines, which shows a lack of completeness on G5, G6, G7, G8, and G9.

• 5. There were quite some differences in the AND/OR dependency paths from the models. The subject associated only one AND-dependency for the entire model. This has to be investigated since the process model did not lack of gateways, which shows a flaw on the guidelines (G10, G11, G12, and G13) that should be investigated.

Test subject 1 vs. Test Subject 2 $e^{3}value$ model

Since both models were derived using the same set of guidelines, and the same BPMN 2.0 model, it is interesting how both models created by the experts differ themselves. The major difference between both models is the addition of the value activity – New Track Release – in one of the models. A better explanation and examples on how to execute G3 and G4 should mitigate this problem. In general, the guidelines that deal with the derivation of value activities and AND/OR dependencies should be better specified. Graphic examples would mitigate the subjective misinterpretation pattern found in the experiment. Despite some differences between the models, we can agree that the guidelines were consistent enough to derive an almost similar $e^{3}value$ model from a BPMN 2.0 model.

6.4.3 Reflection and learning

In this section, we summarize what we have learned from the application of our research in terms of design principles for our guidelines, which will serve as knowledge to apply in other similar research projects. Overall, the guidelines allowed to derive quite good and consistent $e^{3}value$ models. However, looking into the test subjects’ comments and our differential analysis, we can raise some relevant improvements for our set of guidelines.

• Graphical examples explaining step-by-step how each guideline works would mitigate subjectivity and ambiguous thinking.

• Separating between generic and more specific guidelines would add a granularity perspective that would help the modeler.

• The guidelines should be reordered since G2 is actually the starting point in practice.

• There needs to be guideline(s) that assist in finding the service-oriented and economic reciprocity principle of $e^{3}value$ models.

• Guidelines (G10, G11, G12, and G13) have to be reworked or better explained. Description is too generic and conditions too complex to follow.

• Some guidelines seem to be candidate for semi-automated derivation of $e^{3}value$ fragments based on BPMN 2.0 models.

7 Conclusion

Revisiting our research questions, we have presented and used guidelines to derive an $e^{3}value$ model from a BPMN model (RQ1). The model constructed using the normal $e^{3}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 researchers 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). We have also derived a valid $e^{3}value$ model from a BPMN model (RQ3), and improved the guidelines to do so (RQ4). The models constructed using the normal $e^{3}value$ elicitation process show only a few differences from the developed by the test subjects using only the guidelines e.g. the AND/OR dependency paths. Using a single-case experiment, on experts that had no previous knowledge of the domain, had a positive impact on the outcome. The contrast between the models generated improvement points which shall be implemented on subsequent research.

7.1 Limitations

The differential analysis had some limitations: Both the $e^{3}value$ model as derived by the guidelines and the normative $e^{3}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^{3}value$ model which may influence the application of the guidelines to find the $e^{3}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^{3}value$ model and the construction of the $e^{3}value$ model based on the guidelines by using a separate group of persons applying the guidelines. Moreover, we anticipate to repeat the experiment with a larger set of test subjects. Our research also followed a single-case experiment in order to answer our research questions. We anticipate to repeat the experiment with a larger set of test subjects. Another point is the selected subjects (experts). The guidelines were specially designed to help experienced modelers when redesigning complex ecosystems, which limits extending them (at least for now) to non-experts. Also, although we did have confirmation of their expertise in business and process modeling using the before-mentioned languages (BPMN 2.0 and $e^{3}value$ model) in practice, it would be better for upcoming research to test their knowledge in modeling beforehand, which allows us to analyze the results in the context of their real expertise. Another limitation is that our experiment did not consider the time and cognitive load needed of the test subjects, which could be an indicator for the practicability and usefulness of the method in the real-world setting.

7.2 Future work

As future work, we plan in the short term to follow two main lines:

• Refining the proposed guidelines mainly considering the feedback received from the subjects who participated in the experiments reported in this article. In addition, producing practical examples that show the mapping from BPMN elements to $e^{3}value$ elements for each guideline to reduce complexity.

• Extending the experiments performed with new cases as well as extra subjects, including possibly non-experts, using the refined guidelines.

In the medium term, we intend to propose guidelines for the inverse path, i.e., to derive BPMN models from $e^{3}value$ models. Our goal is to present a full set of guidelines that can be used for mapping between the two notations, in both directions. Finally, in the long term, we intend to work on semi-automating these guidelines. We intend to propose a computational support mechanism that can help experts in this work.