Over the past few years, we have encountered a number of times the need to express communities in business value models. We loosely define the notion of 'community' as a set of actors who share goals and are organized in, often an informal, structure. Other definitions of 'community' include 'a group of people with diverse characteristics who are linked by social ties, share common perspectives, and engage in joint action in geographical locations or settings' [7] or 'the gathering of vertices into groups such that there is a higher density of edges within groups than between them' [2] Examples we have seen in our research are: (1) ICT for development (ICT4D): a remote village that offers craft work and home stay to the outside world, (2) open source software development, and (3) block chain applications for a limited set of actors that share the same goals (e.g. doing business in an environmentally friendly way).
All these examples have in common that the community itself has interesting properties to model. In the case of ICT4D (see e.g. [6]), a remote village as a whole offers service to the outside world, because the inhabitants could never do that alone. In other words, they bundle forces. Open source developments participants often share a website or other artifact that offers services for collaboration and for downloading source and binary code (e.g. a github project). In block chain applications, there is the notion of 'the network' that does things on behalf of the participating parties. For example, the Bitcoin network itself has certain rules of engagement, including about how money is generated (the so-called mining), and therefore should be considered as a (virtual) actor.
What do we want to express in a business value model about communities? Based on the three examples mentioned earlier we should at least be capable to represent that:
1. actors do value transfers with the community (e.g. a group of actors) rather than with an individual; 2. the actors who are part of a community; 3. how financial effects of the community break down into the participating actors according to a selection of rules (e.g. distribute revenue evenly).
The e 3 value ontology [5] provides three constructs for modeling stakeholders in a business value model, namely: (1) the actor : an economically and often legally independent entity, (2) the market segment: a set of actors for which each actor is supposed to assign economic value in the same way, and (3) the composite actor : an actor (or market segment) for who individual value interfaces are grouped into larger ones. The composite actor construct is used to model that two or more actors offer products or services jointly as a bundle, for example an electricity supplier and a company who distributes electricity. Jointly, they provide electricity to the end-user.
The 'actor' concept models precisely one entity. A possibility could be to use a single actor as a community (e.g. a village), and model all participants as separate actors, each having value transfers with actor representing the community. From a modeling perspective, this is not very practical, since this requires explicit modeling of many similar actors, and thus does not scale up.
At first sight, the 'market segment' models multiple actors, and could potentially be useful to represent communities. However, the semantics of a 'market segment' means that if 'value objects' are transfered with a market segment, one of the actors in the segment is chosen to trade with. In contrast, in case of a community, we want to say that we want to transfer 'value objects' with the community as a whole. Therefore, the market segment is not really suited to model the notion of 'community.
Finally, actor composition currently only has the semantics that two or more actors are offering a complex service and/or product jointly, each focusing on their own core competence. These cooperating actors could be somehow be considered as a community. However, there is subtle yet important difference between several actors (the 'composite actor') offering together a set of complex products and/or services, also known as a bundle, and a single entity (the 'community') that offers a whole one or more products and/or services to the environment. For example, if we take just the simple example that a community offers just one product (e.g. for money), this cannot be modeled by the 'composite actor' construct, as the construct requires the bundling of at least two services and/or products from different actors.
Therefore, in this paper, we propose a new construct, called the Group, with set operators to model the (implicit) actors in the group. One of the use cases for the 'Group' construct is to model communities.
This paper is structured as follows. In Sec. 2, we introduce a case study in the field of ICT4D, called the Mali Milk service. This is one of the cases we encountered the need for modeling a community. Sec. 3 presents a few attempts to model the Mali Milk case with the existing set of e 3 value constructs. As it turns out, each solution has some drawbacks, Sec. 4 proposes a new e 3 value model construct, namely the 'Group', to model communities. Finally, Sec. 5 presents key points and suggestions for further research.
The Tominian Mali Milk service or m-Milk service [4] is a voice based milk selling and farmer networking platform for Tominian Mali. The Tomanian milk producers in Mali have two important problems. The first is a lack of channels for facilitating buying and selling of milk, while the second is overproduction of milk during a rainy season and underproduction during a dry season. The first problem results in farmers having to sell milk from door to door whereas the second problem leads to wastage of overproduced milk and expensive import of milk during scarce production. One way of solving the two problems is by having a dairy co-operative [3], in which all farmers are represented, and which collects milk from farmers, pasteurize the collected milk and sell it in the market accordingly. Pasteurizing the milk delays spoiling by four days approximately. Yet loopholes in the co-operatives such as lack of prompt milk collection and unreliable communication still loom over the success of the Co-operative.
The m-Milk service is a platform which facilitates communication between local milk producers and potential buyers.This e-service platform enables the farmer to call in the platform and leave a message about the milk available. The potential buyers can call in and retrieve messages from the farmers along with contact information of the farmer with milk for sale. Further, in an already existing co-operative, the platform can be used to encourage more farmers to join the Co-operative and facilitating efficient collection and selling of the milk. In addition, in areas where there are no co-operatives, the farmers can communicate among themselves and organize pooling of milk and transport to a diary producer.
The technology at place for providing communication between the farmers and the potential buyers is a device called KasaDaka [1] along with a GSM/ GPRS dongle. It is a low-cost Raspberry Pi based system which has a low electricity consumption. Therefore, it is suitable in a ICT4D context. In order to make the application able to receive calls, a dongle with a telephone SIM card is inserted. The m-Milk service is compatible with the rural landscape of Mali and requires the farmers and the buyers to have a basic mobile phone to call in to the KasaDaka. The farmers can record their messages by calling into the KasaDaka and the buyers can retrieve the messages in the same way. The KasaDaka could be hosted by the Co-operative or by a farmer who does so for the Co-operative.
Two alternative e 3 value models are constructed to represent the m-Milk service. The first alternative models the Co-operative as a formal actor. This Cooperative also hosts the Kasadaka, and therefore the e-service. In the second alternative, the collaboration between farmers is considered as an informal organization, and therefore not considered as a formal e 3 value actor. The Kasadaka is hosted at a farmer. The e 3 value model. Fig. 1 presents the e 3 value model for the m-Milk service hosted at the Co-operative. The dairy Co-operative hosts the KasaDaka system and offers the m-Milk service to the farmers and the potential buyers in return for increased sales. The farmers are encouraged to call in to the KasaDaka device to share their information regarding the availability of milk. By providing the service for free to the farmers and the buyers, the Co-operative aims to involve more farmers to sell their milk and more buyers to buy the milk from the Co-operative which would result in increased sales for the Co-operative. Since the KasaDaka is hosted at the Co-operative, the operational costs such as electricity is covered by the Co-operative (not modeled explicitly). The farmers and the buyers pay the mobile phone provider for making calls to the application (KasaDaka). The farmers record their calls with date and availability of milk. The buyers call the KasaDaka to listen to the calls of the farmers. Finally, the platform supplier offers the KasaDaka hardware in exchange for money.
Reflection. Does Fig. 1 model the case adequately? The co-operative is considered as a formal e 3 value actor, e.g. an actor who is profit-and-less responsible and/or who is a legal entity. In some cases, this can be precisely the situation. However, in many other cases in which communities play an important role, communities are loosely coupled structures, e.g. without having any legal status. In such a case, the actor construct would not be rightful. Secondly, the model does not say that all farmers form the Co-operative. Apart from the fact this can not be seen from the model, this also has implications for e.g. the calculation of net value sheets. For example, a rule could be that at end of each year, the earned money by the Co-operative is divided over the farmers. This can not be represented in the current model. To show why a Co-operative cannot be modeled as a market segment, consider Fig. 2. The group of farmers is modeled here as a market segment on purpose. One or more farmers hosts the device at their place in exchange of money.
The hosting party (one or more farmers within the group) pays the maintenance cost such as electricity. The group of farmers pay for the device itself, and for the maintenance cost to the hosting farmer(s). The need annotated #1 shows that a farmer who wants the m-Milk service (in return for increased sales on the long term) has to obtain the service from the Farmer market segment, which represents the Co-operation. Similarly, the farmer sells milk to the market segment (see #2).
Reflection. The model in Fig. 2 has a number of problems. First, 'selling to the market segment' means in e 3 value that one actor of the market segment is chosen (e 3 value does not state which specific actor is chosen; only that one actor is chosen). So effectively, the path annotated with #1 represents that a farmer is providing the m-Milk service to another actor. The same holds for path #2; here the milk is not sold to all farmers, but just one specific actor. Second, paths #1 and #2 may result in a cycle. Recall that formally, each e 3 value model is an a-cyclic directed graph. For example, path #2 may represent that a farmer sells milk to him/herself. This is meaningless. Remember that value transfers to and from market segment represent that a (random) actor in the market segment is chosen to exchange value object with. Cycles are forbidden in e 3 value because (1) they are meaningless (it makes no sense to sell something to yourself), and (2) in practice are often indications of fraud.
What we need is a specific construct to model a group. We define a group as a set of actors who share goals and is visualized as in Fig. 3. 2 which wrongly shows the m-Milk platform using the market segment, is redesigned in Fig. 4 with the new group concept. The main difference is that there is now a group of farmers, who cooperate. Value transfers are always with the group, and not with a single actor in the group. Here, the group buys milk from individual farmers, hence 'farmer' is modeled as a market segment. One of the farmer acts as party for hosting the Kasadaka device. This farmer offers the hosting service also to the group of farmers as a whole.
The revised models is an a-cyclic directed graph again, and therefore complies with one of the modeling rules in e 3 value . However, we still have to represent that the farmers in a community are also in a market segment. To this purpose, we introduce a new concept called set operator. It captures the relationship between the two actor sets (e.g. a group and and a market segment). We use set operators such as subset, superset, union and intersection for relationships between a group and a market segment, between two groups, or between two market segments. For instance, in Fig. 4, the group of cooperating farmers is a subset of the market segment containing all farmers, thereby modeling that not all farmers have to participate in the cooperation. Also, two or more different farmer groups might unite to work together, hence an union operator is required to represent the union of the two different groups. Therefore, the concept of subset, superset, union and intersection has been introduced. The symbols corresponding to the set operators are represented in figure 5. In case of subset or superset, the set operator has a right actor set and a left actor set. In case of union, the set operator has a right actor set and a left actor set which results in the formation of a new actor set. Key points. In this paper, a new modeling construct, namely the emphgroup, has been proposed as an extension to the existing e 3 value methodology. The difference between the group and the related construct market segment, is that the 'group' models value transfers with a group of actors as a whole, whereas transfers with a market segment result in the selection of a particular (random) actor in the segment, therefore ultimately leading to transfers with one actor in that segment. Additionally, we added set operations between groups, market segments, and groups and market segments, to represent that actors participate in (sub)sets of actors, either being groups or market segments.
Future work. An important feature of the e 3 value modeling technique is net value flow calculation. We have not studied the effect of the group concept on the net value flow calculation algorithm yet. For now, we assumed that everyone in the group gets an equal share which is unlikely in real world scenarios. In addition, further research is needed how to model the internal structure of the group. For instance, in the Milk service case, most likely an internal structure can be discovered