# Implementing Federated Governance in Data Mesh Architecture +
## 6 Contribution Discussion  
Based on the provided requirements in Section 3, in Table 1 we have summarized the level of the functional maturity of related platforms from the governance perspective.  
We see that no existing solution implements all the 11 requirements of the federated data mesh governance. As anticipated, almost all platforms have the data indexing and usage tracking modules, except the manual, web-form-based access control described in [9]. Indeed, these modules are built within any data platform architecture as they represent paramount importance in data management.  
Semantic enrichment is a more difficult task than indexing or user authorization, thus leading to lower implementation rates. While our prototype and some platforms [9; 10; 19] (an extended description of the Netflix platform was accessed at: [[https://netflixtechblog.com/data-movement-in-netflix-studio-via-data-mesh-3](https://netflixtechblog.com/data-movement-in-netflix-studio-via-data-mesh-3) fddceeb1059]([https://netflixtechblog.com/data-movement-in-netflix-studio-via-data-mesh-3](https://netflixtechblog.com/data-movement-in-netflix-studio-via-data-mesh-3) fddceeb1059)(accessed on 16 February 2024)) use the basic tag-based approach, the others use the advanced methods of knowledge graphs [13; 21] or cloud-offered services for data similarity computation and enrichment [11; 12]. This tendency is also reflected in the link generation aspect, where the most common technique is the lineage tracing of the data products, but some systems also provide the semantic relationship discovery and/or clustering options [11; 12; 13; 21].  
Unfortunately, very little information is provided on the versioning as part of the metadata management. Only our system enables metadata versioning based immutable ledger, while some research works [13; 21] briefly mention this important feature.  
It comes as no surprise that the polyglot data is represented only in the port-oriented data product models. This system design uses the input/output port connection abstraction in the first place and assumes the delivery of the identical product value by means of multiple channels (e.g., Message Queues, BLOBs).  
Our model also uses an input/output port connection approach, but unfortunately, the current level of integration with other platforms in Frybrik is very limited. The Frybrik platform is quite recent, and today it is integrated with a few data storage providers (e.g., AWS S3, MySQL, Postgres) and processing engines (Apache Arrow Flight).  
Even though modern companies adopt the responsibility of separations and containerization technology for ensuring the independent deployment of operational resources, it  
Figure 6: Data product quantum.  
is still an issue to bring this functionality to the governance tooling. Most systems either deploy it as a monolith module or it is under the management of a service provider. Since both parts of our system are based on Kubernetes, we are able to deploy any platform component independently--from computing nodes to smart policies.  
The implementation of the automated policies is conducted as part of the access control modules (e.g., authorization enforcement) while the more general notion of the computational policies is not available. In some works, the process of instantiation of the composable products is still limited to the schema extensions [19; 21].  
When evaluating our system, we see that it satisfies 9 out of 11 requirements, which is greater than any other system. The distinct features of our prototype include the support of data contract management and enforcement based on the blockchain platform and partial support of the automatic governance system testing. This testing may be performed either during the gradual smart contract upgrades or in the mirrored testing networks so that any breaking changes would be refused.