*3.2. Distributed e-Governance*

While Figure 2 presents the collaboration among partners from a lifecycle perspective, Figure 3 depicts the creation sequence of a DGI from an infrastructure perspective, thereby providing the foundation for a distributed, interoperable, dynamic ad-hoc enactment among heterogeneous M2X entities.

**Figure 3.** Distributed M2X governance infrastructure. Source: [1] and based on [23,27].

Finally, the M2X collaboration model enables providers to decide if and in which way changes to a private and internal process must be projected to a related public process view in a way where the process view and the internal process stay consistent with each other. Thus, the M2X collaboration model enables service-consumers to monitor a public process view to safely follow changes performed to a private and internal process.

This way, it is possible to support the evolution of smart contracts [28] as a significant means to achieve flexibility in B2B collaborations. As smart contracts are instrumental to enable decentralized autonomous organizations (DAO) [23] for the formation of electronic communities, service-oriented cloud computing (SOCC) [29] supports companies in the coordination of information- and business-process flows [30] for the choreography and orchestration [31] of heterogeneous legacy-system infrastructures.

For evolving DAO-collaborations, Figure 4a shows a conceptually collaboration configuration where the template for an electronic-community formation is given by a businessnetwork model (BNM) [32] to specify choreographies relevant for a respective business scenario.The BNM defines legally valid [33–35] template contracts as service types together with assigned organizational roles. A collaboration hub that houses business processes as a service (BPaaS-HUB) [36] in the form of process views [30], houses the BNM templates for potential collaborating counterparties to enable a speedy matching.

The external layer of Figure 4a depicts service offers to identically match the service types defined in the BNM with the respective collaborating partner contractual sphere. Furthermore, a collaborating partner is required to comply with a specific partner roles assigned to a specific service type. In [30], further details are contained about a tree-based process-view matching for creating DAO-configurations. We stress that Figure 4a uses Petri net [37] notation, which can be mapped into a tree-formalization as well with less computationally expensive strain.

Figure 4b presents a corresponding mapping and presents the top-level structure of a smart contract using the eSourcing Markup Language (eSML) [38]. "The core structure of a smart contract we organize according to the interrogatives *Who* for defining the contracting parties together with their resources and data definitions, *Where* to specify the business and legal context, and *What* for specifying the exchanged business values. For achieving

a consensus, we assume the What-interrogative employs matching process views that require cross-organizational alignment for monitorability" [23].

**Figure 4.** (**a**) P2P service matching and provision of the M2X ecosystem using the eSourcing framework–(Based on) [23]. (**b**) The eSourcing Markup Language (eSML) for specifying contractual collaborations–Based on [38].
