# The Machine-to-Everything (M2X) Economy: Business Enactments, Collaborations, and e-Goverance
## 3 Enactment, Collaboration, and e-Governance
### 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.  
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 business-network model (BNM) [32] to specify choreographies relevant for a respective business scenario.The BNM defines legally valid [33; 34; 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  
Figure 3: Distributed M2X governance infrastructure. Source: [1] and based on [23; 27].  
a consensus, we assume the What-interrogative employs matching process views that require cross-organizational alignment for monitorability\" [23].