This paper presents a novel approach to automatically generate e3value instance models, based on skeletal design techniques. The approach has three phases. While the rst two phases are related to the generation of a value activity network based on a given value skeleton, the third phase matches the elements of the value network with the capabilities of service providers. The main objective of our approach is to re-use a set of value skeletons for covering an industry sector from which more business cases may be generated. Finally, we validated our approach in a realistic case study.
Enterprises increasingly participate in networked value constellations [
In earlier work [
The contribution of this paper is to lift e3value to the industry level, e.g. to describe the music industry, rather than just a single business case, as e3value normally is used for. To do so we present e3value skeletons. One of the most important di erences between an e3value skeleton and a normal e3value business case model is that a business case contains named, speci c, enterprises who participate in the business case at hand, whereas a skeleton contains only the set of activities to be performed for a business case.
One of the purposes of an e3value skeleton is to easily generate many
variations of business cases, which can be presented to stakeholders for selection.
Moreover, since mass con guration of products is playing an important role
nowadays [
We refer to industry models as skeletons and to business case models as instances. By using skeletal design techniques (Sect. 2.2), we derive e3value instance models from a skeleton. For the music industry (case study description in Sect. 3), we have developed various e3value instance models to study variations of these models. Abstracted versions of these variations are captured in skeleton models (Sect. 4.2). By using user input (Sect. 4.1) and con guration data (Sect. 4.3), we generate e3value instance models (Sect. 5). Fig. 1 depicts this general idea. Finally, Sect. 6 presents conclusions and future work.
An e3value model depicts a network of enterprises creating, distributing, and
consuming objects of economic value [
The most important e3value constructs are as follows: Actors, such as a buyer
and seller, are economically independent entities (Fig. 2). Actors transfer value
objects (money, goods) by means of value transfers, which in turn connect value
ports. For value objects, some actor should be willing to pay, which is shown by
1 and not in HOW, this is the focus of a business process
a value interface. A value interface models the principle of economic reciprocity :
Only if you pay, you can obtain the goods and vice versa. Besides, actors perform
value activities, which create something of economic value. Finally, an e3value
model contains a dependency path, starting with a consumer need and ending
with a boundary element. Along the path are value transfers, value interfaces
and connection elements. The dependency path shows how many value transfers
are executed as a result of a consumer need. An elaborated formalisation of
e3value can be found in [
Since we want to generate value models by means of value skeletons, it is useful
to take into account con guration design theory. According to Motta, a con
guration design problem does not exhibit complex spatial requirements and all
possible solutions adhere to a common solution template [
Parametric design is described as the process of assigning values to design
parameters not only satisfying needs and constraints but also following an
optimization criterion [
To sum up, our approach considers that the target artifact is modeled as a set of elements and the solution implies generating elements based on a common solution template matching the given design requirements and constraints (Sect. 5). 3
In the music industry, Intellectual Property Rights (IPR) are an important concept. Neighboring rights are a kind of IPR, which have to be paid by users if they earn money by playing music, or in other words, if they make music public. Clearing such neighboring rights involves two steps: collecting fees from IPR users, i.e. radio stations, bars, discotheques and others, and distributing these fees to Right Owners, i.e. artists, song writers, producers. This process is usually performed by IPR societies and is called clearing tracks. One of the IPR societies designed to perform this activity in The Netherlands is SENA 3, our case study partner which is also one of our stakeholders.
Some results for modeling this case study have been already provided [
The e3value model depicted in Fig. 3 presents a pay-per-play solution for background music. In this e3value model, IPR users are the starting point, as they require to broadcast background music which is provided by background music providers (BMP). A BMP can provide background music in di erent ways, one of those is streaming (Value Transfer A). When providing streams, the BMP must pay to IPR Societies which collect fees related with making a stream available to the public (Value Transfer D-E). Here, the public refers to IPR users.
IPR users have to also pay IPR Societies, as they make public the music also to their customers. Although the BMP and IPR users pay to two IPR Societies, it does not mean they pay twice for the same thing. Paying BUMA/Stemra 4 is because of the right that the composers, publishers and lyricists hold (Value Transfer C), whereas paying SENA is related to the rights of the performing 2 Motta also mentions preferences, however at this stage they are not essential to nd an optimal solution. 3 (Dutch: Stichting ter Exploitatie van Naburige Rechten, English: Foundation for
Exploitation of Neighboring Rights) 4 BUMA is other IPR society, also working in The Netherlands artists and producers (Value Transfer B). Indeed, Value Transfers A-E are constraints imposed by law, since IPR societies are the responsable entitites for collecting fees on behalf of IPR owners.
Once IPR societies got IPR-user fees, they retain a small percentage of these fees and the next step is to repartition the rest of the fees among Right Owners (Value Transfer K-L). This set of Right Owners is mainly composed by Artists, Producers, Music Publishers, Composers and Lyricists. Whereas SENA only repartitions fees to Artists and Producers (Value Transfer F-G), BUMA/Stemra does the same for Publishers, Composers and Lyricists (Value Transfer H-J). Explosion Elements Due to the fact that tracks are usually performed by more than one artist, SENA must transfer the collected fees to each artist involved, consequently the value transfer F will occur more than one time per consumer need. In order to allow that SENA contacts more artists, an explosion element (EE #1) is added. Since the same holds for all the right owners, there are more explosion elements for each of them (EE #2 - EE #5). An explosion element models that the connected value transfers happen multiple times, rather than just once per dependency path execution.
In this scenario there are only two enterprises clearing tracks (SENA and BUMA). As we described before, market liberalization will require a more exible scheme to assign value activities to di erent enterprises, e.g. the activities \Collect Fees" and \Repartition Fees" can be performed by di erent actors rather than one actor. In order to address this problem we have generated and analyzed variations in which several enterprises can cover di erent value activities. We have used these variations to build a few e3value skeletons, however because of space restrictions just one of these skeletons is described in the next section. 4 4.1
For the con guration process, we assume that our consumer need is playing background music and that we can cover such a need by providing a stream. In addition, since the pay-per-play scenario must be analyzed, we also assume that our stream contains only one music track. So, the need boils down to a streamed track. 4.2
The purpose of a skeleton is to abstract the set of relationships that are involved in an e3value model. Later on, the instances of a skeleton will re ect a speci c business case. In our approach, an e3value skeleton implies three important features, which are described and explained by presenting our e3value skeleton(Fig. 5).
of value activities and not on actors or market segments. In fact, assigning performing actors to value activities is an important part of con guring an e3value instance model (see Sect. 5.4).
No Selection The main idea behind skeletons is that there should be an automatic process to instantiate speci c business models by lling the elements in such skeleton. Therefore, this process must skip selection procedures like choosing among di erent dependency paths or di erent actors, as is normally the case in e3value models. In e3value words it means that we do not use OR-forks in dependency paths nor market segments.
On the use of Explosion Elements Consider the value transfers F-J in Fig. 3, these value transfers involve the repartition of fees among right owners and look very similar. By using explosion elements, we can abstract these transfers as shown in Fig. 4.a. While generating an instance model, this abstraction can be expanded to cover as many value activities as needed. In this example, we assume that fees must be repartitioned among three right owners, hence three
AND-extension ports are needed, which later allow connection with three other value activities (Fig. 4.b).
In the same way, our e3value skeleton (Fig. 5) depicts abstracted versions of the value transfers B-E, K and L (Fig. 3), which are later instantiated into new transfers. How the instantiation process of the skeleton works is explained in Sect. 5.2. Finally, to facilitate reading, our skeleton also depicts short names for some value objects. In this way, RIGHT MP refer to the Right for Making Public a track, RIGHT CL is the Right to CoLlect fees, and RIGHT CT is the Right to Clear a Track. The same holds for MONEY MP, MONEY CL and MONEY CL. 4.3
The information about the environment in which the con guration process takes place is the last element to be speci ed before starting the con guration process. This environment, called con guration data, is composed of eight elements. The main relationships among these elements are depicted in Fig. 6.
Supply Chains The clearing process deals with ve types of suppliers: artists, producers, composers, lyricists and publishers. Most of the time suppliers bring about di erent dependency paths in which di erent value activities and value objects are involved. We refer to these paths as supply chains. As can be observed in Fig. 6, a supply chain consists of several activities, e.g. in our case study, activities like Streaming, Collecting Fees, Repartitioning Fees and Creating are needed to provide a track, i.e. supply a service. Actually, these are the same activities that appear in the skeleton.
Elementary Actors The elementary actors represent the set of service providers willing to participate in a business case. In this sense, an elementary actor has value interfaces to interact with other elementary actors.
Value Activities In the same way, value activities represent the set of activities that must be performed to cover a consumer need. Therefore value activities has value interfaces for transfering value objects. As de ned in Fig. 6 a value activity has a special relationship in which supply chains and elementary actors are involved. In fact, this relationship yields an aggregation class, the same is explained as follows.
Performed-in By using this class we want to express that elementary actors can only perform value activities related to speci c supply chains. As an example, SENA only take care of activities like Collecting and Repartitioning when they deal with artists and producers. BUMA does the same for the rest or right owners.
Value Interfaces A value interface is assigned-to either an elementary actor or a value activity but not both at the same time, which is depicted by using the XOR constraint. A value interface consists-of one or two value o erings, what the actor wants and expects.
Value O erings A value o ering represents what an actor o ers through value interfaces. Therefore a value o ering is in a value interface and consists-of values ports.
Value Ports By using value ports an actor either o ers or requests value objects. In addition a value port is only in one value o ering.
Value Objects Value objects represent the services or products that actors exchange to each other. For instance, according to our case study (Fig. 3), actors exchange value objects like RIGHT MP, RIGHT CL and RIGHT CT. 5
This process involves three phases. While the rst two phases are related to the generation of a value activity network based on a given value skeleton, the third phase matches the elements of the value network with a set of service providers. 5.1
Selecting an e3value skeleton
The rst step to build an e3value instance model is related to selecting an e3value
skeleton from which the generation process can start. In this way, the e3value
skeletons must be chosen according to a consumer need, playing background
music (see Sect. 4.1). At this point we manually select an e3value skeleton. For
a guideline how to perform a semi-automatic process see [
Once a consumer need is de ned and an e3value skeleton is chosen (in this case Fig. 5) , the generation process traverses this skeleton and produces an e3value activity instance network. Algorithm 1 performs this process generating this e3value activity instance network while traversing the skeleton based on a depthrst traversal method, where the consumer need and the boundary element are respectively the root and the leaf of the tree.
Algorithm 1 considers each element in the skeleton. If the considered element is not an explosion element, the element is simply copied into the value activity instance network. If however the element is an explosion element, Algorithm 2 is executed, which evaluates the explosion elements and determines the number of new AND-extension ports to be generated. Algorithm 1 Generating an e3value activity instance network. Explosion Parameters Each explosion element has a set of parameters. These parameters are e3 explosion, ce related actor and ce refers to vo. How these parameters work is explained in the Algorithm 2, and their e ect is illustrated in Fig. 7.
The parameter called e3 explosion controls whether the explosion element will be evaluated. As can be observed in Fig. 7, there exist two ways to evaluate the explosion element: 1. the explosion element will result in a number of parallel supply chains (See
Fig. 7a/b, i.e. ce related actor == F ALSE), 2. the explosion element will result in a number of actors (Fig. 7c/d, i.e.
ce related actor == T RU E). 5.3
We illustrate the case when a track, DE WAARHEID, is cleared on behalf of three artists and two producers, i.e. two supply chains: one for artists and the other one for producers. For readability we omit the composers, lyricists and publishers. Therefore, Algorithm 1 travers the skeleton (Fig. 5). Once Algorithm 1 nds an explosion element, Algorithm 2 is applied to determine the number of new AND-extension ports to be generated.
For instance, assume that our algorithm walks down following the value transfer related to STREAM/MONEY and nds the explosion element #2 (See Algorithm 2 Determine the number of new AND-extension ports if e3 explosion == T RU E then if ce related actor == F ALSE then value object = ce ref ers to vo N ew AN D E ports = Number of supply chains in which value object is involved else value object = current track GET current supply chain GET next value activity according to the skeleton EA = set of actors performing next value activity in supply chain and o ering value object
N ew AN D E ports = Number of actors in EA.
end if else
N ew AN D E ports = 1 end if Fig. 5). The evaluation of this explosion element takes place i.e. Fig. 7 .a and 7.b. This means that we have to count the number of supply chains, and we have to generate the appropriate number of AND-extension ports for that. Since our supply chains are artists and producers, and the RIGHT MP is involved in the artists and producers supply chains, two new AND-extension ports must be generated, as can be seen in Fig. 8, element #2.
We continue to traverse the skeleton (for the artists supply chain) and nd explosion element #3. This time, the evaluation is performed as in Fig. 7.c and 7.d. The number of new AND-extension ports depends on the number of elementary actors performing the Creating value activity in the artists supply chain and for the speci c track, i.e. three artists. The process of copying elements from the skeleton continues till reaching a boundary element. Fig. 8 depicts the nal e3value activity network, the numbering indicates the order in which element are instantiated.
After generating the e3value activity network the next phase assigns activities to service providers. In a naive-sequential way, Algorithm 3 describes this process. Algorithm 3 Assign activities to actors
As can be observed in Algorithm 3, there is a search to determine whether an elementary actor can perform a value activity in a speci c supply chain (by evaluating the performed-in association in Fig. 6). For instance, when assigning the value activity Collecting Fees (Fig. 8, number 8), the algorithm will search for an elementary actor that can perform this activity in the supply chain related to producers. As we already know, SENA is able to perform such as activity in that speci c supply chain, therefore the algorithm assigns this activity to SENA, as shown in Fig. 9. 5.5
The model in Fig. 9 represents the way in which a set of enterprises work together to cover a consumer need which is composed of two things: DE WAARHEID and the needed rights to make this track public.
As can be observed, the set of needed rights contains the rights from artists and producers. Consequently, the consumer must contact to enterprise(s) taking care of those rights, i.e. SENA. In the same way, since the stream provider is making public DE WAARHEID, it also needs to get the same rights. In order to get the rights from the set of right owners, SENA should also perform an activity related to repartitioning fees.
Furthermore, the activities related to repartitioning the fees contact the right owners associated to DE WAARHEID. The supply chain related to artists ends with three artists, whereas the supply chain of producers involves two right owners.
Finally, by applying the previous con guration approach, Sections 4 and 5, we have generated di erent e3value instance models for other tracks. In this way, we test that by just changing our con guration data i.e. actors, their value objects and the activities they perform, we can generate instance models re-using the same skeleton and applying our con guration process. Nevertheless, due to lack of space these instance models are not presented 5. 6
This paper has presented an approach to automatically generate e3value models, based on skeletal design techniques. One of the objectives of our approach is to re-use a set of value skeletons for covering an industry sector from which more business cases may be generated. Consequently, in order to explain the intended use of this approach we have also presented a case study.
By following the idea of skeletal design we have exempli ed how re-use of knowledge can help to solve the problem of massive service con guration. Our e3value skeletons are useful to span (part of) an industry sector, helping to either automate current tasks or forecast/explore new scenarios.
Our next steps will address the problems related to elicitation of consumer needs,
selection of skeletons and assignment of value activities to service providers, i.e.
to add more exibility to Algorithm 3. Consequently, while the work of Sybren
de Kinderen [
Finally, even though our approach solve our con guration problem, we are aware of the limitations of this tool, mainly because some reasoning steps seems to be case speci c. Therefore, more validation must be done and another case study will be explored, related to the energy industry where more dynamic behavior can be found.
Acknowledgements. This paper has been partially funded by the NWO/Jacquard project VALUE-IT no 630.001.205 5 The reader can consult some instances at: http://www.few.vu.nl/ izapata/GeneratingVM-SDT.php