The reference model for distributed market spaces is designed and developed to serve as a framework to structure the analysis, design, and implementation of distributed market spaces as self-organized and decentralized online structures to facilitate the emergence of the post-platform economy.
4.1. Phase Model of Market Transactions for Complex Products
The phase model of market transactions for complex products defines the necessary interactions between market participants, consumers, and providers engaged in transactions of complex products. Hence, it lays the ground for lowering transaction costs for consumers looking for transactions of products over DMS.
The proposed phase model enhances the existing market transaction model as used in MRM [10
]. The extensions refer to
As a result, the phase model of market transactions for complex products encompasses five phases: Knowledge, Intention, Contract, Settlement, and Follow-Up.
Each of these phases represents a group of activities by involved participants, and each of them has a defined output or a phase result. Figure 4
presents the proposed phase model and summarizes the results of each of the five phases, as described in the following.
In the Knowledge phase, market participants acquire an overview of the supply and demand in a distributed market space. Providers publish their offers by publishing descriptions of the products and services they offer. Consumers formulate their demands as complex product requests and, based on that search for potential providers that can provide parts of the required complex product. Consequently, the knowledge phase ends with a product/service description and a formulated complex product request accompanied by a list of possible transaction partners.
In the Intention phase, market participants negotiate conditions for an agreement for the particular complex product. It covers the process of sending “Requests for Offer” (RfO) to the potential transaction partners (consumer), and providers send back particular offerings in a way including the price tag, payment mode, and delivery conditions. Consumers then aggregate all received offerings, and create complex product proposals, which they rank based on the defined requirements and constraints. Consumers might then select one complex product proposal, which best suits their demands. The chosen complex product proposal (consumer side) and offerings (provider side) represent the phase results. They are the starting point for the next phase and form the basis for the contractual agreement to be made.
In the Contract phase, consumers and provides substantiate the negotiated agreement represented by a legally binding contract. From the consumer side, a complex product contract is considered an umbrella contract since it incorporates different arrangements for different parts of the complex product. The umbrella contract represents a one-to-many contract situation and requires consumer’s involvement in several contractual processes (one for each product or service). On the provider side, the contracting process is regarded as a one-to-one contract situation with an additional activity regarding the confirmation of a pending contract. The phase ends with an agreed legally binding complex product contract, which is the starting point for the settlement phase.
The Settlement phase serves to fulfill the obligations resulting from the complex product contract agreed in the contract phase. Similarly to individual products and services, the settlement phase of complex products encompasses interaction processes related to delivery, payment, and logistics. Depending on the type of the exchanged product or service as well as the involved providers, the settlement phase might include additional sub-processes related to the type of settlement, which will be detailed in the following.
The Follow-Up phase completes the market transaction for complex products. As the fifth phase, follow-up supports interactions between transaction partners that happen after the settlement. These are interactions and activities related to reviews of settled transactions, customer support, management of return and refund as well as management of disputes among transaction partners.
The proposed phase model of market transactions for complex products is elaborated on in more detail in Section 4.3
. In this section, the inner workings of each phase, their processes, and related activities are detailed and presented in the context of the interaction view of a reference DMS.
4.2. Ecosystem View
The ecosystem view maps the ecosystem structure of a reference DMS. The Ecosystem Model blueprints the proposed ecosystem structure by outlining the primary activities, actors and their roles, and how actors and activities need to link and align in order to support the shared purpose of the DMS ecosystem.
Ecosystems are economic communities supported by am underlying interacting organizations and individuals [35
] that use common standards and collectively provide goods and services [36
]. As such, ecosystems consist of numerous loosely interconnected actors who create value through the process of streichen and competition [37
]. This explicit dependence of involved actors who rely on one another is considered the essential feature of ecosystems that distinguishes them from other interconnected environments, e.g., value networks or value chains.
As organizational models, ecosystems are defined by two primary characteristics: Firstly by how value is created, and secondly by how it is shared in order to satisfy the individual and collective motivation of actors participating in the ecosystem [37
]. Consequently, ecosystem models are considered constructs composed of entities and elements required to specify how value is created and shared among participating actors.
Literature provides various approaches and concepts in order to formalize ecosystem models e.g., BEAM [38
], MOBENA [41
], 6c [39
], VISOR [40
], Value Design [42
], and Ecosystem Construct [43
]. Even though each of these modeling approaches has its initial focus, they address ecosystem modeling from different perspectives [43
Ecosystem-as-affiliation: views ecosystems as communities of associated actors defined by their network affiliation and as a complement to a focal actor [38
Ecosystem-as-structure: views ecosystems as alignment structures of activities and actors defined by a shared value proposition, rather than being an affiliate of a focal actor [42
For the modeling of an ecosystem for a reference DMS, the ecosystem-as-structure perspective applies, and consequently, the modeling approach by [43
] concerns. The rationale lays in the definition and requirements of a reference DMS. As a self-organized and governed structure of actors with equal rights and responsibilities, the DMS ecosystem needs to organize in a way to allow the shared value proposition to realize in a decentralized manner. As there is no focal actor, this requires that actors align following an agreement on how value is created and shared within the ecosystem they constitute. Such an alignment, thus, refers not only to shared motivation and incentives as the case with ecosystems-as-affiliation but also requires actors’ consistent engagement. As will be discussed below, part of consistent engagement is the commitment to take different roles and provide resources and services to uphold the ecosystem.
presents the resulting Ecosystem Model
for the reference DMS. Value proposition
defines the shared purpose of the DMS ecosystem and is formulated as an end-user enabled ecosystem for the market exchange of complex products directly and reliably
. The following are the core underlying elements of the stated value proposition:
Activities –defining the primary activity groups and discrete actions to be undertaken.
Actors–specifying the entities that undertake these activities, taking different roles.
Positions–specifying where in the flow of activities actors are located.
Links–specifying how actors taking different roles need to interact and what value they need to exchange.
Core elements mutually depend on each other and together describe how value is expected to be created and shared within the ecosystem. Hence, they conceptualize a decentralized environment of interdependent collaboration that is the organizational structure of the DMS ecosystem underlying the stated value proposition.
There are three primary activity groups that the DMS ecosystem needs to support to realize the stated value proposition:
Demand and Supply
The demand and supply activity group defines activities related to the composition and description of complex product requests on the consumer side (i.e., demand) and the description and publishing of products and services on the provider side (i.e., supply).
The market transaction activity group defines activities to support the phase model of market transactions for complex products. As previously described, these are activities necessary to support interaction processes in each of the phases of negotiation, contracting, settlement, and follow-up of complex products.
The ecosystem foundation activity group defines activities to build the foundation, essential for setting up and operating the ecosystem. It includes forming and running the network by providing resources and services (e.g., hosting, tools) and domain knowledge necessary for the market exchange in a specific domain (e.g., domain ontologies and vocabularies for that particular domain).
Actors and Roles
Actors in the DMS ecosystem can be everyone or everything connected to the Internet intending to engage in complex product scenarios. That includes individuals, companies, institutions or associations, and other networks, as well as autonomous actors such as software agents or machines. As shown in Figure 5
, there are at least eight roles that actors can take:
Consumer and Provider are considered shaper roles as they shape the value proposition and, thus, the birth of the DMS ecosystem. The other roles (Technology Provider, Knowledge Provider, Steward, Expert, Mediator, and Reputation Bank) are enabler roles. Their purpose is to enable the ecosystem to provide comprehensive services to the shaper roles. Therefore the primary function of enabler roles is to enable the ecosystem’s value creation by undertaking activities as mentioned above.
Roles are motivated by two sides: on the one hand side, they are motivated by shared purpose in order to realize the ecosystems’ value proposition, and on the other side, they are driven by individual motivation. Shared motivation designates the commitment to be a constitutive part of the ecosystem’s alignment structure and the continuous engagement in order for the ecosystem to uphold. Individual motivation refers to the additional value an actor expects from the participation in the DMS ecosystem. Such an expected value might differ from role to role, be subject to various actor types, and even change over different life stages of the DMS. Even though each of the roles has different functions and is responsible for different activities, roles can overlap and be assumed concurrently, as they do not exclude each other. For example, a consumer (shaper role) can also take the role of, e.g., technology provider, or an expert (enabler role) at the same time. Table 1
summarizes the abovementioned roles describing their functions and stipulating possible individual motivation or expected value from the participation in the DMS ecosystem.
In order for the stated value proposition to realize, the definition of the necessary activities and the identification of actors who need to undertake these activities as well as the assignment of roles are necessary, but not sufficient. In order to create value, the ecosystem’s actors in their different roles need to align around the activities and take a particular position in the overall value creation. Positions, as illustrated in Figure 5
, provide an overview of where in the flow of activities the identified actors need to be located. Single roles can contribute to several activities, and specific activities might require several roles to engage. For example, in order to support consumers in formulating demand, that is, composing complex products as arbitrary combinations of individual products and services, several roles need yo be engaged. Besides the consumer who initiates the process, the technology and knowledge provider are required to provide tools and knowledge to enable the composition of complex products and the integration of the contextual information. Depending on the complexity and level of personalization, the composition of the complex products might also involve further roles. In the example, experts might support composing the required product/service combination, and the reputation bank might provide information about the reputation and worthiness of the possible providers. In that way, enabler roles are supporting consumers proceeding in a more targeted manner, narrowing the selection of the potential providers at the beginning of the market transaction, already contributing to a lowering of transaction costs.
Links illustrate how actors taking different roles need to interact and specifies the transfer between them. Figure 5
visualizes links in the form of a flow diagram, which outlines the overall pattern of exchanges within the DMS ecosystem. The focus lies on shaper roles, both for consumer and provider, and the visualization of the most important interactions with enabler roles and resulting exchanges.
The nodes represent actors performing a particular role and the arrows the essential interactions indicating the ”value exchanged” between these roles. Solid lines denote the ”tangible” exchanges such as product/service delivery or payment as is the case with consumer and provider role (see Figure 5
). Dashed lines indicate additional exchanged value that is considered ”intangible” like for example, feedback, reputation, or usage-related data. Regarding the interaction between shaper roles, this might be the contextual information a provider might receive from a consumer requesting an individual product or service. Such additional information is considered valuable as it can be used to increase the contextualization of offerings, and thus, enables the provider to provide in the consumer context. Vice-versa, a consumer, can get personalized bundles of a product or service that best fits his demand based on the provided contextual information. Links explicate the overall value exchange within the DMS ecosystem necessary to realize its proposition and, thus, the shared motivation of the named roles. Further, links consider the content of transfers required to satisfy the individual motivation of role, i.e., the expected value from the participation in the DMS ecosystem (cf. Table 1
). Note that Figure 5
presents only the most essential exchanges among the named roles.
4.3. Interaction View
The interaction view specifies the core interactions required for market transactions of complex products via a reference DMS. The purpose of the resulting Interaction Process Model is to define the critical processes between shaper roles (consumers and providers) structured around the phase model of market transactions for complex products.
shows a high-level overview of the proposed process model. It presents the core interaction processes between a consumer looking for a complex product, and a provider (or many of them) engaged in the market transaction for that particular complex product. It summarizes the necessary processes for each phase and the resulting information objects, explicating their relationships and locations inside each of the phases of the market transaction model (cf. Figure 4
). The high-level overview and all related sub-processes are modeled and described using the Business Process Model Notation (BPMN 2.0 [44
As indicated in Figure 6
, the high-level interaction process starts with the demand for a particular complex product on the consumer side and the idea for a concrete product or service on the provider side. The prerequisite for participation in the process is DMS membership. DMS memberships are represented by Member cards
, which are the basis for all further process steps.
For consumers (see upper lane), these are process-steps, which enable formulating demand (Complex product request) and acquiring an overview of potential providers who might satisfy such demand (Provider list). For the providers (bottom lane), these are the process steps that provide for a description and registration of offerings (Product/service registration). The resulting information objects (Complex product request/Provider list) enable consumers to reach potential providers and thus start the interaction processes of the following phases:
The interaction processes in the intention phase are characterized by several iterations between consumers and potential providers required to negotiate a preliminary agreement. Consumers initiate the negotiation processes and run them as long as at least one proposal is created (Complex product proposal) fitted to satisfy the requested consumer’s demand.
The interaction processes related to the contract phase, are defined by interactions necessary for creating and confirming a legally-binding contract (Complex product contract) based on the preliminary agreement. As with the intention phase, the interactions are initiated by consumers leading the process of creating an umbrella contract based on confirmations received from the involved providers and ordering.
The interaction processes in the settlement phase are characterized by interactions required for the fulfillment of the legally-binding contract agreed in the previous phase. These fulfillment-related processes generate the transaction data, and together with data generated in previous phases, they build a transactional dataset (Transaction record). The generated transaction records serve as the basis for all subsequent processes that might occur during the follow-up phase. Moreover, these are records of the institutional history that are considered essential for building trust and reliability among the DMS as a self-organized exchange environment.
After overviewing the interaction process model at a higher level, the following sections provide more detailed descriptions of individual phase-related processes.
4.3.1. Knowledge Phase
Three main processes define the knowledge phase. As indicated in Figure 6
, these are processes that enable:
Becoming a member and joining the DMS ecosystem (all roles)
Describing and registering offerings (provider role)
Formulating complex product requests and matching with potential providers (consumer role)
Unlike exchange environments with a centrally provided infrastructure, the DMS ecosystem is an open and self-organized environment of different actors taking different roles. In such self-organized networks, each member is at the same time the contributor of the underlying infrastructure and participant in an exchange market built upon this infrastructure. Therefore, the first step for further members is to register and share in which role (or roles) they intend to contribute to the ecosystem.
shows the process of joining and becoming a member of the DMS ecosystem. The process starts with requesting access, as indicated in the upper lane. The access represents an entry-point or link that enables initial interactions with the DMS (e.g., a website or link for download of required DMS User Interface). Such access requests are processed by technology providers, as indicated in the middle lane. Technology providers are actors whose primary responsibility is to provide software/hardware resources necessary for establishing and the functioning of the ecosystem. After receiving DMS access, new actors request membership by sending membership requests, which are received by stewards. Stewards (i.e., actors responsible for the governance-related tasks) decide based on the defined rules and standards and existing entries in the institutional history. The institutional history of the DMS ecosystem represents a shared record of all registered members, their roles and relevant events, and transaction-related data. Together with rules and standards, it is an instrument for decentralized governance of a self-organized network and forms the foundation for building governance services necessary for the growth and sustainability of the DMS ecosystem. Section 4.4.2
describes these services in more detail.
The membership request can either be denied or approved. The latter creates member cards (with unique identifiers) and sends them back to the requestors making an entry in the institutional history. After receiving member cards, new actors can sign-up to the DMS, and register for different roles. Depending on the chosen role (or roles), the sign-up process might encompass further interactions with technology providers, e.g., access to other tools or services.
After joining the DMS, members taking the provider role, start the process by describing their offerings as shown in Figure 8
. Offerings, structured product/service descriptions, as well as a short description of providers themselves (e.g., name, address, settlement modalities, or ratings), are registered in a distributed product catalog. The distributed product catalog follows the same principle as the DMS institutional history. It serves as an instrument for publishing offerings in a trusted network of actors rather than in a mediated product catalog as is the case with centrally orchestrated solutions.
On the other side, members taking the consumer role, start the process by formulating their demand. As shown in Figure 9
, consumers are enabled to create complex product requests and match them with potential providers. The matching is done based on the data stored in the distributed product catalog. In case there are no matching results (i.e., no providers who can offer product/service combination), consumers need to modify their requests or leave the process. Otherwise, when matching results exist, a provider list is generated. The generated provider list contains all necessary data required for the addressing of identified providers and starting interaction processes related to the following intention phase.
4.3.2. Intention Phase
After formulating demand and acquiring an overview of potential providers, consumers are enabled to initiate the intention phase. As shown in Figure 10
, consumers start the process by addressing identified providers and sending them requests for offers (RfO). RfOs are requests for offers for individual parts of the complex product sent to providers. By sending RfOs, consumers signalize their intention to engage in commercial exchanges with the addressed providers. The addressed providers, on the other side, indicate their intention to provide for a particular product or service by answering RfOs and sending back concrete offerings (see Figure 10
, bottom lane).
Complex products might get arbitrarily complex and include different product/service combinations. As a result, providers for each of the demanded products or services need to be addressed to obtain offerings for each of them. The related activities (i.e., requesting offerings on the consumer side and creating and sending offerings on the provider side) comprise many interactions, which might undergo multiple iterations. Such interactions might be repeated until enough offers are obtained and assessed; hence, enough viable offerings can be collected.
Collected offerings enable consumers to create complex product proposals and rank them based on their requirements and preferences. As a result, a best-fit list is created to support consumer’s decision making. In case there are no viable complex proposals, consumers might go back to the beginning and start another negotiation process undergoing the activities of sending modified RfOs and waiting for providers’ responses. Alternatively, and in case there are viable proposals, they might choose one to proceed. The negotiating process between involved parties ends with a preliminary agreement on a selected proposal for a particular complex product.
4.3.3. Contract Phase
After accepting viable complex product proposals, consumers are enabled to enter into contrectual agreements with the involved providers and to conclude legally binding contracts.
shows the process of concluding a complex product contract. From the consumer side, a complex product contract is considered an umbrella contract since it might incorporate different arrangements for different parts. Such an umbrella contract represents a one-to-many contract situation. It requires the consumer’s involvement in multiple contractual processes, one for each of the requested products or services, the aim of which being to enter into a contractual agreement with all involved providers (counterparts) for all required products or services.
The process of setting up an umbrella contract is two-staged; with stage one being considered provider-confirmed and stage two consumer-confirmed. In the provider-confirmed stage, a pending contract for each of the required product or service is created and sent to the involved providers for confirmation. Only if all addressed providers confirm all pending contracts, the second confirmation stage can start. The consumer-confirmed stage begins with placing orders for provider-confirmed (pending) contracts and receiving order confirmations. After all order confirmations are received, an umbrella contract is created to fix all confirmations.
The supporting activities for the two-stage confirmation process of a complex product contract range from creating pending contracts, sending them to providers, collecting confirmations, and finally placing orders (see the upper lane in Figure 11
). On the provider side, the activities related to contracting are slightly different and considerably more straightforward. That is because the contracting process on the provider side is considered a one-to-one contract situation with an additional activity that includes the confirmation of pending contracts as the prerequisite for the final order confirmation. The setting up process ends with a legally binding complex product contract. As with all legally binding contracts, it is mandatory for all counterparts and entails all terms and conditions required for its settlement and enforcement.
4.3.4. Settlement Phase
After setting up the contractual agreement for complex products, transactional parties are enabled to fulfill obligations resulting from this contractual agreement. These are payments on the consumer side and deliveries of ordered products and services on the provider side. Such settlement processes are well researched and understood (see [26
]). The main issue with settlement processes between transaction partners who do not know each other is the lack of trust that each of them will fulfill the contractual agreement. Centralized models compensate for such trust issues via centrally organized settlement processes and by doing so, position themselves as the trusted intermediary.
Against this background and depending on the expected level of trust, we propose three different approaches regarding the settlement of complex products:
A trusted settlement assumes an adequate level of trust among transaction partners within a reference DMS. That might be the case in situations where consumers know and trust their providers, or they are involved in complex product scenarios perceived as a low-risk scenario. The settlement of standardized products and services from a low-mid price segment offered by established providers is usually perceived less risky, as is the case with personalized products and services from the premium segment.
illustrates the process of fulfilling a complex product contract by applying the trusted settlement approach. On the consumer side, the process starts with payment for each product and service and sending payment notification to each of the involved providers. After the receipt of payment, the process on the provider side starts with returning the receipt of payment followed by the delivery of the order. On the consumer side, the process continues with waiting for the delivery of all orders. In case of delays or other unexpected events, consumers might ask for compensation or alternatively initiate their complaint management. In all other cases, the consumption starts after the delivery of all orders, and the whole process ends with creating a transaction record and an entry for the institutional history.
Trusted third-party settlement assumes engaging a third party trusted to be capable of ensuring safe contract fulfillment (i.e., payment and delivery according to the contractual agreement). In the DMS ecosystem, trusted third parties might come from the ecosystem’s participants taking the mediator or expert roles as described in Section 1.3. Mediators or experts may be involved in the settlement process and support consumers and providers to fulfill obligations defined by the agreed contract. This approach is considered suitable for the settlement of product/service combinations from a higher price segment and higher complexity regarding the coordination and management of payment and delivery activities.
shows the process of fulfilling a complex product contract by applying the trusted third-party settlement approach. It summarizes the collaboration of involved consumers and providers with a mediator as the trusted party. The main activities of the involved mediator (see middle lane) are to coordinate the payment process according to the agreed terms and conditions. The coordination process starts with the payment on the consumer side as the signal of the willingness to pay for the order. After receiving the payment notification from the mediator, providers deliver ordered products and services (i.e., provide access to them). Following the delivery notification from the consumer side, the mediator transfers payment to the providers and hence closes the payment transactions for the entire complex product. The settlement process ends with the sharing of the created transaction record.
The trustless settlement
approach builds on the concept of smart contracts. Smart contracts are automatable and enforceable contractual agreements, which could be implemented as immutable computer programs to run on a broader range of technology platforms, including distributed ledger platforms, e.g., Etherum [47
] and Fabric [48
]. Smart contracts are ”trustless” since they refer to a ”piece of computer code”. They execute the terms of a contract and by doing so, minimize the need for trust between transaction counterparts or the need for a trusted third party [49
]. By using smart contracts, the contractual clauses (i.e., terms and conditions) and interactions between transaction parties are translated into code and are transparent and self-enforced. In case any party deviates from the contractual agreement, the following actions, e.g., payment and penalty, are known and automatically enforced by the smart contract. Even though smart contracts and distributed ledger technology are still in their early stages [50
], the trustless approach seems promising for the settlement of complex products in particular, e.g., the Internet of Things (IoT) scenarios. IoT scenarios incorporate predominately digital products and services and require many different and partly heterogeneous providers (e.g.,autonomous agents and machines) for the ordering of the complex product to be realized.
illustrates a simplified process of trustless contract settlement based on smart contracts. As indicated, transaction partners (consumers and providers) first need to generate the smart contract code that entails the terms and execution logic for the legally binding complex product contract. After all involved partners agree with the generated code, it is deployed in the underlying blockchain waiting to be triggered by the consumer. Once the smart contract is initiated, it executes itself. As a result of the process, a transaction record is created and shared with the involved parties.
4.3.5. Follow-Up Phase
The processes of the follow-up phase close the market transaction for complex products. As indicated in Figure 6
it encompasses processes to enable:
processes for complex products are considered the same as for individual products and services. These are processes that enable transaction partners to review settled transactions to extend their relationship by offering additional activities such as, e.g., customer support, as well as to handle return and refund [26
]. Reviewing settled transactions primarely related to the involved parties providing reviewers (two-side reviewers). Moreover, the reviewing process might entail the sharing of experiences with other ecosystem participants as well as the sharing of transactional data. Based on that, reviews are used to support decision making considering market transactions, but also as an indication of the ecosystem’s ability to support market transactions. For a detailed description of the afore-mentioned after-sales processes, see [25
The dispute resolution
process is required to enable DMS participants to settle potential disputes. A dispute is considered a form of a conflict in which one party makes a claim (called filer), and the other party rejects that claim (called respondent) [52
]. In recent years, diverse Online Dispute Resolution (ODR [53
]) approaches were developed following, in general, the same process. Accordingly, an online dispute resolution process must allow disputants to choose an adjudicator, i.e., a mediator, who is capable of resolving such issues. The mediator, on the other hand, is required to be as neutral as possible and to contribute to the dispute resolution in an efficient and swift manner.
Following these recommendations, Figure 15
presents an exemplary process for dispute resolution within a DMS ecosystem. It illustrates relevant interactions between disputants (a filer and respondent) and a mediator who intervenes to resolve the dispute in place. In disputes related to complex products, the filer is normally the consumer, and the respondent is usually the provider. The mediator is a DMS participant taking the role of an expert or mediator (cf. Section 4.2
). The dispute resolution starts with the recognition of a dispute and the willingness of the filer and the respondent to appoint a mediator. After choosing a trusted mediator, the actual resolution process starts with the request for mediation by the involved parties. After accepting the mediation mandate, the mediator organizes hearing sessions to collect statements pertaining to the dispute by all parties involved, followed by the process of identifying and negotiating viable options. As a result, a binding resolution agreement is proposed by the mediator and in the best case agreed by disputants. The process ends with the wrapping-up of mediation records and their sharing with disputants.
In concluding, it can be noted that after-sales processes are predominately related to the follow-up phase. However, they also might take place as a parallel process in other phases, as well as intersect several phases. In particular, this is the case with sharing transactional data, which can be involved in different activities and as part of various process steps. The next section discusses the abovementioned processes in the context of services considered necessary for their implementation in a reference DMS.
4.5. Infrastructure View
The Infrastructure view outlines the technical infrastructure of a reference DMS necessary for the implementation of the previously defined service stack (cf. Section 4.4
). The technical infrastructure hence represents an underlying information system that implements the foundational, governance, and specialized services, and thus supports a reference DMS on the operational level.
An information system required to support a reference DMS as a self-organized and strictly decentralized market-oriented environment needs to follow the same design principle since the system design should primarily relate to its function or purpose. According to this “form follows function” principle, the underlying information system has to employ distributed resources in order to implement the DMS service stack in a decentralized manner. Therefore, the primary concern of the required system is to support actors not only as market participants (taking part in a decentralized, i.e., peer-to-peer market and its mechanism) but also as the constitutive parts, which actively contribute to these mechanisms.
In our early work [8
], we introduced the Architecture for Distributed Market Spaces. It was purposely designed and developed to serve as a possible implementation of the infrastructure view for a reference DMS. In the following, we provide a high-level overview and brief description of the proposed architecture, as depicted in Figure 17
can be everybody or everything connected to the Internet defined by the intention to participate in the ecosystem. Actors join the ecosystem by connecting to its underlying network, which is organized as a structured peer-to-peer network
. The primary responsibility of the underlying peer-to-peer network
is to enable direct communication and interactions among actors and thus to implement foundational services (cf. Section 4.4.1
). As a result of these direct connections, each actor makes a two-fold contribution to the DMS. Firstly, actors are constitutive parts of the system. They constitute the underlying Peer-to-Peer Network
and by doing so, facilitate the ecosystem to build on top of this network. Secondly, actors are users of the system, and they are taking different roles. As such, they contribute to the ecosystem’s organizational structure, but at the same time, they satisfy their motivation for participation within the ecosystem.
The DMS Node
is the representation of an actor within the DMS. It implements the functionality of governance (cf. Section 4.4.2
) and specialized services (cf. Section 4.4.3
). These are provided by the user application, which runs on each DMS node. The user application connects actors to the ecosystem and supports the actor’s activities related to different ecosystem roles, as well as to different steps of market transactions for complex products.
The distributed RDF store
represents an organized collection of information necessary for the functioning of the DMS. This is, on the other hand, information relevant for the upholding of the ecosystem’s organizational structure. On the other hand, this is domain-related information necessary for the market transactions in that particular domain. This information is encoded using RDF (Resource Definition Framework [58
]) and stored on connected DMS Nodes
by using the operations of the underlying Peer-to-Peer Network
. As a result, each DMS Node
provides resources for the distributed storage and hence stores a fragment of the global data storage. This provides inherent scalability, as an increasing number of DMS Nodes
automatically provide more resources in the underlying network.
The prototypical implementation of the architecture for distributed market spaces [8
] is used for the instantiation of a reference DMS as will be demonstrated in the case study in Section 5
4.6. Life Stages of Distributed Market Spaces
This section focuses on the third dimension of the reference model for distributed market spaces. The Life Stages Model represents that dimension and covers three stages a DMS might undergo during its lifecycle, i.e. Design, Ignition, and Maturity. It follows the principle of separation of concerns, where each of the life stages has different concerns and, therefore, different priorities, which in turn necessitate different activities in order to reach the threshold for the next stage.
presents the proposed life stages model for distributed market spaces and summarizes the concerns of each of the three stages, as described in the following. In addition, Table 2
, provides an overview of activities and tasks related to each of these stages, linking them to the ecosystem, interaction, service, and infrastructure view.
The priority of the design stage is to proof the design hypothesis via a prototypical implementation for an application context. Therefore, the primary concern is to blueprint, prototype, and launch an instance of the DMS that considers the contextual requirements of the particular application
. The blueprint is a conceptualization of a DMS instance that considers different modeling view on the one hand and integrates the application context on the other hand. As a result, a DMS blueprint comprises four extracted models, as indicated in Figure 18
. Together the extracted ecosystem model and its accompanied process, service, and infrastructure models shape the conceptual structure for the DMS instantiation in that particular application context. Some of the significant challenges
in this stage might be caused by a lack of understanding of the application context. However, modeling decisions may be based on wrong assumptions about the application context. The considerations from practitioners reference models analyzed in Section 3
suggest that the best way to start designing an online exchange environment is to focus on one single value proposition that is supported by one core interaction.
The priority of the ignition stage is to build the critical mass of participants in order to establish the DMS as a market-oriented environment. This network is, on the one hand, a network of participants (shaper and enabler roles), and on the other hand, a network which provides the necessary infrastructure since each of the DMS participants has a dual role. Given that, the primary concern is to build a critical mass and clear friction and bottlenecks
in order to ensure its functioning on the operational level. One of the main challenges
of this stage can be to ”miss momentum” after the launch, i.e. to miss the momentum for gaining the critical mass of participants (consumers and providers) and consequently establishing positive network effects. Various strategies exist to cope with this issue; they propose different approaches to attract new participants in order to make the market-oriented environment more valuable for further participants (e.g., strategies by [3
]). Another challenge
related to this stage may be to miss establishing an adequate level of trust within the ecosystem. Therefore, the emphasis in this stage needs to be on the implementation of services which contribute to the ecosystem’s ability to guard against misbehavior and outright fraud (i.e., governance services, cf. Section 4.4
The priority of the maturity stage is to preserve the ecosystem and ensure the ecosystem’s resistance and health. Resilience and health refer to the ecosystem’s capability to face and survive disruptions and to continue to be productive in creating value for all participants [59
]. Consequently, the primary concern is to retain the existing network
as the source of value creation and connect to other networks
to gain new value sources for development and growth. Once this process has been triggered and a critical mass reached, the main challenges
of the maturity stage can be to protect the achieved position. Defending its position includes responding to competitive threats, which may come from ”within” (e.g., envelopment attack) or ”outside” from other ecosystems (e.g., conglomerate or intermodal attacks) [60
]). Envelopment attacks usually come from participants who established themselves as influencers. For example, a provider who uses his influencer position to develop interconnected ecosystems and take away the network or at least part of it. Outside threats, on the other hand, point to the sharing of stable networks and the building of ”conglomerate ecosystems”. Alternatively, they point to a more radical approach aiming to eliminate the competitive ecosystems by taking them over, as is the case with intermodal attacks. However, mature ecosystems have different possibilities to react and defend such attacks. The business ecosystem health concept [61
] and the ”5E” approach [6
] provide an overview of strategies that are helpful in dealing with such challenges and preserve the ecosystem within the maturity stage.